Arthur MorrillandClaude Opus 4.8
b0c5820bb1
The Boundaries line opened with "Complexity only, correctness bugs, security holes, and performance go to a normal review pass." The comma after "Complexity only" fuses the in-scope item with the out-of-scope list, so a model parsing it literally can read all four categories as targets of the audit — the opposite of intent. Restate the boundary as an explicit scope fence: name what is in scope, then mark correctness/security/performance as explicitly out of scope. "Out of scope" is phrasing models reliably honor as a constraint. Also aligns the scope term with each skill's stated purpose (over-engineering). Applied to both skills/ and the .openclaw/ mirror so the two trees stay in sync. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
58 lines
2.3 KiB
Markdown
58 lines
2.3 KiB
Markdown
---
|
|
name: ponytail-review
|
|
description: >
|
|
Code review focused exclusively on over-engineering. Finds what to delete:
|
|
reinvented standard library, unneeded dependencies, speculative abstractions,
|
|
dead flexibility. One line per finding: location, what to cut, what replaces
|
|
it. Use when the user says "review for over-engineering", "what can we
|
|
delete", "is this over-engineered", "simplify review", or invokes
|
|
/ponytail-review. Complements correctness-focused review, this one only
|
|
hunts complexity.
|
|
---
|
|
|
|
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.
|