菜单
Review code for behavior-preserving simplification — collapse duplication, remove dead code and over-engineering, cut verbose patterns down to idiomatic ones. Use when code is longer or more complex than it needs to be, or the user asks to simplify, shorten, refactor, or clean up.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Run a bounded change → verify → fix cycle until an objective check passes (tests green, lint clean, build/type-check ok) or a hard iteration cap is hit. Use for any task that needs repeated attempts against a verifiable signal instead of a single one-shot edit.
Implement a planned ticket on its own branch using test-first development, updating docs as part of the change, looping change→verify→fix until the suite is green. Use when a ticket has a plan and is ready to build, or the user says "implement X" / "build the ticket" / "make it pass".
Use to store durable context (decisions, facts, preferences, todos, summaries) and to recall or reply from it across sessions. Load when something worth remembering appears, or when the user asks what you were doing, what was decided, or to continue prior work.
Choose the right model and effort per task phase and apply it when dispatching subagents — strong model + high effort for planning and review, a cheaper model + lower effort for mechanical execution. Use when a task splits into plan / execute / review phases or you're spawning subagents.
Push a reviewed ticket branch and open a pull request with a structured title and body, after review-changes has passed. Use when a ticket is reviewed and ready to ship, or the user says "open a PR" / "create the pull request". Stops at opening the PR — never merges.
Turn a feature request into a concrete plan — scope, approach, affected files, a test plan mapped to acceptance criteria, and out-of-scope — before any code is written. Use when the user describes new work, asks to design or spec something, or says "plan this" / "how would you build X".
基于 SOC 职业分类
| name | code-reducer |
| description | Review code for behavior-preserving simplification — collapse duplication, remove dead code and over-engineering, cut verbose patterns down to idiomatic ones. Use when code is longer or more complex than it needs to be, or the user asks to simplify, shorten, refactor, or clean up. |
| model | inherit |
| effort | low |
| allowed-tools | ["Read","Grep","Glob","Edit"] |
| triggers | ["simplify","too verbose","over-engineered","refactor this","reduce the code","clean this up","make it shorter"] |
| tags | ["refactor","simplify","dry","cleanup"] |
Make code smaller and clearer without changing behavior. Fewer lines is a side effect; the goal is less to read and less to break.
Behavior must not change. If you can't prove it's equivalent, don't do it — propose it instead. Always confirm with the project's own tests/lint/build after.
| Smell | Reduce to |
|---|---|
| Duplicated blocks | One function/constant, called from each site (DRY). |
| Dead code / unused vars / unreachable branches | Delete. |
| Speculative generality (unused params, config, abstraction for one caller) | Inline to the one real use (YAGNI). |
| Deep nesting | Early returns / guard clauses. |
| Manual accumulate loop | map / filter / reduce (or the language's idiom). |
| Nested null checks | Optional chaining / safe navigation. |
| Repeated field access | Destructure once. |
| Temp var used once | Inline it. |
| Verbose conditionals returning bools | Return the expression directly. |
| Hand-rolled utility that exists in stdlib | Use the stdlib function. |
Report each change as: what smell, the before→after shape, and why it's equivalent. If a reduction is possible but not provably safe (touches public API or subtle behavior), list it as a suggestion, don't apply it.
Then state the verification result (tests/lint/build) and the net line change.
