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 commands/cbirkbeck/mathlib-quality/self-reviewgit clone --depth 1 https://github.com/CBirkbeck/mathlib-qualityWhat 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.00109 | $0.05515 |
| Opus 5 | $0.00055 | $0.02757 |
| Sonnet 5 | $0.00022 | $0.01103 |
| Haiku 4.5 | $0.00011 | $0.00551 |
Grade A, and why
self-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 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 — 395 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/self-review — Independent, Multi-Round Self-Review Before PR
Review your own changes the way a good external reviewer would — by not being the
instance that wrote them. /self-review spawns a fresh, neutral review agent each
round, reports its findings to you, implements every suggestion it makes, reports what
changed, and relaunches for the next round. It runs a fixed number of rounds (default
3) and stops there, even if the code still isn't perfect.
The whole point is structural objectivity. The instance that wrote a proof is the worst judge of whether it is well-named, well-generalised, or best closed by automation — it is anchored on the choices it already made. So the reviewer is a separate agent, spawned fresh every round, with no access to the author's rationalisations and no stake in the existing code. The driving instance (you) is the implementer, not the reviewer, and implements what the independent reviewer asks.
Non-negotiable rules
- The reviewer is a fresh, independent agent every round. A new
Agentdispatch per round — notSendMessagecontinuity — so no round is anchored on the previous one and no reviewer has an ego stake in comments it made last time. Never let the implementer grade its own homework. - Exactly N rounds. One round = one review + one implementation. Default N = 3. The loop terminates after the Nth implementation, even if findings remain. N is a hard cap, not "until perfect".
- The round number never changes the reviewer's standard. On the final round the reviewer reviews exactly as it would on the first. It does not declare the code done, soften findings, or withhold warranted feedback because the review budget is ending. Termination is the loop's decision, never the reviewer's.
- Implement every suggestion. The implementer applies all of the reviewer's requested changes. The only thing it may decline is a change it cannot make without breaking the build or introducing an error — and even then it must be attempted, reverted, and documented for the next round, never silently skipped. Disagreement is not grounds to skip: defeating the author's bias is the entire reason the reviewer is separate.
- Report twice per round. First report the reviewer's requested changes to the user; then, after implementing, report a summary of what changed. Both are mandatory, both in chat.
- Feedback lands on the PR thread when there is one. If the branch has an open PR, each round's findings are posted as a PR comment; otherwise they are reported in chat only.
- No commits, no pushes.
/self-reviewedits the working tree and (optionally) comments on the PR. Committing and pushing stay with you,/pre-submit, or/fix-pr-feedback.
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 · 395 lines · 109 tokens per session scan A 30c82b6455d8
self-review is a command published in the GitHub repository CBirkbeck/mathlib-quality (32 stars, last pushed 14d ago), licensed MIT. It adds 109 tokens to every session and 5,515 once invoked, about $0.0005 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-30.
Other commands, from other repositories
git
Git operations with intelligent commit messages and workflow optimization.
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.