--- name: auto-build-full description: Orchestrates subagents to explore, plan, implement, verify, and review a feature end-to-end. Best fit for larger features or features requiring deeper hands-on verification. --- # Auto Build Full You are the **orchestrator**. Do not implement the feature yourself. Instead, spawn focused subagents, review their output between steps, and keep the workflow moving. Escalate to the user only when requirements are very ambiguous, access is blocked, or the workflow cannot proceed. Formulate each subagent's Task prompt from the step instructions below, passing prior subagent output and absolute project paths as context. ## Workflow overview ``` Explore (A) → Plan (B) → [orchestrator reviews plan] → Implement (C…) → Verify (D) → Code Review (E) → [orchestrator makes reasonable fixes] → Final report ``` Track the feature number `` from `docs/features/_PLAN.md` throughout. --- ## Step 1 — Subagent A: Explore Spawn an `explore` subagent. Pass the feature description and instruct it to: 1. Explore the codebase to understand current state relevant to the feature 2. Infer user intent; resolve ambiguities from code conventions and context when possible 3. Ask the user **only** if something is genuinely unclear and would materially change the implementation 4. Return a concise brief: relevant files/modules, existing patterns to follow, open questions (resolved or escalated), and recommended scope Do not write a plan or code. Wait for A to finish before continuing. If A escalates unanswered questions, ask the user, then re-run or resume A with answers. --- ## Step 2 — Subagent B: Plan Spawn a subagent. It must **read and follow** the `plan-feature` skill. Pass A's exploration brief and the original feature description. B writes `docs/features/_PLAN.md`. --- ## Step 3 — Orchestrator reviews plan Read the plan yourself. Adjust the plan file directly if needed: - Ensure the plan matches the user's intent and fix any scope creep or contradictions to the user's description - Look for any overengineering and opportunities for a simpler or more focused solution - Ensure that the solution "makes sense" and is the most reasonable approach given the current code and user intent Keep edits minimal. Do not rewrite the entire plan. --- ## Step 4 — Subagent C: Implement ### Small features (single phase or few files) Spawn a subagent with the plan path and instruction to implement the **entire** plan. ### Large features (multiple phases) 1. Create `docs/features/_PROGRESS.md` with a checklist of plan phases 2. Spawn subagent(s) per phase: - **Sequential** when phases depend on each other (e.g. data layer before UI/API) - **Parallel** subagents in one message when phases are independent (e.g. Phase 2A UI + Phase 2B API) Update `_PROGRESS.md` after each subagent or wave completes. Each implementer gets: plan path, phase scope, exploration brief, and files already touched. The implementer writes code only; no re-planning, no verify or review workflow. Match existing project conventions and keep scope to the plan. Wait for all implementers to finish before continuing. --- ## Step 5 — Subagent D: Verify Spawn a subagent to launch and validate the app: 1. Run lint and tests if the project has them; fix failures before proceeding 2. Start the dev server (`pnpm run dev` or project equivalent) in the background 3. Smoke-test key flows for the feature using built-in browser tooling (navigate, snapshot, exercise critical paths) 4. Fix issues found during verification 5. Return: commands run, pass/fail summary, fixes made, URLs tested If browser tooling is unavailable, fall back to HTTP health checks and report the gap. Stop the dev server when done unless the user would expect it running. --- ## Step 6 — Subagent E: Code Review Spawn another subagent. This agent must **read and follow** the `code-review` skill to create an objective unbiased review. Do not convey "what was implemented" to this subagent. Simply give it the source plan and instruct it to use the code-review skill. Pass the plan path. E should: 1. Review the implementation against the plan (bugs, data alignment, style, over-engineering) 2. Write `docs/features/_REVIEW.md` documenting findings This agent's sole responsibility is creating the review. --- ## Step 7 — Make reasonable fixes Review the code-review output **yourself** and decide what issues are actually critical and require fixes. Then, make the fixes yourself. Don't go overboard fixing every single thing - focus on the things that need fixing to bring the implementation to meet the user's expectations: 1. Fix issues worth fixing now: correctness bugs, data-alignment issues, and plan deviations 2. Defer large refactors unless critical; note deferred items in the review doc with reasoning 3. Run lint and tests if the project has them; fix failures introduced by the fixes If fixes are substantial, re-run a lightweight verify pass (lint + targeted browser check). --- ## Step 8 — Final report Tell the user: - What was built (1–3 sentences) - Plan and review doc paths (`_PLAN.md`, `_REVIEW.md`, `_PROGRESS.md` if used) - Notable deviations from the original description or plan - Deferred review items and why - How to run/test the feature locally --- ## Escalation rules Escalate to the user when: - Subagent A cannot resolve a blocking ambiguity - Missing credentials, permissions, or external services - Plan and feature description fundamentally conflict - Verify cannot start the app after reasonable fixes - A subagent fails twice on the same step After escalation, incorporate the user's answer and resume from the failed step.