ponytail-review
Review a diff for over-engineering. Finds what to delete: reinvented stdlib, needless deps, speculative abstractions. One line per finding.
- License 许可
- MIT
- 最近更新
- 2026-09-28
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- ponytail-review
- license
- MIT
- homepage
- https://github.com/DietrichGebert/ponytail
- description
- Review a diff for over-engineering. Finds what to delete: reinvented stdlib, needless deps, speculative abstractions. One line per finding.
03 SKILL.md 正文
Review diffs for unnecessary complexity. One line per finding: location, what to cut, what replaces it. The diff's best outcome is getting shorter.
Format
L<line>: <tag> <what>. <replacement>., or <file>:L<line>: ... for
multi-file diffs.
Tags:
delete:dead code, unused flexibility, speculative feature. Replacement: nothing.stdlib:hand-rolled thing the standard library ships. Name the function.native:dependency or code doing what the platform already does. Name the feature.yagni:abstraction with one implementation, config nobody sets, layer with one caller.shrink:same logic, fewer lines. Show the shorter form.
Examples
❌ "This EmailValidator class might be more complex than necessary, have you considered whether all these validation rules are needed at this stage?"
✅ L12-38: stdlib: 27-line validator class. "@" in email, 1 line, real validation is the confirmation mail.
✅ L4: native: moment.js imported for one format call. Intl.DateTimeFormat, 0 deps.
✅ repo.py:L88: yagni: AbstractRepository with one implementation. Inline it until a second one exists.
✅ L52-71: delete: retry wrapper around an idempotent local call. Nothing replaces it.
✅ L30-44: shrink: manual loop builds dict. dict(zip(keys, values)), 1 line.
Scoring
End with the only metric that matters: net: -<N> lines possible.
If there is nothing to cut, say Lean already. Ship. and stop.
Boundaries
Scope: over-engineering and complexity only. Correctness bugs, security holes,
and performance are explicitly out of scope. Route them to a normal review
pass, not this one. A single smoke test or assert-based
self-check is the ponytail minimum, not bloat, never flag it for deletion.
Does not apply the fixes, only lists them.
"stop ponytail-review" or "normal mode": revert to verbose review style.
04 同仓库更多 Skills
wireframe
Produce low-fidelity wireframes or storyboards to explore a flow, layout, or idea across multiple options before committing to hi-fi design. Use when the user wants to 'explore options', 'sketch something out', 'see a few directions', or when the problem is open enough that hi-fi work would be wasted.
video-test
Record a video test of any feature or user flow via Playwright. Use when the user says "record video test", "video test", "record a test", "show me the feature", "record the UI", "capture video", or wants a visual demo of a feature. Accepts a description of what to test as an argument (e.g., `/video-test the brainstorm creation flow`).
risk-assessment
Assess the delivery risk and ambiguity of an issue. Scores three anchored 1-5 risk dimensions — Code Blast Radius, Complexity, Business Blast Radius — into an overall risk level (Low/Medium/High) with safeguards, plus a separate Ambiguity score (how many open questions remain) with the open questions listed. Use this BEFORE work starts, whenever someone wants to know how risky, how big, how complex, or how well-specified an issue is, or asks to "assess risk", "risk assessment", "score this issue", "how risky is this", "what's the blast radius", "how complex is this", "how ambiguous is this", or "how many open questions are there". Accepts a Multica issue ID, a GitHub issue/PR, or a free-text description as the argument.
research
Deep parallel codebase research before planning or implementation. Spawns 4 specialized agents that explore behavior, architecture, coding standards, and test coverage simultaneously, then synthesizes findings into a structured RESEARCH.md document. Use this skill when the user says "research", "investigate", "explore the codebase", "understand the code", "deep dive", or wants thorough analysis of an area before making changes. Also use it as the first step of any complex feature — research first, then plan, then implement.
ponytail
Lazy senior dev mode for any coding task (write, refactor, fix, review): YAGNI, stdlib first, no unrequested abstractions. Not for non-coding requests.
polish-pass
Run a comprehensive end-of-design quality gate before a design is shown to stakeholders or shipped, covering hierarchy, AI-slop, interaction states, and accessibility. Use as the final review pass before delivery, or when the user asks to 'polish', 'finalize', or 'make it shippable'.