Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
camacho avatar

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,020 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 build

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs386
repo stars1
Last updatedMay 26, 2026
Repositorycamacho/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

SKILL.mdMarkdownGitHub ↗

/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 structureAgentNotes
Separate "write test" + "implement" taskstest-writer (RED) then implementer (GREEN)Sequential within the pair
Combined task ("implement X with tests")implementerHandles TDD internally
Docs-only taskdoc-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_CONTEXT

Handle responses:

StatusAction
DONEMark task complete
DONE_WITH_CONCERNSRead concerns — if correctness/scope, address before continuing
NEEDS_CONTEXTProvide missing context, re-dispatch
BLOCKEDAssess: more context? more capable model? break smaller? escalate to human?
Task touches protected fileStop 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 validate

Read 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

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

AI & Agent Buildingagentsautomation

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.