/recipe-front-review

name: recipe-front-review
description: Reviews completed frontend implementation for governing-source compliance, scope economy, repository quality, and security, then applies user-approved React corrections.
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.

**Context**: Post-implementation quality assurance for React/TypeScript frontend

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 Gate**: Complete Steps 1-10 in order, following only the branches activated by their stated conditions. Advance through each review, correction, and re-validation transition only at its declared convergence condition. Present the final report after every applicable finding and retained quality limitation reaches its required disposition or retry result.

Execution Method

• Implementation review → performed by code-reviewer
• Security validation → performed by security-reviewer
• **Code-side fix path**: Fix implementation → task-executor-frontend; Quality checks → quality-fixer-frontend; Re-validation → code-reviewer / security-reviewer
• **Design-side update path**: DD revision → technical-designer-frontend (update mode); DD review → document-reviewer; cross-DD consistency → design-sync (when multiple DDs exist); Re-validation → code-reviewer

The design-side path applies when the Design Doc is stale, excessive, or incorrect for the required outcome. Neither path makes the existing implementation or the prior design authoritative by default.

At each Agent invocation below, build the prompt as a mechanical extraction: copy the named source values into the exact fields, apply only the declared serialization, then invoke immediately.

Design Doc: $ARGUMENTS

Execution Flow

Step 1: Prerequisite Check

Derive `implementationFiles` from paths changed between the current branch's merge base with the repository's default branch and the current repository state, including committed changes, working-tree changes, and untracked files. `implementationFiles` contains each changed path whose contents implement or verify the reviewed behavior or control its schema, build, deployment, or runtime behavior, including source files, tests, migrations, executable scripts, and behavior-affecting configuration. Governing documents and Work Plans retain their dedicated roles in document selection and governing-document inputs; task files and documentation-only paths remain outside this recipe's code and security review inputs.

Use the Design Doc explicitly supplied in `$ARGUMENTS`. When omitted, first use a Work Plan whose declared target files or responsibilities intersect `implementationFiles` and take its recorded Design Doc path. When that does not produce one candidate, use the sole Design Doc under `docs/design/`. Present candidates only when multiple governing Design Docs remain; report a missing prerequisite when none exists.

Step 2: Execute code-reviewer

Invoke code-reviewer using Agent tool:

• `subagent_type`: "dev-workflows-frontend:code-reviewer"
• `description`: "Completed frontend implementation review"
• `prompt`: "Review the completed frontend implementation. governingDocuments: [{\"type\":\"design-doc\",\"path\":\"[path]\"}]. implementationFiles: [implementationFiles]. Return the initial review JSON."

**Store output as**: `$STEP_2_OUTPUT`

Step 3: Execute security-reviewer

Invoke security-reviewer using Agent tool:

• `subagent_type`: "dev-workflows-frontend:security-reviewer"
• `description`: "Security review"
• `prompt`: "governingDocuments: [{\"type\":\"design-doc\",\"path\":\"[path]\"}]. implementationFiles: [implementationFiles]. Review security compliance."

**Store output as**: `$STEP_3_OUTPUT`

Step 4: Verdict and Response

When either reviewer returns a blocked or otherwise unusable result, apply subagents-orchestration-guide Specialist Result Acceptance to its semantic cause. Carry only a remaining verification limitation into the report.

Apply the Review Resolution Gate to both outputs before reporting or routing them. Finding dispositions determine routing.

For each `apply` finding, compute a proposed route using the rule below. A finding takes one route, or both `d` and `c` when a selected reduction removes a design statement and the implementation it authorized:

| Finding pattern | Recommended route | |-----------------|-------------------| | Resolution keeps the current implementation because it matches the original requirement and corrects a stale Design Doc | `d` (Design-side update) | | Resolution requires changing implementation to reach the accepted state | `c` (Code-side correction) | | Resolution removes a mechanism the Design Doc selected that the required outcome does not need | `d` and `c` (design statement first) |

Then present the adjudicated result to the user. Group `apply` findings by proposed route and list declined IDs with their reasons:

Implementation Review: [verdict from code-reviewer]
  Acceptance Criteria:
  - [fulfilled] [item]: [evidence]
  - [unfulfilled] [item] -> [corresponding finding ID under Re