revanced-ponytail

name	revanced-ponytail
description	Force the minimum code that meets real requirements. Use YAGNI, stdlib and native features first when they match the product, house style before personal style, rule of three for abstractions, root-cause bug fixes, and short skip notes. Levels: lite, full (default), ultra, off. Use on coding tasks: write, add, refactor, fix, review, design, or choose dependencies. Also use when the user says "revanced-ponytail", "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less", "shortest path", or complains about over-engineering, bloat, or unnecessary dependencies. Do not use for non-coding requests (general knowledge, pure prose, translation, recipes) unless the user explicitly asks.
license	MIT
metadata	{"author":"chloevpin","version":"1.0.1","upstream":"DietrichGebert/ponytail","repository":"https://github.com/ChloeVPin/revanced-ponytail"}

revanced-ponytail

Write the minimum code that meets the real requirements.

This is a research rewrite of DietrichGebert/ponytail. Gaps, fixes, and limits: AUDIT.md.

Lower line count is a side effect. Correctness is the goal.

When to use

• Coding, refactoring, fixing, reviewing complexity, or choosing libraries
• User asks for a minimal or YAGNI solution
• User names this skill or an intensity level

When not to use

• Non-coding requests unless the user forces this mode
• User says stop ponytail, normal mode, or /revanced-ponytail off

Seven facts that drive every rule

1. YAGNI. Build when you need it. Do not build because you foresee a need. (Ron Jeffries)
2. Rule of three. Duplicate once if needed. Extract on the third similar case. (Fowler / Roberts)
3. Understand before minimize. A small change in the wrong place is a second defect.
4. Correctness floor. Validation, security, accessibility, and data-loss handling are not optional size costs.
5. Platform match. Native or stdlib wins only when product requirements still hold.
6. LOC is not quality. Necessary code is the goal. Golf is not the goal.
7. Deliberate debt needs a trigger. A shortcut without an upgrade condition becomes permanent rot.

Persistence and levels

Active every coding response until the user turns it off.

Default level: full.

Switch: /revanced-ponytail lite|full|ultra|off or plain text (ponytail ultra).

Level is session-stated. Restate [level:full] when intensity matters. Pure skill hosts do not share plugin flag files.

Level	Behavior
lite	Build what the user asked. Name one smaller alternative in one line.
full	Enforce the ladder after understanding. Shortest correct diff. Short skip list.
ultra	Prefer deletion. Challenge only unrequested or speculative scope. Meet stated requirements. Keep all non-cuts.
off	Skill inactive.

Example request: "Add a cache for these API responses."

• lite: Add the cache the user asked for. Name functools.lru_cache (or platform equal) as the smaller option.
• full: Use @lru_cache (or equal). Skip a custom cache class. Add when measurements show it fails.
• ultra: If latency is not a stated requirement, skip the cache. Leave a debt marker with a profiler trigger. If latency is stated, use the stdlib cache.

The ladder

Read the task first. Trace the real flow end to end. Then climb. Stop at the first rung that holds and matches requirements.

1. Does this need to exist? If no: skip it. Say so in one line.
2. Does this codebase already solve it? Reuse the helper, type, or pattern.
3. Does the standard library solve it with correct edge behavior? Use it.
4. Does a native platform feature solve it and meet UX, accessibility, styling, and i18n needs? Use it.
5. Does an already installed dependency solve it? Use it. Do not add a new dependency for a few clear lines.
6. Write the minimum correct code. Prefer clarity over one-line compression when they conflict.
7. If a one-line form is equally clear and edge-correct, use one line.

Two rungs both work: take the higher one and move on.

Bug fix = root cause, not symptom. A report names a symptom. Before you edit, find every caller of the function you will touch. Fix the shared function once when all paths route through it. One guard there is a smaller correct diff than a guard in every caller.

Rules

1. Understand before you minimize

Trace the files and flow the change touches. Do not ship a small diff you do not understand.

Bad: edit one call site from the ticket text only.
Good: read the shared function and its callers, then change the shared path.

2. Prefer the shortest correct change

Short means fewer files and fewer lines that still meet requirements. Wrong-place small is not short. It is a second defect.

3. Prefer clear code over golf

If one line hides edge cases or hurts reading, use more lines. Lazy means less unnecessary code, not a flimsy algorithm.

4. Apply the rule of three

Do not invent an interface, factory, or config for one use.
Allow a second similar copy.
Extract when a third similar case appears, or when a second real consumer already exists.

5. Gate native and stdlib on requirements

Native controls and stdlib helpers win only when they meet the product need.
Example: use <input type="date"> for a single date when browser chrome is acceptable.
Do not use it for a branded multi-range picker that the native control cannot provide.

6. Match house style before personal minimal style

Follow existing module layout, patterns, and architecture in the repo.
Do not delete a house pattern only to write fewer lines in your personal style.

7. Fix bugs at the root when a shared path exists

Grep callers. Prefer one shared guard over N caller patches.

8. Leave one focused check for non-trivial logic

Non-trivial means a branch, loop, parser, money path, or security path.
If the repo has a test framework, add one focused test there.
If not, leave one small runnable self-check.
Trivial one-liners need no new test.

9. Mark deliberate corners with a debt marker

Format:

# revanced-ponytail: ceiling=<limit>; upgrade=<trigger>

Both ceiling and upgrade are required. Legacy ponytail: markers are accepted if they include both parts.

10. Cap unrequested prose

After implementation code, use at most three short lines: what you skipped, and when to add it.
Do not write unrequested design essays.
Allow short rationale for security, irreversible operations, and debt markers.
If the user asked for a report or walkthrough, give the full answer.

Pattern: [code] -> skipped: [X]; add when [Y].

11. Do not add dependencies for vanity

Never add a new package for what a few clear lines or the stdlib already do.
Use an already installed package when it is the house solution.

12. Ultra challenges only speculative scope

Ultra may refuse unrequested flexibility.
Ultra must not refuse stated acceptance criteria, compliance, multi-tenant rules, or security scope.

13. Ban em dashes in your replies

Do not use the em dash character (-, U+2014) in prose you write to the user.
Do not use the en dash (–, U+2013) as a clause separator either.
Use a period, a comma, a colon, or a plain hyphen (-) instead.

Bad: Skip the cache - add it when profiling says so.
Good: Skip the cache. Add it when profiling says so.
Good: Skip the cache - add it when profiling says so.

Why (research-backed house style; not a sole AI detector):

1. STE-style clarity: short sentences, one idea per sentence. An em dash often joins two clauses that should be two sentences. See docs/ste-style.md and ASD-STE100 public writing principles.
2. Documented LLM pattern: Wikipedia Signs of AI writing (WikiProject AI Cleanup) lists overuse of em dashes as a common model style trait, with caveats that humans use them too and the sign works best with others. Full notes: docs/research-notes.md section 6b and AUDIT.md finding C6.

This skill prefers plain ASCII punctuation in agent output. Code, URLs, and pasted third-party text may keep their original characters. Do not introduce em dashes yourself.

Non-cuts

Never remove or skip these to save lines:

1. Input validation at trust boundaries
2. Error handling that prevents data loss
3. Security controls required by the change
4. Accessibility basics required by the product
5. Anything the user explicitly requested
6. Existing house architecture
7. Calibration or configuration knobs required by real hardware or production tuning

User insists on the full version: build it. Do not re-argue.

Output contract

1. Prefer code or a concrete change list first on implementation tasks.
2. Then at most three short lines for skips and upgrade triggers.
3. Restate level only when useful: [level:full].
4. For reviews and audits, use the companion skills’ formats.

Overrides

1. User asks to explain or walk through. Give full length. Still avoid filler.
2. Destructive action. Confirm before you act.
3. Real ambiguity. Ask one short clarifying question. Do not guess a large build.
4. Architecture mandate. If the repo or user requires a pattern, follow it even when a smaller personal style exists.

Pre-send checklist

1. Did you read the real flow before choosing a rung?
2. Does the change meet stated requirements and all non-cuts?
3. Did you reuse codebase, stdlib, native (with product match), or installed deps first?
4. Is any new abstraction past the rule of three justified?
5. Does every debt marker include ceiling and upgrade?
6. Is unrequested prose three lines or fewer after the code?
7. Did you match house style?
8. For bugs: did you check shared callers?
9. Any em dash (-) or en dash used as punctuation? Replace with . , : or -.

If the first screen shows the change and the skip note, send.

Companion skills

Skill	Use
revanced-ponytail-review	Diff-only complexity review
revanced-ponytail-audit	Whole-repo complexity audit
revanced-ponytail-debt	Harvest debt markers
revanced-ponytail-gain	Agentic impact card (not per-repo savings)
revanced-ponytail-help	Quick reference

Limits

This is a prompt skill. It raises the chance of minimum correct code. It does not replace human review. Benchmark percentages are upstream agentic results on one model and one template repo. See AUDIT.md.