Ponytail Minimalist Development Mode

The Problem It Solves

When coding agents generate implementation, the failure is often not “it does not work” but “it works too broadly”: single-product interfaces, factories for one use case, config for fixed values, third-party dependencies for standard-library behavior, and long design prose. Ponytail targets this over-engineering by turning “write less” into enforceable session constraints.

How It Works

Ponytail defaults to full mode and asks the model to understand the task and code paths before choosing the smallest workable solution. It follows a Ladder:
- Does it need to exist: apply YAGNI and skip speculative requirements;
- Is it already in the repo: reuse existing helpers, utils, and types;
- Is it stdlib or native: prefer stdlib, CSS, DB constraints, or platform features;
- Is an installed dependency enough: avoid adding new packages for a few lines of code;
- Can it be one line: only then write the minimum working code.

The output is code first, with at most three short explanation lines, such as skipped: custom cache; add when lru_cache falls short. Related skills include ponytail-review for diff review, ponytail-audit for repo-wide complexity scanning, ponytail-debt for collecting ponytail: ceiling and upgrade-path comments, and ponytail-gain for displaying benchmark scoreboards.

Boundaries

Ponytail governs complexity, not correctness, security, or performance; it lists findings but does not apply fixes by default. It should not simplify away trust-boundary validation, data-loss protection, security, accessibility, or anything the user explicitly requests as a full implementation.