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 skills/mtthsnc/tempest/reviewnpx skills add mtthsnc/tempest --skill reviewgit clone --depth 1 https://github.com/mtthsnc/tempestWrote 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/mtthsnc/tempest/review)<a href="https://agentmods.dev/skills/mtthsnc/tempest/review"><img src="https://agentmods.dev/badge/skills/mtthsnc/tempest/review.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.00068 | $0.00940 |
| Opus 5 | $0.00034 | $0.00470 |
| Sonnet 5 | $0.00014 | $0.00188 |
| Haiku 4.5 | $0.00007 | $0.00094 |
Grade A, and why
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 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 — 72 lines — stays where its author put it; the contents beside it link to each section on GitHub.
review — audit a diff like a staff engineer
Overview
The quality gate. Read a change the way a careful senior reviewer would: hunt for real bugs and security holes first, then for ways the code could be simpler or reuse what already exists. Every finding gets a location, a concrete fix, and an honest confidence level — and the high-confidence, low-risk ones can be fixed and verified on the spot.
This is a STARTER skill — a generic spine. Rewrite the review lenses and the severity bar below to encode your own engineering opinions and standards.
The output is a grouped set of findings (must-fix vs. nits), optionally with applied-and-verified fixes. You review the change; you do not redesign it.
Procedure
1. Scope the diff
- Establish exactly what changed and against what base (e.g.
git diff <base>...HEAD, a PR, or the named files). If the base is ambiguous, ask before reviewing the wrong thing. - Restate in one sentence what the change is supposed to do. Review whether it does that — not just whether the code that's there is locally fine.
- Read enough surrounding code to judge each change in context, not in isolation.
2. Review through distinct lenses
Pass over the diff once per lens (collapse or extend to taste):
- Correctness / logic — off-by-one, null/empty/error paths, boundary and concurrency cases, wrong conditionals, broken invariants. Does it handle the inputs it will actually see?
- Security — untrusted input, injection, authz/authn gaps, secrets, unsafe deserialization.
- Error handling — swallowed errors, missing cleanup, failure modes left unhandled.
- Simplification / reuse — is there an existing utility or pattern that makes a chunk of this unnecessary? Can it be smaller, clearer, or less duplicated?
- Tests / coverage — are the new paths and edge cases tested? What's the gap?
3. Classify each finding
Tag every finding with:
- Severity — must-fix (bug, security, data loss) vs. nit (style, taste).
- Confidence — high (you can prove it) vs. a judgement call for the human.
Give each finding a
file:linereference and a concrete suggested fix. A finding with no location or no fix is noise — drop it.
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 · 72 lines · 68 tokens per session scan A c6c0608f4c6a
review is a skill published in the GitHub repository mtthsnc/tempest (2 stars, last pushed 2mo ago), licensed MIT. It adds 68 tokens to every session and 940 once invoked, about $0.0003 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 skills, from other repositories
pi-ralph-wiggum
Long-running iterative development loops with pacing control and verifiable progress. Use when tasks require multiple iterations, many discrete steps, or periodic reflection with clear checkpoints; avoid for simple one-shot tasks or quick fixes.
improvement-discovery
Heuristics and process for discovering structural improvements in this package. Load when planning a new improvement round — contains the smell taxonomy, analysis workflow, and prioritization framework distilled from many phases of refactoring.
markdown-conventions
Project-specific markdown rules (one-sentence-per-line, compact tables, sequential numbering) and YAML frontmatter schema for plans/retros. Load when writing or editing markdown — contains rules that differ from standard markdownlint defaults.
fabric-supervisor
Starts a persistent Pi Fabric supervisor that watches the main session toward a concrete goal and steers only when needed. Use for long-running goal supervision without another extension.
pre-completion
Pre-completion protocol for implementation agents — gather context, dispatch the pre-completion-reviewer subagent, and handle its report before writing stage notes and recommending /ship-issue. Load at the end of /tdd-plan and /build-plan after all implementation steps are complete.
prose-review
Review prose written for others -- user-facing docs, prompts for other LLMs, inline comments, docstrings, and other-facing messages -- for local jargon leakage, orphaned references, missing grounding, and audience or genre misfit.