Menu
Use when reviewing code changes for specification compliance, correctness, quality, security, and maintainability.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when following the Super Compound BRD -> PRD -> FSD -> GOAL -> IMPLEMENTATION -> VERIFICATION delivery path, artifact traceability, FSD authority, optional ADR handling, zero context bloat issue slicing, or OPEN-* stop conditions.
Use when an approved FSD goal or lightweight issue pointer is ready for implementation.
Use when multi-component work needs cross-component verification of API contracts, data flow, events, auth, config, UI, background jobs, or tests.
Use when /sc-plan needs FSD GOAL-* packets turned into lightweight issue pointers, local Markdown Kanban boards, blocker DAGs, or multi-agent task contracts.
Use when a plan or issue board has 2+ independent execution streams whose time saving exceeds coordination overhead. Dispatches agents in isolated git worktrees only after required delivery gates pass.
Use when an FSD and goal issue board need requirement coverage, goal quality, dependency DAG, sizing, and verification validated before execution.
| name | code-review |
| description | Use when reviewing code changes for specification compliance, correctness, quality, security, and maintainability. |
Announce: "I'm using the code-review skill to review these changes."
Review in two distinct stages: first the contract, then implementation quality. Standards compliance cannot rescue the wrong behavior.
Use for external reviews, self-review before handoff, and /sc-review.
CONTEXT.md, acceptance criteria, or accepted ADR defines the change.P1 critical, P2 important, or P3 suggestion.file:line, impact, evidence, and a concrete correction. If no findings exist, say so and name residual testing risk.Severity is driven by impact, not preference. Wrong dependency direction, exploitable security defects, data loss, and contract-breaking behavior are P1.
| Thought | Required response |
|---|---|
| "The code looks clean" before reading the spec | Complete Stage 1 first. |
| "This extra behavior is useful" | Treat unapproved behavior as scope creep. |
| "Probably vulnerable/buggy" | Trace a concrete path and verify the finding. |
| "Style issue" labeled P1 | Reclassify by user/operational impact. |
| Generic advice without location | Give a tight line range and corrective action. |
| Empty catch, disabled test, debug output, wrong layer | Investigate specifically; do not overlook it. |
executing-plans feeds completed implementation into review./sc-review orchestrates the full pipeline.verification-before-completion validates findings and the final verdict.gap-closure handles P1/P2 remediation.security-audit, secure-code-patterns, and data-privacy provide deep specialist review.knowledge-compounding captures recurring review lessons.