Install an autonomous Build, QA, Review loop into a practice repo, feed it cards on a GitHub Project board, watch the first wave and merge by hand. Twelve prompts from an empty folder to a readiness audit of your real project. The engine is super-board (MIT), renamed and adapted.
What you build
| Part | What it is | What it does |
|---|---|---|
| The practice repo | Harbor Lane Bookings, a small Node app with real tests on a private GitHub repo | Gives the factory something to pass before it ever touches code that matters. One deliberate gap is left for the first card to find. |
| The engine | Eight Claude Code skills, six guard hooks and a merge gate, installed into the repo's .claude folder | Blocks secret reads, deletes outside the project and pushes to main; merges only when the base plus your tests pass on the reviewed commit. |
| The board | A GitHub Project with seven columns and three labels, created by an eight-step onboarding wizard | Holds the state. Cards move Ready, Building, QA, Review, Done; a card that needs a person waits in Blocked with a note. |
| The lanes | Build, QA and Review, each in its own git worktree, graded and routed by a cheap model | Build opens a draft pull request, QA attaches evidence and screenshots, Review checks it and runs the gate. You watch from one status command. |
| The merge | Merge policy human for the whole lesson | Every pull request waits for you. You read the evidence, test the reviewed commit against main, and merge with the head pinned. |
| The readiness audit | One prompt run inside your real project, installing nothing | Tests, staging, deploy signals, secrets, migrations, conflicting rules. Ends in Go or Not yet and the exact onboarding answers for that repo. |
Where this comes from
The engine in this pack is super-board by Eric
Tech, published under the MIT licence: eight Claude Code skills, six guard hooks, a merge gate
and a wave workflow that drain a GitHub Project board on their own. We took the code as the
licence allows, renamed it (super-board became factory), replaced the author's example data
with a fictional practice project and removed his site, videos and release machinery. His
licence file ships unchanged inside the zip; the pack's CREDITS.md lists everything else he
credits in turn.
What we added is the lesson around it. On its own the engine assumes you already know what a testable card looks like, why the merge waits for a human and what a wave costs. Twelve prompts walk you from an empty folder to a board that drains, on a practice repo you can throw away, before you ever point it at code that matters.
What you build
When it runs, you write cards and walk away. A router grades each one, a Build lane works it in
its own git worktree and opens a draft pull request, a QA lane tests it and attaches evidence, a
Review lane checks it and runs the merge gate. You watch from the board and from one status
command. In this lesson the merge policy is human: every pull request waits for your click,
and nothing lands on main unless your tests pass on the reviewed commit.
The one thing it deliberately does not do: it never merges on its own here, and it is never installed on a real repo in this lesson. The last prompt is a readiness audit of your real project that ends in Go or Not yet, and installing there is a decision you make after reading it.
Do you need this? Be honest first
This is for someone who already uses Claude Code on a repo with tests and keeps a list of small, well-defined changes that never get done. If your project has no tests, the factory has nothing to pass and the first card is "write the tests", which you can do without a board. If you have three changes a month, a board is more ceremony than work. If your main branch deploys on every push and you have no staging branch, the lesson tells you to create one before anything runs.
You need to be comfortable reading a pull request. The factory produces evidence; it does not remove the reading.
What you need
- Any laptop. Windows 10/11 with WSL2, a Mac with Apple Silicon, or Linux. No GPU, no Docker, no database in this lesson.
- Claude Code on your own Anthropic account, Pro or above. Every card spends usage: a router call plus a Build, a QA and a Review session. The lesson starts every board on the cheapest tier and has you read your usage after the first wave.
- A free GitHub account. The board is a GitHub Project; the pull requests live on a private repo you create. Prompt 01 installs the GitHub CLI, jq and Python 3 and signs you in with the project scopes.
- Time. Setup is 30 to 45 minutes. The twelve prompts take four or five evenings, because the factory runs while you watch and you should watch the first waves.
What is in the zip
software-factory/
README.md the lesson: what you build, the rule that never bends, the paths
index.html the clickable setup guide with every prompt and a copy button
COSTS.md every cost, with the date it was read
CREDITS.md where the engine comes from, what was verified, terms
DISCLAIMER.md as is, no warranty, use at your own risk
paths/ Windows WSL2, Mac Apple Silicon, Linux Omarchy, from a clean machine
prompts/ twelve prompts, 00 to 11
source/factory/ the engine: install.sh, skills/, hooks/, scripts/, workflows/, LICENSE
What was verified and what was not
Verified on 2026-10-10: the renamed engine passed bash -n on every shell script, py_compile
on every Python file and node --check on both workflow files; the rename was audited by
search for every old name; the clickable guide was driven by a script in a real Chromium (tabs,
progress bar, saved progress, copy buttons, the file:// fallback); every text file was scanned
for keys, private addresses, mailboxes and the source's example names before the zip was built;
and a second model (Codex, gpt-6-astra) reviewed the pack in two read-only passes, 26 and 25
findings, with each finding's disposition recorded in the project.
Not verified: the twelve prompts run in order on a fresh machine; the three setup paths on three fresh machines; the engine installed into a repo and a wave run after the rename. The upstream project's own test suite is not included and was not executed after the rename. When something breaks, paste the whole error into Claude Code and ask it to fix it, then post what broke in the community.
Read the prompt before you run it
Hand each prompt to Claude first and ask what it plans to do. Compare that with the proof line at the end of the prompt. A prompt costs a minute to fix. A wave of wrong pull requests costs an evening and your GitHub API budget for the hour.
