code-review
starsforks
How to install code-review?
girijashankarj/cursor-handbook/code-review
$npx -y skills add girijashankarj/cursor-handbook --skill code-reviewStructured workflow for conducting thorough code reviews. Use when the user asks to review code, a PR, or specific files.
SKILL.md
| 1 | # Skill: Code Review Workflow |
| 2 | |
| 3 | ## Trigger |
| 4 | When the user asks to review code, a PR, or specific files. |
| 5 | |
| 6 | ## Steps |
| 7 | |
| 8 | ### Step 1: Understand Context |
| 9 | - [ ] Read the PR description or user's explanation |
| 10 | - [ ] Identify the type of change (feature, bug fix, refactor, test) |
| 11 | - [ ] Check which files are modified |
| 12 | |
| 13 | ### Step 2: High-Level Review |
| 14 | - [ ] Does the change accomplish its stated goal? |
| 15 | - [ ] Is the approach appropriate for the problem? |
| 16 | - [ ] Are there simpler alternatives? |
| 17 | - [ ] Does it follow project architecture patterns? |
| 18 | |
| 19 | ### Step 3: Security Review |
| 20 | - [ ] No hardcoded secrets or credentials |
| 21 | - [ ] No PII in logs or error messages |
| 22 | - [ ] Input validation on all external inputs |
| 23 | - [ ] Parameterized database queries |
| 24 | - [ ] Proper authentication/authorization checks |
| 25 | - [ ] No sensitive data in URLs or headers |
| 26 | |
| 27 | ### Step 4: Code Quality Review |
| 28 | - [ ] Functions are single-responsibility and < 30 lines |
| 29 | - [ ] Naming is clear and consistent |
| 30 | - [ ] No code duplication |
| 31 | - [ ] Error handling is comprehensive |
| 32 | - [ ] Logging includes correlationId |
| 33 | - [ ] Import order follows conventions |
| 34 | |
| 35 | ### Step 5: Testing Review |
| 36 | - [ ] Tests exist for new/changed code |
| 37 | - [ ] Success and error paths tested |
| 38 | - [ ] Edge cases covered |
| 39 | - [ ] Mocks are appropriate (not over-mocking) |
| 40 | - [ ] Test names are descriptive |
| 41 | |
| 42 | ### Step 6: Performance Review |
| 43 | - [ ] No N+1 database queries |
| 44 | - [ ] Appropriate use of indexes |
| 45 | - [ ] No unnecessary data loading |
| 46 | - [ ] Caching where appropriate |
| 47 | - [ ] No memory leaks |
| 48 | |
| 49 | ### Step 7: Provide Feedback |
| 50 | Use this format: |
| 51 | - 🔴 **Critical**: Must fix before merge |
| 52 | - 🟡 **Suggestion**: Should improve |
| 53 | - 🟢 **Nitpick**: Optional improvement |
| 54 | - 👍 **Positive**: Things done well |
| 55 | |
| 56 | ## Completion |
| 57 | Review is complete with actionable feedback categorized by priority. |
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
