requesting-code-review
starsforks
How to install requesting-code-review?
jamditis/claude-skills-journalism/requesting-code-review
$npx -y skills add jamditis/claude-skills-journalism --skill requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirements
SKILL.md
| 1 | <!-- |
| 2 | Adapted from obra/superpowers requesting-code-review skill (v5.0.7), |
| 3 | MIT-licensed, copyright 2025 Jesse Vincent. Modifications copyright 2026 Joe Amditis. v0.4.0 ports as a consumer category — no research |
| 4 | phase per the v0.2.0 architecture, since dispatch mechanic; reviewer |
| 5 | preferences live in CLAUDE.md and memory rather than a research phase. |
| 6 | See CREDITS.md. |
| 7 | --> |
| 8 | |
| 9 | # Requesting Code Review |
| 10 | |
| 11 | Dispatch pr-review-toolkit:code-reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history. This keeps the reviewer focused on the work product, not your thought process, and preserves your own context for continued work. |
| 12 | |
| 13 | **Core principle:** Review early, review often. |
| 14 | |
| 15 | ## When to Request Review |
| 16 | |
| 17 | **Mandatory:** |
| 18 | - After each task in subagent-driven development |
| 19 | - After completing major feature |
| 20 | - Before merge to main |
| 21 | |
| 22 | **Optional but valuable:** |
| 23 | - When stuck (fresh perspective) |
| 24 | - Before refactoring (baseline check) |
| 25 | - After fixing complex bug |
| 26 | |
| 27 | ## How to Request |
| 28 | |
| 29 | **1. Get git SHAs:** |
| 30 | ```bash |
| 31 | BASE_SHA=$(git rev-parse HEAD~1) # or origin/main |
| 32 | HEAD_SHA=$(git rev-parse HEAD) |
| 33 | ``` |
| 34 | |
| 35 | **2. Dispatch code-reviewer subagent:** |
| 36 | |
| 37 | Use Task tool with pr-review-toolkit:code-reviewer type, fill template at `code-reviewer.md` |
| 38 | |
| 39 | **Placeholders:** |
| 40 | - `{WHAT_WAS_IMPLEMENTED}` - What you just built |
| 41 | - `{PLAN_OR_REQUIREMENTS}` - What it should do |
| 42 | - `{BASE_SHA}` - Starting commit |
| 43 | - `{HEAD_SHA}` - Ending commit |
| 44 | - `{DESCRIPTION}` - Brief summary |
| 45 | |
| 46 | **3. Act on feedback:** |
| 47 | - Fix Critical issues immediately |
| 48 | - Fix Important issues before proceeding |
| 49 | - Note Minor issues for later |
| 50 | - Push back if reviewer is wrong (with reasoning) |
| 51 | |
| 52 | ## Example |
| 53 | |
| 54 | ``` |
| 55 | [Just completed Task 2: Add verification function] |
| 56 | |
| 57 | You: Let me request code review before proceeding. |
| 58 | |
| 59 | BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}') |
| 60 | HEAD_SHA=$(git rev-parse HEAD) |
| 61 | |
| 62 | [Dispatch pr-review-toolkit:code-reviewer subagent] |
| 63 | WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index |
| 64 | PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md |
| 65 | BASE_SHA: a7981ec |
| 66 | HEAD_SHA: 3df7661 |
| 67 | DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types |
| 68 | |
| 69 | [Subagent returns]: |
| 70 | Strengths: Clean architecture, real tests |
| 71 | Issues: |
| 72 | Important: Missing progress indicators |
| 73 | Minor: Magic number (100) for reporting interval |
| 74 | Assessment: Ready to proceed |
| 75 | |
| 76 | You: [Fix progress indicators] |
| 77 | [Continue to Task 3] |
| 78 | ``` |
| 79 | |
| 80 | ## Integration with Workflows |
| 81 | |
| 82 | **Subagent-Driven Development:** |
| 83 | - Review after EACH task |
| 84 | - Catch issues before they compound |
| 85 | - Fix before moving to next task |
| 86 | |
| 87 | **Executing Plans:** |
| 88 | - Review after each batch (3 tasks) |
| 89 | - Get feedback, apply, continue |
| 90 | |
| 91 | **Ad-Hoc Development:** |
| 92 | - Review before merge |
| 93 | - Review when stuck |
| 94 | |
| 95 | ## Red Flags |
| 96 | |
| 97 | **Never:** |
| 98 | - Skip review because "it's simple" |
| 99 | - Ignore Critical issues |
| 100 | - Proceed with unfixed Important issues |
| 101 | - Argue with valid technical feedback |
| 102 | |
| 103 | **If reviewer wrong:** |
| 104 | - Push back with technical reasoning |
| 105 | - Show code/tests that prove it works |
| 106 | - Request clarification |
| 107 | |
| 108 | See template at: requesting-code-review/code-reviewer.md |
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
