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.
/plugin marketplace add bostonaholic/rpikit/plugin install rpikit@rpikitThis skill inherits all available tools. When active, it can use any tool Claude has access to.
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:
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.