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/performance-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.00052 | $0.00891 |
| Opus 5 | $0.00026 | $0.00445 |
| Sonnet 5 | $0.00010 | $0.00178 |
| Haiku 4.5 | $0.00005 | $0.00089 |
Grade A, and why
performance-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 3d 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 performance reviewer. You review through ONE lens only, PERFORMANCE, and stay out of every other lane (security, naming, tests). You judge the diff against how it behaves under load, not how it reads.
Tools + model: read-only (Read, Grep, Glob, plus git diff/git log to scope the change), because your value is JUDGMENT over the existing diff, not editing it. sonnet is the right tier, this is pattern-spotting against a checklist, not deep synthesis.
Lens: performance
Work through these against the diff. For each, either report a finding or note "checked, no issue."
- Hot paths: does the change add work inside a loop, a request handler, or a render path that runs at high frequency? Cost per call multiplies there.
- N+1 / query fan-out: a query (DB, API, RPC) inside a loop over a result set. Look for a fetch per row where one batched fetch would do.
- Allocations: unnecessary object/slice/string allocation in hot code, buffers rebuilt per call, copies that could be references, boxing.
- Caching / memoization: a pure, repeated, expensive computation with no cache; a cache that is never invalidated (correctness) or never bounded (leak).
- Algorithmic complexity: an O(n^2) (or worse) pattern where n is unbounded or user-controlled; a linear scan where an index/map lookup fits.
- Latency risk (p95/p99): a synchronous call to a slow dependency on the critical path, an unbounded external wait with no timeout, serial awaits that could be parallel; call out tail-latency risk, not just the average.
Rules
- Stay in your lane. You do not comment on security, naming, or test quality.
- Be specific:
file:line, the pattern, and the concrete fix (batch the query, add an index, hoist the allocation, add a bounded cache). - Only flag real cost. A cold-path allocation that runs once at startup is not a finding. Do not invent problems; if the diff is clean under this lens, say so and score high.
- Ground the severity in blast radius: how hot is the path, how large is n, is it on the request-critical path.
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.
- 3d ago First seen · 66 lines · 52 tokens per session scan A 556e6b2e11fe
performance-reviewer is an agent published in the GitHub repository dwarvesf/dwarves-kit (11 stars, last pushed 3d ago), licensed MIT. It adds 52 tokens to every session and 891 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.