Will Cory roninjin10

name	description
poc-research	Write proof-of-concept scripts to research external systems, test assumptions, and validate integration patterns. Use when exploring new APIs, SDK capabilities, infrastructure providers, or any external dependency. PoCs live in poc/ and their assertions graduate into the real test suite.

PoC Research

Write small, runnable proof-of-concept scripts that test assumptions about external systems. PoCs are throwaway code that validates integration patterns before building the real thing.

Directory Structure

JJHub Workspaces and Sandbox Specification

This document defines the product model for JJHub cloud workspaces, preview environments, and sandboxed execution. It covers the end-user experience across CLI, API, and web UI. Implementation details of the underlying VM platform are outside the scope of this spec.

1. Overview

JJHub workspaces are cloud development environments attached to repositories. Every bookmark in a repository can have an associated workspace. Workspaces are created lazily on first access and hibernate automatically when idle. They preserve full memory state across sessions so developers resume exactly where they left off.

Workspaces serve three product purposes:

interactive cloud development with terminal access

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.

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

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

Misty Browser — UI/UX Design Document

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

	// .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";

	#!/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:

	#!/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:

	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.