agentleFS
Sign inStart free
bdunn313bdunn313/repolab/.agents/skills/build/SKILL.md

build

Skill1 starsChanged 4 months agoMITView on GitHub

Plan-then-execute implementation against SPEC.md. Native single-thread loop, no sub-agents. On test or build failure, auto-invokes the backprop skill before retrying — a failed verification always considers whether a new §V invariant would prevent recurrence. Triggers when the user asks to build, implement, execute the spec, or tackle a specific §T task (`build §T.3`, `build --next`, `implement next task`, `run the build`). Expects SPEC.md to exist; if not, defers to the spec skill.

156 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use finances, favicon and 7 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.
  • 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

  • synaptiaiSkill

    gate

    Create a BDSK review_gate artifact. Defines a checkpoint that controls whether generated output may proceed toward acceptance. Use when defining quality, security, or scope gates for execution plans.

    Also in 5 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

  • HAR5HA-7663Skill

    shape

    Plan the UX and UI for a feature before writing code. Runs a structured discovery interview, then produces a design brief that guides implementation. Use during the planning phase to establish design direction, constraints, and strategy before any code is written.

    Also in 5 projects that use this

The file

We split this skill into the rules it gives an agent

12 rules. 0 are common, 7 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 142 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read SPEC.md. If missing → tell user to invoke the spec skill first.

    line 19
  2. Very specific:

    Read FORMAT.md once if not loaded.

    line 20
  3. Distinctive:

    Read §R if present — external facts the build must honor, ⊥ re-derive or contradict.

    line 21
  4. Distinctive:

    Ask: is failure (a) my code bug, (b) spec wrong, or (c) unspecified edge case?

    line 58
  5. Distinctive:

    If (a) → fix code, re-run.

    line 59
  6. Very specific:

    If (b) or (c) → invoke spec skill with bug: <cause> first, let it update §V and §B, then resume build against updated spec.

    line 60
  7. Distinctive:

    Only flip §T status. No other SPEC.md edits from build.

    line 66
  8. Very specific:

    Commit after each §T completes.

    line 68
  9. Distinctive:

    Every §V touched has its named test from the verification contract, and it passes.

    line 74
  10. Distinctive:

    No sub-agents. No parallel workers.

    line 79
  11. Very specific:

    No progress dashboards. cat SPEC.md | grep §T is the dashboard.

    line 80
  12. Distinctive:

    No speculative work beyond chosen task scope.

    line 81

“Common” is measured: kept by at least 6 in 10 of the 142 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 — implement spec

Single-thread native plan→execute. You are main Claude. No swarm.

LOAD

  1. Read SPEC.md. If missing → tell user to invoke the spec skill first. Stop.
  2. Read FORMAT.md once if not loaded.
  3. Read §R if present — external facts the build must honor, ⊥ re-derive or contradict.
  4. Parse invocation args:
    • §T.n → that task only
    • --next → lowest-numbered row with status . or ~
    • --all or empty → every . row in §T order

High blast radius (shared module, auth, data, money, public §I)? Run /review first. Trivial & reversible? Skip planning ceremony, just do step EXECUTE.

PLAN

Native plan mode — you delegate to it, you do not reinvent task breakdown. For chosen task(s):

  1. Cite every §V invariant that applies. Plan must respect all.
  2. Cite every §I interface touched. Plan must preserve shape.
  3. List files to create / edit.
  4. Verification contract — name the EXACT test(s) / acceptance criteria that prove each §V touched. Which test, not "add tests". "Do TDD" alone backfires; the spec says what to check. Each §V touched → a named test that fails first.
  5. Name verification command (test, build, lint) — this is the external oracle. Green = done; ⊥ "looks done".

Show plan. Wait for user OK unless auto mode.

EXECUTE

Per task in order:

  1. Flip §T.n status cell . → ~. Just write to SPEC.md.
  2. Edit code per plan.
  3. Run verification command.
  4. Pass → flip ~ → x. Next task.
  5. Fail → invoke backprop skill. Do NOT retry blindly.

FAIL → BACKPROP

On test/build failure:

  1. Read failure output.
  2. Ask: is failure (a) my code bug, (b) spec wrong, or (c) unspecified edge case?
  3. If (a) → fix code, re-run. No spec change.
  4. If (b) or (c) → invoke spec skill with bug: <cause> first, let it update §V and §B, then resume build against updated spec.

Rule: never silently fix root-cause without considering backprop. §B is the memory that stops recurrence.

WRITE POLICY

  • Only flip §T status. No other SPEC.md edits from build.
  • Other spec edits → invoke spec skill.
  • Commit after each §T completes. Message: T<n>: <goal line> + §V cites.

VERIFICATION

Task x only if:

  • Verification command (the oracle) exits 0.
  • Every §V touched has its named test from the verification contract, and it passes.
  • No §V invariant regressed (run full test suite at end).

NON-GOALS

  • No sub-agents. No parallel workers. Main thread only.
  • No progress dashboards. cat SPEC.md | grep §T is the dashboard.
  • No speculative work beyond chosen task scope.

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.

Check your setup, free