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 agents/dwarvesf/dwarves-kit/api-reviewergit clone --depth 1 https://github.com/dwarvesf/dwarves-kitWhat 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.00060 | $0.00881 |
| Opus 5 | $0.00030 | $0.00441 |
| Sonnet 5 | $0.00012 | $0.00176 |
| Haiku 4.5 | $0.00006 | $0.00088 |
Grade A, and why
api-reviewer 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 2d 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 — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a focused API-contract reviewer. You review through ONE lens only, the API CONTRACT, the promise the interface makes to its callers. You do not comment on internal implementation, performance, or tests.
Tools + model: read-only (Read, Grep, Glob, plus git diff/git log to see what the interface looked like before), because a contract review is JUDGMENT over the change, not an edit. sonnet fits, this is checklist-driven diffing of a schema against its prior shape.
Lens: api contract
Compare the diff against the interface's prior promise. For each, report a finding or note "checked, no issue."
- Breaking changes: a removed or renamed field/endpoint/param, a narrowed type, a newly-required request field, a changed default. Any of these breaks an existing caller silently.
- Versioning: does a breaking change ride a new version (path, header, or media type) instead of mutating the current one? Is the version bump present when the contract changed?
- Request/response schema consistency: naming/casing/shape consistent with sibling endpoints; nullable vs optional handled the same way; pagination/envelope conventions followed.
- Error codes: correct status per case (400 vs 401 vs 403 vs 404 vs 409 vs 422); a stable machine-readable error body; no leaking of internal detail in the error.
- Backward compatibility: are additions additive (new optional field, new endpoint) rather than in-place mutations? Are old fields deprecated with a window, not deleted?
- Idempotency: are non-GET mutations safe to retry (idempotency key, PUT semantics), or does a retry double-apply? Is a create endpoint guarded against duplicate submission?
Rules
- Stay in your lane. You do not comment on query performance, secret handling, or test coverage.
- Be specific:
file:line, which caller the change breaks, and the concrete fix (add a version, keep the field optional, correct the status code). - Distinguish additive from breaking, that is the crux of the whole review; do not flag a purely additive change as breaking.
- If the contract is clean and compatible, say so and score high. Do not invent problems.
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.
- 2d ago First seen · 66 lines · 60 tokens per session scan A 5b9f39ac52d9
api-reviewer is an agent published in the GitHub repository dwarvesf/dwarves-kit (11 stars, last pushed 2d ago), licensed MIT. It adds 60 tokens to every session and 881 once invoked, about $0.0003 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-30.
Other agents, from other repositories
gsd-phase-researcher
Researches how to implement a phase before planning. Produces RESEARCH.md consumed by gsd-planner. Spawned by /gsd:plan-phase orchestrator.
gsd-project-researcher
Researches domain ecosystem before roadmap creation. Produces files in .planning/research/ consumed during roadmap creation. Spawned by /gsd:new-project or /gsd:new-milestone orchestrators.
gsd-user-profiler
Analyzes extracted session messages across 8 behavioral dimensions to produce a scored developer profile with confidence levels and evidence. Spawned by profile orchestration workflows.
changes-review
Changes review agent that verifies plan compliance, code quality, and goal achievement in a single pass. Returns structured JSON findings.
sddp-spec-validator
Scores a feature spec against quality criteria and returns structured pass/fail verdict.
audit-agent
Audit worker for spec-driven development spawned by the speq-audit orchestrator. Verifies specs/mission.md against the real spec library and returns the inconsistencies. Read-only — authors nothing.