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 agentmods add skills/matheuspavaneli/workbench/address-reviewnpx skills add matheusPavaneli/workbench --skill address-reviewgit clone --depth 1 https://github.com/matheusPavaneli/workbenchWrote 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/matheuspavaneli/workbench/address-review)<a href="https://agentmods.dev/skills/matheuspavaneli/workbench/address-review"><img src="https://agentmods.dev/badge/skills/matheuspavaneli/workbench/address-review.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 | $0.00042 | $0.00593 |
| Opus 5 | $0.00021 | $0.00296 |
| Sonnet 5 | $0.00008 | $0.00119 |
| Haiku 4.5 | $0.00004 | $0.00059 |
Grade A, and why
address-review 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 4d 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 — 56 lines — stays where its author put it; the contents beside it link to each section on GitHub.
address-review
python "${CLAUDE_PLUGIN_ROOT}/lib/wb.py" <args>
Steps
-
Collect the comments. This plugin talks to issue trackers, not code hosts, so use whatever the environment provides —
gh pr view --comments,gh api, the Azure DevOps CLI, or text the user pastes. If none is available, ask for the comments rather than guessing what they said. -
Triage each one into exactly one bucket, and say which:
- accept — correct, will change.
- question — cannot act until the reviewer clarifies; draft the question.
- disagree — will not change, with a reason and evidence.
- out of scope — real, but a separate ticket; name the follow-up.
Do not silently drop a comment. A reviewer who gets no answer assumes it was missed, and asks again.
-
Verify before agreeing. A reviewer can be wrong about this codebase. Read the code the comment refers to before accepting it —
${CLAUDE_PLUGIN_ROOT}/shared/code-search.md— and quote the line in the reply when you disagree. -
Apply the accepted changes. Same discipline as
implement-change: smallest diff, existing patterns, tests updated with the code. If a comment pushes the change outside the plan's file list, that is a plan change — updatesdd.jsonand re-runsdd audit <KEY>. -
Re-verify.
impl verify <KEY>if a plan exists, otherwise the repo's test command. Review feedback is exactly when a regression slips in. -
Re-review your own diff.
review contexton the new changes. -
Write the replies to
.workflow/<KEY>/review-response.md, one per comment, each saying what was done or why not. Show them; posting is the user's call.
Rules
- Every comment gets an answer, including the ones you disagree with.
- Disagreement needs evidence.
file:lineand the actual line, not an assertion. If you cannot support it, the reviewer is probably right. - Never widen the change to satisfy a stylistic note. Offer the follow-up ticket instead.
- Do not weaken a test to make review feedback pass. If the test now fails, say whether the change is wrong or the test encoded old behaviour.
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.
- 4d ago First seen · 56 lines · 42 tokens per session scan A 1293d382f926
address-review is a skill published in the GitHub repository matheusPavaneli/workbench (1 stars, last pushed 13d ago), licensed MIT. It adds 42 tokens to every session and 593 once invoked, about $0.0002 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
integration-rule-engine
A declarative routing engine that turns ticket / error attributes (reporter, label, project, area path, error class, environment) into a tag + AI agent + priority assignment, so cross-source workflows ("security tickets always go to the OWASP reviewer") stay out of code and in user-editable rules.
stale-ticket-triage
Replace the weekly "look at every ticket older than X days" meeting with a scheduled AI scan that picks close / snooze / keep per ticket plus a one-sentence reason, so a PM can bulk-approve in 90 seconds Monday morning.
dev-kit-setup
First-use bootstrap for the dev kit. Detects the team's issue tracker, discovers what it can via MCP/CLI, asks only what cannot be discovered, and persists the result to .claude/dev-kit.json in the consuming repo. Use when that file is missing, when the user asks to set up or reconfigure the kit, or when issue-fetch…
feature-execution
This skill should be used when the user asks to "orchestrate the feature", "run the phases", "resume implementation", "continue the plan", "the phase agent died", "the agent stopped on its usage limit", "accept this phase", "can these phases run in parallel", "is this phase done", "does this shortfall matter", or…
create-pr
Create a branch, commit the work, and open a pull request for a completed user story, after all quality gates pass. Use when the user asks to open/create a PR or as the final step of the story workflow.
fix-pr
Resolve the findings on an existing pull request - review comments, CI failures, and self-review findings - driving each to a decision (fix / defer to a tracked issue / discard), re-verifying the gates, replying to each reviewer, and watching for late feedback. The counterpart to pr-review that closes the loop.