build
Skill2 starsChanged 4 months agoApache-2.0View on GitHub
Execute a gate-passed plan: test-first, one green commit per task, until the branch is ready for pr-review. Light specs: implement without a per-task reviewer. Full specs: one implementer plus one initial review. Use AFTER the gate verdict is ready to build and BEFORE pr-review. Triggers: 'build', 'implement the plan', 'execute the tasks', a clean gate-report.md with a settled Plan. Scope: only within an Agent SDLC run. Conductor: it dispatches and gates; it writes product code only on the light path or a recorded subagent death.
156 other projects use a version of this.
Adopted by
Most recently taken up by
- jskswamy/skillstheir own version, first seen Nov 8, 2026
- domengabrovsek/agent-configtheir own version, first seen Nov 8, 2026
- domengabrovsek/claudetheir own version, first seen Nov 8, 2026
- lilly-builds/senior-engineer-modetheir own version, first seen Nov 8, 2026
- endqwerty/endstacktheir own version, first seen Nov 8, 2026
- DnsQueen/orcinus-skillstheir own version, first seen Nov 8, 2026
Used with
Projects with it also use backprop, finances and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
JuliusBrusseeSkillbackprop
Bug → spec protocol. When a bug is found or a test fails, trace the cause, decide whether a new §V invariant would catch recurrence, append to §B. This is the one non-obvious thing SDD does that plan-then-execute doesn't. Triggers on test failure, bug report, post-mortem, or explicit user ask.
Also in 4 projects that use this
GerardoRdz96Skillfinances
Use when Gera talks about his money — logging an expense ("I spent X on Y"), checking where he stands this pay-period, closing a period, planning debt payoff, onboarding his financial picture, or asking for budgeting/finance opinions. Servy's financial brain. Triggers — "I spent", "log this expense", "where am I this period", "close the period", "how's my budget", "debt plan", "should I pay off", "finances onboard", "/finances".
Also in 3 projects that use this
cpiprintSkillfavicon
Generate favicons from a source image
Also in 3 projects that use this
madeehahassanSkillGo-Live
Pre-launch checklist. Use before making any app public, sharing a link externally, or announcing a product launch. Adapts to Claude Code, claude.ai, and Cowork.
Also in 3 projects that use this
JuliusBrusseeSkilldeepen
Optional design-improvement pass for when you have spare usage to drain. Finds the shallowest modules in the code the spec touches, researches a deeper design, and proposes refactors that shrink interfaces and hide decisions — behavior held constant, tests green before and after. Proposes §I/§V/§T edits, never silent rewrites. Triggers when the user says "deepen this", "improve the design", "this module feels shallow", "pull complexity down", "use spare budget on the codebase", or invokes /ck:deepen. Leans on the codebase-design skill's deep-module vocabulary when present.
Also in 3 projects that use this
TrevokeSkilldefine
Use when a new feature request, bug report, or work request needs requirements defined before implementation
Also in 3 projects that use this
Other versions156 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 156
- FalkorDB/FalkorDB★ 10ksame name
- microsoft/microsoft-ui-xaml★ 8.6ksame name
- NexaAI/nexa-sdk★ 8.5ksame name
- hathach/tinyusb★ 7.3ksame name
- parcadei/Continuous-Claude★ 3.9ksame name
- parcadei/Continuous-Claude-v2★ 3.9ksame name
- parcadei/Continuous-Claude-v3★ 3.9ksame name
- pytorch/TensorRT★ 3ksame name
- oxsecurity/megalinter★ 2.6ksame name
- iPlug2/iPlug2★ 2.4ksame name
146 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 repository18 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- llms.txtllms.txt
- acceptance-criteriaSkill
- architecture-designSkill
- gateSkill
- getting-startedSkill
- handoffSkill
- ideaSkill
- lightSkill
- linear-syncSkill
- planSkill
- pr-reviewSkill
- repo-setupSkill
- techstackSkill
- writing-readmesSkill
- writing-repo-docsSkill
- writing-technical-docsSkill
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 2 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 143 edited versions we read keep these.
2
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
- Very specific: line 21
Light: when the spec has no ## Design / ## Tech Stack (or the user said this is a light run).
- Very specific: line 57
Hand off: when every task is done: sdlc-check … --require ledger again, then ask: "The branch is ready.
- Distinctive: line 78
Stop at a blocker: Do not improvise past an unsettled plan.
- Distinctive: line 79
Evidence is your captured run,: never a transcribed subagent summary.
- Very specific: line 102
Every T-N is test-first, green, atomically committed.
“Common” is measured: kept by at least 6 in 10 of the 143 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
Build: plan to a green branch
Execute the ## Plan test-first. Light specs skip the per-task reviewer; whole-change review is
pr-review. Full specs keep one initial independent review per task. One remediations pass, then stop
and ask. Do not open the PR.
<HARD-GATE>
Precondition: a **gate verdict of ready to build** for the plan in hand. Resolve the plan per
input-resolution. If no verdict exists, run `/agent-sdlc:gate` inline and proceed only on a clean
verdict. Output is product code on a feature branch, one atomic commit per task, and
`docs/specs/<feature>/build-report.md`. Terminal action: report the green branch, then ask whether to run `/agent-sdlc:pr-review`.
</HARD-GATE>Light or full
- Light when the spec has no
## Design/## Tech Stack(or the user said this is a light run). The conductor implements eachT-Nitself (or one implementer). No per-task reviewer. - Full otherwise. One implementer + one initial reviewer per task. If that review blocks: one remediations pass on the same implementer, then stop and ask. No third reviewer round.
The loop
- Precondition resolve the plan; ingest an external plan first if needed (read ingesting-plans now). Confirm a ready-to-build verdict.
- Isolate worktree (existing isolation -> native tool ->
git worktree). Run the green bar from## Tech Stackonce. On light, there is no feature## Tech Stack: take the green bar fromdocs/specs/overview.md## Tech Stack, else the repo's existing declared commands (package.jsonscripts, CI,AGENTS.md). Greenfield missing paths are vacuously green. An unrunnable declared command is a techstack defect, not "red code". Pin implementer/reviewer types once; announce substitutions once in the ledger. - Ledger open
build-report.mdand resume from it plusgit log. If a ledger already exists, runsdlc-check docs/specs/<feature>/<feature>.md --require ledgerfirst (fail-closed; runtime absent -> announced degrade). IfHANDOFF.mdexists at the working-copy root, update it (handoff skill, hook-driven case). Never create that file here. For each
T-Nin dependency order (dispatch mechanics: subagent-loop): a. Implement test-first: the failing test the plan named, then the minimal code. Light: you (or one implementer). Full: dispatch the implementer with a one-task file brief. b. Full only: one initial reviewer on the complete task-scoped diff. Light: skip. c. Full only, and only if that review has Critical/Important findings: one remediations pass (continue the same implementer). Then stop and ask. Do not start a third round. d. Stage the task, run the full green bar on that snapshot (see Reading the green bar). Capturecmd > out.txt 2>&1; rc=$?. Record per-test names from the file. e. One atomic commit:feat(T-N): …. f. Update the ledger: done, SHA,AC-N, fenced evidence from your run, not the subagent's count. g. Linear transition if enabled.Plan/reality mismatch: read plan-amendments, stop the task, amend through
plan, gate the delta. Scope or AC change: stop and ask. Subagent death: capture -> retry once fresh -> only then conductor-takeover, recorded.- Hand off when every task is done:
sdlc-check … --require ledgeragain, then ask: "The branch is ready. Should I run/agent-sdlc:pr-review?" Stop there until the user answers.
Disciplines for implementers: tdd, source-driven, simplicity, debugging.
Reading the green bar
- Exit code unpiped.
cmd | filter; echo $?is the filter's status. Capture first (cmd > out.txt 2>&1; rc=$?). - Machine reporter over human summary. Exit code,
# fail N, vitest jsonnumFailedTests. A reporter disagreement is investigated, never waved off as flake. - Record the form in the ledger: command, exit code, machine counts.
Principles
- Light does not review per task.
pr-reviewruns Review panel on the whole change. - Full reviews once per task, not in a loop. One remediations pass, then ask.
- Test-first. The plan named the failing test; write it first.
- One task, one green commit. The whole bar, isolated.
- The ledger survives compaction. Trust it and
git logover memory. - Stop at a blocker. Do not improvise past an unsettled plan.
- Evidence is your captured run, never a transcribed subagent summary.
- Degrade loud. No
nodeat a checker point: say so in the ledger.
Rationalizations
| Excuse | Rebuttal |
| "I'll add a reviewer on this light task, it's safer." | Light review is pr-review. A per-task reviewer is the cost we just removed. |
| "Write the code, test after." | The plan named the failing test. Write it first. |
| "Skip the green bar, pr-review will catch it." | A red commit compounds. Verify now. |
| "Another review round will finish it." | One remediations pass, then ask. Do not spin. |
Red flags
- Per-task reviewer on a light spec.
- Third review round on a full spec.
- Code before a failing test.
- Done task with no SHA or no conductor-captured evidence block.
- Green bar read through a pipe or a human summary.
- Checker failed at resume or hand-off with no recorded override.
Done when
- Every
T-Nis test-first, green, atomically committed. - Light: no per-task reviewer ran. Full: one initial review per task, at most one remediations pass.
build-report.mdhas every task done with SHA,AC-N, and captured evidence.- Checker corroborated at resume (if any) and at hand-off, or an announced degrade is recorded.
- The green branch is reported and the user is asked whether to run
/agent-sdlc:pr-review.
The artifact (output)
- Product code: one reviewed-or-light, green commit per task.
docs/specs/<feature>/build-report.md— ledger: Task / Status / Commit / AC advanced / Notes; per done task a### T-N (@ \SHA`)heading with a non-empty fenced evidence block that names tests;## Deviations` for any plan delta or death/takeover.
Checker grammar
- Task ledger:
## Task ledgertable, columns by header name (Task,Status,Commit,AC advanced,Notes).donetriggers evidence and ledger-vs-git. First SHA-shaped token inCommitis the task's own commit. - Green-bar evidence: one
### T-N (@ `SHA`)heading per done task, at least one non-empty fenced block containing per-test names. - Ledger-vs-git: that SHA exists, is reachable from HEAD, and the commit scope is exactly
feat(T-N): ….
Conventions
- Writes product code +
build-report.md. Does not author front-half spec sections except materializing an ingested plan. sdlc-check … --require ledgerat resume and hand-off. Never--require verification-report.- Downstream: ask whether to run
/agent-sdlc:pr-review; never start it from build alone.
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.

