Recipe Front Review

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

Required Skills [LOAD BEFORE EXECUTION]

1. [LOAD IF NOT ACTIVE] coding-rules -- coding standards
2. [LOAD IF NOT ACTIVE] testing -- test strategy and quality gates
3. [LOAD IF NOT ACTIVE] ai-development-guide -- AI development patterns
4. [LOAD IF NOT ACTIVE] llm-friendly-context -- clear prompts, handoffs, and generated artifacts

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

Execution Method

• Compliance validation -> performed by code-reviewer
• Security validation -> performed by security-reviewer
• Rule analysis -> performed by rule-advisor
• Code-side fix path -> performed by task-executor-frontend
• Design-side update path -> performed by technical-designer-frontend in update mode, then document-reviewer, then design-sync when multiple Design Docs exist
• Quality checks -> performed by quality-fixer-frontend
• Re-validation -> performed by code-reviewer / security-reviewer

Orchestrator spawns agents and passes structured data between them.

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

Execution Flow

1. Prerequisite Check

Identify the Design Doc in docs/design/ and check implementation files changed from the default branch (detect via git symbolic-ref refs/remotes/origin/HEAD or fall back to current branch diff). 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.

[STOP -- BLOCKING] If no Design Doc or implementation files found, notify user and halt. CANNOT proceed without both a Design Doc and implementation files.

2. Execute code-reviewer

Spawn code-reviewer agent: "Validate Design Doc compliance for [design-doc-path]. Work Plan: [resolved work plan path or none]. Review Scope: [literal Review Scope value or none]. Implementation files: [git diff file list]. Review mode: full. Return structured JSON report per your Output Format specification."

Store output as: $STEP_2_OUTPUT

3. Execute security-reviewer

Spawn security-reviewer agent: "Design Doc: [path]. Implementation files: [file list from git diff in Step 1]. Review security compliance."

Store output as: $STEP_3_OUTPUT and $STEP_1_FILES (the initial file list)

4. Verdict and Response

If security-reviewer returned blocked: Stop immediately. Report the blocked finding and escalate to user. Do not proceed to fix steps.

Code compliance criteria (considering project stage):

• code-reviewer verdict is pass
• Coverage thresholds pass only when configured by the project, task file, work plan, or Design Doc
• Determine pass/fail from the code-reviewer verdict and configured coverage thresholds; treat complianceRate as diagnostic context only

Security criteria:

• approved or approved_with_notes -> Pass
• needs_revision -> Fail

Report both results independently using subagent output fields only (do not add fields that are not in the subagent response):

Code Compliance: [complianceRate from code-reviewer]
  Verdict: [verdict from code-reviewer]
  Identifier Match Rate: [identifierMatchRate from code-reviewer]
  Acceptance Criteria:
  - [fulfilled] [item] (confidence: [high/medium/low])
  - [partially_fulfilled] [item]: [gap] — [suggestion]
  - [unfulfilled] [item]: [gap] — [suggestion]
  Identifier Mismatches (show only mismatches; write `None` if all identifiers match):
  - None
  - [identifier]: DD=[designDocValue] Code=[codeValue] at [location] (confidence: [high/medium/low])
  Quality Findings:
  - [category] [location]: [description] — [rationale]

Security Review: [status from security-reviewer]
  Findings by category:
  - [confirmed_risk] [location]: [description] — [rationale]
  - [defense_gap] [location]: [description] — [rationale]
  - [hardening] [location]: [description] — [rationale]
  - [policy] [location]: [description] — [rationale]
  Notes: [notes from security-reviewer, if present]

Resolve discrepancies by route:
  c) Code-side fix
  d) Design-side update
  s) Skip

Default: accept all recommended routes.

Accepted response formats:
- empty input -- accept every recommended route
- `all-recommended` -- accept every recommended route
- `all:c`, `all:d`, or `all:s` -- apply one route to every finding
- Per-finding routes, e.g. `F1:c, F2:d, F3:s`

Before presenting results, recommend a route for each finding:

• Use d when implementation intent matches the requirement but the Design Doc is stale or too narrow.
• Use c when code drifted from a still-correct Design Doc, or when the finding is reliability, security, or maintainability related.
• Use s only when the user explicitly accepts the current state without changes.

[STOP -- BLOCKING] Wait for user response on routes. CANNOT proceed with fixes or document updates without user approval.

If all findings are skipped: Skip fix steps, proceed to Final Report.

Pre-fix Metacognition

1. Spawn rule-advisor agent: "Analyze fixes needed. Code issues: $STEP2OUTPUT. Security findings: $STEP3OUTPUT. Determine root solutions vs symptomatic treatments."
2. Design-side update: If any finding is routed to d, spawn technical-designer-frontend in update mode, then document-reviewer, then design-sync when multiple Design Docs exist. If both d and c routes exist, re-evaluate c findings against the updated Design Doc and drop any now satisfied.
3. Register tasks: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Create task file -> docs/plans/tasks/review-fixes-YYYYMMDD.md. Include only code compliance issues and security requiredFixes routed to c.
4. Spawn task-executor-frontend agent: "Execute staged auto-fixes for [task-file-path]. Stop at 5 files."
5. Spawn quality-fixer-frontend agent: "Execute all frontend quality checks and confirm quality gate passage"
6. Re-validate code-reviewer: Spawn code-reviewer agent: "Re-validate compliance for [design-doc-path]. Prior issues: $STEP2OUTPUT. Measure improvement."
7. Re-validate security-reviewer (only if security fixes were applied): Spawn security-reviewer agent: "Re-validate security after fixes. Prior findings: $STEP3OUTPUT. Design Doc: [path]. Implementation files: [union of $STEP1FILES and task-executor-frontend filesModified from step 4, deduplicated]."

ENFORCEMENT: Auto-fixes MUST go through quality-fixer-frontend before re-validation. Skipping quality checks invalidates fixes.

Final Report

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

Code Compliance:
  Initial: [X]%
  Final: [Y]% (if fixes executed)

Security Review:
  Initial: [status]
  Final: [status] (if fixes executed)
  Notes: [notes from approved_with_notes, if any]

Remaining issues:
- [items requiring manual intervention]

Auto-fixable Items

• Simple unimplemented acceptance criteria
• Error handling additions
• Contract definition fixes
• Function splitting (length/complexity improvements)
• Security confirmedrisk and defensegap fixes (input validation, auth checks, output encoding)

Non-fixable Items

• Fundamental business logic changes
• Architecture-level modifications
• Design Doc deficiencies
• Committed secrets (blocked -> human intervention)

Completion Criteria

• [ ] Design Doc compliance validated
• [ ] Security review completed
• [ ] Compliance percentage calculated
• [ ] User informed of results
• [ ] Fixes executed if requested and approved
• [ ] Quality gates passed for all fixes
• [ ] Final compliance and security re-measured

Scope: Design Doc compliance validation, security review, and auto-fixes.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: shinpr
• Source: shinpr/codex-workflows
• License: MIT

Install and usage instructions live in the source repository linked above.