Menu
On-demand code review for directories, git diffs, staged changes, or files. Manual invocation, structured feedback.
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
| name | code-review |
| description | On-demand code review for directories, git diffs, staged changes, or files. Manual invocation, structured feedback. |
Review the last thing done in this conversation.
No args needed. Just say "review" or "review this".
If the context contains:
"review staged changes" → git diff --cached
"review diff main..HEAD" → git diff main...HEAD
"review src/auth/" → read & review dir
"review last 3 commits" → git diff HEAD~3..HEAD
╱╲
╱ ╲ Style ← automate (ruff/eslint)
╱────╲
╱ ╲ Tests
╱────────╲
╱ ╲ Docs
╱────────────╲
╱ ╲ Implementation
╱────────────────╲
╱ API Design ╲ ← FOCUS HERE
────────────────────
Source: morling.dev/blog/the-code-review-pyramid
Approve if it improves overall code health, even if not perfect.
Nit:Source: google.github.io/eng-practices
| Area | Check |
|---|---|
| Design | Does it belong here? Right abstraction? |
| Functionality | Works correctly? Edge cases? Concurrency? |
| Complexity | Can be understood quickly? Over-engineered? |
| Tests | Correct, sensible, useful? |
| Naming | Clear intent without being verbose? |
| Comments | Explain why, not what? |
| Style | Consistent? (delegate to linter) |
Format: label: subject
| Label | Meaning |
|---|---|
praise: | Highlight good stuff |
nitpick: | Minor, non-blocking |
suggestion: | Propose improvement |
issue: | Problem that must be addressed |
question: | Need clarification |
thought: | Idea for consideration |
chore: | Cleanup/maintenance task |
Decorations: (blocking), (non-blocking), (security), (performance)
suggestion (security): This SQL uses string concat.
Use parameterized queries to prevent injection.
Source: conventionalcomments.org
eval()/exec() → RCEpickle.load() untrusted data## Review: <context>
### Summary
<1-2 sentences>
### Issues
**file:line** - `issue:`/`suggestion:`/`nitpick:`
<description>
### Good
<acknowledge quality>
### Questions
<clarifications needed>
From Google eng-practices:
❌ "Why did you do this?" ✅ "This approach adds complexity without benefit because..."
Run before reviewing:
ruff check . # Python
eslint . # JS/TS
go vet ./... && staticcheck ./... # Go
cargo clippy # Rust
Don't waste review time on what tools catch.
Behavioral testing methodology — test what users experience, not how code is structured. Use when writing tests, reviewing test quality, planning test strategy for new features, or when existing tests are brittle/verbose/coupled to implementation details. Triggers: writing tests, TDD, test review, "tests keep breaking", "too many mocks", "tests are verbose", test coverage planning, behavior-driven development.
Summon 8–12 fictional but statistically plausible people from Kyrgyzstan to judge your web app. They take screenshots, click around, get confused, get delighted, and write honest reviews in Russian. Output: a single .md report with embedded screenshots. Use when you need brutal UX feedback from people who ride marshrutkas.
Artemy Lebedev-style бизнес-линч design review. Opens the site in a real browser, screenshots everything, then tears it apart (or praises it) in his signature voice — brutal, specific, visual. Use when you want a no-bullshit design review, 'линч', 'lebedev review', 'artemy review', or 'roast my site'.
Autonomous experiment loop — modify code, measure, keep/discard, repeat forever. Based on Karpathy's autoresearch pattern. Use when there's working code + a measurable metric to optimize. Agent works while you sleep.
Iterative deep research agent — recursive breadth×depth tree search that accumulates learnings, generates follow-ups, and produces cited reports. Uses exa + serper + subagents. Use when user says 'deep research', 'investigate', 'deep dive', 'thorough analysis', or needs multi-source synthesis with depth.
Detect and fix design system leaks — default shadcn/bootstrap/MUI styling breaking through your brand. Use when: UI feels 'template-y', 'looks like shadcn', 'too generic', buttons are inconsistent colors, cards look default, or after shipping many features fast. Also: 'audit my design', 'check consistency', 'brand leak', 'fix the defaults'.