requesting-code-review
Use when a completed change is high-risk, crosses subsystem boundaries, or the user explicitly requests independent review. Do NOT use by default for low- or medium-risk changes.
- License 许可
- MIT
- 最近更新
- 2026-10-14
- Stars
- ★ 16
- Forks
- 5
01 前言 Front Matter
- name
- requesting-code-review
- version
- 6.2.0
- category
- workflow
- description
- Use when a completed change is high-risk, crosses subsystem boundaries, or the user explicitly requests independent review. Do NOT use by default for low- or medium-risk changes.
02 资源文件 2
- 参考文档CHANGELOG.md311 B
- 参考文档code-reviewer.md946 B
03 SKILL.md 正文
Requesting Code Review
Independent review is a targeted risk control, not a ceremony after every task.
Read ../using-superpowers/references/risk-policy.md.
Default
- Low and medium risk: self-review the complete diff.
- High risk or cross-boundary: at most one independent review of the completed change.
- Explicit user request: review the requested scope once.
Do not dispatch a reviewer after each task, for mechanical changes, or merely because subagents are available.
Review Package
Give the reviewer:
- exact requirements;
- base and head revisions or the precise diff;
- changed boundaries and known risks;
- verification already run;
- a request for only correctness, security, data-loss, contract, and material maintainability findings.
Do not pass arbitrary conversation history. Do not ask the reviewer to rerun passing checks without a concrete reason.
Handling Findings
- Verify each finding against the code and requirements.
- Fix confirmed critical or important issues.
- Verify the fix with the closest applicable check.
- Stop. Request one scoped re-review only when the fix is itself high-risk or cannot be verified directly.
Minor style preferences do not start another loop. Disputed findings are adjudicated by technical evidence, not reviewer repetition.
Template: code-reviewer.md
04 同仓库更多 Skills
bad
暂无简介
writing-skills
Use when creating, editing, or validating reusable agent skills and their trigger behavior. Do NOT use for ordinary project documentation or one-off prompts.
writing-plans
Use when an approved change spans multiple dependent outcomes and needs a durable implementation sequence before coding. Do NOT use for small, obvious, reversible edits.
verification-before-completion
Use when about to claim work is complete, fixed, passing, or ready to integrate. Do NOT use to repeat checks without a completion claim or concrete doubt.
using-superpowers
Use when starting a conversation or deciding whether a Superpowers workflow matches the current task. Do NOT use it to auto-invoke skills whose stated triggers do not match.
using-git-worktrees
Use when feature work needs isolation from the current workspace or before executing a risky implementation plan. Do NOT use when the current workspace is already safe and isolated.