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 commands/dwarvesf/dwarves-kit/review-teamgit clone --depth 1 https://github.com/dwarvesf/dwarves-kitWrote 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/commands/dwarvesf/dwarves-kit/review-team)<a href="https://agentmods.dev/commands/dwarvesf/dwarves-kit/review-team"><img src="https://agentmods.dev/badge/commands/dwarvesf/dwarves-kit/review-team.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.00045 | $0.05733 |
| Opus 5 | $0.00023 | $0.02867 |
| Sonnet 5 | $0.00009 | $0.01147 |
| Haiku 4.5 | $0.00005 | $0.00573 |
Grade A, and why
review-team 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 5d 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 — 368 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a review coordinator. Your job is to dispatch 3 focused lenses in parallel, collect their findings, deduplicate, and present a unified report.
Prerequisites
- There are code changes to review (git diff is not empty)
- Optionally,
docs/specs/SPEC-NNN-<slug>.mdexists for spec-compliance checking
If no changes exist, tell the user and stop.
Process
Bracket the review phase for timing (SPEC-129) before starting: bash lib/gate/gate-ledger.sh outcome "$rid" review start.
Step 1: Gather the diff
Run git diff main (or git diff HEAD~N if on main). Capture the diff and the list of changed files.
Fail fast BEFORE any dispatch (SPEC-205). Confirm the fixed point resolves
(git rev-parse <fixed-point>) and the diff is non-empty. A bad ref or an empty diff
fails here with one line , never inside four parallel subagents.
Advisory coverage-delta signal (SPEC-130, ADVISORY, never blocks). Before dispatching the lenses, run the coverage-delta gate and fold its one line into the test-coverage lens's input:
bash lib/gate/coverage-delta.sh check "$(git rev-parse --show-toplevel)" --rid "$(bash lib/gate/gate-ledger.sh rid 2>/dev/null)"
It prints one [coverage-delta] line , WARNING under-tested (source moved, no matching test
change; it names the uncovered files), ok (source + test moved together), or exempt
(docs/test/generated only). It ALWAYS exits 0 and records an advisory | GATE | coverage-delta | ran | marker on the ledger; it is a warn-only signal for the test-coverage reviewer, NOT a
block. This is the live dispatch path for the SPEC-130 gate (the Review phase, off the push
blocker). A WARNING is advisory input to the test-coverage lens, never a stop.
Step 2: Dispatch 3 lenses in parallel
Dispatch these 3 subagents via the Task tool. They can run simultaneously since they're all read-only and don't modify anything.
Domain lens (opt-in, SPEC-111). In addition to the fixed 3, classify the changed files' domain , bash lib/classify/role-classify.sh classify "<changed paths + diff summary>" , and if a domain REVIEWER exists for that domain (performance-reviewer, api-reviewer, frontend-reviewer, infra-reviewer), dispatch it too, in the same parallel batch, through its domain lens. This is the live dispatch path for the SPEC-111 read-only domain reviewers (workers dispatch via /kit:execute 2b-0 instead). Skip when no domain reviewer matches; the fixed 3 lenses are unchanged.
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.
- 5d ago First seen · 368 lines · 45 tokens per session scan A dcd012a82fc6
review-team is a command published in the GitHub repository dwarvesf/dwarves-kit (11 stars, last pushed yesterday), licensed MIT. It adds 45 tokens to every session and 5,733 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-30.
Other commands, from other repositories
OPSX: Archive
Archive a completed change in the experimental workflow.
OPSX: Explore
Enter explore mode - think through ideas, investigate problems, clarify requirements.
OPSX: Propose
Propose a new change - create it and generate all artifacts in one step.
OPSX: Sync
Sync delta specs from a change to main specs.
OPSX: Apply
Implement tasks from an OpenSpec change (Experimental).
OPSX: Update
Update a change - revise existing planning artifacts and keep them coherent (Experimental).