Add Ponytail programming Hermes skill

skill/ponytail-programming/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: ponytail-programming
+description: "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."
+version: 1.0.0
+author: Hermes Agent
+license: MIT
+metadata:
+  hermes:
+    tags: [software-development, yagni, simplification, code-review, minimalism]
+    related_skills: [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.
+
+## 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:
+
+```python
+# ponytail: O(n) scan is fine under 1k rows; add an index when imports exceed that.
+```
+
+```ts
+// 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.
+
+## 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`.