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 skills add Mathews-Tom/armory --skill plan-reviewgit clone --depth 1 https://github.com/Mathews-Tom/armoryWrote 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/skills/mathews-tom/armory/plan-review)<a href="https://agentmods.dev/skills/mathews-tom/armory/plan-review"><img src="https://agentmods.dev/badge/skills/mathews-tom/armory/plan-review/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/skills/mathews-tom/armory/plan-review"><img src="https://agentmods.dev/badge/skills/mathews-tom/armory/plan-review.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00059 | $0.01631 |
| Opus 5.5 | $0.00024 | $0.00652 |
| Sonnet 5.5 | $0.00012 | $0.00326 |
| Haiku 4.5 | $0.00006 | $0.00163 |
Grade A, and why
plan-review 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 1mo 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 — 199 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Plan Review Skill
Purpose
Execute a structured pre-implementation audit of a technical plan, proposal, or design document. The goal is to surface risks, bad assumptions, missing pieces, and scope problems before any code is written — when course corrections are cheapest.
This skill is read-only. It never modifies code. It produces a severity-tagged review document with a final ship/rethink/reject verdict.
Step 0 — Mode Selection
Ask the user a single question via AskUserQuestion:
Which review lens? (1) Product — scope, user impact, business alignment. (2) Engineering — architecture, failure modes, test strategy, performance. (3) Combined (default) — both lenses integrated.
Accept the answer and proceed. Do not ask follow-up configuration questions.
Also assess scope size from the plan:
- Small change (single file, ~100 lines or fewer): deliver a compressed 4-section review — Scope, Risks, Missing, Verdict. Skip the full multi-section template.
- Standard change: execute the full review sequence below.
Full Review Sequence
1. Plan Comprehension
Read the plan end-to-end. Produce a 2–3 sentence summary confirming understanding. Explicitly list:
- Stated goals — what the plan claims to achieve.
- Non-goals — what is explicitly out of scope.
- Constraints — budget, timeline, compatibility, team size, or technology constraints mentioned or implied.
If the summary is wrong, the user corrects it here before the rest of the review proceeds on a false foundation.
2. Assumption Challenge
Extract every implicit assumption. For each one:
| Assumption | If wrong? | Supporting evidence | What falsifies it? |
|---|
Common assumption categories to probe:
- Data availability and shape
- Third-party API stability and rate limits
- Team familiarity with chosen tools
- Performance characteristics of dependencies
- Backward compatibility requirements
- Deployment environment capabilities
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 1mo ago First seen · 199 lines · 59 tokens per session scan A 5a2c3f143a8b
plan-review is a skill published in the GitHub repository Mathews-Tom/armory (337 stars, last pushed 2d ago), licensed MIT. It adds 59 tokens to every session and 1,631 once invoked, about $0.0002 per session on Opus 5.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 skills, from other repositories
gh-pr-review
Review GitHub Pull Requests using the gh CLI. Use when a user asks to review a PR, perform code review, check a pull request, or provide feedback on proposed changes. Triggers on phrases like "review PR", "review pull request", "check PR", "code review".
code-review
Provides expert code review guidelines and best practices.
mx-flow
Full development workflow orchestrator: brainstorm → plan → worktree → convergent TDD/review loop → verify → PR. One human gate (spec approval); all other gates auto-proceed. Use when starting a feature or significant change from scratch. Usage: /mx-flow ; /mx-flow status [name]; /mx-flow finish .
mx-team-review
Deep code review of a local git diff or files against this user's own engineering standards (Go, C#), written to a report file that /mx-review-triage consumes. Use before commit/merge when you want the standards-based review, not a quick diff scan. Usage: /mx-team-review [diff-spec] | --repo.
mx-pr
Draft a pull request from the feature spec and git log, then publish to GitHub or GitLab (Bitbucket experimental) — or hand off. Use when a feature branch is ready for PR, standalone or from mx-flow. Usage: /mx-pr [name].
mx-brainstorm
Turn a rough idea into an approved design spec: clarifying questions in one batch, 2-3 distinct approaches with trade-offs, spec (and ADR when a real choice was made) written to /.mx/ / /. Hard gate: no implementation until the user approves the spec. Use when starting any feature or non-trivial fix.