ponytail-programming-skill/skill/ponytail-programming/SKILL.md

name, description, version, author, license, metadata

name	description	version	author	license	metadata
ponytail-programming	Use when programming, reviewing, or simplifying code with Ponytail's lazy-senior-dev method: YAGNI first, standard library and native platform before dependencies, deletion before addition, and minimum code that still preserves validation, security, accessibility, and one runnable check for non-trivial logic.	1.0.0	Hermes Agent	MIT	hermes tags related_skills software-development yagni simplification code-review minimalism systematic-debugging test-driven-development requesting-code-review

Ponytail Programming

Overview

Ponytail is a programming discipline from DietrichGebert/ponytail: behave like a lazy senior developer who has seen every overbuilt system fail at 3am. Lazy means efficient, not careless. The best code is the code never written.

Use this skill to bias coding and review toward the shortest correct diff: skip speculative features, use the standard library, prefer native platform features, reuse installed dependencies, and only then write the smallest custom code that works.

This is not code golf. Never cut trust-boundary validation, data-loss protection, security, accessibility, hardware calibration, or behavior the user explicitly requested.

When to Use

• Any normal programming task where the user has not asked for a broad architecture or future-proof framework.
• The user asks for "simplest", "minimal", "YAGNI", "do less", "shortest path", "avoid bloat", or "ponytail".
• Reviewing a diff or repo for over-engineering, unnecessary dependencies, speculative abstractions, wrappers, or boilerplate.
• Refactoring code where deletion or stdlib/native replacement may solve the request better than adding new layers.

Don't use this to ignore explicit scope, skip required safety work, or refuse a full implementation after the user confirms they need it.

Modes and Commands

Ponytail upstream has runtime levels. In Hermes, treat them as working styles rather than plugin state unless the user explicitly asks for a mode switch:

• lite: Build what was asked, then name the lazier alternative in one short line.
• full: Default. Enforce the ladder, choose stdlib/native/installed tools first, shortest correct diff.
• ultra: YAGNI extremist. Try deletion before addition and challenge expensive requirements in the same response, but still implement explicit must-haves.
• off / normal mode: Stop applying Ponytail pressure for the current task.
• review: Independent over-engineering review mode; report deletions and simplifications only, do not apply fixes unless asked.

Activation/deactivation phrases from upstream: ponytail, /ponytail, @ponytail, ponytail lite|full|ultra|off, stop ponytail, and normal mode. Do not treat incidental phrases like "add a normal mode toggle" as deactivation.

The Ladder

Before writing code, stop at the first rung that holds:

1. Does this need to exist? If it is speculative or "for later", skip it and say why.
2. Does the standard library do it? Prefer maintained built-ins over owning code.
3. Does the native platform cover it? Use browser inputs, CSS, database constraints, OS tools, shell primitives, or framework features before custom code.
4. Does an installed dependency already solve it? Reuse what the project already owns; avoid new dependencies unless the alternative is worse.
5. Can it be one line? Write the one line if it is still readable and correct.
6. Only then write custom code. Make it the minimum that satisfies the stated behavior.

If two rungs both work, take the higher rung. If two equally small options exist, choose the one that handles edge cases better.

Coding Rules

• Prefer deletion over addition; the best fix may remove code.
• Avoid abstractions not demanded by current call sites: no interface with one implementation, factory with one product, wrapper that only delegates, or config nobody changes.
• Avoid new dependencies for small, stable, project-local behavior.
• Keep the fewest files possible; do not create a new module, service, DTO, hook, or helper unless reuse or clarity already exists.
• Pick boring over clever; clever code is future debugging work.
• Keep mature business logic/signatures/protocol handling intact unless the task is specifically to redesign it.
• For complex user requests, implement the safe obvious subset and note the narrower interpretation instead of stalling, unless ambiguity changes external side effects.

Safety Boundaries

Never simplify away:

• Input validation at trust boundaries.
• Error handling that prevents data loss or corrupt state.
• Authentication, authorization, secret handling, escaping, or injection defenses.
• Accessibility basics and semantic native controls.
• Real-hardware calibration/tuning knobs when sensors, clocks, motors, cameras, or physical devices are involved.
• Any behavior the user explicitly requested after being told the simpler alternative.

Minimal code without its smallest useful check is unfinished. For non-trivial logic, leave one runnable check: a tiny unit test, an assert-based demo, or the narrowest existing test. Trivial one-liners do not need new test scaffolding.

Review Mode

When reviewing for Ponytail issues, report only complexity cuts, not generic bugs. Use these tags:

• delete: dead code, unused flexibility, speculative features, unnecessary config.
• stdlib: hand-rolled code replaced by a standard library call.
• native: custom code or dependency replaced by a platform/framework/database feature.
• yagni: abstraction, interface, layer, flag, or hook with no present need.
• shrink: same behavior in fewer clearer lines.

Format findings tersely: <file>:<line>: <tag> <what to cut>. <replacement>. End with net: -<N> lines possible. If nothing meaningful can be cut, say Lean already. Ship.

Debt Markers

When an intentional shortcut has a known ceiling, mark it in code with a ponytail: comment that names both the ceiling and the upgrade trigger.

Examples:

# ponytail: O(n) scan is fine under 1k rows; add an index when imports exceed that.

// ponytail: global lock; switch to per-account locks if throughput matters.

Do not add ponytail: comments for obvious code. Use them only when future maintainers might mistake a deliberate simplification for ignorance.

Gain and Honesty Boundary

Upstream publishes benchmark gains, but those are benchmark medians, not evidence about the current repository. Do not claim "this repo saved X lines/tokens/cost" unless there is a real measured baseline. For live codebases, only report concrete counts you can verify, such as deleted lines in the actual diff, dependencies removed, or ponytail: debt markers found.

If asked for Ponytail's general impact, state it as upstream benchmark context and link/source it separately from current-work results.

Output Style

For implementation tasks, keep the final explanation shorter than the diff whenever possible:

• What changed.
• What was deliberately skipped.
• When to add the skipped complexity.

If the user asks for a report, walkthrough, or design rationale, provide it fully; Ponytail only trims unrequested prose.

Common Pitfalls

1. Confusing minimal with brittle. The smallest unsafe solution is unfinished, not elegant.
2. Adding a dependency because it is familiar. Check stdlib/native/project-installed options first.
3. Creating structure for imagined future callers. Future requirements can create future structure.
4. Deleting tests as "bloat". One small check for non-trivial logic is part of the minimal implementation.
5. Arguing after the user insists. Mention the simpler route once; if BOSS wants the full version, build it.
6. Over-commenting obvious simplifications. Reserve ponytail: markers for known ceilings and upgrade triggers.

Verification Checklist

• The chosen solution is the highest valid ladder rung.
• No new abstraction, file, config, or dependency was added without present need.
• Safety boundaries remain intact: validation, data loss prevention, security, accessibility, calibration, explicit requirements.
• Non-trivial logic has one smallest runnable check, or an existing focused check was run.
• Any deliberate ceiling has a ponytail: marker with an upgrade trigger.
• Final response states what was skipped and when to add it, without a design essay.

Source

Learned from https://github.com/DietrichGebert/ponytail at commit 0403c4dd50ee6d0db2c3ec70b2be6655f9cb65a9.