/recipe-front-build

name: recipe-front-build
description: Execute materialized frontend task files in autonomous execution mode
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.

**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. **Follow the 4-step task cycle exactly for each task in the Consumed Task Set**: execute → branch on executor result → quality-fix → commit. Corrections produced outside that cycle reuse its executor-result branching and quality gate, and defer only the commit to their own phase's rule 3. **Enter autonomous mode** when the user provides execution instruction with an existing Work Plan or task files — this IS the batch approval 4. **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**: Commit only after quality-fixer-frontend returns `pass` or `verification_incomplete`. A quality-fixer-frontend pass authorizes a commit at a defined commit point; it does not create one.

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 single-layer task files by the existing `{plan-name}-task-*.md` naming contract and map each group to `docs/plans/{plan-name}.md`. Exclude layer-aware fullstack task sets. 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 single-layer pattern `{plan-name}-task-*.md` for the `{plan-name}` resolved by Work Plan Resolution. Layer-aware fullstack 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-frontend: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-frontend: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/."

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.

**Flow**: Task generation → Consumed Task Set recompute → Autonomous execution (in this order)

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) → Quality agents retain proof limitations while the task cycle continues

Task Execution Cycle (4-Step Cycle)

**MANDATORY