ponytail

Solid

Forces the laziest solution that actually works — simplest, shortest, most minimal. Channels a senior dev who has seen everything: question whether the task needs to exist at all (YAGNI), reach for the standard library before custom code, native platform features before dependencies, one line before fifty. Supports intensity levels: lite, full (default), ultra. Use whenever the user says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less", or "shortest path" — and whenever they complain about over-engineering, bloat, boilerplate, or unnecessary dependencies.

AI & Automation 407 stars 15 forks Updated today MIT

Install

View on GitHub

Quality Score: 93/100

Stars 20%
87
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Ponytail You are a lazy senior developer. Lazy means efficient, not careless. You have seen every over-engineered codebase and been paged at 3am for one. 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: 1. **Does this need to exist at all?** Speculative need = skip it, say so in one line. (YAGNI) 2. **Stdlib does it?** Use it. 3. **Native platform feature covers it?** `<input type="date">` over a picker lib, CSS over JS, DB constraint over app code. 4. **Already-installed dependency solves it?** Use it. Never add a new one for what a few lines can do. 5. **Can it be one line?** One line. 6. **Only then:** the minimum code that works. The ladder is a reflex, not a research project. Two rungs work → take the higher one and move on. The first lazy solution that works is the right one. ## 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. - Complex request? Ship the lazy version and question it in the same response — "Did X; Y covers ...

Details

Author
DietrichGebert
Repository
DietrichGebert/ponytail
Created
today
Last Updated
today
Language
JavaScript
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Data & Documents Listed

think-twice

Forces Claude to pause before any high-cost task and ask: "Is there a cleverer, cheaper way to do this?" Triggers before heavy computation, large code generation, repetitive data writing, or any implementation that feels like hard work. Claude must run a full think-twice check — questioning the approach, the scope, and the strategy — before committing tokens to the obvious path. The goal is productive laziness: always find the shortcut if one exists, always do less if less is enough.

2 Updated 1 weeks ago
albertobarnabo
DevOps & Infrastructure Listed

think-twice

Forces Claude to pause before picking an implementation approach and ask: "Is there a cleverer, cheaper way?" Triggers when the request involves generating data or fixtures (lists, datasets, sample records), implementing a problem that is likely already solved by a stdlib function, package, or public API (validation, parsing, lookups, auth, date/currency/geo data), or any implementation expected to exceed ~20 lines. Does NOT trigger when the user has explicitly chosen the approach or library, when the task is under ~10 lines, when fixing a bug in existing code, or for infra/terraform/k8s and DB queries. Run the checklist before writing code, stop at the first question that reveals a cheaper path, and take that path.

35 Updated today
albertobarnabo
AI & Automation Solid

ponytail-review

Code review focused exclusively on over-engineering. Finds what to delete: reinvented standard library, unneeded dependencies, speculative abstractions, dead flexibility. One line per finding: location, what to cut, what replaces it. Use when the user says "review for over-engineering", "what can we delete", "is this over-engineered", "simplify review", or invokes /ponytail-review. Complements correctness-focused review — this one only hunts complexity.

407 Updated today
DietrichGebert