원클릭으로
code-review
On-demand code review for directories, git diffs, staged changes, or files. Manual invocation, structured feedback.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
On-demand code review for directories, git diffs, staged changes, or files. Manual invocation, structured feedback.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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'.
| 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.