Receiving code review
Skill NjoyimPeguy/augments/skills/testing/receiving-code-review
A collection of rigorous, phase-isolated SDLC skills to tether autonomous agents to real-world engineering standards.
npx -y skills add NjoyimPeguy/augments --skill receiving-code-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
ALWAYS invoke when review feedback arrives — from a human or another agent — on code you wrote, before you respond or act on any finding. Verifying each finding against the code first is mandatory; agreeing or editing without checking is the mistake. Push back with evidence when a finding is wrong; refuse performative agreement.
SKILL.md
2.7 KB, as published. Nobody here has run it
Receiving Code Review
Review feedback is input to verify — not orders to obey, and not applause to return. Each finding is a claim about your code; your job is to confirm it against the code, then act on the merits. A reviewer can be wrong; so can you. Technical correctness over social comfort.
When to use
- Any review feedback has arrived on code you wrote — a human reviewer, an AI reviewer, a PR comment thread.
- Not a step you skip because the feedback "looks obviously right". Obvious-looking findings are exactly where unverified agreement ships a wrong change.
The discipline
- Gather all of it first. Collect every comment — top-level, inline, per-file — before acting. Items relate; acting on a subset misimplements the whole.
- Understand each item. If any is unclear, STOP — ask, don't guess. Partial understanding produces the wrong fix.
- Verify against the code. For each finding, confirm the problem is real before changing anything. For each suggestion, check it's actually needed here (grep for the usage) before adopting it.
- Respond on the merits. Agree where verified; push back with evidence where not. "Checked X — it already handles Y, leaving as is" is a complete, correct response.
- Acknowledge substantively, not socially. "Verified — fixing." / "You're right, confirmed Z." No "absolutely right!", no thanks, no over-explaining. State it and move.
Red flags — these thoughts mean STOP
| Thought | Reality |
|---|---|
| "You're absolutely right!" | You haven't checked yet. Verify first, then respond. |
| "The reviewer said so, just do it" | Reviewers are fallible. Confirm the problem is real before changing code. |
| "I'll make it more robust while I'm here" | A suggested feature still has to be needed. Grep for the use; YAGNI otherwise. |
| "I'll fix the ones I get and skip the unclear ones" | Partial understanding = wrong fix. Items relate — clarify before acting. |
| "Easier to just agree and move on" | Social comfort over correctness. The reviewer and you both serve the code. |
Common mistakes
- Implementing a finding without reproducing the problem it claims to find.
- Adding "proper" machinery a reviewer suggested that nothing in the codebase needs.
- Performative agreement that commits you to a change you never verified.
Gives 0 of the 12 instructions most code review skills give
Counted across 610 of the 674 authors here whose files we hold, read 2026-08-06
- push back with technical reasoning if wrongin 60 of 610, across 24 files
- ask for clarification on unclear itemsin 51 of 610, across 16 files
- fix critical issues immediatelyin 45 of 610, across 29 files
- implement one item at a timein 45 of 610, across 11 files
- group findings by severityin 44 of 610, across 43 files
- verify feedback against the codebasein 42 of 610, across 8 files
- dispatch a code reviewer subagentin 39 of 610, across 23 files
- fix important issues before proceedingin 37 of 610, across 22 files
- test each fix individuallyin 35 of 610, across 7 files
- reply in github comment threadsin 33 of 610, across 5 files
- check for security vulnerabilitiesin 31 of 610, across 27 files
- factualize corrections without over-explainingin 30 of 610, across 2 files
Said here and by no other author read
- Gather all review comments before acting on any
- Confirm suggested additions are actually needed before adopting them
- Acknowledge feedback substantively and without social padding
- Reproduce claimed problems before implementing fixes
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.