What It Does

Turns a ticket queue into a batch of draft pull requests while you sleep. You define the queue filters, set safety limits, and walk away. In the morning you have PRs ready for review.

The Pattern

The core loop is simple: pull a ticket, create an isolated workspace, implement it, verify it, open a draft PR, move to the next ticket.

Queue definition is the safety boundary. You pick a specific team, status, and optional label allowlist. The factory only touches tickets that match all filters. Start narrow.

Git worktrees prevent conflicts between tickets. Each ticket gets its own worktree and branch, so multiple implementations can happen without stepping on each other. The base branch is always freshly fetched before creating each worktree.

The execution loop per ticket:

1. Create a worktree from the latest base branch
2. Pass the ticket details to a coding agent with a self-contained prompt
3. The agent implements the change and runs verification commands
4. The runner (not the agent) does git add/commit/push and opens a draft PR
5. Optionally wait for CI to pass
6. Optionally run a read-only judge agent that decides PASS or FAIL
7. Move the ticket to the appropriate status based on the outcome

tmux wraps the whole thing so it survives terminal disconnects. You can tmux attach anytime to watch progress.

Key Decisions

Runner-owned PRs, not agent-owned. The coding agent never touches git directly. The runner script handles all git operations after the agent finishes. This prevents agents from making dangerous git mistakes.

Draft PRs only. The factory never merges anything. You review in the morning. This is a hard constraint, not a preference.

Completion promises. The agent must output a specific marker (like FINAL: DONE or FINAL: BLOCKED) to signal completion. The runner watches for this marker. No marker after max iterations means the ticket gets marked as blocked.

Optional judge gate. After the PR is created and CI passes, a separate read-only agent reviews the changes. Only if the judge returns PASS does the ticket move to the "done" status. This catches subtle issues that CI misses.

Multi-repo runs. Most real workloads span multiple repos. Run one factory loop per repo with disjoint label filters. Backend tickets go to the backend repo, website tickets go to the website repo. Keep the scopes clean.

When to Use It

• You have a queue of well-scoped tickets (clear requirements, single-repo scope)
• The tickets are implementation work, not architectural decisions
• You want to use overnight hours productively
• You have CI pipelines that catch regressions

Not suitable for tickets that require product decisions, cross-repo coordination, or ambiguous requirements.