code-reviewer
installsforks
How to install code-reviewer?
magebyte-zero/spec-superflow/code-reviewer
$npx -y skills add MageByte-Zero/spec-superflow --skill code-reviewerReview completed implementation batches for spec compliance and code quality. Invoke after execution batches complete, before merging, or when a review gate is reached in the workflow.
SKILL.md
| 1 | # Code Reviewer |
| 2 | |
| 3 | Two responsibilities: requesting review (dispatching a reviewer subagent) and receiving review (acting on feedback with technical rigor). **Review early, review often. Verify before implementing feedback.** |
| 4 | |
| 5 | ## Part 1: Requesting Review |
| 6 | |
| 7 | **Mandatory after**: each task in SDD, each planned execution wave, each major feature, before merge. |
| 8 | **Optional**: when stuck, before refactoring, after fixing complex bugs. |
| 9 | |
| 10 | ### Procedure |
| 11 | 1. Get SHAs: `BASE_SHA=$(git rev-parse HEAD~1)` and `HEAD_SHA=$(git rev-parse HEAD)` |
| 12 | 2. Dispatch `general-purpose` subagent using template at `skills/code-reviewer/code-reviewer-prompt.md` |
| 13 | 3. Fill placeholders: `[DESCRIPTION]` (what was built), `[PLAN_OR_REQUIREMENTS]` (contract/spec reference), `[BASE_SHA]`, `[HEAD_SHA]`, `[WAVE_ID]`, and a distinct `[REVIEW_REPORT_FILE]`. |
| 14 | 4. Require the reviewer to write a non-empty persisted review report at `[REVIEW_REPORT_FILE]`, then record that exact path in the wave receipt: `npx --yes --package spec-superflow@0.11.0 ssf execution review <change-dir> --wave <id> --base <sha> --head <sha> --report <review-report-path> --verdict <pass|fail>`. |
| 15 | 5. Act on feedback: Critical/Important findings require a `fail` receipt, focused repair, re-review, and replacement `pass` receipt before a dependent wave or closing can proceed. Note Minor for later, push back with reasoning if reviewer is wrong. |
| 16 | |
| 17 | ### Minimality And Scope |
| 18 | |
| 19 | For unrequested complexity, cite the missing task requirement and diff line. |
| 20 | Use Important for merge-blocking complexity and Minor for safe, |
| 21 | behavior-neutral redundancy; never score by line count. |
| 22 | |
| 23 | ## Part 2: Receiving Review Feedback |
| 24 | |
| 25 | ### The Response Pattern |
| 26 | 1. READ feedback without reacting |
| 27 | 2. UNDERSTAND and restate requirement |
| 28 | 3. VERIFY against codebase reality |
| 29 | 4. EVALUATE: technically sound for THIS codebase? |
| 30 | 5. RESPOND: technical acknowledgment or reasoned pushback |
| 31 | 6. IMPLEMENT: one item at a time, test each |
| 32 | |
| 33 | ### Severity Levels |
| 34 | |
| 35 | | Level | Meaning | Action | |
| 36 | |-------|---------|--------| |
| 37 | | Critical | Bugs, security, data loss, broken functionality | Fix immediately | |
| 38 | | Important | Architecture problems, missing features, poor error handling, test gaps | Fix before next batch | |
| 39 | | Minor | Code style, optimization, documentation polish | Note for later | |
| 40 | |
| 41 | ### Forbidden Responses |
| 42 | Never: performative agreement ("You're right!", "Great point!"), blind implementation before verification, thanking the reviewer. Instead: restate the requirement, ask clarifying questions, push back with reasoning, or just fix it (actions > words). |
| 43 | |
| 44 | ### Handling Unclear Feedback |
| 45 | If any item is unclear → STOP. Do not implement anything yet. Ask for clarification on unclear items. Partial understanding = wrong implementation. |
| 46 | |
| 47 | ### Source-Specific Rules |
| 48 | |
| 49 | **From user**: Trusted — implement after understanding. Still ask if scope unclear. No performative agreement. |
| 50 | |
| 51 | **From external reviewer**: Before implementing, check: technically correct for this codebase? breaks existing functionality? reason for current implementation? works on all platforms? reviewer understands full context? If suggestion seems wrong, push back with technical reasoning. |
| 52 | |
| 53 | ### When to Push Back |
| 54 | Suggestion breaks existing functionality, reviewer lacks context, violates YAGNI, technically incorrect for this stack, legacy/compatibility reasons, conflicts with user's architectural decisions. Push back with technical reasoning, not defensiveness. |
| 55 | |
| 56 | ### Implementation Order |
| 57 | 1. Clarify unclear items first |
| 58 | 2. Fix blocking issues (breaks, security) |
| 59 | 3. Fix simple issues (typos, imports) |
| 60 | 4. Fix complex issues (refactoring, logic) |
| 61 | 5. Test each fix individually, verify no regressions |
| 62 | |
| 63 | ## Common Mistakes |
| 64 | |
| 65 | | Mistake | Fix | |
| 66 | |---------|-----| |
| 67 | | Performative agreement | State requirement or just act | |
| 68 | | Blind implementation | Verify against codebase first | |
| 69 | | Batch without testing | One at a time, test each | |
| 70 | | Proceeding without a wave receipt | Record `pass`/`fail` via `npx --yes --package spec-superflow@0.11.0 ssf execution review` before the next dependent wave | |
| 71 | | Assuming reviewer is right | Check if breaks things | |
| 72 | | Avoiding pushback | Technical correctness > comfort | |
| 73 | | Partial implementation | Clarify all items first | |
| 74 | |
| 75 | ## Exception Handling |
| 76 | |
| 77 | - **Parse failures**: Report specific file, request regenerated review package |
| 78 | - **Missing files**: Regenerate via `scripts/review-package`. Empty diff = nothing to review |
| 79 | - **User interruption**: Re-read review report on resume, continue from next unreviewed batch |
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
