Hermes/ponytail-programming-skill
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Complete Ponytail mode and honesty boundaries

Browse Source
This commit is contained in:
Hermes Agent
2026-06-20 02:08:36 +08:00
parent 9c3bd8bd1e
commit b705eac771
1 changed files with 18 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skill/ponytail-programming/SKILL.md
+18
View File
@@ -29,6 +29,18 @@ This is not code golf. Never cut trust-boundary validation, data-loss protection
Don't use this to ignore explicit scope, skip required safety work, or refuse a full implementation after the user confirms they need it. Don't use this to ignore explicit scope, skip required safety work, or refuse a full implementation after the user confirms they need it.
## Modes and Commands
Ponytail upstream has runtime levels. In Hermes, treat them as working styles rather than plugin state unless the user explicitly asks for a mode switch:
- **lite:** Build what was asked, then name the lazier alternative in one short line.
- **full:** Default. Enforce the ladder, choose stdlib/native/installed tools first, shortest correct diff.
- **ultra:** YAGNI extremist. Try deletion before addition and challenge expensive requirements in the same response, but still implement explicit must-haves.
- **off / normal mode:** Stop applying Ponytail pressure for the current task.
- **review:** Independent over-engineering review mode; report deletions and simplifications only, do not apply fixes unless asked.
Activation/deactivation phrases from upstream: `ponytail`, `/ponytail`, `@ponytail`, `ponytail lite|full|ultra|off`, `stop ponytail`, and `normal mode`. Do not treat incidental phrases like "add a normal mode toggle" as deactivation.
## The Ladder ## The Ladder
Before writing code, stop at the first rung that holds: Before writing code, stop at the first rung that holds:
@@ -93,6 +105,12 @@ Examples:
Do not add `ponytail:` comments for obvious code. Use them only when future maintainers might mistake a deliberate simplification for ignorance. Do not add `ponytail:` comments for obvious code. Use them only when future maintainers might mistake a deliberate simplification for ignorance.
## Gain and Honesty Boundary
Upstream publishes benchmark gains, but those are benchmark medians, not evidence about the current repository. Do not claim "this repo saved X lines/tokens/cost" unless there is a real measured baseline. For live codebases, only report concrete counts you can verify, such as deleted lines in the actual diff, dependencies removed, or `ponytail:` debt markers found.
If asked for Ponytail's general impact, state it as upstream benchmark context and link/source it separately from current-work results.
## Output Style ## Output Style
For implementation tasks, keep the final explanation shorter than the diff whenever possible: For implementation tasks, keep the final explanation shorter than the diff whenever possible: