Receiving code review
Skill kimtth/agent-skill-100-lines-or-less/skills/receiving-code-review
🧿 Minimal but effective AI agent skill definitions in 100 lines or less.
npx -y skills add kimtth/agent-skill-100-lines-or-less --skill receiving-code-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 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
Use when: handling code review feedback before implementing suggestions or pushing back.
SKILL.md
1.0 KB, as published. Nobody here has run it
Goal: respond to review feedback with technical rigor, not automatic agreement.
Workflow:
- Read every review item before editing.
- Restate the technical requirement when it is unclear.
- Verify each claim against code, tests, docs, and runtime behavior.
- Decide whether the feedback is correct for this codebase.
- Implement one item at a time with focused verification.
- Push back with evidence when a suggestion is wrong or risky.
Use for:
- PR review comments
- reviewer requests that appear contradictory
- broad requests such as "fix 1-6"
- feedback that changes API, behavior, or test expectations
Response pattern:
- understood requirement
- evidence checked
- action taken or reasoned pushback
- verification result
Rules:
- do not say feedback is right before checking
- do not implement unclear items silently
- avoid bundling unrelated review fixes
- keep behavior changes explicit
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
- read every review item before editing
- decide whether feedback is correct for the codebase
- implement one item at a time with focused verification
- keep behavior changes explicit
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.