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 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/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/matheuspavaneli/workbench/address-review"><img src="https://agentmods.dev/badge/skills/matheuspavaneli/workbench/address-review.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.00042 | $0.00634 |
| Opus 5.5 | $0.00017 | $0.00254 |
| Sonnet 5.5 | $0.00008 | $0.00127 |
| Haiku 4.5 | $0.00004 | $0.00063 |
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 1mo 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 — 57 lines — stays where its author put it; the contents beside it link to each section on GitHub.
address-review
wb <args> # wb not on PATH: python <this skill's directory>/../../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 —
../../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, citing code as`path:line` — `the line`.cite checkthat file (--worktreefor uncommitted changes) before showing it; 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.
- 1mo ago Changed 2aaefd30e217
- 1mo ago Changed · +1 lines be9e6ca8eeec
- 2mo 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 1mo ago), licensed MIT. It adds 42 tokens to every session and 634 once invoked, about $0.0002 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-08-31.
Other skills, from other repositories
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.
coverage-check
Run the repo's unit tests with coverage and verify that every file touched in the current change keeps line, branch, and function coverage at or above 95%. Language- and framework-agnostic. Use before committing, before PR creation, or when the user asks about coverage.
work-story
Work a user story end to end — fetch the ticket, plan (with approval), implement, verify the applicable gates, self-review, open the PR, and update the tracker. Use when given an issue key like PROJ-1234, ENG-42, or.
run
The single lifecycle entry point — take one or more tickets and drive each through its whole lifecycle (investigate, red tests, implement, gates, review, PR, merge, archive), interleaving them. Lean by default — one worker per ticket runs red tests, implementation and the gate scripts in one worktree, then…
release
Cut a brooks-lint release: set the version in package.json, propagate it across all four plugin manifests and every version-bearing text file (README badges, docs site metadata), write the CHANGELOG entry, validate, then commit, push, tag, and publish the GitHub release. Triggers when the maintainer asks to "release"…
pr
Comprehensive PR/issue review - analyzes architecture, tests, identifies unrelated changes mixed in, drafts review comment or issue comment. Use when user asks to review a PR, check a PR, look at PR changes, or comment on an issue.