Get an AI code review worth reading
Skills used in this guide (3)
当完成任务、实现主要功能，或在合并前验证工作是否符合需求时使用。
npx skills add obra/superpowers -g当收到代码评审反馈、在实现建议前，尤其反馈不清或技术存疑时——需要技术严谨与验证，而非表演式同意或盲目实现。
npx skills add obra/superpowers -g使用 Playwright 与本地 Web 应用交互并测试的工具集。支持验证前端功能、调试 UI 行为、截取浏览器截图、查看浏览器日志。
npx skills add anthropics/skills -g
The classic failure mode is twenty "suggestions" where eighteen are style preferences. A useful review contains only two kinds of information: what will break, and what will confuse the next reader. So the job is not to make AI say more. It is to forbid everything else.
Who this is for
Good fit
- Self-review before handing a PR to a human
- PRs from a few dozen to a few hundred lines (split above 500)
- Teams without a shared checklist that need a baseline
Bad fit
- Replacing a security audit. AI spots obvious injection and missing auth checks, not business logic holes
- Generated code (protobuf, lockfiles, migration scaffolding). Exclude it first
- Architecture questions. That is a design review
Prepare
- Diff only, never the whole repo:
git diff main...HEAD. - One sentence of intent. Without it, the model can only check syntax.
- Run the tests and include any failures.
Steps
1. Install
git clone --depth 1 https://github.com/obra/superpowersCopy skills/requesting-code-review/ and skills/receiving-code-review/ into your client skills directory.
2. Write a review request, not "have a look"
State the intent in one sentence, list the changed files, and ask for: a three-line summary, risks bucketed as "will break / will confuse / taste" while keeping only the first two, and the two places you want the reviewer to focus. Explicitly ban style comments.
3. Run the review with a hard filter
Only report two categories, each with file:line and a trigger condition:
A. Will break: nulls, boundaries, concurrency, error paths, leaks, wrong error handling
B. Will confuse: names that contradict behaviour, hidden preconditions, missing failure explanation
Mark uncertain items [uncertain]. No style, no performance guesses, no "consider a comment".
If there is only one finding, return one.The last line matters. Padding is the default behaviour.
4. Triage the feedback
Ask it to split findings into must-fix, needs-context (and say exactly what context is missing), and ignore. Throw the third bucket away.
5. Verify the fix in a browser
For UI changes, drive the key paths with a browser testing skill and ask for screenshots plus console errors.
Traps
| Trap | Symptom | Fix |
|---|---|---|
| Padding | Twenty findings, eighteen about comments | Ban style, require a trigger condition |
| Confident guesses | It flags code that upstream already validates | Ask for a "needs context" bucket |
| No line numbers | Unusable output | Require file:line |
| Test noise | Twenty minutes chasing a flaky test | Run tests first and pass the output |
| Large PRs | Only the first 100 lines get reviewed | Split the PR |
FAQ
Can it replace a human reviewer? No, but it replaces pre-submit self-checks. It is good at enumerating edges, bad at judging whether the change should exist.
Why does it keep suggesting comments? Because it is the safest possible output. Ban it explicitly.
Can this run in CI? Yes, but only report category A and never block the merge. Noisy bots get ignored fast.
Which languages work best? Statically typed ones, since types are context. For Python, pass signatures and call sites.
What if I disagree with a finding? Ask for the trigger condition. If it cannot produce a failure path, it is a preference.
References
Related Scenes
Guard code quality with AI (translated)
AI writes fast, but the quality gate matters more. Community consensus in three: reverse TDD (AI writes tests, then minimal impl), zero-warning gate (`--max-warnings=0`, warnings silently become the new baseline), review as a gate (every change through the same gate). Make AI output verifiable and g
Write test cases and automation scripts with AI
The biggest value of testing isn't "high coverage" — it's "catching the paths that actually break". The point of AI-generated tests: give it the implemented code or a clear behavior contract, then have it add edge cases. Don't let it invent the thing under test; a test that passes on a fake object p