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 makifbaysal/tasktrooper --skill addressing-review-feedbackgit clone --depth 1 https://github.com/makifbaysal/tasktrooperWrote 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/makifbaysal/tasktrooper/addressing-review-feedback)<a href="https://agentmods.dev/skills/makifbaysal/tasktrooper/addressing-review-feedback"><img src="https://agentmods.dev/badge/skills/makifbaysal/tasktrooper/addressing-review-feedback/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/makifbaysal/tasktrooper/addressing-review-feedback"><img src="https://agentmods.dev/badge/skills/makifbaysal/tasktrooper/addressing-review-feedback.svg" alt="Reviewed on agentmods" width="80" 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.00037 | $0.00719 |
| Opus 5.5 | $0.00015 | $0.00288 |
| Sonnet 5.5 | $0.00007 | $0.00144 |
| Haiku 4.5 | $0.00004 | $0.00072 |
Grade A, and why
addressing-review-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 8d 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 — 29 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Addressing Review Feedback
Overview
A need_revision task is somebody else's evidence that something is wrong, not a request to improvise. Treat it the way you would a bug report: verify, fix at the root, prove it with a test, and answer every point — silence on one is how a task bounces a second time for something you could have agreed or disagreed with up front.
The Process
- Read everything before touching code. Every numbered point on the task, plus the PR review comments when the round happened there (
list_task_comments,get_task_pull_requestwithinclude_diff: falsewhen you don't need the diff itself). If a point is unclear, re-read the code it's about before acting on a guess. Points can be related — a root cause can explain two of them at once. - Verify each claim against the code and, where you can, the running product — a reviewer can be wrong about where a line lives or what a function does. Classify each point: fix (the claim holds), disagree (with evidence — a file:line or a run that shows the current behavior is correct), or needs a human decision (a product call neither of you can settle from the code).
- Fix in order: blocking → simple → complex. Blocking = crash, security hole, or an acceptance criterion left unmet. Each fix gets its own guard test that fails before the fix and passes after (root-cause-debugging) — a fix with no failing-first test is not verified, it's hoped.
- Push back technically, never performatively. A point you disagree with gets a reasoned answer with evidence, not silent compliance and not silent skipping. Reply in the PR thread (
comment_on_pull_requestwithreply_to_comment_id) when it came from a review comment — a new top-level comment leaves the reviewer's thread looking unanswered; otherwiseadd_task_commentfor a task-comment point. No "You're absolutely right," no thanks, no preamble — state the finding. - A YAGNI check when a reviewer asks you to "implement it properly" or "handle the general case":
grep_codefor actual callers first. Build the general version only if more than one caller needs it; otherwise say so and keep the fix scoped to what broke. - Closing message: a point map. One line per numbered point — point → root cause → fix (file:line) → guard test, or point → why you disagree, with evidence. The architect's review of your revision reads this map against the diff; a revision with no map is a second bounce waiting to happen.
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.
- 8d ago First seen · 29 lines · 37 tokens per session scan A 04d99602d4f3
addressing-review-feedback is a skill published in the GitHub repository makifbaysal/tasktrooper (113 stars, last pushed yesterday), licensed Apache-2.0. It adds 37 tokens to every session and 719 once invoked, about $0.0001 per session on Opus 5.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-10-05.
Other skills, from other repositories
github-pr-workflow
Prepare a GitHub pull request from a feature branch — branch hygiene, commit shape, title/body, verification notes, screenshots for UI work, and replies to review comments.
issue-triage
Triage Paperclip inbox issues that are stale, blocked, in-review, or assigned-but-not-progressing, and decide a single next action per issue (resume, reassign, unblock, escalate, or close).
doca-flow
Build and debug DOCA Flow applications on supported NVIDIA NICs/DPUs: define match/action pipes, initialize ports and representors, choose forwarding targets, validate pipes before hardware programming, read counters, match the Flow version to the installed DOCA release, and diagnose Flow API errors. Trigger on DOCA…
mcore-create-issue
Investigate a failing GitHub Actions run or job and create a GitHub issue for the failure.
doca-dpa-hl-tracer
Use this skill when the user runs docadpahltracer to capture/decode DPA-side traces at the programming-events layer (kernel entry/exit, sync points, comm primitive calls, RDMA WR submission, completion drain) — picking TRACE vs CRIT, tuning the JSON config (file-size limits + filesizelimitpolicy, thread…
doca-debug
Use this skill when the user is debugging any DOCA symptom — a build that won't compile, a link step that can't resolve a doca symbol, a runtime call returning DOCAERROR, a silent service or tool, or a stack trace / valgrind / core dump — and needs the layered ladder (install → version → build → link → runtime →…