SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsrecipe-front-review

recipe-front-review

Frontend & websites

View repository

Updated 10-16 09:27

About this skill

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.