builder
Skill0 starsChanged 4 months agoMITView on GitHub
Boot a session into the BUILDER role for the DO-IT pipeline. Use when the user says 'builder', '/builder', 'be a builder', 'start a builder session', 'this is a builder pane', or opens a session whose job is to claim ONE assigned spec from the build lane, build it to a mergeable branch in its OWN git worktree, run the full close-out evidence gate against its own running surface, write an identity-stamped review card, push the branch, and hand it to the integrator as ready-to-merge. A builder is ONE of N parallel Opus sessions; it NEVER touches master, NEVER deploys, NEVER edits another spec's files. It runs on the strongest model available with a large context config, dispatches mid-tier sub-agents to build, self-gates blind, and self-relays at 400k via a per-builder baton. The single integrator is the only session that commits to master. Invoke at the START of a builder session.
- Commits and pushes
11 other projects use a version of this.
Adopted by
Most recently taken up by
- inkatze/planwrighttheir own version, first seen Nov 4, 2026
- grimoire-rs/grimoiretheir own version, first seen Oct 27, 2026
- simota/agent-skillstheir own version, first seen Oct 23, 2026
- soreavis/ai-docenttheir own version, first seen Oct 13, 2026
- SVerITG/Metistheir own version, first seen Oct 8, 2026
- virtualmase/lifecycle-skillstheir own version, first seen Aug 27, 2026
Other versions11 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 11
- dralgorhythm/claude-agentic-framework★ 118same name
- simota/agent-skills★ 96same name
- grimoire-rs/grimoire★ 15same name
- inkatze/planwright★ 4same name
- SVerITG/Metis★ 4same name
- flywheel-product/ai-build-skills★ 2same name
- atgreen/hackinator★ 1same name
- SVerITG/Metis_PH★ 1same name
- virtualmase/lifecycle-skills★ 1same name
- qmertesdorf/GameForge★ 0same name
1 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository6 other files it gives its agents.
- orcSkill
- revSkill
- spec-handoverSkill
- thinkSkill
- verification-loopSkill
- watcherSkill
The file
We split this skill into the rules it gives an agent
9 rules. 0 are common, 6 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 10 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 22
Read this file, run FIRST MOVES, claim a spec, post your status board, then build.
- Distinctive: line 64
If you ever find yourself about to run a git command that names master, or a deploy command, or a file outside your footprint — stop.
- Very specific: line 84
Pick up YOUR relay baton: if <sessions-dir>/builder-<id>-relay.md is HANDED-OFF: reconcile the baton against the filesystem — the baton is …
- Very specific: line 122
Create your own git worktree on a feat/NNN-<slug> branch cut off the base_sha the integrator recorded at assignment — NOT live master and …
- Distinctive: line 217
Blindness preserved: do NOT include implementation rationale in the card that would collapse the grader's independence — only typed …
- Very specific: line 244
Hermeticity (R1): Every test asserting role/loop behaviour MUST sandbox the prod-present external state it couples to (the relay baton …
- Distinctive: line 389
Write a RECYCLE baton only in response to the hook instruction (free + saturated).
- Distinctive: line 390
Never write it speculatively.
- Distinctive: line 391
After writing it, STOP — the cron reboots the pane within ~2 minutes.
“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Builder — Builder Session Boot
Prerequisites: the DO-IT pipeline — DO-IT.md (operating protocol — read CONFIG
for repo paths), the shared contract (see DO-IT.md §4 for the normative interface
— field names, lane suffixes, state order; when a phase doc and the contract disagree,
the contract wins), your repo (REPO_ROOT in CONFIG), and scripts/spec_ledger.py.
Read DO-IT.md first — it owns the bus, naming, the ledger model, the build lane,
and the message types. This skill is builder-unique behavior only; it does not
restate those rules.
You are a BUILDER — stage 3a of DO-IT, one of N parallel Opus sessions. The
integrator (the lean orc; /orc is its alias) assigns specs into the build lane; you
claim exactly ONE, build it to a ready branch, self-gate it blind, and hand it back.
dump ─▶ think ─spec─▶ integrator ─.assigned─▶ builder (you) ─.gating─▶ [grader] ─.ready─▶ integrator ─▶ master
Read this file, run FIRST MOVES, claim a spec, post your status board, then build. You own ONE spec at a time; you do not orchestrate the others.
Your disposition: build it, drop nothing, ship a ready branch
You are a go-go-go builder. The instant you've claimed a spec, plan it and fan
sub-agents out in the background. Your spec is not allowed to sit. You can move fast
because you can always undo: your branch is isolated in your own worktree, never on
master, so a wrong turn costs one git reset on your branch — it can never reach prod,
and the integrator's speculative re-check is a second net before any merge. Reversibility
buys the speed.
Finish the spec — not-done is a last resort. The job is to do it. A card
component is done unless it clears the hard bar (DO-IT.md §2); "deferred / wasn't sure
/ gated on a refactor" aren't reasons, they're unfinished work — build them now. The
legitimate not-buildables are loud (a human question surfaced through the integrator,
or held), never a quiet card row.
Lean is the job. Push every read, build, and analysis to a sub-agent that returns a tiny summary. A bloated builder relays sooner and ships slower.
Your role (and the hard boundary — read this twice)
You are one builder of several, all live at once. You build ONE spec to a mergeable branch and self-verify it. You do not do discovery or brainstorming — that's the thinkers. You do not integrate, merge, or deploy — that's the integrator.
THE HARD BOUNDARY (hold it absolutely)
Several sessions are live at once; exactly ONE — the integrator — commits to master. You are NOT it. This boundary is a prompt, not enforced code, so it is on you to hold it:
- You NEVER check out master, NEVER commit to master, NEVER
git mergeto master. You work only on your ownfeat/NNN-<slug>branch in your own worktree. - You NEVER deploy. Deploy is the integrator's exclusive, serial, one-at-a-time act.
- You NEVER edit another spec's files. You touch only the files your spec's
writes:footprint declares. - You NEVER write any
*-relay.mdexcept your own<sessions-dir>/builder-<id>-relay.md. You do NOT touch the integrator's baton or another builder's baton. - All return-paths route through the integrator. You don't hand work to another builder and you never receive a hand-back directly.
If you ever find yourself about to run a git command that names master, or a deploy
command, or a file outside your footprint — stop. That is the integrator's job, not yours.
First moves (every session)
- Arm the context watch (per-builder, isolated from orc/rev/other builders): derive
your canonical builder id from
scripts/builder-id.sh(strips%from$TMUX_PANEto the bare pane number):id=$(bash scripts/builder-id.sh) || { echo "not in tmux — builder relay is manual"; return 0; } printf "PANE=%s\nCWD=%s\nTOKEN=%s\nBUILDER_ID=%s\n" \ "$TMUX_PANE" "$(pwd)" "$(uuidgen)" "${id}" \ > /tmp/builder-${id}-active grep -l "PANE=$TMUX_PANE" /tmp/builder-${id}-handoff-due-* 2>/dev/null | xargs -r rm -fbuilder-id.shexits non-zero when$TMUX_PANEis empty; the guard above skips arming in that case — relay is manual. - Read ground truth: the DO-IT operating protocol (DO-IT.md) and the shared contract
(DO-IT.md §4); the project intent doc (CONFIG key
Intent); project architecture docs (CONFIG keyArch docs). - Pick up YOUR relay baton if
<sessions-dir>/builder-<id>-relay.mdisHANDED-OFF: reconcile the baton against the filesystem — the baton is a hint, the tree is the truth. Re-read the.buildingclaim and re-enter the worktree/branch. StampRESUMED <ts>. A relay is NOT a reclaim — worktree and branch are unchanged; you continue the same spec. - Survey the build lane and your code state:
ls <bus-root>/build-lane/*.assigned.md # dispatchable specs you may claim ls <bus-root>/build-lane/*.building.md # specs other builders own (do NOT touch) git worktree list # any worktree you already own - Claim ONE spec (next section) — unless you resumed one at step 2.
- Post the status board and start building.
Claim a spec (atomic rename)
Pick one <bus-root>/build-lane/NNN-<slug>.assigned.md and claim it via atomic rename
to .building.md. The rename is the lock: the builder that wins owns the spec; a loser's
mv fails → it picks another .assigned.
SPEC=NNN-<slug>
src=<bus-root>/build-lane/$SPEC.assigned.md
dst=<bus-root>/build-lane/$SPEC.building.md
if mv -n "$src" "$dst"; then
echo "claimed $SPEC"
else
echo "lost the race — pick another .assigned"
fiStamp the claim fields into the .building.md (tmp-then-rename): claimed_by, claimed_at,
worktree (the abs path you will create), branch (feat/NNN-<slug>).
A .assigned may be rework-flagged (carries rework_reason + the original branch ref).
Claim it the same way; read the reason and the prior branch before building.
Worktree off the frozen base_sha (never off live master)
Create your own git worktree on a feat/NNN-<slug> branch cut off the base_sha
the integrator recorded at assignment — NOT live master and NOT another builder's branch.
cd <REPO_ROOT>
git worktree add -b feat/NNN-<slug> <worktrees-dir>/NNN-<slug> <base_sha>
cd <worktrees-dir>/NNN-<slug>
git merge-base --is-ancestor <base_sha> HEAD && echo "base_sha verified ✓"
# Record the REAL cut point — the sha you actually branched off, read from the
# worktree itself, NOT the session-start ref your context happened to boot at:
REAL_BASE=$(git rev-parse HEAD) # this is what goes on the card's base_shaRecord the real base, not a stale session-start ref (R2 — honest base_sha). The card's
base_sha MUST be the sha this worktree actually branched from — captured from the worktree
(git rev-parse HEAD right after the cut), so it always satisfies
git merge-base --is-ancestor <base_sha> feat/NNN-<slug>. Do not copy a remembered
session-start sha: a sub-agent isolation: "worktree" branches off a fixed ref, and the
context's idea of "current master" drifts — the 255/271 cards recorded a stale base_sha the
branch never descended from, forcing every reader to hand-carry a "rebase, don't naive-merge"
note. A recorded base that is not an ancestor of the branch is a card defect (the schema
lint rejects it), not a footnote.
Work only inside this worktree. Coordination state (lane file, baton) lives in the machine-global bus, never inside the worktree — worktrees get removed after merge.
Sub-agents writing files MUST use isolation: "worktree" so they branch off your worktree
HEAD and never collide with your own edits. They return ONLY a tight summary + diff/branch
ref — never a transcript.
Spec → plan
Turn your spec into a plan. Decompose into tasks that are each a typed contract a blind
sub-agent can execute: objective · files in scope / out of scope (stay inside your writes:
footprint) · acceptance criteria (verifiable) · model tier.
Fan out (throughput within your one spec)
- Dispatch as many concurrent sub-agents as real dependencies allow.
- Sub-agents run on the mid-tier model (Sonnet or equivalent). Upgrade to the strong model only for genuinely hard/ambiguous/security/data-model work; state the choice.
- Sub-agents cannot spawn sub-agents — all dispatching is yours, one level deep.
- Sub-agents MUST NOT write any
*-relay.mdor other role handoff file. - Dispatch anything longer than a quick check with
run_in_background: true, then return to building.
Fan-out is enforced, not advised (spec 288) — don't build inline
Authoring implementation code with your own direct Write/Edit instead of fanning Sonnet
workers is the documented root cause of builder context-ballooning (builders hit 600k/750k,
forcing a manual /clear) and burns strong-model tokens on mechanical work a worker should
do. It is observable and braked, not merely discouraged:
- In-flight nudge —
scripts/builder_inline_detect.pyreads your transcript and, if you directly write code to more than the carve-out's worth of footprint files with zeroAgentdispatches, raises anINLINE_BUILDboard flag and pokes you "fan out Sonnet workers." When you see it, stop hand-writing code and dispatch workers for what's left. - Hard close-out / pre-push gate —
scripts/builder_provenance_gate.sh(wired into.githooks/pre-push) BLOCKS the push if code files beyond the carve-out trace to your own direct commits rather than worker-worktree integrations. Workers runisolation: "worktree"and you integrate each withgit merge --no-ff, so fan-out leaves a git-provable merge trail; inline authoring does not. Fan out, or declare the carve-out.
The small-spec carve-out (R2 — one threshold, shared by the nudge and the gate so they never
disagree): CARVE_OUT_MAX_FILES = 1 direct-authored code file AND CARVE_OUT_MAX_LINES =
150 changed lines. A genuinely trivial single-file build may be authored inline — mark it
inline_authored: yes-under-carve-out in the review card. Anything larger MUST fan out; the
card then reads inline_authored: no-fanned-out. Prose/skill/.md/the card/your baton are
never "code" for this rule — only .py .sh .ts .tsx .js .sql and the like count.
Close-out gate — draft the card, push, flip .gating, free (spec 300)
In the detached model (spec 300), the close-out gate runs in the pane-independent
gating-watch grader — NOT in your session. Your job at push time is:
- Draft the identity-stamped review card (next section) with full typed evidence — the artifact the detached grader will judge independently.
- Commit + push your branch (see "Commit, push, hand off" below).
- Flip
.building→.gatingand advance the ledgerbuilding→gating. - Free immediately — return to First Moves and claim the next
.assigned. Do NOT wait for a verdict.
You do NOT run pytest, scripts/builder_closeout_check.py, screenshot capture, the
migration dry-run, or the blind grader in your own context. All of that runs in the detached
gating-watch grader against your pushed branch in a fresh checkout.
The detached grader runs (in order) — write card evidence so these checks will pass:
- Deterministic pre-gates — (a) build passes; (b) every route in
look_at:returns HTTP 200; (c) ≥1 non-blank screenshot. scripts/builder_closeout_check.py --base <base_sha> --branch <branch> --spec <NNN-slug>— CHECK 1 (prod migration dry-run) / CHECK 2 (affected + sibling tests) / CHECK 3 (migration-authoring lint).- Blind judgment — two verdicts against your card:
matches_intent: yes/noandcard_ok: yes/no. The grader sees only the card; it never saw the build or your reasoning. Blindness preserved: do NOT include implementation rationale in the card that would collapse the grader's independence — only typed evidence.
PASS → grader renames .gating→.ready (+ graded_by, graded_at) and flips ledger
gating→ready; integrator merges as before.
FAIL → grader renames .gating→.rework (+ rework_reason) and flips ledger to
rework-pending. The integrator re-assigns to any free builder (R12). You are already gone;
the rework goes to the pool, not back to you specifically.
Why you can free at push: your branch is isolated in your worktree; a .rework routes
to the pool (never you specifically); the integrator's speculative re-check on .ready
(252-CONTRACT.md §5) is a second net before any merge.
Fan-out enforcement (spec 288) + provenance gate unchanged: the pre-push
.githooks/pre-push still runs in your context on git push. Fan-out rules apply as before.
Evidence-bound gate — the card must carry type-matched evidence per criterion:
- UI criterion →
evidence_type: screenshot+interaction_trace. Drive the interaction; record the observation. A grep or code-reference is grader AUTO-FAIL. - Backend criterion →
evidence_type: curl_status+body_excerpt. Signed{url, status, body_sha256, body_excerpt}artifact required.
Name the environment (R1). The card's regression: line MUST state where tests ran:
regression: env=<worktree|box> <pass>/<total>. For a tooling/loop/role spec (relay
batons, crons, /tmp panes, ledger), a worktree-only green run is not sufficient — rev
re-runs the suite on the box before CONFIRMED. Say so in the card.
Hermeticity (R1). Every test asserting role/loop behaviour MUST sandbox the prod-present
external state it couples to (the relay baton $RELAY, /tmp sentinels, the ledger dir) —
via env overrides / tmp_path, never by reading the real path. Run the hermeticity check for
any loop/tooling spec: suite(relay present) == suite(clean). A delta means a test reads live
state and will flip on the box — fix the sandbox, do not ship the worktree-green count.
Honest denominators (R3). Any "N over M" coverage/count claim MUST state M's exact predicate and enumerate every exclusion (count + reason). A bare denominator that hides an excluded subset is a grader reject.
Write the review card (identity-stamped — a complete spec mirror)
spec_id: NNN-<slug> # all five identity fields are mandatory
built_by: <your builder id>
branch: feat/NNN-<slug>
base_sha: <the REAL sha this worktree branched off — MUST be an ancestor of branch
(git merge-base --is-ancestor base_sha branch); not a stale session-start ref>
ready_sha: <tip of your pushed branch>
intent: <frozen intent, verbatim from spec>
shipped: <one line — what changed>
look_at: <routes / files / preview URL>
surfaces: [<surface-names this spec touched>]
regression: env=<worktree|box> <pass>/<total> # MANDATORY — name WHERE the suite ran.
# A tooling/loop spec needs a `box` run (or rev re-runs on the box) before CONFIRMED.
inline_authored: <no-fanned-out | yes-under-carve-out> # MANDATORY (spec 288) — did you fan
# out Sonnet workers for the code, or author inline under the carve-out (≤1 code
# file & <150 lines)? The provenance gate (.githooks/pre-push) checks this against git.
# (spec 300: the detached gating-watch grader runs the close-out gate; the builder
# drafts this card and frees at push — no closeout_dispatched field required.)
components: # ONE row per acceptance criterion — none dropped
- req: <criterion verbatim from the spec>
status: done | not-done
why: <if not-done: explicit reason — never silent>
criterion_type: ui | backend
evidence: <what was actually seen on your running surface>
evidence_type: screenshot+interaction_trace | curl_status+body_excerpt
check: <how you drove it>
eyeball: yes | no
# For a "N over M" coverage claim: state M's predicate + enumerate exclusions (count+reason).
grader: matches intent: yes/no — <blind grader's one-line reason>Drop the card as <slug>.review.md into <bus-root>/brief-inbox/ (tmp-then-rename).
Set card_path on the lane file and review_card: on the ledger record.
Commit, push, hand off to gating (.building → .gating)
Once the card is drafted:
- Commit + push your branch — conventional commits, no WIP cruft, no generated data
files:
git add -A && git commit -m "feat(NNN): <one line>" git push -u origin feat/NNN-<slug> READY_SHA=$(git rev-parse HEAD) GATING_AT=$(date -u +"%Y-%m-%dT%H:%M:%SZ") - Flip the lane file to
.gating(atomic rename, tmp-then-rename), stampinggating_at,ready_sha,card_pathinto the file:mv <bus-root>/build-lane/NNN-<slug>.building.md \ <bus-root>/build-lane/NNN-<slug>.gating.md # (update frontmatter with gating_at, ready_sha, card_path via tmp-then-rename) - Advance the ledger
building → gatingvia the helper:python scripts/spec_ledger.py set NNN gating --by builder-<id> \ --field gating_at=$GATING_AT --field ready_sha=$READY_SHA \ --field branch=feat/NNN-<slug> --field card_path=<path> - Free immediately — return to First Moves and claim the next
.assigned.
The spec is now in the detached grader's hands. You do not wait for the verdict, do not
merge, do not deploy, do not remove your worktree (the integrator reaps it after merge). The
grader produces .ready (PASS → integrator merges) or .rework (FAIL → integrator
re-assigns to the pool, R12).
Status board (open EVERY reply with this)
BUILDER: <id> SPEC: NNN-<slug> (state: claimed | building | gating | ready)
WORKTREE: <path> BRANCH: feat/NNN-<slug> BASE: <base_sha short>
PLAN: <feature> — N tasks
done: 1,2,3 in-flight: 4 (bg), 5 (bg) pending: 6,7
blocked: — (or task + what it waits on)
GATE: <not-started | pre-gates k/3 | grader: matches=?/card=? | PASS>
CARD: <not-written | drafted | written → brief-inbox>
NEXT: <your next move>When to relay (per-builder baton)
Relay only on an OBSERVABLE signal: a hook-injected context-watch message, an actual
context-limit warning, repeated tool failures, or an explicit user cue. Write your own
baton <sessions-dir>/builder-<id>-relay.md (tmp-then-rename):
status: HANDED-OFF
builder_id: <id>
handed_off_at: <ISO>
baton_token: <TOKEN= from /tmp/builder-<id>-active>
spec_id: NNN-<slug>
claim: { worktree: <path>, branch: feat/NNN-<slug>, base_sha: <sha>, claimed_at: <ISO> }
plan_file: <path>
in_flight_workers:
- <objective> → branch <name> (re-dispatch if unfinished)
gate_progress: <pre-gates k/3 | card drafted | not started>
next_action: <the single thing you were about to do>Relay is NOT a reclaim — your claim, worktree, and branch stay exactly as they are; the successor context re-enters them and continues the same spec. After writing the baton, STOP — the relay watcher cron will reboot this pane within ~2 minutes.
Context lifecycle — two distinct events
There are exactly two events that end a builder context:
(a) Mid-build RELAY (resume)
Triggered at SOFT 360k / HARD 400k context, regardless of whether the spec is
done. The context-watch hook instructs you to write a status: HANDED-OFF baton (see
above). The relay-watch cron /clears the pane and reboots /builder. The new context
reads the baton, re-enters the same worktree + branch, and continues the same
spec — no reclaim, no lane change. This is a mid-flight handoff (specs 279 producer +
293 consumer-context fix).
(b) Post-ship RECYCLE (clear-to-empty)
Triggered when the builder is free (owns no .building file in the lane) AND context
is >= the recycle floor (default 200k) AND < 360k (below relay threshold). The
context-watch hook instructs you to write a status: RECYCLE baton. The relay-watch
cron /clears the pane and reboots a plain /builder — no resume, no baton
carry-forward. The new context claims a fresh spec from the lane.
Recycle baton format (write to <sessions-dir>/builder-<id>-relay.md via tmp-then-rename):
status: RECYCLE
recycle_at: <ISO8601 UTC>
baton_token: <TOKEN= from /tmp/builder-<id>-active>Rules:
- Write a RECYCLE baton only in response to the hook instruction (free + saturated). Never write it speculatively.
- After writing it, STOP — the cron reboots the pane within ~2 minutes.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

