/recipe-fullstack-build

name: recipe-fullstack-build
description: Execute materialized fullstack task files with layer-aware agent routing
disable-model-invocation: true

**Explicit User Instruction**: The user explicitly instructs and authorizes every subagent call named in this recipe. Execute each applicable call when its prerequisites are met.

Execute Skill: llm-friendly-context before writing Agent prompts, handoffs, or generated artifacts. Execute Skill: subagents-orchestration-guide before making workflow decisions, invoking agents, or resolving findings.

Orchestrator Definition

**Core Identity**: "I am an orchestrator." (see subagents-orchestration-guide skill)

**Local authority gate**: Make this recipe's workflow decisions and validate each returned result directly; delegate semantic deliverable production to the named specialist.

**Review Resolution Gate [MANDATORY]**: Resolve every actionable deliverable-review finding through subagents-orchestration-guide `Review Resolution` before correction or progression. Before the first finding disposition, read `references/review-resolution.md` from the loaded subagents-orchestration-guide skill.

Required Reference

**MANDATORY**: Read `references/monorepo-flow.md` from subagents-orchestration-guide skill BEFORE proceeding. Follow the Extended Task Cycle and Agent Routing defined there.

Execution Protocol

1. **Invoke named specialists for deliverable production** — pass deliverable paths between them and validate their results (see subagents-orchestration-guide "Orchestrator Execution Boundary") 2. **Route agents by task filename pattern** (see monorepo-flow.md reference):

• `*-backend-task-*` → task-executor + quality-fixer
• `*-frontend-task-*` → task-executor-frontend + quality-fixer-frontend

3. **Follow the 4-step task cycle exactly**: execute → branch on executor result → quality-fix → commit 4. **Enter autonomous mode** when the user provides execution instruction with an existing Work Plan or task files — this IS the batch approval 5. **Scope**: Complete consumed task-set execution, post-implementation verification, consumed-task cleanup, and completion reporting in order, or stop autonomous execution at the current phase for a valid user-owned escalation. Advance only when the current phase's stated transition condition is satisfied.

**CRITICAL**: Run layer-appropriate quality-fixer(s) before every commit.

Work plan: $ARGUMENTS

Pre-execution Prerequisites

Work Plan Resolution

Before any task processing, locate the work plan. Resolution rule: 1. Use the work plan explicitly supplied in `$ARGUMENTS` when present. 2. Otherwise group layer-aware task files by the existing `{plan-name}-{backend|frontend}-task-*.md` naming contract and map each group to `docs/plans/{plan-name}.md`. 3. When task groups produce no candidate, use the only Work Plan under `docs/plans/` when exactly one exists. 4. Select the sole candidate. When multiple candidates remain, present them for selection. When none exists, continue through the missing-prerequisite branch below.

Consumed Task Set

Compute the **Consumed Task Set** for this run — the exact files this recipe owns, executes, and later deletes. Use the same restricted pattern as Work Plan Resolution:

1. List task files in `docs/plans/tasks/` matching the layer-aware patterns `{plan-name}-backend-task-*.md` and `{plan-name}-frontend-task-*.md` for the `{plan-name}` resolved by Work Plan Resolution. Single-layer tasks are excluded

Every subsequent reference to "task files" in this recipe — Task Generation Decision Flow, Task Execution Cycle iteration, and Final Cleanup — uses this set, not the unrestricted `docs/plans/tasks/*.md` glob.

Task Generation Decision Flow

Analyze the Consumed Task Set and determine the action required:

| State | Criteria | Next Action | |-------|----------|-------------| | Tasks exist | Consumed Task Set is non-empty | User's execution instruction serves as batch approval → Enter autonomous execution immediately | | No tasks + plan exists | Consumed Task Set is empty and the resolved work plan exists | User's execution instruction serves as batch approval → Run task-decomposer | | Neither exists + Design Doc exists | No plan, no Consumed Task Set, but `docs/design/*.md` exists | Invoke work-planner to create a work plan, then run document-reviewer (`dev-workflows:document-reviewer`, doc_type: WorkPlan). Run Review Resolution through correction re-review, its parent requirement or authority exits, and convergence, using work-planner for rerouted corrections; then present the resolved plan for batch approval before task materialization | | Neither exists | No plan, no Consumed Task Set, no Design Doc | Report missing prerequisites to user and stop |

Task Materialization Phase (Conditional)

When the Consumed Task Set is empty:

1. Task Materialization

Invoke task-decomposer using Agent tool:

• `subagent_type`: "dev-workflows:task-decomposer"
• `description`: "Materialize work plan tasks"
• `prompt`: "Read work plan at docs/plans/[plan-name].md and output individual single-commit task files in docs/plans/tasks/. Use layer-aware naming: {plan}-backend-task-{n}.md, {plan}-frontend-task-{n}.md from each Work Plan task's Executor lane."

2. Verify Generation

Recompute the Consumed Task Set using the same restricted pattern from the Consumed Task Set section above. When it remains empty, apply Specialist Result Acceptance: validate the invocation and returned artifacts, correct recoverable input or naming errors, and rerun.

Pre-execution Checklist

• [ ] Confirmed Consumed Task Set is non-empty (computed in the Consumed Task Set section above)
• [ ] Identified task execution order within the Consumed Task Set (dependencies)
• [ ] **Environment check**: Can I execute per-task commit cycle?
• If commit capability is unavailable → Apply Specialist Result Acceptance before autonomous mode
• Other environments (tests, quality tools) →