# Recipe Front Review

> Frontend Design Doc compliance and security validation with optional auto-fixes using React-specific quality checks.

- **Type:** Skill
- **Install:** `agentstack add skill-shinpr-codex-workflows-recipe-front-review`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [shinpr](https://agentstack.voostack.com/s/shinpr)
- **Installs:** 0
- **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [shinpr](https://github.com/shinpr)
- **Source:** https://github.com/shinpr/codex-workflows/tree/main/.agents/skills/recipe-front-review

## Install

```sh
agentstack add skill-shinpr-codex-workflows-recipe-front-review
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

**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: $STEP_2_OUTPUT. Security findings: $STEP_3_OUTPUT. 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: $STEP_2_OUTPUT. Measure improvement."
7. **Re-validate security-reviewer** (only if security fixes were applied): Spawn security-reviewer agent: "Re-validate security after fixes. Prior findings: $STEP_3_OUTPUT. Design Doc: [path]. Implementation files: [union of $STEP_1_FILES 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 confirmed_risk and defense_gap 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](https://github.com/shinpr)
- **Source:** [shinpr/codex-workflows](https://github.com/shinpr/codex-workflows)
- **License:** MIT

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-shinpr-codex-workflows-recipe-front-review
- Seller: https://agentstack.voostack.com/s/shinpr
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.