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/drubinstein/terry/ronaldnpx skills add drubinstein/terry --skill ronaldgit clone --depth 1 https://github.com/drubinstein/terryWrote 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/drubinstein/terry/ronald)<a href="https://agentmods.dev/skills/drubinstein/terry/ronald"><img src="https://agentmods.dev/badge/skills/drubinstein/terry/ronald.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.00140 | $0.03089 |
| Opus 5 | $0.00070 | $0.01545 |
| Sonnet 5 | $0.00028 | $0.00618 |
| Haiku 4.5 | $0.00014 | $0.00309 |
Grade A, and why
ronald 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 — 202 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Ronald — controlled A/B experiments across models & prompts
"To consult the statistician after an experiment is finished is often merely to ask him to conduct a post mortem. He can perhaps say what the experiment died of." — R. A. Fisher
Ronald brings experimental design to model and prompt comparison. The default way people compare models — run the prompt on each once, read the two answers, pick the one that "feels better" — is an experiment with N=1, no control, no blinding, and a metric chosen after seeing the results. It tells you almost nothing, because model outputs are stochastic: run the same prompt twice and you get different answers, so a single-sample "A beats B" is often just which sample you happened to draw.
Ronald replaces the vibe check with a fair, replicated, blinded, pre-registered comparison that ends in an honest verdict — "B wins by X, beyond the noise," or "no significant difference." It is Fisher's RCT applied to prompts: arms are treatments, test cases are blocks, replicates absorb sampling noise, the judge is a measurement instrument you must calibrate and blind.
Six principles, each a guard against a way comparisons lie:
- One variable. Change exactly the factor under test — the model, or the prompt — and hold everything else constant (same inputs, temperature, system prompt, tools, judge). If A and B differ in two things, the result is a confound.
- Replication. Outputs are stochastic, so run each (arm × case) N times. One sample is an anecdote; N gives you the mean and the spread — and the spread is what tells you whether a gap is real.
- Pairing (blocking). Run the same test cases through every arm (within-subject), so per-case difficulty cancels and you compare like-for-like. Paired is far more sensitive than different inputs per arm.
- Randomize & blind. Randomize run order, and blind the judge to which arm produced an output (anonymize labels, randomize A/B position). Otherwise brand bias ("it's GPT, must be good") and position bias decide, not quality.
- Pre-register. Fix the metric, the test suite, N, and the decision rule before you look at any output. Choosing the metric after seeing results is how every comparison "proves" the answer you already wanted.
- Compare honestly. Report each arm's metric with its spread, the paired effect size, and whether the gap beats the noise — plus cost and latency. A 1-point edge across 5 noisy runs is nothing.
What ships with it
5 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.
- 3d ago First seen · 202 lines · 0 tokens per session scan A 1f70328228b7
ronald is a skill published in the GitHub repository drubinstein/terry (1 stars, last pushed 2mo ago), licensed MIT. It adds 140 tokens to every session and 3,089 once invoked, about $0.0007 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
optimize-prompt-token-efficiency
Iteratively optimizes prompts for token efficiency by maximizing information density - reduces verbosity, removes redundancy, tightens phrasing while preserving semantic content. Use when asked to compress, shorten, reduce tokens, tighten, maximize density, increase information density, or make a prompt more concise.
compress-prompt
Compresses prompts/skills into minimal goal-focused instructions. Trusts the model, drops what it already knows, maximizes action space. Use when asked to compress, condense, or minimize a prompt.
prompt-engineering
Create, update, review, or discuss an LLM prompt — a system prompt, a skill, or an agent. Use when writing or improving a prompt, discussing a skill or agent, diagnosing prompt failures, or when the user says a prompt needs work.
review-prompt
Review LLM prompts against the prompt-engineering skill's principles — leading with where each line came from — and report the findings without modifying files. Use when reviewing prompt quality, auditing a prompt, evaluating a system prompt, or checking whether prompt issues are high-confidence and fixable.
auto-optimize-prompt
Iteratively auto-optimize a prompt until no issues remain. Uses review-prompt in a loop, asks user for ambiguities, applies fixes via prompt-engineering skill. Runs until converged.
kanso-prompting
Use when rewriting, sharpening, or producing a prompt for Claude or another current frontier model. Sets standing rules for getting better LLM output through better prompts. Loaded by /kanso-task; not directly invoked by the user.