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/verifynpx skills add mtthsnc/tempest --skill verifygit clone --depth 1 https://github.com/mtthsnc/tempestWhat 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.00088 | $0.00734 |
| Opus 5 | $0.00044 | $0.00367 |
| Sonnet 5 | $0.00018 | $0.00147 |
| Haiku 4.5 | $0.00009 | $0.00073 |
Grade A, and why
verify 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 2d 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 — 58 lines — stays where its author put it; the contents beside it link to each section on GitHub.
verify — run it and judge on what you observe
Overview
Proof by observation. A change is verified only when you have run the thing, exercised the exact behavior the change targets, and seen real evidence that it does what it should. Tests passing is a signal, not proof — verification is watching the feature work for the user.
This is a STARTER skill — a generic spine. Rewrite the procedure below to encode how your project is actually run and what counts as convincing evidence.
You verify here; you do not fix or re-review. If it fails, report the failure with evidence.
Procedure
1. Pin down the behavior
- Restate, in concrete observable terms, what the change is supposed to make happen — the specific input, action, or condition and the result you'd expect to see.
- If you can't name an observable difference, you can't verify it. Get that crisp first.
2. Figure out how to run it
- Find this project's documented build/run/start command — dev server, CLI entry point, script, or test harness. Read the README, package manifest, or task runner; use the project's own way.
- Note how you'll observe output: stdout, logs, HTTP responses, exit codes, files produced, UI.
3. Run it and drive the real scenario
- Start it and exercise the actual code path the change touches, with real inputs.
- For web-UI behavior, hand off to the
qaskill — it drives a real browser via agent-browser. Don't guess at rendered UI from the code. - Otherwise observe directly: read the CLI output, tail the logs, hit the endpoint, check the file.
4. Judge against expected behavior
- Capture concrete evidence — an output snippet, a log line, a status code, a screenshot.
- Decide PASS or FAIL against the expectation from step 1. Note anything surprising, and scan the run output for warnings or errors even if the headline result looked right.
5. Report
- State PASS/FAIL, exactly what you ran, what you observed (with the evidence), and any follow-up.
Common mistakes
- Treating green unit tests as proof. Tests check code in isolation; verification checks the feature works for the user. Run the actual thing.
- Never running it. Reading the diff and concluding it "should work" is not verification.
- "Looks good" with no evidence. Every PASS/FAIL needs a concrete observation behind it.
- Verifying the wrong path. Exercise the path the change touched, not an adjacent one.
- Ignoring warnings/errors in the output. A passing result over a stack trace is not a pass.
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.
- 2d ago First seen · 58 lines · 88 tokens per session scan A c184c9721894
verify is a skill published in the GitHub repository mtthsnc/tempest (2 stars, last pushed 2mo ago), licensed MIT. It adds 88 tokens to every session and 734 once invoked, about $0.0004 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
codebase-memory
Use the codebase knowledge graph for structural code queries. Triggers on: explore the codebase, understand the architecture, what functions exist, show me the structure, who calls this function, what does X call, trace the call chain, find callers of, show dependencies, impact analysis, dead code, unused functions…
using-pi-subagents
Operate pi-subagents jobs safely, including direct-work decisions, least-privilege tool selection, thinking-level selection, delegation, bidirectional messaging, parallel starts, timeout selection, waiting, cancellation, result handling, verification, and writer isolation.
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.
fabric-workflow
Runs a dynamic Pi Fabric workflow with code-held phases, fan-out, pipelines, structured agents, and best-effort verification. Use for large audits, migrations, parallel research, or explicit workflow requests.
fabric-spec
Starts a persistent Pi Fabric spec supervisor that audits the main session against a feature design spec and steers only when a requirement lacks verified evidence. Use for strict, unblocked spec compliance while the main agent keeps full freedom to orchestrate.
surf
Control Chrome browser via CLI for testing, automation, and debugging. Use when the user needs browser automation, screenshots, form filling, page inspection, network/CPU emulation, DevTools streaming, or AI queries via ChatGPT/Gemini/Perplexity/Grok/AI Studio.