agentsclimarketplace
Sign in

Receiving feedback

Skill nicograef/handbook/.claude/skills/receiving-feedback

Acts on code-review feedback (from a human, a PR comment, or an AI reviewer) by verifying each item against the codebase before implementing, and asking when items are unclear. Use when receiving code review comments, PR feedback, or suggestions from another reviewer — before implementing any of them.From its SKILL.md

Install
npx -y skills add nicograef/handbook --skill receiving-feedback

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 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.

SKILL.md

3.4 KB, as published. Nobody here has run it

Receiving Feedback

Adapted from the MIT-licensed superpowers plugin.

Code review requires technical evaluation, not a reflex to agree. Verify before implementing, ask before assuming, and prefer technical correctness over social comfort.

Workflow

  1. Read all feedback first. Do not reply or start fixing item by item.
    • Items are often related; a partial read leads to a wrong fix.
  2. Restate each item as a concrete technical requirement in your own words.
    • Genuinely ambiguous item — mark it unclear instead of guessing.
  3. Any item unclear — ask about all unclear items before implementing anything.
    • Never implement the clear items first and ask later.
    • Resolving the unclear ones can change how the clear ones should be done.
  4. Verify each clear item against the actual codebase:
    • Does it match current behavior, or is the reviewer assuming something false?
    • Would the change break existing tests or other callers?
    • Is there a reason the code is the way it is?
    • Such reasons: compatibility, a prior decision, a constraint the reviewer may not see.
    • Is the suggestion actually used, or does it add something nothing calls (YAGNI)?
  5. Evaluate technical soundness for this stack.
    • A suggestion can be generically reasonable and still wrong for Nico's stack.
    • Judge it in that context, never in the abstract.
    • That context: Go stdlib patterns, React/TS conventions, sqlc-generated code, etc.
  6. Push back with reasoning when a suggestion is wrong.
    • State the specific technical reason: a failing assumption, a broken test, a compatibility constraint.
    • Then propose an alternative, or ask which tradeoff to take.
  7. Implement one item at a time, in this order: blocking issues (bugs, security), then simple fixes, then complex/structural fixes.
    • Verify each one (tests, build, manual check) before moving to the next.
  8. Report back factually. Counts line first: 6 items — 4 implemented, 1 rejected, 1 open.
    • Implemented — what changed and where.
    • Not implemented — the item, plus the technical reason it was rejected.
    • Wrong pushback — you pushed back and were wrong: say so plainly, then fix it.
    • Nothing to report: one line, no padding.

Constraints

  • Acknowledge with the fix itself or a one-line factual note.
  • Skip the social filler: "you're right", "great point", "thanks for catching that".
  • Architectural pushback goes to Nico, never into a unilateral decision.
  • A suggestion conflicting with an existing architectural choice — flag it and ask.
  • Never silently override either the reviewer or the prior decision.
  • Reply to inline PR comments on GitHub in the comment thread, not as a new top-level PR comment.
  • Thread reply endpoint: gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies.

Quality

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.