recipe-review git:20260915.0c8f517A

Immutable. This exact content is served forever at /api/v1/blob/91d7b5602de6e1b5.

---
name: recipe-review
description: "Reviews completed implementation for governing-source compliance, scope economy, repository quality, and security, and applies user-approved corrections."
---

## Required Skills [LOAD BEFORE EXECUTION]

1. [LOAD IF NOT ACTIVE] `coding-rules` — repository implementation rules
2. [LOAD IF NOT ACTIVE] `testing` — verification and test quality rules
3. [LOAD IF NOT ACTIVE] `ai-development-guide` — review and repair discipline
4. [LOAD IF NOT ACTIVE] `llm-friendly-context` — task file contract
5. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` — agent coordination and result handling

**Spawn rule**: every `spawn_agent` call uses `fork_turns="none"` so the subagent receives only the task message and explicitly provided context.

**Context**: Post-implementation quality assurance

## Orchestrator Definition

**Core Identity**: Coordinate review, perform lightweight evidence collection and routing directly, and invoke specialists for semantic review and implementation repair.

**Execution Plan**: Reuse the active execution plan. When the workflow has multiple dependent actions and no plan exists, create one that tracks them through final verification.

## Execution Method

- Implementation review -> Spawn code-reviewer agent
- Security validation -> Spawn security-reviewer agent
- Code-side fix path -> Spawn task-executor agent
- Design-side update path -> Spawn technical-designer in update mode, then document-reviewer, then design-sync when multiple Design Docs exist
- Quality checks -> Spawn quality-fixer agent
- Re-validation -> Spawn code-reviewer / security-reviewer agents

Orchestrator spawns sub-agents and passes structured data between them.

Design Doc (uses most recent if omitted): $ARGUMENTS

## Execution Flow

### Step 1: Prerequisite Check
Identify the Design Doc in `docs/design/`. Derive `$STEP_1_FILES` as the complete change set for the current work from repository history, tracking state, and the working tree. Include committed, staged, unstaged, and untracked paths, and pass the complete set unchanged to both reviewers.
If a single active work plan is explicitly provided or unambiguously resolved for that Design Doc, read its `Review Scope` line. Otherwise set `Work Plan: none` and `Review Scope: none`; do not infer.

### Step 2: Execute code-reviewer
Spawn code-reviewer agent: "Review the completed implementation. governingDocuments: [{type: design-doc, path: [path]}]. Work Plan: [resolved work plan path or none]. Review Scope: [literal Review Scope value or none]. implementationFiles: [$STEP_1_FILES]. Return the initial review JSON."

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

### Step 3: Execute security-reviewer
Spawn security-reviewer with `governingDocuments: [{type: "design-doc", path: [path]}]` and `implementationFiles: $STEP_1_FILES`.

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

### Step 4: Verdict and Response

**Review reception:** Unnecessary repairs create lasting work. Before assigning a fix, use Review Resolution to judge no change, removal or narrowing, and reuse first; record why any retained or added mechanism is necessary.

If either reviewer returns a blocked or otherwise unusable result, apply Orchestrator Escalation Resolution before continuing.

Apply a security-reviewer finding only when leaving it unresolved would violate an explicit governing requirement or repository rule, or leave a concrete material security failure in the actual reachable trust model. The violated requirement, rule, or failure defines implementation scope: route the smallest correction that resolves it, treating the reviewer's suggestion as one candidate implementation.

**Code criteria**:
- `code-reviewer` verdict is `pass`

**Security criteria**:
- `pass` -> Pass
- `needs_revision` -> Requires disposition

Report required corrections from both results, then apply Review Resolution before proposing corrections:

```
Implementation Review: [verdict]
  Acceptance Criteria: [fulfilled/unfulfilled items with evidence]
  Findings: [required-correction findings with basis and effect]

Security Review: [status from security-reviewer]
  Findings by category:
  - [confirmed_risk] [location]: [description] — [rationale]
  - [defense_gap] [location]: [description] — [rationale]

Proposed corrections:
  Code-side fix
  Design-side update
```

Apply Review Resolution before presenting results. Recommend a correction route only for findings classified `apply` or `user decision required`:
- Use the design-side route when the Design Doc is stale, excessive, or incorrect for the required outcome. A selected reduction may require both source updates and code removal; neither route makes existing implementation authoritative.
- Use the code-side route when the required correction changes implementation.

Present the review. When no correction remains, proceed to Step 11. Because this recipe is a review request rather than prior implementation authority, ask once before applying the proposed code or document corrections.

If the user declines corrections, skip Steps 5-10 and proceed to Step 11.

### Step 5: Prepare Fix Context

Use the llm-friendly-context Task File Contract.

### Step 5d: Design-Side Update

Run this step only when the user selects a design-side correction.

1. Spawn technical-designer agent in update mode: "Update Design Doc at [path]. Apply the selected Review Resolution disposition to these findings; neither existing implementation nor the prior design is automatically correct: [d-routed findings with code locations and current Design Doc values]. Update the relevant sections and add change history."
2. Spawn document-reviewer agent: "Review updated Design Doc at [path] for consistency and completeness. doc_type: DesignDoc. review_context: update."
3. If multiple Design Docs exist in `docs/design/`, spawn design-sync agent: "Check cross-Design Doc consistency after updating [path]."
4. If the user selected both routes, re-evaluate the code-side findings against the updated Design Doc and drop any that are now satisfied.

### Step 6: Create Task File

Create task file at `docs/plans/tasks/review-fixes-task-01.md`
Include only findings selected for code-side correction.

### Step 7: Execute Fixes

Spawn task-executor agent: "Execute the accepted review fixes. Task file: docs/plans/tasks/review-fixes-task-01.md."

Start the Per-Task Change Set before execution. Inspect the executor result and repository diff, add its paths, and continue when the requested fixes are present; resolve an incomplete or unusable result through Orchestrator Escalation Resolution.

### Step 8: Quality Check

Spawn quality-fixer with `task_file`, `filesModified: taskWriteSet`, and executor operation-verification evidence. On pass, add its paths and commit the reconciled Per-Task Change Set; repair stubs through task-executor, accumulate their paths, and resolve blocked results through Orchestrator Escalation Resolution.

### Step 9: Re-validate code-reviewer

Spawn code-reviewer with the original governing documents and implementation change set, plus `prior_feedback: [the complete Step 2 result, applied corrections, declined finding IDs with reasons and evidence, and the correction paths or diff]`. Apply its Rerun Boundary.

### Step 10: Re-validate security-reviewer

Spawn security-reviewer with `governingDocuments: [{type: "design-doc", path: [path]}]`, the actual implementation and fix files, and `prior_feedback: [applied corrections and declined finding IDs with reasons and evidence from Step 4]`.

After any code fix, both Steps 9 and 10 are mandatory even when only one reviewer initially reported a finding.

Apply Review Resolution to rerun findings. Its convergence rule governs any further correction and rerun; code-reviewer receives the latest complete result and the next correction paths or diff.

### Step 11: Final Report

Delete the review-fix task file this recipe created, if present. Its work is committed; `docs/plans/` is ephemeral working state.

```
Implementation Review:
  Initial: [verdict]
  Final: [verdict] (if fixes executed)

Security Review:
  Initial: [status]
  Final: [status] (if fixes executed)

Remaining issues:
- [items requiring manual intervention]
```

## Completion Criteria

- [ ] Design Doc identified and implementation files checked
- [ ] code-reviewer spawned and compliance validated
- [ ] security-reviewer spawned and security reviewed
- [ ] Results presented to user
- [ ] Fixes executed if user approved (with quality-fixer gate)
- [ ] Re-validation completed after fixes (both code and security)
- [ ] Final report presented to user

**Scope**: Completed implementation review, security review, and approved corrections.