Ponytail minimalism
The posture that stops an agent over-building - smallest change that actually works.
In simple words
Left alone, a coding agent over-builds: a helper class where a function would do, a dependency where the standard library was fine, fifty lines where one was enough.
Ponytail is the posture that pushes back. It injects a “lazy senior dev” ruleset into the agents that write code, so their default is the smallest change that actually works.
It is on by default, and it is one switch: the ponytail row under General on the dashboard’s Config page, or from a terminal:
vibe config set ponytail falseOnly the seats that produce a diff see it - the implementer and the fixer. Planners, reviewers, the arbiter and the verifier run without it, so the check on a change stays independent of the posture that wrote it.
What it changes
Fewer dependencies Standard library before a package, native platform feature before a library.
Fewer abstractions No interface with one implementation, no config for a value that never varies.
Smaller diffs A one-line bug does not earn a refactor.
Questions the task Sometimes the smallest change that works is no change.
Minimal is not careless. The correctness rules survive the posture, and every diff still passes the post-turn gate and your review. Ponytail changes what an agent reaches for first, not what it is allowed to skip.
What it makes an agent do
Before writing code, a ponytail agent climbs a ladder and stops at the first rung that answers the problem:
Does this need to exist? The cheapest code is the code you don’t write. Question the task itself before building it.
Is it already here? Reach for something in the codebase before adding anything new.
Standard library? Prefer what the language already ships over a new helper.
Native feature? Prefer a platform or framework feature over a dependency.
Already installed? Solve it with a dependency the project has before adding one it doesn’t.
Can this be one line? If it can, make it one line.
Only then, write it The minimum code that works, not the most general version of it.
What it will not trade away
The ladder runs after the agent understands the problem, not instead of it. What it is told never to be lazy about: read the task and the code it touches and trace the real flow end to end before picking a rung, validate at trust boundaries, handle the errors that would lose data, fix a bug at its root rather than at the caller that reported it, and leave one runnable check behind. Ponytail trims the speculative work, not the correctness work.
Why only the writers
The split mirrors how reviewLenses aim the reviewers and the Spec-up posture aims the planners: each role gets the guidance for its job. A reviewer judging whether a change is right must not also be told to make it smaller - that is the writer’s job.
In code the rule is narrow: a model turn at the executing stage whose output includes a diff. That is the implementer and the fixer, and nothing else.
Trust and provenance
The posture is committed project config, never fetched at run time - the same trust class as the rest of your run settings, and every diff still passes the post-turn gate before it can merge. It is vendored verbatim from the open-source ponytail skill (MIT), so it behaves the same across every provider with no plugin dependency.
