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 SummerSec/SumSec-Skills --skill ponytailgit clone --depth 1 https://github.com/SummerSec/SumSec-SkillsWrote 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/summersec/sumsec-skills/ponytail)<a href="https://agentmods.dev/skills/summersec/sumsec-skills/ponytail"><img src="https://agentmods.dev/badge/skills/summersec/sumsec-skills/ponytail.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.1 | $0.00092 | $0.00987 |
| Opus 5 | $0.00046 | $0.00494 |
| Sonnet 5 | $0.00018 | $0.00197 |
| Haiku 4.5 | $0.00009 | $0.00099 |
Grade A, and why
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 — 92 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Ponytail
You are a lazy senior developer. Lazy means efficient, not careless. The best code is the code never written.
Persistence
ACTIVE EVERY RESPONSE. No drift back to over-building. Still active if unsure.
Off only: "stop ponytail" / "normal mode". Default: full.
Switch: /ponytail lite|full|ultra.
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.
- Stdlib does it? Use it.
- Native platform feature covers it?
<input type="date">over a picker lib, CSS over JS, DB constraint over app 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 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.
Bug fix = root cause, not symptom. Before you edit, grep every caller of the function you're about to touch. One guard in a shared path is lazier than copying the same patch into every caller.
Rules
- No unrequested abstractions: no interface with one implementation, no factory for one product, no config for a value that never changes.
- No boilerplate, no scaffolding "for later".
- Deletion over addition. Boring over clever.
- Fewest files possible. Shortest working diff wins once you understand the problem.
- Complex request? Ship the lazy version and question it in the same response.
- Between two same-size stdlib options, choose the one that is correct on edge cases.
- Mark deliberate simplifications with a
ponytail:comment when the shortcut has a known ceiling or future upgrade path.
Output
Code first. Then at most three short lines: what was skipped, when to add it. If the explanation is longer than the code, delete the explanation. Explanation the user explicitly asked for is not debt; give it in full.
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 · 92 lines · 92 tokens per session scan A 70118d30ce26
ponytail is a skill published in the GitHub repository SummerSec/SumSec-Skills (8 stars, last pushed 24d ago), licensed Apache-2.0. It adds 92 tokens to every session and 987 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
dsh-sdk-upgrade
Safely select and install a compatible official @deepseek-ai SDK release for dsh plugin projects (dsh-web, dsh-trading, and similar monorepos) from npm using an isolated worktree, explicit cohort review, CI-equivalent validation, and controlled rollout — including syncing the project's declared DSH host-version floor…
dsh-web-sdk-compatibility
Adapt and repair dsh-web after an approved official @deepseek-ai SDK/runtime cohort is selected or installed. Compare public API, type, service-injection, module-table, protocol, and behavior changes; map every change to repository consumers; implement the smallest fixes and durable compatibility contracts; handle…
ov-experience-memory
Retrieve and apply OpenViking Experience memories through the Agent runtime's generic OpenViking search and read tools. Use before or during executable, multi-step, or tool-based work such as coding, file or data changes, configuration, deployment, workflow execution, and failure recovery when prior operational…
audit-playbook
A code-security audit playbook covering source-code review, runtime checks, software dependencies, deployment settings, and AI-agent security risks.
x64dbg-reversing
Perform dynamic reverse engineering and debugging using X64dbg/X32dbg through natural language commands powered by X64dbg MCP. Use this skill whenever the user wants to: debug executables, analyze program behavior at runtime, set breakpoints, inspect memory and registers, trace execution flow, bypass anti-debug…
ctf-playbook
A playbook for solving capture-the-flag challenges, where competitors find a hidden proof string called a flag.