roninjin10

// .jjhub/workflows/bug-review.tsx
//
// InfiniteTokenBurnReview — parallel bug-hunting agents that loop until
// two consecutive rounds find nothing. Optionally fixes bugs inline.
//
// Usage (CI):
//   Triggered on landing request opened / ready-to-land
//   Also available via manual dispatch with fix-immediately toggle
//
import { z } from "zod";

roninjin10

#!/usr/bin/env bun
/**
 * JJHub Smithers Workflow — batch runner for Linear tickets.
 *
 * Usage:
 *   bun scripts/smithers.tsx --team JJH --backfill --all-open --batch
 *   bun scripts/smithers.tsx --team JJH --backfill --all-open --batch --limit 2 --concurrency 2
 *   bun scripts/smithers.tsx --team JJH --backfill --all-open --batch --limit 1 --dry-run
 *
 * Env:

roninjin10

#!/usr/bin/env bun
/**
 * JJHub Smithers Workflow — webhook listener and backfill runner for Linear.
 *
 * Modes:
 *   1. Webhook mode: process issues when the trigger label is added.
 *   2. Backfill mode: enqueue existing issues on startup.
 *   3. Batch mode: backfill and exit once the queue drains.
 *
 * Usage:

roninjin10

Work on Linear issue JJH-101:

<issue identifier="JJH-101">
<title>Migrate agent tasks + workspaces from GKE Sandbox to Freestyle VMs</title>
<description>
## Summary

Replace our GKE Sandbox (gVisor) runner pods and K8s workspace pods with [Freestyle](<https://freestyle.sh>) micro-VMs for agent tasks and workspaces. This eliminates \~1,500 lines of undifferentiated infrastructure (runner pool management, heartbeats, WebRTC signaling, PTY orchestration) in favor of Freestyle's managed VM lifecycle, built-in SSH/terminal access, and snapshot caching.

**Scope**: Agent tasks + Workspaces only. CI/workflow steps stay on the existing runner infrastructure.

roninjin10

title	description
Vision	How JJHub is building the code platform for agentic engineering teams

Autonomous development agents require us to rethink every part of how engineering teams get work done, from how we manage source control to how we execute our CI/CD pipelines. JJHub's goal is to provide engineering leaders a streamlined product to easily handhold them into this future.

Rethinking Version Control

Github has worked remarkably well. However, the absolute largest technology companies (like Google and Facebook) have long recognized that traditional Git cannot handle their massive volume of commits. They built custom, centralized version control systems (like Piper and Eden) specifically designed for extreme throughput.

roninjin10

Publicly Documented Internal Source Control and Issue Management at Google

Executive summary

Public sources describe Google’s internal software development environment as centered on a single, extremely large monolithic repository (“monorepo”) used by most engineers, backed by a custom centralized version control system called Piper and typically accessed through a cloud-backed workspace mechanism called Clients in the Cloud (CitC). citeturn12view0turn13view2turn14view1 This stack is explicitly optimized for trunk-based development: most work happens at “head” of a single mainline, with release branches cut from specific revisions and maintained via cherry-picks rather than parallel long-lived development. citeturn12view0turn25view0

Code review is described as mandatory for essentially all changes, and it is treated as the primary gate to submission. citeturn12view0turn18view1turn11view0 Modern publications and the book chapter on Critique describe Google’s in-house code review tool (Cri

roninjin10

Using skill-creator to generate the skill.

SKILL.md

---
name: filesystem-automation-scheduler
description: Schedule Codex desktop automations by editing the filesystem directly. Use when asked to create, update, or explain automations via automation.toml, RRULEs, or $CODEX_HOME/automations.
---

# Filesystem Automation Scheduler

roninjin10

Misty Browser — UI/UX Design Document

Status: Draft Last updated: 2026-02-02 Related: PRD, Engineering

---

Design pillars

roninjin10

Misty Browser — Engineering Design Document

Status: Draft (implementation-ready) Last updated: 2026-02-02 Audience: Core engineering (Bun backend, Astro/Solid main view, provider bridge, wallet/security) Scope: Desktop macOS (Electrobun + CEF), Base-first

Related: PRD, Design, Infra, Testing

---

roninjin10

Misty Browser for Base — Product Requirements Document

Status: Draft (v0.2) Owner: Product/Eng Last updated: 2026-02-02 Platforms: macOS (Electrobun) Default chain: Base mainnet (chainId 8453)

---