Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add redhuntlabs/wizard --skill responding-to-feedbackgit clone --depth 1 https://github.com/redhuntlabs/wizardWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/redhuntlabs/wizard/responding-to-feedback)<a href="https://agentmods.dev/skills/redhuntlabs/wizard/responding-to-feedback"><img src="https://agentmods.dev/badge/skills/redhuntlabs/wizard/responding-to-feedback.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00025 | $0.01009 |
| Opus 5 | $0.00013 | $0.00504 |
| Sonnet 5 | $0.00005 | $0.00202 |
| Haiku 4.5 | $0.00003 | $0.00101 |
Grade A, and why
responding-to-feedback scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 122 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Responding to Feedback
What this does
Turns a pile of feedback (comments, edits, critique) into a structured response that addresses each piece explicitly: accept, reject, negotiate, or defer — with reasons.
When to use
- Code review with many comments
- Manuscript revisions from an editor or reviewer
- Design critique session output
- Performance review feedback you need to respond to
- Customer feedback on a delivered product
What you bring (Inputs)
- The piece of work
- The feedback (as a list, or a thread to parse first)
- Your authority (can you accept/reject unilaterally, or do you need to negotiate?)
What you get (Output)
A response that addresses every atom of feedback with a classification and a decision, plus the implementation plan for accepts.
How it works (Steps)
This is a workflow.
Stages
Stage 1: Parse into atoms
Break the feedback into individual atoms — one issue per atom. A comment that says "this is unclear and the example is wrong" is two atoms.
Stage 2: Classify each atom
For each atom, label one of:
- blocker: must address to ship
- suggestion: could improve the work; not required
- question: the reviewer wants info, not a change
- nit: minor stylistic preference
- out-of-scope: belongs in a different conversation
Stage 3: Decide each atom
For each, decide:
- accept: name what you'll change
- reject: name your reason in one sentence (cite the work or the goal, not feelings)
- negotiate: propose a middle ground
- defer: name when you'll address it (next version / next milestone / never)
Stage 4: Draft the response
For each atom, write one short paragraph: classification → decision → reasoning. Group by classification: blockers first.
Stage 5: Tone check
Read the whole response back. Tone target: grateful (without sycophancy), direct, focused on the work not the person.
Stage 6: Update the work
For accepts, do the actual changes. For negotiates that get agreement, do those too. Don't ship the response without doing the work.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 122 lines · 25 tokens per session scan A 02927fc4268e
responding-to-feedback is a skill published in the GitHub repository redhuntlabs/wizard (9 stars, last pushed 4mo ago), licensed MIT. It adds 25 tokens to every session and 1,009 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
squid-architecture-review
Periodic architectural sweep — reads existing ADRs, maps modules/dependencies/layering, and reports up to 10 prioritised findings shaped as refactor proposals /squid-refactor can consume directly.
squid-implement-night
Run the full agent-team pipeline end-to-end for one feature whose Tasks Plan is already approved by /squid-plan, handing the human a validated, ready-to-squash-merge PR. Trigger after /squid-plan.
squid-review
Push the committed feature branch, create or update its PR, then run Product Architect acceptance and PR-Reviewer on it. Output: a clean PR with no blockers, or ONE rollup task. Trigger after a feature's tasks are implemented and committed.
pr-review
AUTHOR SKILL (internal to microsoft/aspire-skills). Reviews pull requests into this repo for problems only — bugs, regressions, missing eval coverage, frontmatter or routing damage, plugin-manifest drift, hook safety, and other concrete issues. Drives a six-step workflow: identify the PR, ensure the branch is…
generic-fullstack-code-reviewer
Review full-stack code for bugs, security vulnerabilities, performance issues, accessibility gaps, and CLAUDE.md compliance. Enforces TypeScript strict mode, input validation, GPU-accelerated animations, and design system consistency. Use when completing features, before commits, or reviewing pull requests.
generic-react-code-reviewer
Review React/TypeScript code for bugs, security vulnerabilities, performance issues, accessibility gaps, and CLAUDE.md workflow compliance. Enforces TypeScript strict mode, GPU-accelerated animations, WCAG AA accessibility, bundle size limits, and surgical simplicity. Use when completing features, before commits, or…