review
starsforks
How to install review?
smartwhale8/claude-playbook/review
$npx -y skills add smartwhale8/claude-playbook --skill reviewReview all uncommitted changes against project standards before committing
SKILL.md
| 1 | Review all uncommitted changes in this project. $ARGUMENTS |
| 2 | |
| 3 | ## Process |
| 4 | |
| 5 | 1. **Gather changes**: Run `git diff --staged` for staged changes, or `git diff` if nothing is staged. Also check `git status` for new untracked files. |
| 6 | |
| 7 | 2. **Check each changed file against the project rules** (`.claude/rules/*.md`): |
| 8 | |
| 9 | ### Code Quality |
| 10 | - Is there dead code, unused imports, or commented-out code? |
| 11 | - Are there bandaid fixes or workarounds instead of root-cause solutions? |
| 12 | - Is anything over-engineered for what it needs to do? |
| 13 | |
| 14 | ### Architecture |
| 15 | - Does this follow existing patterns in the codebase? |
| 16 | - Is there duplicate logic that should use an existing shared component or utility? |
| 17 | - Are dependencies pointing in the right direction (inward, not outward)? |
| 18 | |
| 19 | ### Consistency |
| 20 | - Does the code match the style and structure of similar files in the project? |
| 21 | - For frontend: are spacing, colors, and component usage consistent with the rest of the UI? |
| 22 | - For backend: are error handling, response format, and validation patterns consistent? |
| 23 | |
| 24 | ### Reuse |
| 25 | - Could any new component, function, or pattern already exist in the codebase? Search before approving. |
| 26 | - If something similar exists, flag it — it should be reused or extracted into a shared utility. |
| 27 | |
| 28 | ### Security |
| 29 | - Any hardcoded secrets, credentials, or API keys? |
| 30 | - Is user input validated at the boundary? |
| 31 | - Are there SQL injection, XSS, or other OWASP risks? |
| 32 | |
| 33 | ### Performance |
| 34 | - Any N+1 query patterns (database calls inside loops)? |
| 35 | - Any unbounded queries missing LIMIT/pagination? |
| 36 | - Frontend: unnecessary re-renders, missing debounce on inputs? |
| 37 | |
| 38 | 3. **Verdict**: Provide one of: |
| 39 | - **Ready to commit** — no issues found |
| 40 | - **Minor issues** — list them, but committing is acceptable after acknowledging |
| 41 | - **Needs changes** — list specific issues that must be fixed before committing |
| 42 | |
| 43 | For each issue, provide: the file, the line(s), what's wrong, and what the fix should be. |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
