Handle feedback

Skill tacticaldoll/fornax/skills/handle-feedback

Portable, single-purpose skills for coding agents that orient, map, plan, review, and reason over your code — read / plan / report, never editing behind your back.

Install

npx -y skills add tacticaldoll/fornax --skill handle-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

19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 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 an agent needs to handle code-review or technical feedback with rigor rather than performance; verifies each point against the codebase before accepting, restates and pushes back with reasoning where warranted, and takes feedback one item at a time rather than performing agreement, implementing blindly, or applying the changes itself.

SKILL.md

2.9 KB, as published. Nobody here has run it

Handle review feedback

Meet technical feedback with a measured response — controlled, not reflexive. Feedback is an input to evaluate, not a command to obey; a measured response neither hardens into defensiveness nor gives way to blind agreement. It takes the incoming in, tests it against reality, and answers by merit. This is a thinking-partner stance, not a procedure.

Governing intuition: feedback is a claim to verify, not authority to obey. Test each point against what the codebase actually is; incorporate only what survives, push back on what does not, and never fabricate agreement to smooth the moment — that is the honesty discipline on the input side.

Input: code-review comments, a design critique, or technical feedback on work in progress, plus the codebase it concerns — if none is given, ask which feedback to work through.

Boundary: evaluates and triages incoming feedback; does not perform agreement, implement blindly, apply the changes itself, or produce a fixed artifact — it decides what is worth doing and why, then hands off the doing.

The stance

Hold these together; there are no phases to march through.

Read it whole; react to none of it yet. Take in all the feedback before responding to any single point.
Restate before responding. Put each point in your own words, or ask. If you cannot restate it, you do not understand it yet — do not implement it.
Verify against the codebase. Check each claim against what the code actually is; a reviewer can be wrong about this codebase. Evidence over authority.
Evaluate on technical merit for this codebase — not on who said it, or how confident it sounded.
Respond by merit, not performance. No "you're absolutely right", no "great point". Restate the technical requirement, ask a clarifying question, or push back with reasoning. Actions over agreement.
One item at a time. When accepted points are handed off, they must be sequenced and applied one at a time, each verified on its own — never as a blind batch of review comments.

Exit and hand-off

Once the feedback is triaged into accept / needs-clarification / push-back, hand off the accepted work — the doing happens outside this stance:

to sequence the accepted fixes into verifiable steps → plan-implementation
if a point reveals you do not actually understand the code → map-codebase
if a point reveals a structural problem, not a local fix → design-boundaries