
Build
- 386 installs
- 1 repo stars
- Updated May 26, 2026
- camacho/ai-skills
build is an agent skill that executes approved plan tasks via subagent dispatch, validation, and reporting for developers who need plan-to-code implementation in a worktree.
About
build is a Camacho ai-skills workflow that turns an approved `ai-workspace/plans/<name>.md` plan—or a one-sentence hotfix scope—into implemented code, configs, and project artifacts. The skill announces execution, loads ordered task batches (parallel steps grouped, dependent steps sequenced), dispatches subagents per task, validates results, and reports completion. Prerequisites include plan approval from `/review` (Step 4) or a minimal hotfix scope, and work in a linked git worktree rather than the primary branch. Developers reach for build when design is done and they want TDD-guided execution without manually shepherding every subtask.
- Spec-to-code agent loops
- Incremental implementation steps
- Stack-aware scaffolding
- Handoff-ready deliverables
Build by the numbers
- 386 all-time installs (skills.sh)
- Ranked #2,039 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/camacho/ai-skills --skill buildAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 386 |
|---|---|
| repo stars | ★ 1 |
| Last updated | May 26, 2026 |
| Repository | camacho/ai-skills ↗ |
How do you execute an approved agent plan into code?
Execute agent-guided implementation passes that turn approved specs into working code, configs, and project artifacts.
Who is it for?
Developers with an approved plan or a tight hotfix scope who want automated subagent execution in a dedicated worktree.
Skip if: Developers still scoping features or lacking an approved plan should use planning and review skills before invoking build.
When should I use this skill?
An approved plan exists in ai-workspace/plans or a one-sentence hotfix needs direct TDD implementation in a linked worktree.
What you get
Implemented source files, configs, validation results, and a completion report from subagent batches.
- Implemented code and configs
- Validation report
- Subagent execution summary
By the numbers
- Reads task plans from ai-workspace/plans/<name>.md
- Requires plan approval at /review Step 4 or one-sentence hotfix scope
Files
/build
Execute plan tasks via subagents, validate, report.
Announce: "Starting /build — executing plan with subagent dispatch."
Prerequisites
- Plan approved by
/review(Step 4), OR one-sentence scope / hotfix (no plan) - Working in a linked worktree (not primary)
With Plan
1. Load
Read ai-workspace/plans/<name>.md. Extract tasks into ordered batches:
- Tasks under the same step or marked parallel = one batch
- Tasks with dependencies on prior tasks = separate sequential batch
- Note file paths, test expectations, and acceptance criteria per task
2. Execute Batches
Batches run sequentially. Tasks within a batch dispatch in parallel via subagents.
Agent selection per task:
| Plan structure | Agent | Notes |
|---|---|---|
| Separate "write test" + "implement" tasks | test-writer (RED) then implementer (GREEN) | Sequential within the pair |
| Combined task ("implement X with tests") | implementer | Handles TDD internally |
| Docs-only task | doc-writer |
Parallel safety: only dispatch tasks in parallel when they touch different files.
Subagent prompt — provide each agent:
You are implementing Task N: [task name]
## Task Description
[FULL TEXT from plan — paste it, don't make the subagent read the file]
## Context
[Where this fits, what earlier batches produced, architectural decisions]
## Working Directory
[Absolute path to worktree]
## Project Conventions
- TDD: write failing test first, make it pass, refactor
- Commit after task completes (conventional commits) AND ensure your work is on disk before reporting DONE — the inter-batch step commits a batch boundary, but your task-level commits make recovery from inter-batch failures cleaner
- TypeScript strict, ESM, Biome, Vitest, Pino logger, no barrel exports
- Self-review before reporting back
## Report: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXTHandle responses:
| Status | Action |
|---|---|
| DONE | Mark task complete |
| DONE_WITH_CONCERNS | Read concerns — if correctness/scope, address before continuing |
| NEEDS_CONTEXT | Provide missing context, re-dispatch |
| BLOCKED | Assess: more context? more capable model? break smaller? escalate to human? |
| Task touches protected file | Stop immediately — never dispatch |
Never retry BLOCKED without changing something.
Inter-batch check — after each batch, verify no regressions AND commit the batch's output before starting the next batch:
pnpm typecheck && pnpm test
git -C "$WORKTREE" add -A
git -C "$WORKTREE" commit -m "<type>(<scope>): batch N — <summary>"Per-task commits inside a batch are best-effort; batch-boundary commits are mandatory (per /task invariant REQUIRE batch.commit BEFORE batch.next). A batch that finishes verify but doesn't commit can lose all its work if the next batch fails or the session ends. The wip-checkpoint Stop hook (ADR-008) captures dirty state at session end as a backstop, but inter-batch commits keep the recovery shape clean — per-batch granularity in branch history rather than a single dirty-state blob on the side ref.
3. Validate (Hard Gate)
After ALL batches complete:
pnpm validateRead the output. Never claim success without evidence. If it fails: 1. Diagnose the failure 2. Fix (dispatch subagent or fix directly for small issues) 3. Re-run pnpm validate 4. Max 3 fix-validate cycles. If still failing, stop and report.
Step 6 (/review) CANNOT begin until validate passes.
4. Report
Build complete.
Tasks: <completed>/<total>
Validate: PASS
Next step: /review (Step 6)Include any DONE_WITH_CONCERNS notes. Update .branch-context.md with decisions made during build.
Without Plan (Hotfix / One-Sentence Scope)
Implement directly — no subagent orchestration for small scope.
1. TDD: write failing test (RED), implement fix (GREEN), refactor 2. Minimal change: fix the defect, nothing else (hotfixes) 3. Root cause: document in commit message body (hotfixes) 4. Validate: pnpm validate — same hard gate, same 3-attempt max
Codex / Cursor Fallback
No subagent dispatch. Execute tasks sequentially in main session. Same validation gate applies.
Integration
| Relation | Skill |
|---|---|
| Called by | /task (Step 5) |
| Depends on | /blueprint (Step 3) + /review plan approval (Step 4) |
| Followed by | /review build review (Step 6) |
Related skills
How it compares
Pick build over generic coding skills when a structured plan file already exists and you need batched subagent execution with validation in a worktree.
FAQ
What does the build skill require before running?
build requires either a plan approved by `/review` (Step 4) stored under `ai-workspace/plans/<name>.md`, or a one-sentence hotfix scope. The skill also expects work inside a linked git worktree rather than the primary repository checkout.
How does build handle parallel plan tasks?
build reads the plan markdown, extracts tasks into ordered batches, and groups tasks under the same step or marked parallel into one batch. Tasks that depend on earlier work are placed in separate sequential batches before subagent dispatch.