メニュー
Code review methodology for evaluating implementation changes. Use when reviewing code changes for quality, design, correctness, and maintainability. Focuses on changes made during implementation using Conventional Comments for clear, actionable feedback.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Collaborative design methodology for creative work. Use before research or planning when requirements are unclear, multiple approaches exist, or the idea needs exploration. Refines ideas through progressive questioning.
Disciplined plan execution with checkpoint validation, progress tracking, and verification at each step. Follows an approved plan strictly, running verification criteria before proceeding.
End-to-end Research-Plan-Implement pipeline using parallel subagents. Each phase (research, plan, implement) runs in its own context window with file artifacts as the communication channel between phases.
Record architectural decisions as ADRs from design documents. Use after brainstorming or planning to capture what was decided, why, and what alternatives were considered. Produces sequentially numbered ADR files in docs/decisions/.
Thorough codebase exploration that builds understanding through collaborative dialogue. Investigates architecture, patterns, and implementation details before planning or making changes.
Security review methodology for evaluating implementation changes. Use when reviewing code changes for vulnerabilities, insecure patterns, and security best practices. Focuses on changes made during implementation rather than full codebase audits.
| name | reviewing-code |
| description | Code review methodology for evaluating implementation changes. Use when reviewing code changes for quality, design, correctness, and maintainability. Focuses on changes made during implementation using Conventional Comments for clear, actionable feedback. |
| argument-hint | scope or focus of the code review |
Deep code reviews that protect architecture, catch correctness issues, and provide mentoring-quality feedback using Conventional Comments.
This skill provides methodology for reviewing code changes introduced during implementation. Unlike full codebase audits, this focuses on the delta - what was added or modified - to catch quality issues before they're committed.
Follow this order - don't jump to nits.
Pattern Recognition:
| Smell | Pattern to Suggest |
|---|---|
| Long method | Compose Method |
| Type-based conditionals | Replace Conditional with Polymorphism |
| Duplicate algorithm structure | Form Template Method |
| Scattered null checks | Introduce Null Object |
| Type field drives behavior | Replace Type Code with State/Strategy |
Always name patterns explicitly.
SOLID Quick Check:
| Principle | Red Flag |
|---|---|
| SRP | Class has multiple unrelated responsibilities |
| OCP | Must modify existing code to add behavior |
| LSP | Subclass changes expected behavior |
| ISP | Fat interface forces unused dependencies |
| DIP | High-level depends on low-level details |
Red Flags:
Note obvious security concerns for security-reviewer to examine in depth:
Defer detailed security analysis to the security-reviewer agent.
<label> [decorations]: <subject>
[discussion]
| Label | Use For |
|---|---|
praise: | Highlight positives (aim for 1+ per review) |
nitpick: | Trivial preferences (non-blocking) |
suggestion: | Propose improvement with what and why |
issue: | Concrete problem (pair with suggestion) |
todo: | Small necessary changes |
question: | Need clarification |
thought: | Non-blocking future ideas |
chore: | Process tasks before acceptance |
(blocking) - Must resolve before merge(non-blocking) - Helpful but not required(security), (performance), (tests), (readability), (maintainability)[src/validation.ts:34]
**praise**: Clean extraction of validation logic improves readability.
[api/users.py:127]
**issue (blocking)**: Missing null check before accessing user.email.
Add guard clause or use optional chaining.
[handlers/payment.js:89-105]
**suggestion (non-blocking, readability)**: Nested conditionals hard to scan.
Consider early returns to flatten. Classic Compose Method pattern (Fowler).
[core/processor.go:234]
**question**: Is this on the hot path? If so, consider allocation cost in loop.
Apply first principles and attribute by name for shared vocabulary:
**issue (blocking, design)**: This mutates shared state. Following Rich Hickey's
immutability principle, return new value from pure function instead.
**suggestion (non-blocking)**: Following Ousterhout's principle, pull this
complexity into the implementation. Simplify the interface.
**issue (blocking)**: Subclass overrides parent method but changes expected behavior.
This violates Liskov Substitution - callers can't safely substitute implementations.
Principles to apply:
| Lines | Action |
|---|---|
| < 200 | Full detailed review of every line |
| 200-400 | Full detailed review (optimal size) |
| 400-1000 | Focus on critical paths, security boundaries, architecture; suggest splitting |
| > 1000 | Architectural review only; strong recommendation to split |
For large changes:
**suggestion (blocking)**: This change (1,450 lines) exceeds reviewable size.
Please split per atomic change principle (200-400 lines optimal).
Providing architectural review only until split.
## Code Review: $ARGUMENTS
### Summary
[Brief overview of changes reviewed and overall assessment]
### Findings
[File location first, then Conventional Comment]
[file:line]
**<label> (<decorations>)**: <subject>
<discussion>
### Verdict
[APPROVE / APPROVE WITH NITS / REQUEST CHANGES]
### Rationale
[Brief explanation of verdict decision]
APPROVE - No blocking issues, code is ready
APPROVE WITH NITS - Only non-blocking suggestions
REQUEST CHANGES - Blocking issues present
When called from implementation phase: