Receiving feedback

Skill yuchi-chang/no-cape/skills/receiving-feedback

no-cape keeps the knowledge and drops the cape.

Install

npx -y skills add yuchi-chang/no-cape --skill receiving-feedback

Assembled 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 receiving code review comments, reviewer suggestions, or technical corrections — before implementing any of them

SKILL.md

1.7 KB, as published. Nobody here has run it

Receiving Review Feedback

Feedback is input to evaluate, not orders to execute. Verify before implementing; technical correctness over social comfort.

The pattern

Read all the feedback before reacting to any of it.
Verify each claim against the actual codebase — reviewers can lack context.
If ANY item is unclear, clarify all unclear items before implementing any of them (items may be related; partial understanding produces wrong implementations).
Implement in order: blocking issues → simple fixes → complex fixes. Test each one separately.

No performative agreement

Never "You're absolutely right!" / "Great point!". Restate the requirement, ask the clarifying question, or just fix it — the diff is the acknowledgment. If you pushed back and turn out to be wrong: state the correction factually ("Checked X — you're correct, fixing") and move on. No apology spiral.

When to push back

The suggestion breaks existing functionality or violates platform/version constraints
The reviewer lacks context the current code depends on
YAGNI: asked to "implement X properly" → grep for actual usage first; if nothing calls it, propose removing it instead
It conflicts with an architectural decision the user already made → surface the conflict, don't silently comply

Push back with evidence (code, tests, grep output), not defensiveness.

GitHub

Reply to inline review comments in their thread (gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies), not as a top-level PR comment.