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 skills add lukas-grigis/ralphctl --skill ralphctl-ponytailgit clone --depth 1 https://github.com/lukas-grigis/ralphctlWrote 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/lukas-grigis/ralphctl/ralphctl-ponytail)<a href="https://agentmods.dev/skills/lukas-grigis/ralphctl/ralphctl-ponytail"><img src="https://agentmods.dev/badge/skills/lukas-grigis/ralphctl/ralphctl-ponytail.svg" alt="Measured on agentmods" height="20"></a>- NVIDIA SkillSpector pass
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.1 | $0.00116 | $0.01316 |
| Opus 5 | $0.00058 | $0.00658 |
| Sonnet 5 | $0.00023 | $0.00263 |
| Haiku 4.5 | $0.00012 | $0.00132 |
Grade A, and why
ralphctl-ponytail 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 8d 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 — 87 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Ponytail
Adapted from DietrichGebert/ponytail (MIT). Adapted for ralphctl's harness contract.
Be a lazy senior developer. Lazy means efficient, not careless — the posture of someone who has seen every over-engineered codebase and been paged at 3am for one. The best code is the code never written.
When this applies
- Plan — when sizing tasks, prefer the plan whose steps each pass the ladder; a task that exists only to build scaffolding "for later" should not exist.
- Execute — every time you are about to write code: new features, fixes, refactors, and especially the moment before adding a dependency.
- Create PR — when summarising the change, name what was deliberately skipped and when it would be worth adding.
The ladder
Stop at the first rung that holds:
- Does this need to exist at all? Speculative need = skip it, say so in one line. (YAGNI)
- Already in this codebase? A helper, util, type, or pattern that already lives here → reuse it. Look before you write; re-implementing what's a few files over is the most common slop.
- Standard library does it? Use it.
- Native platform feature covers it? A built-in form control over a widget library, a stylesheet rule over scripted behaviour, a database constraint over application code.
- Already-installed dependency solves it? Use it. Never add a new one for what a few lines can do.
- Can it be one line? One line.
- Only then: the minimum code that works.
The ladder is a reflex, not a research project — but it runs after you understand the problem, not instead of it. Read the task and the code it touches first, trace the real flow end to end, then climb. Two rungs work → take the higher one and move on. The first lazy solution that works is the right one — once you actually know what the change has to touch.
Bug fix = root cause, not symptom. A report names a symptom. Before you edit, find every caller of the function you're about to touch. The lazy fix IS the root-cause fix: one guard in the shared function is a smaller diff than a guard in every caller — and patching only the path the report names leaves every sibling caller still broken. Fix it once, where all callers route through.
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.
- 8d ago First seen · 87 lines · 116 tokens per session scan A 7f8e46085f5d
ralphctl-ponytail is a skill published in the GitHub repository lukas-grigis/ralphctl (23 stars, last pushed yesterday), licensed MIT. It adds 116 tokens to every session and 1,316 once invoked, about $0.0006 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 skills, from other repositories
rework-rate
Measure and interpret PR rework rate — the emerging 5th DORA metric.
My Skill
Content here.
atomic-visual-options
Planning-phase visual comparison aid. Renders 2-4 side-by-side variants per decision dimension as a single throwaway, self-contained HTML file and captures the user's pick as typed terminal codes (e.g. "A2 B3"). Auto-fires on phrases like "show me a few options", "mock up some variants", "let me see this side by…
atomic-wiki
Conversational wiki and capture-bucket routing. Fires when the user wants a place, space, or folder for notes, research, tickets, raw dumps, or knowledge capture — checks the block in /.claude/CLAUDE.md; if the cwd is under a registered realm, creates the folder as a bucket via atomic wiki bucket add rather than a…
atomic-review
Compressed code review comments. Cuts noise from PR feedback while preserving the actionable signal. Each comment is one line: location, problem, fix. Use when user says "review this PR", "code review", "review the diff", or invokes /atomic-review. Auto-triggers when reviewing pull requests.
atomic-verify
Evidence-before-claim gate. Auto-triggers when Claude is about to claim "done", "fixed", "passing", "complete", "ready to merge", "looks good", "should work", "should pass", "green", or any synonym. Iron rule: no completion claim without a fresh verification command run in this turn. Explicit invocation…