菜单
Review a diff or branch for over-engineering only — reinvented stdlib, dependencies the platform covers, one-implementation abstractions, dead flexibility, code that shrinks. Use on "review for over-engineering", "is this over-engineered", "what can we delete", "simplify review". Correctness, security, and performance stay with `dev-code-review`.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Write documentation someone will actually read — READMEs, guides, API references, runbooks — short, scannable, example-first, and verified against the code. Trigger on "write docs", "document this", "write a README", "explain how to use this", "our docs are too long/confusing", or a doc that needs rewriting for humans.
Review a diff, branch, or PR for correctness bugs, security issues, and simplification opportunities; findings to docs/<feature-name>/REVIEW.md. Trigger on "review this", "code review", "security review", "audit this", or after something is implemented and needs checking before merge.
Write docs/<feature-name>/PLAN.md with phased, checkbox-driven steps for a feature, refactor, upgrade, or infrastructure change. Trigger on "create/make a plan", "plan this feature/refactor/upgrade", any request to document steps before coding, and proactively when complexity warrants a written plan.
Decide a feature's shape before planning — system design, data model, API contract, UI/UX, whichever apply — and write docs/<feature-name>/DESIGN.md. Trigger on "design this feature/API/schema/UI", "how should we structure this", or between dev-research and dev-create-plan.
Execute an implementation plan from docs/<feature-name>/PLAN.md — tick checkboxes, commit each phase. Trigger on "implement/execute/continue/resume the plan", "start phase 1", "go" right after a plan was created, or whenever there is a PLAN.md to build, even if the user never says "plan".
Run an autonomous plan → implement → review loop for a feature, iterating until the code review passes and pausing for approval before pushing. Use on "loop on this", "keep going until it passes review", "autonomous dev loop", "plan implement and review", or a self-correcting agent workflow.
| name | dev-ponytail-review |
| description | Review a diff or branch for over-engineering only — reinvented stdlib, dependencies the platform covers, one-implementation abstractions, dead flexibility, code that shrinks. Use on "review for over-engineering", "is this over-engineered", "what can we delete", "simplify review". Correctness, security, and performance stay with `dev-code-review`. |
Review the diff for unnecessary complexity, nothing else. Its best outcome is getting shorter.
lite | full | ultra, default lite)Mode is the trailing argument when it is exactly lite, full, or ultra; everything else is the task/feature description. No mode given → lite.
lite (default) — the five biggest cuts. Report only.full — every finding, ranked biggest cut first. Report only.ultra — full, then apply the unambiguous findings (a stdlib swap, a one-implementation interface inlined) and leave them uncommitted. Judgement calls stay findings.Named target → review it. Otherwise the working diff (git diff + staged), and
if that's empty, the branch against its merge base.
Read the surrounding code, not just the hunks: "this abstraction has one implementation" is a claim about the whole repo, and a wrong finding costs more than a missed one.
<file>:L<line>: <tag> <what>. <replacement>. — L<line>: alone for a
single-file diff.
delete: dead code, unused flexibility, speculative feature. Replacement: nothing.stdlib: hand-rolled thing the stdlib ships. Name the function.native: dependency or code doing what the platform 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.Not a hedged paragraph — "this EmailValidator might be more complex than necessary, have you considered..." — but:
L12-38: stdlib: 27-line validator class. "@" in email; the confirmation mail is the real validation.L4: native: moment.js for one format call. Intl.DateTimeFormat, zero deps.repo.py:L88: yagni: AbstractRepository with one implementation. Inline until a second exists.L52-71: delete: retry wrapper around an idempotent local call. Nothing replaces it.L30-44: shrink: manual loop builds a dict. dict(zip(keys, values)), one line.End with net: -<N> lines possible. (deleted minus what replacements add).
Nothing to cut → Lean already. Ship. A tight diff is a pass, not a failed hunt.
Complexity only. A real bug spotted while reading gets one line at the end under
out of scope: and goes to dev-code-review — don't swallow it, don't expand
into a full review.
One smoke test or assert self-check is the dev-ponytail minimum, not bloat.
Never flag it for deletion.