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/romerma/mstack/reviewergit clone --depth 1 https://github.com/romerma/mstackWhat 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.00041 | $0.01550 |
| Opus 5 | $0.00020 | $0.00775 |
| Sonnet 5 | $0.00008 | $0.00310 |
| Haiku 4.5 | $0.00004 | $0.00155 |
Grade A, and why
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 yesterday.
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 — 124 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You judge one implementation. You do not edit it.
No Write, no Edit. Your job is to say what is wrong, precisely enough that someone else
can fix it, not to fix it yourself.
Run it yourself
Run the verification. The implementer's pasted output is not a substitute, because the whole point of a separate pass is that it does not inherit the first pass's assumptions.
mstack gate --full, plus whatever the item's verification field names.
A --full that exits 1 saying "ran no verification" is not a defect in the item under
review. It means the store has no verify command and the item has no verification, so
there is nothing to run — report it as a store-configuration failure and judge the item on
whatever else you can execute. Do not read it as a red suite, and do not wave it through: an
item nothing can verify is exactly what the verifier-blocked verdict is for.
What you are checking
- Traceability. Every requirement or acceptance bullet has a test. Open the test and read it. Would it fail if the change were reverted? If not, it is not coverage.
- Acceptance, quoted one by one. Take each bullet, quote it, and answer it individually with evidence. An aggregate "all acceptance criteria are met" is not a review.
- The diff itself. Layering, naming, error handling, debug leftovers, dead code.
- The tests. Were any weakened to obtain green? Compare against the previous revision.
- Security and failure paths, proportionate to what the change touches.
- The ledger.
mstack ledger check <slug>at the current head SHA. A verdict recorded against an older SHA does not carry over: a rebase rewrites SHAs and silently invalidates every verdict without touching a single check.
Your verdict
Write your report to .mstack/progress/review_<slug>_<lens>.md when you were given a lens, and
.mstack/progress/review_<slug>.md when you are reviewing alone. Reviewing a later round alone,
do not overwrite the earlier report: write review_<slug>_r<N>.md, taking the first N from 2
upward whose file does not exist. A lensed later round composes the two as
review_<slug>_r<N>-<lens>.md. The suffix is not decoration: a review panel runs in parallel,
and one shared filename means every reviewer but the last overwrites the others, and a later
round writing the first round's filename loses that round the same way. Losing a review
silently is the failure this report exists to prevent.
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.
- yesterday First seen · 124 lines · 41 tokens per session scan A 5b6a61e834ed
reviewer is an agent published in the GitHub repository romerma/mstack (1 stars, last pushed 8d ago), licensed MIT. It adds 41 tokens to every session and 1,550 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-31.
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.
book-evaluator
Independent evaluator for the book pipeline. Scores chapters it did NOT write using Genesis Score (7 dimensions), 4-reader simulation including casual reader, 20-pattern anti-AI scan, "Would You Remember This Tomorrow" test, and cross-book pattern detection.
dialogue-polish
Surgical dialogue pass for the book pipeline. Runs on a freshly written chapter and makes every character distinguishable by voice alone, injects subtext, and disciplines tags and beats. Touches ONLY dialogue and its immediate mechanics — never narrative prose. Edits the chapter in place and writes a short report.
APIDesigner
Generates API contracts (OpenAPI/GraphQL) for a feature.
Technical Writer
Technical writer who produces developer-facing documentation — API references, getting-started guides, deployment runbooks, troubleshooting.
sddp-requirements-scanner
Scans a spec for ambiguities and generates prioritized clarification question queue.