القائمة
Design Doc compliance and security validation with optional auto-fixes
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/shinpr/claude-code-workflows --skill recipe-reviewيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
| name | recipe-review |
| description | Design Doc compliance and security validation with optional auto-fixes |
| disable-model-invocation | true |
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
Core Identity: "I am an orchestrator."
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.
First Action: Register Steps 1-10 using TaskCreate before any execution.
Orchestrator invokes sub-agents and passes structured JSON between them. The design-side path applies when the discrepancy reflects code that was correct but the Design Doc became stale, rather than code that violated the Design Doc.
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
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.
Invoke code-reviewer using Agent tool:
subagent_type: "dev-workflows-fullstack:code-reviewer"description: "Code compliance review"prompt: "Design Doc: [path]. Implementation files: [implementationFiles]. Review mode: full. Validate Design Doc compliance and return structured JSON report."Store output as: $STEP_2_OUTPUT
Invoke security-reviewer using Agent tool:
subagent_type: "dev-workflows-fullstack:security-reviewer"description: "Security review"prompt: "governingDocuments: [{"type":"design-doc","path":"[path]"}]. implementationFiles: [implementationFiles]. Review security compliance."Store output as: $STEP_3_OUTPUT
If security-reviewer reports a limitation: Apply subagents-orchestration-guide Specialist Result Acceptance. Route findings from their substance and repository evidence, carry unavailable verification into the report, and present only a user-owned decision or unavailable authority to the user.
Apply the Review Resolution Gate to both outputs before reporting or routing them. Finding dispositions determine routing.
For each apply or user_decision_required finding, compute a proposed route using the rule below:
| Finding pattern | Recommended route |
|---|---|
dd_violation where the code intent matches the original requirement but the Design Doc captured a different design | d (Design-side update) |
dd_violation where the code drifted from a still-correct Design Doc | c (Code-side fix) |
reliability / security / maintainability findings | c (Code-side fix) |
Then present the adjudicated result to the user. Group apply and user_decision_required findings by proposed route, and list declined IDs with their reasons separately:
Code Review: [verdict from code-reviewer]
Acceptance Criteria:
- [fulfilled] [item] (confidence: [high/medium/low])
- [unfulfilled] [item]: [gap] — [suggestion] [recommended: c | d]
Identifier Mismatches:
- [identifier]: DD=[designDocValue] Code=[codeValue] at [location] [recommended: c | d]
Quality Findings:
- [category] [location]: [description] — [rationale] [recommended: c]
Security Review: [status from security-reviewer]
Findings by category:
- [confirmed_risk] [location]: [description] — [rationale] [recommended: c]
- [defense_gap] [location]: [description] — [rationale] [recommended: c]
Approve the proposed changes or decide unresolved items:
c) Code-side fix — code violates Design Doc; modify code to match
d) Design-side update — code is correct; Design Doc is stale, revise it
s) Decline — record the governing reason and accept current state
This review command authorizes analysis; use AskUserQuestion to obtain separate implementation authority. The batch option is "approve all proposed apply routes" and its scope consists exclusively of those routes. Collect an explicit decision for each user_decision_required item. When the approved change set is empty, proceed directly to Step 10.
Pass approved findings, routes, covered files/sections, and any stated total size budget to update or fix agents. Before re-validation, map every diff hunk to an approved finding or required consistency update; request a scope decision for unmapped or over-budget changes.
Run this step only when the user routed at least one finding to d. When no d routes exist, skip it; continue to Step 6 only when approved c routes remain.
Invoke technical-designer in update mode using Agent tool:
subagent_type: "dev-workflows-fullstack:technical-designer"description: "Design Doc update from review findings"prompt: "Update Design Doc at [path] in update mode. Ratify these findings in the design rather than the code: [complete d-routed finding objects from $STEP_2_OUTPUT, unchanged except for their approved routes]. Reflect the current code behavior in the relevant sections and add a history entry."Invoke document-reviewer to verify the updated Design Doc:
subagent_type: "dev-workflows-fullstack:document-reviewer"description: "Document review of updated Design Doc"prompt: "Review updated Design Doc at [path] for consistency and completeness. doc_type: DesignDoc. review_context: update."When more than one Design Doc exists under docs/design/, invoke design-sync:
subagent_type: "dev-workflows-fullstack:design-sync"description: "Cross-DD consistency check"prompt: "source_design: [updated DD path]"sync_status: CONFLICTS_FOUND, apply the Review Resolution Gate using design-sync as a fresh verifier. Send the apply conflicts to the owning technical-designer, rerun design-sync after correction, retain evidenced declines as complete, and request user input for user_decision_required or the Gate's escalation conditions.After Step 5 completes:
d for all findings (no c routes) → skip Steps 6-7, proceed to Step 8 for re-validationd and c → re-evaluate the c-routed findings against the updated DD and drop any that are now satisfied by the DD revision; then proceed to Step 6 with the remaining c findingsInvoke task-executor using Agent tool:
subagent_type: "dev-workflows-fullstack:task-executor"description: "Execute review fixes"direct_scope: Apply the approved code-side corrections within the confirmed review scope and stated total size budgetgoverning_sources: The reviewed Design Doc and accepted requirement or ADR pathstarget_paths: The implementation and test paths confirmed for the approved code-side routesobservable_verification: The focused tests or observable contract checks named by the findings and governing sources passcorrection_findings: Complete reviewer finding objects verbatim, with only their orchestrator dispositions addedInvoke quality-fixer using Agent tool:
subagent_type: "dev-workflows-fullstack:quality-fixer"description: "Quality gate check"mutationEvidence.prompt: "Confirm quality gate passage for fixed files."Route the quality-fixer result:
approved → Proceed to Step 8stub_detected → Return to Step 6 with incompleteImplementations unchanged, then repeat Step 7verification_incomplete → Retain the complete result and proceed to Step 8blocked → Apply Specialist Result AcceptanceImmediately before this invocation, re-derive implementationFiles using the Step 1 inclusion rule so it includes implementation artifacts added or changed by the approved corrections.
Invoke code-reviewer using Agent tool:
subagent_type: "dev-workflows-fullstack:code-reviewer"description: "Re-validate compliance"prompt: "Re-validate Design Doc compliance after fixes. Design Doc: [path]. Implementation files: [implementationFiles]. prior_feedback: [{id, disposition, reason?, evidence}]. Reconcile every prior item under the reviewer's re-review scope."Immediately before this invocation, re-derive implementationFiles using the Step 1 inclusion rule so it includes implementation artifacts added or changed by the approved security corrections.
Invoke security-reviewer using Agent tool (only if security fixes were applied):
subagent_type: "dev-workflows-fullstack:security-reviewer"description: "Re-validate security"prompt: "Re-validate security after fixes. governingDocuments: [{"type":"design-doc","path":"[path]"}]. implementationFiles: [implementationFiles]. prior_feedback: [{id, disposition, reason?, evidence}]. Reconcile every prior item under the reviewer's re-review scope."Apply the Review Resolution Gate to every Step 8 and Step 9 result before Step 10. Follow its maintained transitions and repeat the affected verification after a rerouted correction; stop at its escalation conditions; proceed at its convergence condition.
Before Step 10, retry each retained quality-fixer limitation once with the same Step 7 inputs and affected check. Clear an approved result, route newly discovered incomplete implementation through Steps 6-9, and report a repeated verification_incomplete result. When the retry changes the repository, repeat Steps 8-9 for the changed code before reporting.
Present the final report:
Code Review:
Initial: [verdict from code-reviewer]
Correction review: [verdict for the re-review scope] (if fixes executed)
Reconciliation: [resolved / withdrawn / maintained by finding ID]
Security Review:
Initial: [status]
Correction review: [status for the re-review scope] (if fixes executed)
Reconciliation: [resolved / withdrawn / maintained by finding ID]
Quality Check:
Final: [approved / verification_incomplete / not_run when no code-side fixes were selected]
Remaining proof limitations:
- [reason — affected check and evidence] (only when repeated after retry)
Declined actionable findings:
- [ID: governing reason — evidence] (only when any were declined)
Remaining issues:
- [items requiring manual intervention]
Discrepancies suitable for the design-side path (code is correct, DD became stale):
Scope: Design Doc compliance validation, security review, code-side auto-fixes, and design-side update routing.