refactor
Apply a refactoring lens — restructure code without changing behavior, guarded by tests that pass before and after. Use when the user says "refactor", "clean this up", "extract this", "simplify this", "reduce duplication", or "make this readable" on existing working code. Skip when the change is meant to alter behavior (that's a feature or a fix).
- License 许可
- MIT
- 最近更新
- 2026-11-07
- Stars
- ★ 1
- Forks
- 1
01 前言 Front Matter
- name
- refactor
- description
- Apply a refactoring lens — restructure code without changing behavior, guarded by tests that pass before and after. Use when the user says "refactor", "clean this up", "extract this", "simplify this", "reduce duplication", or "make this readable" on existing working code. Skip when the change is meant to alter behavior (that's a feature or a fix).
03 SKILL.md 正文
Refactor lens
Contract (shared by prompt-craft lenses): state the assumptions you're acting on, confirm anything load-bearing that's missing before changing code, make the smallest change that fits, and define how you'll know it's right.
The invariant: behavior is unchanged. The proof: the same tests pass before and after. No green test suite covering the target? That's step zero.
Steps
- Pin behavior with tests. Ensure tests cover the code being moved. If they don't, add characterization tests first — refactoring untested code is editing blind.
- Run the suite GREEN before touching anything (the baseline).
- Refactor in small, reversible steps — extract, rename, dedupe. Match the surrounding style even if you'd do it differently.
- Re-run the suite after each step; it must stay GREEN. A red test means the refactor changed behavior — revert and reconsider.
- Stop at the goal. No bundled feature changes, no opportunistic rewrites of adjacent code.
Confirm-step (before editing)
If there's no test coverage and the behavior contract is non-obvious, ask whether to add characterization tests first or whether a behavior change is actually intended.
04 同仓库更多 Skills
second-wind
Orchestrate long unattended Claude Code runs across multiple repos with the wind CLI. Use when the user wants to run Claude Code overnight, resume sessions after the 5-hour usage limit, run Claude in many repos at once via tmux, or says "set up second wind", "wind up", "overnight run", "resume after limit", "usage limit orchestrator".
structured-output-adaptive-thinking-token-bloat
A Claude API call using output_config.format (json_schema structured outputs) with thinking:{type:"adaptive"} burns most of its output budget on thinking (observed ~21k of ~24k tokens) without improving JSON quality, making the run up to ~5x more expensive than the same call with thinking omitted — use when calling the Messages API with a json_schema output format for extraction, ranking, classification, or summarization tasks, or when a schema-constrained call's usage.output_tokens is far larger than the returned JSON.
review
Apply a code-review lens to a diff, branch, or file — find correctness bugs, security issues, and quality problems, ranked by severity, with a concrete fix for each. Use when the user says "review this", "review my diff", "check this PR", "look this over before I commit", or "is this safe". Skip when the user wants the code written, not reviewed.
refresh
Rebuild the prompt-craft command registry and usage profile, and print a summary of installed commands and your personalized recommendations. Use when you install or update plugins and want the advisor to pick them up immediately, or say "refresh prompt-craft", "rebuild the command registry".
plan
Decompose a non-trivial task into an explicit, tracked plan with goals and per-step acceptance criteria before writing code. Use when the user says "plan this", "break this down", "what's the plan", or asks for a multi-step feature/refactor that touches more than one file. Pairs with plan mode. Skip for single-edit changes that need no decomposition.
improve-prompt
Turn a rough, vague, or one-line request into a deterministic spec before any work starts — restated goal, explicit acceptance criteria, surfaced assumptions to confirm, and recommended slash commands. Use when the user says "improve this prompt", "make this a spec", "sharpen this", "what would you need to know", or hands over a fuzzy ask like "fix the thing" / "make it better" / "add auth" with no detail. Skip when the request is already precise and self-contained.