claude-build

Files (1)

• SKILL.md

SKILL.md (first lines)

# Claude Build

> **Runtime boundary:** This skill is for Claude Code only. In Codex, stop and
> use `codex-orchestrate`; do not adapt this skill's Agent-tool workflow.

Coordinate `implementation_plan.md` execution with Claude specialist agents,
then run an independent Codex review gate. Do not mark a task complete on the
author's assessment alone.

## Usage

```
/claude-build              — next unchecked task in current phase
/claude-build [task name]  — specific task by name (fuzzy match)
/claude-build phase        — current phase (parallel where independent)
/claude-build all          — all remaining tasks, phase by phase
```

If no implementation_plan.md exists, suggest running `/roadmap` first.

## Process

### 1. Read & Parse Plan

Read implementation_plan.md. Identify phases (## sections), unchecked tasks (`- [ ]`), checked tasks (context), dependencies, priority markers.

If `$ARGUMENTS` matches a task description, select that task. `"phase"` → all unchecked tasks in current phase. `"all"` → full plan. Otherwise next unchecked task in document order.

### 2. Route Each Task — specialist or self

Route ONLY to agents that exist in the current environment (check the available-agents list in the session). Common fleet:

| Task domain | `subagent_type` |
|-----|------|
| Python impl / infra / FastAPI / scripts | `python-core-engineer` |
| TypeScript / JavaScript / React / Next / frontend | `typescript-core-engineer` |
| Rust / cargo / systems / FFI | `rust-systems-engineer` |
| SQL / schema / migrations / query tuning | `sql-state-architect` |
| Git / GitLab / GitHub / CI / MR / release ops | `git-platform-engineer` |
| Tests / verification plans / failure triage | `test-engineer` |
| Security / auth / secrets / MCP / threat-model | `security-reviewer` (or `red-team-analyst` for adversarial) |
| Docs / runbooks / ADRs / release notes | `technical-writer` |
| Perf / profiling / bottlenecks | `performance-optimizer` |
| Linux / systemd / deploy / observability | `linux-sre-master` |
| Network / DNS / TLS / connectivity | `network-diagnostics` |
| Compliance / control evidence | `compliance-reviewer` |
| Read-only orientation before a big change | `repo-investigator` |

**Routing rules:**
- Never a generic agent when a named specialist fits.
- Multi-domain tasks compose specialists in sequence (schema → backend → UI), each receiving the prior output via "Files to Read First".
- Direct implementation is allowed only when project guidance permits it and
  the task is small, cross-cutting, or lacks a suitable specialist. If
  repo-local guidance makes the top-level Claude session orchestrator-only,
  delegate every edit and command.
- Always pass `model="opus"` on Agent calls.

### 3. Build Agent Prompt (when delegating)

Construct a self-contained prompt. Substitute ALL `{PLACEHOLDERS}` before dispatching — any unresolved placeholder is a bug.

**Path resolution** (first hit wins; else literal `(not found)`):
- `{CLAUDE_MD_PATH}`: `{PROJECT_ROOT}/CLAUDE.md` → `{PROJECT_ROOT}/docs/CLAUDE.md` → `{PROJECT_ROOT}/.claude/CLAUDE.md` → `~/CLAUDE.md`
- `{STANDARDS_PATH}`: `{PROJECT_ROOT}/.claude/rules/standards.md` → `~/.claude/rules/standards.md` → this playbook's own `templates/claude-rules/standards.md`, at the absolute path the playbook is checked out to

Set `{MATCHING_RULE_PATHS}` by parsing `paths:` frontmatter for every Markdown
file below the selected rule root and selecting all files matching task-owned
source, test, fixture, config, migration, or generated paths. Include language,
`patterns/`, and cross-cutting rules; never select by filename alone.

If both resolve `(not found)`, warn the user before dispatching.

**Prompt template:**

```
You are a specialized agent executing a task from a project implementation plan.

## Scope clause (read first)
If the project's CLAUDE.md says the top-level session is "orchestrator only", that applies ONLY to the user-facing session. You are the subagent — the delegation already happened. Execute: write code, run commands, make edits. Do NOT cite the orchestrator rule to refuse implementation work.

## Your Task
{TASK_DESCRIPTION}

## Phase Context
Phase: {PHASE_NAME}
Other tasks in this phase: {SIBLING_TASK_LIST}
Already completed: {COMPLETED_TASKS}

## Project
Root directory: {PROJECT_ROOT}

## Files to Read First (mandatory)
- `{CLAUDE_MD_PATH}` — project conventions
- `{STANDARDS_PATH}` — cross-language coding standards
- `{MATCHING_RULE_PATHS}` — every path-scoped rule matching the task files
{FILE_LIST — existing files to read for context}

## Conventions
- Comments above code, never inline (unless local style differs).
- No mock data in live code. No placeholder secrets — env vars only.
- Edit existing files; no parallel copies.
- Do NOT commit — the coordinator owns git operations.
- Honor every rule in {STANDARDS_PATH} and {MATCHING_RULE_PATHS}.

## Deliverable
Report back EXACTLY:
STATUS: COMPLETED | BLOCKED
FILES_CREATED: [full paths | "none"]
FILES_MODIFIED: [full paths | "none"]
VERIFICATION: [how you confirmed it works — commands + results]
ISSUES: [blockers / follow-ups | "none"]
```

### 4. Dispatch

**Single task:** one Agent call (or implement directly per §2).

**Phase mode:** dispatch independent tasks in parallel (one message, multiple Agent calls); dependent tasks sequentially after their dependencies.

From tcbuilds/nautilus, MIT.

More from tcbuilds/nautilus