name: recipe-implement description: Orchestrate the complete implementation lifecycle from requirements to deployment disable-model-invocation: true
Context: Full-cycle implementation management (Requirements Analysis → Design → Planning → Implementation → Quality Assurance)
Orchestrator Definition
Core Identity: "I am an orchestrator." (see subagents-orchestration-guide skill)
Execution Protocol:
- Delegate all work through Agent tool — invoke sub-agents, pass deliverable paths between them, and report results (permitted tools: see subagents-orchestration-guide "Orchestrator's Permitted Tools")
- Follow subagents-orchestration-guide skill flows exactly:
- Execute one step at a time in the defined flow (Large/Medium/Small scale)
- When flow specifies "Execute document-reviewer" → Execute it immediately
- Stop at every
[Stop: ...]marker → Use AskUserQuestion for confirmation and wait for approval before proceeding
- Enter autonomous mode only after "batch approval for entire implementation phase"
CRITICAL: Execute all steps, sub-agents, and stopping points defined in subagents-orchestration-guide skill flows.
Execution Decision Flow
1. Current Situation Assessment
Instruction Content: $ARGUMENTS
Assess the current situation:
| Situation Pattern | Decision Criteria | Next Action |
|---|---|---|
| New Requirements | No existing work, new feature/fix request | Start with requirement-analyzer |
| Flow Continuation | Existing docs/tasks present, continuation directive | Identify next step in sub-agents.md flow |
| Quality Errors | Error detection, test failures, build errors | Execute quality-fixer |
| Ambiguous | Intent unclear, multiple interpretations possible | Confirm with user |
2. Progress Verification for Continuation
When continuing existing flow, verify:
- Latest artifacts (PRD/ADR/Design Doc/Work Plan/Tasks)
- Current phase position (Requirements/Design/Planning/Implementation/QA)
- Identify next step in subagents-orchestration-guide skill corresponding flow
3. Next Action Execution
MANDATORY subagents-orchestration-guide skill reference:
- Verify scale-based flow (Large/Medium/Small scale)
- Confirm autonomous execution mode conditions
- Recognize mandatory stopping points
- Invoke next sub-agent defined in flow
After requirement-analyzer [Stop]
When user responds to questions:
- If response matches any
scopeDependencies.question→ Checkimpactfor scale change - If scale changes → Re-execute requirement-analyzer with updated context
- If
confidence: "confirmed"or no scale change → Proceed to next step
4. Register All Flow Steps Using TaskCreate (MANDATORY)
After scale determination, register all steps of the applicable flow using TaskCreate:
- First task: "Map preloaded skills to applicable concrete rules"
- Register each step as individual task
- Set currently executing step to
in_progressusing TaskUpdate - Complete task registration before invoking subagents
Subagents Orchestration Guide Compliance Execution
Pre-execution Checklist (MANDATORY):
- Confirmed relevant subagents-orchestration-guide skill flow
- Identified current progress position
- Clarified next step
- Recognized stopping points
- codebase-analyzer included before Design Doc creation (Medium/Large scale)
- code-verifier included before document-reviewer for Design Doc review (Medium/Large scale)
- Environment check: Can I execute per-task commit cycle?
- If commit capability unavailable → Escalate before autonomous mode
- Other environments (tests, quality tools) → Subagents will escalate
Required Flow Compliance:
- Run quality-fixer before every commit
- Obtain user approval before Edit/Write/MultiEdit outside autonomous mode
Implementation Readiness Check (between work-planner approval and task-decomposer)
After work-planner completes and the user grants batch approval, before invoking task-decomposer, read the work plan header and find the line Implementation Readiness: <status>. Apply this rule:
| Status | Action |
|---|---|
ready | Proceed to task-decomposer |
escalated | Read the work plan's Readiness Report section, surface remaining gaps to the user via AskUserQuestion: "Implementation Readiness is escalated with the following remaining gaps: [list]. Continue execution? (y/n)". On y proceed; on n stop |
pending | Present via AskUserQuestion: "Implementation Readiness is pending. Run /recipe-prepare-implementation [plan-path] first to verify the work plan is implementable, then resume. Continue without preflight? (y/n)". On y proceed; on n stop |
| absent (line missing) | Treat as pending — older work plans created before the readiness marker existed should be preflighted explicitly |
This check applies to all scales (Small / Medium / Large) because recipe-implement is the scale-agnostic orchestrator.
Scope Boundary for Subagents
Append the following block to every subagent prompt invoked from this recipe:
Scope boundary for subagents:
Operate within the task scope and referenced files in the prompt.
Use loaded skills to execute that scope.
Escalate when the required fix or investigation falls outside that scope.
Mandatory Orchestrator Responsibilities
Task Execution Quality Cycle (4-Step Cycle per Task)
Per-task cycle (complete each task before starting next):
- Agent tool (subagent_type: "dev-workflows:task-executor") → Pass task file path in prompt, receive structured response
- Check task-executor response:
status: escalation_neededorblocked→ Escalate to userrequiresTestReviewistrue→ Execute integration-test-reviewerneeds_revision→ Return to step 1 withrequiredFixesapproved→ Proceed to step 3
- Otherwise → Proceed to step 3
- quality-fixer → Quality check and fixes. Always pass the current task file path as
task_filestub_detected→ Return to step 1 withincompleteImplementations[]detailsblocked→ Escalate to userapproved→ Proceed to step 4
- git commit → Execute with Bash (on
approved)
Post-Implementation Verification (After All Tasks Complete)
After all task cycles finish, run verification agents in parallel before the completion report:
-
Invoke both in parallel using Agent tool:
- code-verifier (subagent_type: "dev-workflows:code-verifier") →
doc_type: design-doc, Design Doc path,code_paths: implementation file list (git diff --name-only main...HEAD) - security-reviewer (subagent_type: "dev-workflows:security-reviewer") → Design Doc path, implementation file list
- code-verifier (subagent_type: "dev-workflows:code-verifier") →
-
Consolidate results — check pass/fail for each:
- code-verifier: pass when
statusisconsistentormostly_consistent. fail whenneeds_revieworinconsistent. Collectdiscrepancieswith statusdrift,conflict, orgap - security-reviewer: pass when
statusisapprovedorapproved_with_notes. fail whenneeds_revision. blocked → Escalate to user - Present unified verification report to user
- code-verifier: pass when
-
Fix cycle (when any verifier failed):
- Consolidate all actionable findings into a single task file
- Execute task-executor with consolidated fixes → quality-fixer
- Re-run only the failed verifiers (by the criteria in step 2)
- Repeat until all pass or
blocked→ Escalate to user
-
All passed → Proceed to Final Cleanup
Final Cleanup
Before the completion report, delete the implementation task files this recipe consumed. Their work is committed; docs/plans/ is ephemeral working state and is not retained between recipe runs:
- Delete every file matching
docs/plans/tasks/{plan-name}-task-*.md(the{plan-name}derived from the work plan path used in this run) - Delete every file matching
docs/plans/tasks/{plan-name}-phase*-completion.md(the per-phase completion files generated by task-decomposer) - Delete the corresponding
docs/plans/tasks/_overview-{plan-name}.mdif present - Preserve the work plan itself (
docs/plans/{plan-name}.md) — the user decides whether to delete it after final review
If task files cannot be deleted (filesystem error), report the failure but do not block the completion report.
Test Information Communication
After acceptance-test-generator execution, when invoking work-planner (subagent_type: "dev-workflows:work-planner"), communicate:
- Generated integration test file path (from
generatedFiles.integration) - Generated fixture-e2e test file path or null (from
generatedFiles.fixtureE2e) - Generated service-integration-e2e test file path or null (from
generatedFiles.serviceE2e) - Per-lane E2E absence reason (from
e2eAbsenceReason.fixtureE2eande2eAbsenceReason.serviceE2e, when each lane is null) - Explicit note: integration tests are created simultaneously with implementation, fixture-e2e tests are created alongside the UI feature phase, service-integration-e2e tests are executed only in the final phase
Execution Method
All work is executed through sub-agents. Sub-agent selection follows subagents-orchestration-guide skill.