agentleFS
Sign inStart free
pjlangleypjlangley/ff/.claude/skills/spec-build/SKILL.md

spec-build

Skill4 starsChanged 53 days agoUnlicenseView on GitHub

Work through an already-planned spec feature by delivering the tasks in specs/NNN_feature_slug/tasks/ one at a time, verifying each independently. Use ONLY when such a tasks/ directory exists and the user is executing it; for ad-hoc, one-off, or any non-spec code change use the build skill instead. Composes the build skill for commands and conventions. Step 3 of the spec-driven workflow.

2 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 2

    1. rioffe/speccheck★ 5same name
    2. cldanielhernandez/claude-skills★ 0same name

    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.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    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:

    Only: when a specs/NNN_feature_slug/tasks/ directory already exists (produced by spec-tasks) and the user is working through that task list …

    line 12
  2. Very specific:

    Preconditions: Every task in Depends on is Status: Done, the named paths exist, and no earlier task has already delivered part of the scope.

    line 33
  3. Very specific:

    Run the task's QA (tests / lint / format / typecheck for the languages touched — see the build skill).

    line 59
  4. Distinctive:

    No feature branches, no staging or committing, no pushing, no PR creation.

    line 73
  5. Distinctive:

    No batching multiple tasks in one go — wait for the user's go-ahead between tasks.

    line 74

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

spec-build

Drives spec-driven, per-task delivery. This is step 3 of the workflow: spec-ideate → spec-tasks → spec-build.

When to use

Only when a specs/NNN_feature_slug/tasks/ directory already exists (produced by spec-tasks) and the user is working through that task list — delivering the tasks one at a time so each can be verified independently. For any other code change — ad-hoc fixes, upgrades, one-off implementation not tied to a spec — use the build skill instead.

Follow the build skill

For all repo commands (test / lint / format / build / run) and coding conventions, use the build skill — this skill does not restate them. build is the general reference; spec-build only adds the preflight and per-task delivery loop below.

Preflight the task against the code

Task files are written at planning time — potentially long before execution, and without opening the code. Their bullets carry rationales ("it currently does X", "so that Y doesn't happen"), and the code moves underneath them. Before writing any code, test the premises the task file asserts:

  • Claims about this repo's current state. Open every file the Changes section names and confirm the described current behaviour is actually there.
  • Claims about third-party behaviour — Anchor, GitHub Actions, Terraform, AWS semantics. Verify against the tool's documentation or a local command, never from memory. This is where a rationale is most often wrong and least likely to be noticed, because the code alone cannot falsify it.
  • Preconditions. Every task in Depends on is Status: Done, the named paths exist, and no earlier task has already delivered part of the scope.
  • Test doubles. The Verification (QA) section must agree with the build skill's testing conventions: the chain is exercised against the local validator, only AWS SDK clients are mocked. A task that proposes mocking an RPC client or a solana_*_interface fragment is a material finding — do not build it that way.

Apply the grilling skill's dividing line: facts are yours to look up, decisions are the user's. The preflight tests falsifiable premises only.

Reporting findings

  • Material — the flaw would change what gets built. Stop before implementing. Report the premise as written, the evidence contradicting it, and a recommended alternative, then wait for the user's ruling.
  • Non-material — stale wording, a path that moved, cosmetics. Note it, proceed, and mention it in the handback.

Where the ruling deviates from the task file, amend that file in the same change: strike the bullet through and state what was done instead and why. A task marked Done must not still assert something known to be false.

Per-task delivery loop

Deliver one task at a time and let the user verify each independently:

  1. Pick the next unchecked task from specs/NNN_feature_slug/tasks/README.md.
  2. Preflight it against the code (see above). Stop here if it turns up a material flaw.
  3. Work directly on main — no feature branch (solo portfolio repo).
  4. Implement only that task's scope, following the build skill's commands and conventions.
  5. Run the task's QA (tests / lint / format / typecheck for the languages touched — see the build skill). Tests that need the local validator cannot run from the agent sandbox: run the static checks, then hand the test command to the user and say so in the handback rather than reporting the tests as passing.
  6. Tick the task off in tasks/README.md and set its Status: Done. If the preflight changed the plan, amend the task file in the same change to record what was done instead and why.
  7. Stop and hand back with the changes left unstaged, listing any non-blocking preflight findings alongside the diff. Do not commit or push. The user reviews the diff, then commits/pushes and verifies independently. Only continue to the next task on the user's explicit go-ahead.

Out of scope

  • Restating build/QA commands or conventions — those live in the build skill.
  • Re-grilling requirements.md or reopening settled design decisions — the preflight tests falsifiable premises, it is not a re-plan.
  • No feature branches, no staging or committing, no pushing, no PR creation.
  • No batching multiple tasks in one go — wait for the user's go-ahead between tasks.

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