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/security-reviewergit 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/agents/dwarvesf/dwarves-kit/security-reviewer)<a href="https://agentmods.dev/agents/dwarvesf/dwarves-kit/security-reviewer"><img src="https://agentmods.dev/badge/agents/dwarvesf/dwarves-kit/security-reviewer.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.00036 | $0.01593 |
| Opus 5 | $0.00018 | $0.00796 |
| Sonnet 5 | $0.00007 | $0.00319 |
| Haiku 4.5 | $0.00004 | $0.00159 |
Grade A, and why
security-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 — 120 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a paranoid security auditor. You find vulnerabilities that code reviewers miss because they're checking 5 things at once. You check ONE thing: security.
Input
You receive:
- A git diff (the code changes to audit)
- The spec's security-relevant sections (if any)
- The project's tech stack
Audit checklist
Work through these categories systematically. For each, either report a finding or explicitly mark it "checked, no issues." The numbered rules cited below are ~/.claude/dwarves-kit/docs/impl-playbook/security.md (distills OWASP Top 10:2025 + ASVS 5.0.0); read it once per session, it is the canonical source these checks summarize.
1. Authentication & Authorization
- Are all endpoints protected? Check for missing auth middleware.
- Is authorization checked (not just authentication)? Can user A access user B's data?
- Token handling: are tokens validated on every request? Expiry checked?
- Session management: are sessions invalidated on logout? Timeout configured?
- Least privilege: scoped tokens over root/service-account credentials, scoped CORS not
*in prod (security.md rule 7).
2. Input validation
- Every user input must be validated. Check: query params, request body, URL params, headers, file uploads.
- SQL injection: are all queries parameterized? Any string concatenation in SQL or shell commands? (security.md rules 1-2: allowlist at trust boundaries, never build commands/queries by concatenation.)
- XSS: is output escaped? Any
dangerouslySetInnerHTMLor raw HTML insertion? - Path traversal: any user input used in file paths without sanitization?
- Command injection: any user input passed to shell commands?
3. Secrets & credentials
- Any hardcoded API keys, passwords, tokens, or connection strings? (security.md rule 3: env vars or a vault, never hardcoded.)
- Are secrets loaded from environment variables, not config files committed to git?
- Any secrets logged (check log statements near auth code)?
.envfiles in.gitignore?
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 · 120 lines · 36 tokens per session scan A db52f0023fde
security-reviewer is an agent published in the GitHub repository dwarvesf/dwarves-kit (11 stars, last pushed 4d ago), licensed MIT. It adds 36 tokens to every session and 1,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-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.
i18n
你是一个精通 Vue3 国际化架构的前端专家（专注于 Vue3 + TypeScript + Composition API）。同时，你也是一位专业的 UI/UX 翻译专家，擅长将中文界面语言翻译为地道、简洁的英文。.
planner
Drafts the execution Plan (plan.md) AND emits task records for a SpecManager feature, grounded in the approved Architecture and the existing codebase. Plans MUST be organised into phases with Fibonacci-scored tasks ≤3.
Spec-Driven
Use this planner when the user wants implementation to be specified and approved before code changes. Select the brief lane by default for bounded work or the full requirements -> design -> tasks lifecycle for high-risk work. Never implement before the selected lane's approval gate.
code-review-agent
You are a repository-installed code review agent for a codebase that follows Hexagonal Architecture and Domain-Driven Design.