ponytail-review

A preserved method from https://github.com/dietrichgebert/ponytail at 356918eba965, path skills/ponytail-review, MIT. 33 of 57 source lines differ (58%), every difference claimed by an entry of the ledger with its reason. Entries: baseline-copies-2026-09-11, pull-2026-09-11, fold-2026-09-11.

  • dependency 1
  • harness 1
  • lifecycle 1
  • location 1
  • scope 1

Files

Every difference, as it stands

SKILL.md

---
---
harnesschangedbaseline-copies-2026-09-11

greenline renders its own frontmatter: quoted name and description, the description from the manifest override where one existed, no upstream activation flag

name: ponytail-review
name: "ponytail-review"
description: >
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."
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.
---
---
 
 
scopechangedfold-2026-09-11

one opening paragraph in the skill's voice before the method (upstream has no title): the over-engineering pass on a committed range, a ticket's base_commit..result_commit or a named range, fired by the user's review-for-over-engineering phrases; correctness and fidelity are delivery-review's, test-suite cuts and the seams those tests demanded are sweep-tests'; it hunts production-code complexity only, proves nothing and applies nothing, and each accepted cut returns to the ticket that owns the code

This skill is the over-engineering pass on a committed range: a ticket's `base_commit..result_commit`, or a named range. It fires when the user says "review for over-engineering", "what can we delete", "is this over-engineered" or "simplify review". Correctness and fidelity belong to delivery-review; cuts to the test suite and the seams those tests demanded belong to sweep-tests, which proves a deletion by mutation. This skill hunts production-code complexity only, proves nothing and applies nothing: it reports findings, and each accepted cut returns to the ticket that owns the code.
 
Review diffs for unnecessary complexity. One line per finding: location, what
Review diffs for unnecessary complexity. One line per finding: location, what
to cut, what replaces it. The diff's best outcome is getting shorter.
to cut, what replaces it. The diff's best outcome is getting shorter.
 
 
31 unchanged lines
## Format
## Format
 
 
`L<line>: <tag> <what>. <replacement>.`, or `<file>:L<line>: ...` for
`L<line>: <tag> <what>. <replacement>.`, or `<file>:L<line>: ...` for
multi-file diffs.
multi-file diffs.
 
 
Tags:
Tags:
 
 
- `delete:` dead code, unused flexibility, speculative feature. Replacement: nothing.
- `delete:` dead code, unused flexibility, speculative feature. Replacement: nothing.
- `stdlib:` hand-rolled thing the standard library ships. Name the function.
- `stdlib:` hand-rolled thing the standard library ships. Name the function.
- `native:` dependency or code doing what the platform already does. Name the feature.
- `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.
- `yagni:` abstraction with one implementation, config nobody sets, layer with one caller.
- `shrink:` same logic, fewer lines. Show the shorter form.
- `shrink:` same logic, fewer lines. Show the shorter form.
 
 
## Examples
## Examples
 
 
❌ "This EmailValidator class might be more complex than necessary, have you
❌ "This EmailValidator class might be more complex than necessary, have you
considered whether all these validation rules are needed at this stage?"
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.`
✅ `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.`
✅ `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.`
✅ `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.`
✅ `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.`
✅ `L30-44: shrink: manual loop builds dict. dict(zip(keys, values)), 1 line.`
 
 
## Scoring
## Scoring
 
 
End with the only metric that matters: `net: -<N> lines possible.`
End with the only metric that matters: `net: -<N> lines possible.`
 
 
If there is nothing to cut, say `Lean already. Ship.` and stop.
If there is nothing to cut, say `Lean already. Ship.` and stop.
 
 
locationchangedfold-2026-09-11

the Scoring section says where the finding list and the net: line land: .greenline/work/reviews/REV-NNN.md under its ticket, execution account and result range when a durable review exists, otherwise the reply; reporting a cut is not approval to make it

The finding list and the `net:` line are the review report. When a durable
review exists for the range, write them into `.greenline/work/reviews/REV-NNN.md`
under its ticket, execution account and result range; a read-only review
returns them in the reply. Reporting a cut is not approval to make it.
 
## Boundaries
## Boundaries
 
 
Scope: over-engineering and complexity only. Correctness bugs, security holes,
Scope: over-engineering and complexity only. Correctness bugs, security holes,
dependencychangedfold-2026-09-11

upstream's 'a normal review pass' is the roster skill that owns correctness, delivery-review, and the Boundaries name sweep-tests as the owner of test-suite cuts and the seams those tests demanded

and performance are explicitly out of scope. Route them to a normal review
and performance are explicitly out of scope. Route them to delivery-review,
pass, not this one. A single smoke test or `assert`-based
not this one. Test-suite cuts and the seams those tests demanded go to
sweep-tests. A single smoke test or `assert`-based
self-check is the ponytail minimum, not bloat, never flag it for deletion.
self-check is the ponytail minimum, not bloat, never flag it for deletion.
lifecyclechangedfold-2026-09-11

the closing Boundaries line says an accepted cut returns to the owning ticket for implementation and fresh proof, and the Handoff section names the consumed range, the produced findings with their home, and implement as the next stage; upstream's 'stop ponytail-review' mode-toggle line stays dropped inside the same hunk, since greenline has no verbose review mode to revert to

Does not apply the fixes, only lists them.
Does not apply the fixes, only lists them: an accepted cut returns to the
"stop ponytail-review" or "normal mode": revert to verbose review style.
owning ticket for implementation and fresh proof.
 
## Handoff
 
Consumes: a committed range, a ticket's base_commit..result_commit or a named range
Produces: findings, one line each with location, what to cut and what replaces it, and the net: line, in .greenline/work/reviews/REV-NNN.md when a durable review exists, otherwise in the reply
Next: implement takes each accepted cut back into the owning ticket

The timeline

Each entry that touched this method, with the differences it claimed as they stood at its commit, read from the repository's history.

2026-09-11 baseline-copies-2026-09-11

the cutover to an edited copy (ADR 0039): the composed output written as the copy, every difference from upstream claimed with the reason of the overlay that produced it

SKILL.md

harnesschangedbaseline-copies-2026-09-11

greenline renders its own frontmatter: quoted name and description, the description from the manifest override where one existed, no upstream activation flag

name: ponytail-review
name: "ponytail-review"
description: >
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."
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.
lifecyclechangedbaseline-copies-2026-09-11

greenline prelude, to fold: a dedicated over-engineering pass beside delivery-review; production-code cuts only, test-suite cuts belong to sweep-tests; findings only

**greenline prelude.** A dedicated over-engineering pass, complementary to `delivery-review`, which owns correctness and fidelity. Run it on a committed range or diff; report findings only, and route each accepted cut through the ticket that owns the code.
 
The cuts here are production-code cuts: test-suite cuts and the seams those tests demanded belong to `sweep-tests`, which proves a deletion by mutation, where this skill proves nothing and applies nothing.
 
lifecyclechangedbaseline-copies-2026-09-11

greenline completion, to fold: findings and the net line go in the review report; accepted cuts return to the work owner

"stop ponytail-review" or "normal mode": revert to verbose review style.
 
 
## greenline completion: where the findings land
 
Return the finding list and `net:` line in the review report. A durable commissioned review uses the common review artifact and its exact ticket, execution account, and result range. Read-only review stays in the response. Accepted cuts return to the work owner for implementation and fresh proof; reporting an opportunity is not approval to make it.

2026-09-11 pull-2026-09-11

pin advance to 356918e: upstream moved with no change under the vendored paths

2026-09-11 fold-2026-09-11

the fold (ADR 0039, S3): the prelude and completion are gone; the committed range, the review report's home, the routing of correctness to delivery-review and of test-suite cuts to sweep-tests, and the return of accepted cuts to the owning ticket sit where the reader reaches them, with the Handoff section the skills-handoff gate parses

SKILL.md

scopechangedfold-2026-09-11

one opening paragraph in the skill's voice before the method (upstream has no title): the over-engineering pass on a committed range, a ticket's base_commit..result_commit or a named range, fired by the user's review-for-over-engineering phrases; correctness and fidelity are delivery-review's, test-suite cuts and the seams those tests demanded are sweep-tests'; it hunts production-code complexity only, proves nothing and applies nothing, and each accepted cut returns to the ticket that owns the code

This skill is the over-engineering pass on a committed range: a ticket's `base_commit..result_commit`, or a named range. It fires when the user says "review for over-engineering", "what can we delete", "is this over-engineered" or "simplify review". Correctness and fidelity belong to delivery-review; cuts to the test suite and the seams those tests demanded belong to sweep-tests, which proves a deletion by mutation. This skill hunts production-code complexity only, proves nothing and applies nothing: it reports findings, and each accepted cut returns to the ticket that owns the code.
 
locationchangedfold-2026-09-11

the Scoring section says where the finding list and the net: line land: .greenline/work/reviews/REV-NNN.md under its ticket, execution account and result range when a durable review exists, otherwise the reply; reporting a cut is not approval to make it

The finding list and the `net:` line are the review report. When a durable
review exists for the range, write them into `.greenline/work/reviews/REV-NNN.md`
under its ticket, execution account and result range; a read-only review
returns them in the reply. Reporting a cut is not approval to make it.
 
dependencychangedfold-2026-09-11

upstream's 'a normal review pass' is the roster skill that owns correctness, delivery-review, and the Boundaries name sweep-tests as the owner of test-suite cuts and the seams those tests demanded

and performance are explicitly out of scope. Route them to a normal review
and performance are explicitly out of scope. Route them to delivery-review,
pass, not this one. A single smoke test or `assert`-based
not this one. Test-suite cuts and the seams those tests demanded go to
sweep-tests. A single smoke test or `assert`-based
lifecyclechangedfold-2026-09-11

the closing Boundaries line says an accepted cut returns to the owning ticket for implementation and fresh proof, and the Handoff section names the consumed range, the produced findings with their home, and implement as the next stage; upstream's 'stop ponytail-review' mode-toggle line stays dropped inside the same hunk, since greenline has no verbose review mode to revert to

Does not apply the fixes, only lists them.
Does not apply the fixes, only lists them: an accepted cut returns to the
"stop ponytail-review" or "normal mode": revert to verbose review style.
owning ticket for implementation and fresh proof.
 
## Handoff
 
Consumes: a committed range, a ticket's base_commit..result_commit or a named range
Produces: findings, one line each with location, what to cut and what replaces it, and the net: line, in .greenline/work/reviews/REV-NNN.md when a durable review exists, otherwise in the reply
Next: implement takes each accepted cut back into the owning ticket