agentleFS
smarzbansmarzban/agent-sdlc/skills/build/SKILL.md

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

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.
  • JuliusBrusseeSkill

    backprop

    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

  • GerardoRdz96Skill

    finances

    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

  • cpiprintSkill

    favicon

    Generate favicons from a source image

    Also in 3 projects that use this

  • madeehahassanSkill

    Go-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

  • JuliusBrusseeSkill

    deepen

    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

  • TrevokeSkill

    define

    Use when a new feature request, bug report, or work request needs requirements defined before implementation

    Also in 3 projects that use this

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
  1. Very specific:

    Light: when the spec has no ## Design / ## Tech Stack (or the user said this is a light run).

    line 21
  2. Very specific:

    Hand off: when every task is done: sdlc-check … --require ledger again, then ask: "The branch is ready.

    line 57
  3. Distinctive:

    Stop at a blocker: Do not improvise past an unsettled plan.

    line 78
  4. Distinctive:

    Evidence is your captured run,: never a transcribed subagent summary.

    line 79
  5. Very specific:

    Every T-N is test-first, green, atomically committed.

    line 102

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 each T-N itself (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

  1. Precondition resolve the plan; ingest an external plan first if needed (read ingesting-plans now). Confirm a ready-to-build verdict.
  2. Isolate worktree (existing isolation -> native tool -> git worktree). Run the green bar from ## Tech Stack once. On light, there is no feature ## Tech Stack: take the green bar from docs/specs/overview.md ## Tech Stack, else the repo's existing declared commands (package.json scripts, 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.
  3. Ledger open build-report.md and resume from it plus git log. If a ledger already exists, run sdlc-check docs/specs/<feature>/<feature>.md --require ledger first (fail-closed; runtime absent -> announced degrade). If HANDOFF.md exists at the working-copy root, update it (handoff skill, hook-driven case). Never create that file here.
  4. For each T-N in 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). Capture cmd > 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.

  5. Hand off when every task is done: sdlc-check … --require ledger again, 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 json numFailedTests. 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-review runs 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 log over 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 node at a checker point: say so in the ledger.

Rationalizations

ExcuseRebuttal
"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-N is test-first, green, atomically committed.
  • Light: no per-task reviewer ran. Full: one initial review per task, at most one remediations pass.
  • build-report.md has 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 ledger table, columns by header name (Task, Status, Commit, AC advanced, Notes). done triggers evidence and ledger-vs-git. First SHA-shaped token in Commit is 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 ledger at resume and hand-off. Never --require verification-report.
  • Downstream: ask whether to run /agent-sdlc:pr-review; never start it from build alone.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.