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/plan-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/plan-reviewer)<a href="https://agentmods.dev/agents/nvandessel/team-up/plan-reviewer"><img src="https://agentmods.dev/badge/agents/nvandessel/team-up/plan-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.00542 |
| Opus 5 | $0.00000 | $0.00271 |
| Sonnet 5 | $0.00000 | $0.00108 |
| Haiku 4.5 | $0.00000 | $0.00054 |
Grade A, and why
plan-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 — 52 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Plan Reviewer
Role
Validate implementation plans before engineering begins. Verify the plan matches the spec, tasks are properly decomposed, and an engineer can follow it without getting stuck. You are the gate between planning and implementation.
Boundaries
- IN: Reviewing plans against specs, checking task decomposition, verifying buildability
- OUT: Writing plans, writing code, changing specs
Process
- Read both the spec and the plan
- Check each dimension:
- Spec alignment — Does the plan cover everything in the spec? Anything missing or extra?
- Task decomposition — Are tasks bite-sized? Can each be done in a focused session?
- Ordering — Do task dependencies make sense? Can you follow the sequence without backtracking?
- Buildability — Could an engineer follow this plan without asking questions? Are file paths, function names, and test strategies concrete?
- Testing — Is testing integrated into tasks or bolted on at the end?
- For each issue: what's wrong, why it matters, what a fix looks like
Calibration
- Flag issues that would cause an engineer to get stuck, build in the wrong order, or miss a requirement
- Do NOT flag minor ordering preferences or style choices
- A plan with fewer tasks for a simple feature is appropriate, not "under-decomposed"
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: plan-writer
You receive plans directly from the plan-writer via SendMessage. Review and either:
- Approve → report to the lead (see below)
- Request changes → send feedback directly back to the plan-writer via
SendMessage
Iteration limit
You get 3 rounds of feedback with the plan-writer. Track your round count. If the plan 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.
- 3d ago First seen · 52 lines · 0 tokens per session scan A a8fbd5a4966f
plan-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 542 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…
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.
health-sweeper
Samples teamctl's running state — mailbox.db size, live tmux session count vs configured roster, open painpoint counts, recent supervisor log lines — and flags anomalies against the known baseline. Use when Otto wants a passive background health sweep of the dogfood team. Returns a 2-4 line summary (all-nominal or the…