Comment and commit behavior.

[x4cc3]

Does it always have to add "ponytail:" or "//ponytail:" in each code change and commit name?

[Lakshya77089]

No to both — and it's a fair thing to be unsure about.

Code comments: the ponytail: marker is only for deliberate simplifications — a corner you cut on purpose, especially one with a known ceiling (e.g. // ponytail: global lock, per-account locks if throughput matters). The point is that a reviewer reads the shortcut as intent, not a mistake. Normal or trivial code shouldn't get a comment. If your agent is stamping // ponytail: on routine edits, it's over-applying the rule — /ponytail lite, or a one-line "only mark real shortcuts," reins it in.

Commit messages: ponytail doesn't touch commits at all. There's no instruction anywhere in the ruleset, hooks, or plugins to prefix commit names — the only commit reference in the code is a test confirming the OpenCode plugin ignores the commit command. So a ponytail:-prefixed commit is the agent inventing the convention; you can just tell it to stop and it will.

[x4cc3]

regardless of the model it just seems to add it every time ponytail is active. I added the "DO NOT INCLUDE" in my pi agent appendsystem but still no workaround.

[jeremiah-k]

Code comments: the ponytail: marker is only for deliberate simplifications — a corner you cut on purpose, especially one with a known ceiling (e.g. // ponytail: global lock, per-account locks if throughput matters). The point is that a reviewer reads the shortcut as intent, not a mistake. Normal or trivial code shouldn't get a comment. If your agent is stamping // ponytail: on routine edits, it's over-applying the rule — /ponytail lite, or a one-line "only mark real shortcuts," reins it in.

Applying these markers to your own codebase is fine (if that's what you want), but it looks tacky when submitting patches to larger projects. Its something I have to actively clean up before submitting anything upstream.

To me it seems like something that should be configurable and disabled by default. Good to know about the lite option though.

[Lakshya77089]

Dug into why the marker keeps landing on every edit even with "DO NOT INCLUDE" set. It's a prompt-design issue, not your setup:

The rule says "Mark deliberate simplifications with a ponytail: comment" with a generic example (// ponytail: this exists) and no negative boundary. Combined with the skill's "ACTIVE EVERY RESPONSE / the best code is the code never written" framing, a model reads every lazy edit as a "deliberate simplification" worth marking. There's nothing telling it not to mark normal/trivial code.

And the reason "DO NOT INCLUDE" in pi's appendsystem loses: the ponytail ruleset is re-injected every turn, so it outranks a one-line note that competes with it. That's also why /ponytail lite or "only mark real shortcuts" works — it changes the injected rule itself instead of fighting it.

The fix that matches how this repo likes to work (one line, shipped to every rule copy, no flag) is to give the marker rule an explicit ceiling, e.g.: "Mark only deliberate simplifications that cut a real corner — a shortcut with a known ceiling. Normal or trivial code gets no comment." That's one line in AGENTS.md + the static copies, no config.

On @jeremiah-k's "configurable, off by default": that runs into the same coverage gap @DietrichGebert raised on #79 — a flag only lives in the hooks, so the static-file integrations (Cursor, Windsurf, Cline, Kiro, Gemini) would get no guard even with it set. Tightening the rule text fixes it everywhere at once. The one catch: it rides the always-on prompt every turn, so per the maintainer's stated bar it'd want a quick benchmark before shipping.

Happy to open a PR with that one-line tightening if there's appetite.

[DietrichGebert]

Confirming what Lakshya said: no on both. The ponytail: marker is only for deliberate shortcuts with a known ceiling, and ponytail never touches commit names, anything prefixing commits is the agent inventing it.

On the real issue here, the marker landing on every edit: that's a legit rough edge, not your setup. The rule says to mark deliberate simplifications but gives no boundary for what NOT to mark, so a model reads every lazy edit as worth a marker. And since the ruleset re-injects every turn, a "DO NOT INCLUDE" note in your appendsystem loses to it.

The fix that fits this repo is one line in the rule itself: mark only real corner-cuts, normal code gets nothing, shipped to every rules copy so the static integrations (Cursor, Windsurf, etc.) get it too. @Lakshya77089 offered a PR for that, I'd take it (with the quick benchmark since it rides the always-on prompt). For right now, /ponytail lite or "only mark real shortcuts" reins it in.

Leaving open to track the rule fix.