Build one

Skill tmusser/ai-engineering-skills/skills/build-one

Portable AI-engineering skills for Claude Code, Codex, and coding agents: bounded scope, mini-specs, vertical slices, verification, ship gates, and handoff.

Install

npx -y skills add tmusser/ai-engineering-skills --skill build-one

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Implement exactly one planned slice after scope is frozen, without exceeding the spec ceiling or carrying known analysis debt into the build.

SKILL.md

3.0 KB, as published. Nobody here has run it

Build One

Purpose

Implement exactly one planned slice without expanding the behavioral contract or building through a known stale/required analysis checkpoint.

When to use

Use after a task is selected and scope is frozen.

Inputs

SPEC.md
PLAN.md
TODO.md
Scope boundary
Current repo status
Analysis checkpoint when present in HANDOFF.md or other current state

Workflow

Read SPEC.md, PLAN.md, and TODO.md.
Select one task.
Confirm the scope boundary.
Perform the cheap analyze-mini eligibility check using artifacts already loaded for this build:
- REQUIRED or STALE checkpoint -> invoke analyze-mini before editing.
- FRESH checkpoint -> confirm its task-defining inputs still match current state; if not, mark it STALE and invoke analyze-mini.
- missing checkpoint or NOT_NEEDED -> invoke analyze-mini only when a current trigger exists.
- Missing prior analysis alone does not require analyze-mini.
- Do not broaden discovery merely to prove that analysis is unnecessary.
If full analysis returns BLOCKED, stop before implementation and resolve the contradiction or decision.
Confirm the spec ceiling: each intended behavior change must satisfy an acceptance criterion or be necessary support for one. Explicit non-goals remain out of scope.
If the implementation needs behavior outside that ceiling, stop and renegotiate or update the spec before making that expansion.
Make the minimum useful change.
Run relevant verification.
Update VERIFY.md or HANDOFF.md with a compact build note:
- Selected slice
- Files touched
- Why each file was touched
- Compatibility seams preserved
- Analysis checkpoint: FRESH | NOT_NEEDED
- Spec ceiling respected: yes/no
- Unexpected behavior added: none | describe
- Tests changed: yes/no
- Verification run
- Stop reason
Update task status.
Stop after one task.
Summarize changed files and result.

Outputs

One implemented slice
Changed file summary
Verification result
Build note
Updated TODO.md if appropriate

Stop conditions

The selected task is complete and verified.
The task needs a scope or spec change.
Analysis is REQUIRED, STALE, or BLOCKED and must be resolved before editing.
Verification fails and diagnosis is needed.
A useful adjacent improvement is discovered but is not required by the current acceptance criteria.

Anti-patterns

Running analyze-mini before every build as a ritual.
Treating absence of an analysis checkpoint as a blocker by itself.
Continuing into the next task without approval.
Refactoring unrelated code.
Adding "helpful" behavior beyond the acceptance criteria because it is nearby or easy.
Treating partial infrastructure as a completed slice.