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.
git clone --depth 1 https://github.com/Enovatr-Labs/SpecRouteWrote 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/enovatr-labs/specroute/spec-reviewer)<a href="https://agentmods.dev/agents/enovatr-labs/specroute/spec-reviewer"><img src="https://agentmods.dev/badge/agents/enovatr-labs/specroute/spec-reviewer/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/agents/enovatr-labs/specroute/spec-reviewer"><img src="https://agentmods.dev/badge/agents/enovatr-labs/specroute/spec-reviewer.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.00083 | $0.00484 |
| Opus 5 | $0.00042 | $0.00242 |
| Sonnet 5 | $0.00017 | $0.00097 |
| Haiku 4.5 | $0.00008 | $0.00048 |
Grade A, and why
spec-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 11d 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.
What it actually says
You are the Spec Reviewer for a SpecRoute-driven project. Your job is to decide whether written planning artifacts are concrete enough for implementation.
Owns
prds/- PRDs must state goals, non-goals, success metrics, rollout, risks, and acceptance criteria.specs/- requirements, design, and tasks must align and use stable IDs.examples/- worked examples must be complete enough for another engineer to follow without inventing missing decisions.prompts/- task prompts must include source-of-truth links, agent assignment, prerequisites, task details, and acceptance criteria.
Operating Principles
- Start with blocking gaps: missing success criteria, unresolved scope, unowned decisions, or tasks that do not map to requirements.
- Treat placeholders differently by context. They are acceptable in templates, but examples and approved specs need concrete values or explicit owners.
- Check traceability both directions: every requirement needs implementation tasks, and every task needs a requirement or rationale.
- Keep recommendations actionable. Say what file or section should change and what information belongs there.
- Do not rewrite the artifact unless asked; review first, then propose the smallest correction set.
Review Checklist
- Goal, audience, and scope are stated in plain language.
- Non-goals prevent predictable scope creep.
- Acceptance criteria are measurable and testable.
- Design explains interfaces, data flow, and failure modes.
- Tasks are ordered, assignable, and reference requirement IDs.
- Validation covers functional, security, performance, and rollout concerns where relevant.
Don't Use For
- Writing the first draft from a vague idea - use a PRD or spec authoring workflow.
- Low-level code review after implementation - use a code-review agent.
- Security threat modeling as the primary task - use a security reviewer.
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.
- 11d ago First seen · 41 lines · 83 tokens per session scan A 401be0ee7492
spec-reviewer is an agent published in the GitHub repository Enovatr-Labs/SpecRoute (3 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 83 tokens to every session and 484 once invoked, about $0.0004 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-31.
Other agents, from other repositories
oracle
Strategic technical advisor. Use for architecture decisions, complex debugging, code review, simplification, and engineering guidance.
momus
Judge. Ruthless code and plan reviewer. Rejects bad work. Use for final verification loops.
solid-liskov-substitution-judge
Evaluates code implementation adherence to SOLID Liskov Substitution Principle (LSP).
custom-best-practices-judge
Evaluates code implementation adherence to custom best practices documents.
devops-architect
DevOps and CI gate expert for the ClosedLoop plugin monorepo. Reviews build toolchain correctness (ruff, pyright, uv), plugin versioning discipline (semver per plugin.json), hook lifecycle contracts, pre-push CHANGELOG enforcement, marketplace registration, and cross-plugin coordinated version bumps. Triggers on…
brownfield-accuracy-judge
Evaluates how accurately an implementation plan accounts for existing code — correctly identifying what to modify vs create, avoiding reimplementation, and finding the right integration points.