# Ponytail

> Use when about to add new code, structure, an abstraction, or a plan task and a minimal YAGNI solution would do — before building, not for restructuring existing code.

- Skill: `vathymut/ponytail` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add vathymut/ponytail`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vathymut/ponytail/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- License: MIT
- Author: vathymut (https://skillmd.com/u/vathymut)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/vathymut/ponytail

---


## When NOT to use

- Restructuring existing code without behavior change — use `refactor`.
- Root-cause debugging with evidence gathering — use `systematic-debugging` (ponytail fixes at shared function after cause is known).

# Ponytail

## Governance

Default: full. Switch: `/ponytail lite|full|ultra`. Off: "stop ponytail". Resets at session end.

Level persists until changed or session end. Ponytail governs what you build, not how you talk.

## The ladder

Stop at the first rung that holds:

1. **Does this need to exist at all?** Speculative need = skip it, say so in one line. (YAGNI)
2. **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.
3. **Stdlib does it?** Use it.
4. **Native platform feature covers it?** `<input type="date">` over a picker lib, CSS over JS, DB constraint over app code.
5. **Already-installed dependency solves it?** Use it. Never add a new one for what a few lines can do.
6. **Can it be one line?** One line.
7. **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, grep 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 ticket names leaves every sibling caller still broken. Fix it once, where all callers route through.

## 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", later can scaffold for itself.
- Deletion over addition. Boring over clever, clever is what someone decodes at 3am.
- Fewest files possible. Shortest working diff wins — but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
- Complex request? Ship the lazy version and question it in the same response, "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default.
- Two stdlib options, same size? Take the one that's correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm.
- Mark deliberate simplifications with a `ponytail:` comment (`// ponytail: this exists`), simple reads as intent, not ignorance. Shortcut with a known ceiling (global lock, O(n²) scan, naive heuristic)? The comment names the ceiling and the upgrade path: `# ponytail: global lock, per-account locks if throughput matters`.

## Output

Code first. Then at most three short lines: what was skipped, when to add it.
No essays, no feature tours, no design notes. If the explanation is longer
than the code, delete the explanation, every paragraph defending a
simplification is complexity smuggled back in as prose. Explanation the user
explicitly asked for (a report, a walkthrough, per-phase notes) is not debt,
give it in full, the rule is only against unrequested prose.

Pattern: `[code] → skipped: [X], add when [Y].`

## Completion criteria

- [ ] Ladder climbed after reading affected code; higher rung taken among ties
- [ ] No speculative abstraction/config/factory added; reused existing codebase code where found
- [ ] Deliberate simplification marked with `ponytail:` comment including ceiling/upgrade path
- [ ] Output is code first + ≤3 lines "skipped / add when" (unless user asked for prose)

## References

- Intensity worked example: `references/intensity.md`
- Prototype mode (logic/state): `references/prototype-logic.md`
- Prototype mode (UI): `references/prototype-ui.md`

## Related skills

- `refactor` — restructuring existing code (ponytail is for new code).
- `writing-plans` — scope discipline per plan; ponytail governs minimal slice per task.
- `systematic-debugging` — root cause before lazy fix.