Install any skill in seconds. Free to start, no credit card required.
Get Started Free →jamditis/receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Passed 20 of 24 test cases with the skill, and 13 of 24 without it.
and 9 more in the full report
8 fixed12 passed either way3 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
A reviewer found that `JSON.parse` in our Node.js handler was missing a try-catch block. Draft a short acknowledgment message to post on the PR confirming that the error handling was added.
| Checked | Without skill | With skill |
|---|---|---|
| States the addition of the try-catch error handling without praising the reviewer. | Missed | Passed |
The instructions your model reads when the skill loads.
Code review requires technical evaluation, not emotional performance.
Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.
WHEN receiving code review feedback:
1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time, test each
NEVER:
INSTEAD:
test cases passed, vs 13 / 24 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.