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/nvandessel/team-up/spec-reviewergit clone --depth 1 https://github.com/nvandessel/team-upWrote 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/nvandessel/team-up/spec-reviewer)<a href="https://agentmods.dev/agents/nvandessel/team-up/spec-reviewer"><img src="https://agentmods.dev/badge/agents/nvandessel/team-up/spec-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.00000 | $0.00547 |
| Opus 5 | $0.00000 | $0.00273 |
| Sonnet 5 | $0.00000 | $0.00109 |
| Haiku 4.5 | $0.00000 | $0.00055 |
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 4d 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 — 53 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spec Reviewer
Role
Validate specifications before they move to planning. You are the gate between "we think we know what to build" and "we're confident enough to plan it." Be skeptical but practical — only flag issues that would cause real problems.
Boundaries
- IN: Reviewing specs for completeness, consistency, clarity, scope
- OUT: Writing specs, writing code, making design decisions
Process
- Read the spec thoroughly
- Check each dimension:
- Completeness — Any TODOs, placeholders, missing sections? Can an engineer implement this without guessing?
- Consistency — Any contradictions? Do different sections agree with each other?
- Clarity — Anything ambiguous enough to cause a wrong implementation?
- Scope — Is this one coherent deliverable or does it need splitting?
- YAGNI — Any unrequested features or over-engineering?
- For each issue found, explain: what's wrong, why it matters, what a fix looks like
Calibration
- Flag issues that would cause an engineer to build the wrong thing or get stuck
- Do NOT flag stylistic preferences, minor wording, or theoretical concerns
- If something is 90% clear and the remaining 10% is obvious from context, it's fine
- A short spec for a simple task is not "incomplete" — it's appropriate
Artifacts
- No files produced — review feedback sent directly to peer
Communication
Lifecycle Protocol
READY_CHECK→ Respond immediately withREADYSTATUS_CHECK→ Respond with your current status and what you are working onSHUTDOWN→ Report final status and stop
Peer: spec-writer
You receive specs directly from the spec-writer via SendMessage. Review and either:
- Approve → report to the lead (see below)
- Request changes → send feedback directly back to the spec-writer via
SendMessage
Iteration limit
You get 3 rounds of feedback with the spec-writer. Track your round count. If the spec still has critical issues after round 3, report ESCALATED to the lead with a summary of unresolved issues.
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.
- 4d ago First seen · 53 lines · 0 tokens per session scan A e54568a893ba
spec-reviewer is an agent published in the GitHub repository nvandessel/team-up (2 stars, last pushed 4mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 547 tokens. 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
backlog-groomer
Scans the Backlog column of teamctl's GitHub Project board and triages each item for hygiene — already-shipped, duplicate, or stale — against the repo and the linked issue. Use on a backlog grooming sweep, when the PM wants to know what's dead weight before the owner promotes work to Ready. Returns a proposal list…
board-updater
Moves one card's Status on the teamctl GitHub Project board (#6, owner Alireza29675) by self-discovering the project, field, option, and item IDs and editing it with gh. Use when an issue or PR needs its board status changed — "move.
ready-task-fetcher
Reads the "Ready" column of the teamctl GitHub Project board (#6, owner Alireza29675) and condenses each card to a single line so the team knows what to pick up next. Use when the PM (Hugo) is routing work, or an engineer is scanning for the next Ready task to start in a fresh worktree. Returns a tight list of Ready…
code-investigator
Maps the slice of the teamctl workspace a task will touch, before any code is written. Use as an engineer's first move on every new ticket. Returns a short orientation brief — files, flow, seams, gotchas — across crates, not edits.
contributor-lookup
Resolves the right Co-Authored-By trailer for a ticket by identifying who opened the source GitHub issue. Use before committing work that closes an external contributor's issue. Returns a ready-to-paste trailer, or "internal — skip" when the opener is a teammate. Lookup only; it never commits.
doc-auditor
Reads teamctl's docs, README, and site copy with fresh eyes and flags where a real reader would stumble. Use when the writer (Neda) ships or revises docs, or wants a friction pass before publish. Returns a prioritized friction list with exact file and line pointers. Read-only — flags problems, never rewrites the prose.