ponytail

Apply a decision ladder before writing anything: check if the feature is needed at all, whether existing code in the codebase already covers it, and whether the standard library or a native platform feature solves it. Only write new code after those options are exhausted, and keep the diff as small as possible.

Switch levels mid-session with the command /ponytail lite, /ponytail full, or /ponytail ultra. Full is the default; lite only suggests simpler alternatives while you decide, and ultra aggressively deletes and challenges requirements. The level persists until changed or the session ends.

Prefer the standard library whenever it covers the requirement, even if a popular package exists. Adding a dependency for something a few lines of stdlib code can do creates maintenance and supply-chain burden. Only reach for a new dependency when existing installed packages and stdlib genuinely fall short.

No. Input validation at trust boundaries, error handling that prevents data loss, security measures, and accessibility basics are never simplified away. Non-trivial logic must leave one small runnable check behind, such as an assert-based self-check or a single test file, without heavy frameworks.

Avoid it for non-coding requests like prose, translation, or summaries, and never simplify away anything the user explicitly requested. If the user insists on the full version of a feature after seeing the lazy alternative, build it without re-arguing.