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/benchnpx skills add mtthsnc/tempest --skill benchgit 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.00091 | $0.00959 |
| Opus 5 | $0.00046 | $0.00479 |
| Sonnet 5 | $0.00018 | $0.00192 |
| Haiku 4.5 | $0.00009 | $0.00096 |
Grade A, and why
bench 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 — 69 lines — stays where its author put it; the contents beside it link to each section on GitHub.
bench — measure Core Web Vitals against a budget
Overview
The performance gate. Turn "feels slow" into numbers: capture Core Web Vitals (LCP, CLS, INP/TBT) plus load and hydration timing for a page, then compare them against an explicit budget or a baseline so a regression is a fact, not a vibe.
This is a STARTER skill — a generic spine. Rewrite the procedure and thresholds below to encode your own perf budgets (your LCP/CLS/INP targets, the build you measure, the device profile).
Measurement runs through agent-browser's vitals capability. Use whichever invocation path your
harness offers:
- On pi: prefer the native
agent_browsertool from thepi-agent-browser-nativeextension, passing raw args —{ "args": ["vitals", "<url>"] }, or{ "args": ["open", "<url>"] }then{ "args": ["vitals"] }. - On Claude Code (or any harness without that tool): drive the same CLI via Bash —
agent-browser vitals <url>.
Prefer the native tool when present, else the CLI; the vocabulary is identical. Setup: the
agent-browser CLI must be on PATH (and on pi, the pi-agent-browser-native extension installed).
If it is missing, run the repo's scripts/doctor.sh (or pi-agent-browser-doctor) before measuring.
Procedure
1. Decide what to measure and against what
- Pick the exact URL/page under test.
- Measure a production-like build, never a dev build — dev bundles are unminified and slow, so their numbers are meaningless.
- Name the comparison target up front: the perf budget (e.g. LCP ≤ 2.5s, CLS ≤ 0.1, INP ≤ 200ms) or a baseline run from before the change. Without one, "slow" has no meaning.
2. Capture vitals
- Run
agent-browser vitals <url>— native tool args on pi, the CLI on Claude Code. - Collect LCP, CLS, INP (or TBT as its proxy), and load/hydration timing from the output.
3. Take multiple samples
- A single run is noisy. Run several (e.g. 5) and use the median, not the best or first.
- Note the variance / spread across runs so you can tell a real change from jitter.
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 · 69 lines · 91 tokens per session scan A c93a697453e4
bench is a skill published in the GitHub repository mtthsnc/tempest (2 stars, last pushed 2mo ago), licensed MIT. It adds 91 tokens to every session and 959 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-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.
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.
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.
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.