vasuag09 /review — code quality & correctness
Goal: catch bugs and quality issues before they merge.
Do this
- Delegate to
harness-claude:code-reviewerwith the diff in scope (git diff,git diff --staged, or the files named). - The reviewer checks correctness, edge cases, error handling, naming, complexity,
duplication, adherence to harness rules, and test coverage — reporting
file:linewith severity. - Triage findings:
- Critical → block, fix now.
- High → fix before merge.
- Medium/Low → fix when reasonable / note.
- Apply fixes, then re-review the changed lines if Critical/High were found.
Common rationalizations (don't accept these from yourself)
| Excuse | Reality |
|---|---|
| "The diff is tiny — review would be ceremony" | Small diffs cause outsized breakage precisely because nobody looks. The reviewer is cheap; the regression isn't. |
| "I just wrote it, so I know it's correct" | The author is the worst-placed reviewer. That's the whole reason this gate delegates to a fresh-context agent. |
| "It's only a High, and the user is waiting" | High means fix before merge. Speed pressure is when gates earn their keep. |
| "I'll batch the findings with the next change" | Deferred findings become permanent. Fix now while the context is loaded. |
Red flags — stop and re-check
- You summarized the diff to the reviewer instead of giving it the actual diff.
- The review returned zero findings on a non-trivial change (suspicious, not reassuring).
- Critical/High fixes landed but the changed lines were never re-reviewed.
Exit criterion
No Critical or High findings outstanding. Then /harness-claude:security-review (or run both in
parallel if the change is security-sensitive).