refactor

Featured

Restructure existing code without changing its behavior, through a test-gated refactoring loop: a named target, a green suite over that target before any edit, a planned sequence of small named refactorings, and the full suite re-run after every step. Use when the user wants to refactor, restructure, clean up, simplify, or improve the design of existing code, or to apply refactoring recommendations from a code-review or architectural-analysis report. This skill changes code; it does not review code (use code-review), assess architecture (use architectural-analysis), or build new behavior test-first (use tdd). Do not use it on code inside an active tdd loop; the refactor step of tdd owns that cleanup. Runs its planned sequence to completion without pausing for review; to review each named refactoring as it lands, use pairing.

Code & Development 263 stars 23 forks Updated today MIT

Install

View on GitHub

Quality Score: 91/100

Stars 20%
81
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

## Project Context - git installed: !`which git 2>/dev/null || echo "not installed"` - current branch: !`git branch --show-current 2>/dev/null || echo unknown` - working tree: !`git status --porcelain 2>/dev/null | head -5` - CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f` - project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f` - personal config directory: !`bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"` - project .han/config.md: !`cat .han/config.md 2>/dev/null || echo ""` As your first action, use the Read tool on `.han/config.md` inside the `personal config directory` path above. A read that returns no file is no personal configuration: continue silently. When that file or the `project .han/config.md` probe supplies content, apply it per [config-rule.md](../../references/config-rule.md), which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used. ## Constraints (read before anything else) This skill restructures existing production and test code in your working tree. It is an execution skill, not a document generator. These constraints shape every step and override any instinct to move faster. The canon they derive from, with provenance, is in [references/refactoring-discipline.md](./references/refactoring-discipline.md); pull that reference when a step needs the full rule or a step feels off. - **Behavior preservat...

Details

Author
testdouble
Repository
testdouble/han
Created
4 months ago
Last Updated
today
Language
Shell
License
MIT

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Featured

tdd

Write code through a disciplined, BDD-framed Test-Driven Development loop: build a behavior test list, then drive each behavior through red-green-refactor with an enforced observed-failure gate. Use when the user wants to implement, build, or write code test-first, "do TDD", follow "red-green-refactor", drive code from tests, choose the next test by the Transformation Priority Premise (TPP) or ZOMBIES ordering, or grow a feature behavior-by-behavior with tests leading. This skill writes and changes code; it does not produce a test plan document (use automated-test-planning, or manual-test-planning for a plan a person runs by hand), review or audit existing code (use code-review), restructure existing code outside a TDD loop (use refactor), specify what a feature should do (use plan-a-feature), or find the root cause of a bug (use investigate). Runs its loop to completion without pausing for review; to review each behavior as it lands, use pairing.

263 Updated today
testdouble
Code & Development Listed

refactor

Clean up and improve already-written code — simplification, reuse/DRY extraction, efficiency, language modernization, and architecture/layer hygiene. QUALITY-ONLY: this skill does NOT hunt for correctness bugs — use /code-review for that. It applies edits then verifies via format + test. TRIGGER when: the user wants to tidy, simplify, modernize, de-duplicate, or make changed code more reusable or efficient. DO NOT TRIGGER when: the user wants to hunt correctness/security/crash bugs (use /code-review), scan the WHOLE codebase for rot/ball-of-mud hotspots (use /arch-health), or design a module's interface from scratch (use /codebase-design).

2 Updated 1 weeks ago
mik2win
Code & Development Featured

pairing

Build work collaboratively in reviewable pieces, handing each piece back for review before starting the next, so the person stays in the lead and steers while the work happens instead of reviewing a finished result. Use when someone says to pair with them on something, asks to collaborate rather than direct, wants to review as it goes, or wants to guide the work piece by piece — on code, on a design decision, or on writing. For a test-first build it runs tdd, for restructuring it runs refactor, for an interface contract it runs design-an-api, and for plan work it runs iterative-plan-review or plan-implementation, each collaboratively; invoke any of those directly instead to run it straight through without pausing. Does not pace someone through code that already exists and builds nothing — use code-walkthrough. Does not explain, summarize, or research something instead of producing it — use code-overview or research.

263 Updated today
testdouble