Requests a code review from a separate agent after implementation or before merging. It provides the change summary, requirements, and commit range, then guides follow-up work according to the severity of the findings.
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Requests a review from a separate agent to check whether implemented code meets its requirements. It organizes the change summary, plan or requirements, and starting and ending commit identifiers, then supplies this information through the code-reviewer.md template. The reviewer receives a focused description of the work to evaluate, rather than the entire conversation history. Findings are handled by severity: critical issues are fixed immediately, and important issues are fixed before the next task begins.
Use it after implementing a major feature or before merging into the main branch. It also helps after a complex bug fix, before reorganizing code through refactoring, or when you are stuck and need another perspective on the work.
The procedure requires access to Git commit information and the ability to invoke subagents. Review requests use the included code-reviewer.md. If a finding is technically incorrect, the response should use code or tests as evidence. Valid critical and important findings must be resolved before proceeding.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI rated this skill on four points using only the contents of its SKILL.md. Stars and popularity are not taken into account.
The total counts each point as A = 25, B = 15, C = 5. Rated by AI (OpenAI Codex) as of Oct 19, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history.
Core principle: Review early, review often.
Mandatory:
Optional but valuable:
1. Get git SHAs:
BASE_SHA=$(git rev-parse HEAD~1) # or: git merge-base origin/main HEAD
HEAD_SHA=$(git rev-parse HEAD)
2. Dispatch code reviewer subagent:
Dispatch a general-purpose subagent, filling the template at code-reviewer.md
Placeholders:
{DESCRIPTION} - Brief summary of what you built{PLAN_OR_REQUIREMENTS} - What it should do{BASE_SHA} - Starting commit{HEAD_SHA} - Ending commit3. Act on feedback:
[Just completed Task 2: Add verification function]
You: Let me request code review before proceeding.
BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | cut -d' ' -f1)
HEAD_SHA=$(git rev-parse HEAD)
[Dispatch code reviewer subagent]
DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
BASE_SHA: a7981ec
HEAD_SHA: 3df7661
[Subagent returns]:
Strengths: Clean architecture, real tests
Issues:
Important: Missing progress indicators
Minor: Magic number (100) for reporting interval
Assessment: Ready to proceed
You: [Fix progress indicators]
[Continue to Task 3]
| Excuse | Reality |
|---|---|
| "I'll just review the diff myself instead of dispatching a reviewer" | You're the coordinator — reviewing the diff inline burns the context window you need to keep driving the work. Dispatch a reviewer subagent: the diff and the evaluation live in its context, and only the findings come back to you. |
| "The reviewer needs my whole session history to understand the change" | Hand it precisely crafted context, never your session's history. That keeps the reviewer on the work product, not your thought process. |
Never:
If reviewer wrong:
See template at: code-reviewer.md
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Clarifies the purpose, preferences, and constraints of a new feature or project through conversation. When useful, it offers mockups or temporary prototypes, then captures an agreed description or written design before implementation begins.
Examine superpowers session records to document repeated work, departures from plans, delays, and token usage. Produce an evidence-based report with file and line references, and prepare bug-report material when requested.
Assign independent bugs or test failures to separate agents that work at the same time. Define each agent’s scope and expected report, then check for conflicting changes and run the full test suite before integrating fixes.
Carry out an existing implementation plan in one session, task by task. Verify each step with tests, record progress and decisions in a file, and finish with a review of all changes on the branch.
Finish completed development work by checking the full test suite and presenting integration choices: merge locally, create a Pull Request, or keep the branch. It carries out the selected path and handles workspace cleanup accordingly.
Evaluate code review feedback against the actual code, supported environments, and existing behavior. Clarify uncertain requests, respond with technical evidence, and implement valid changes one at a time with tests for each fix.