which git 2>/dev/null || echo \"not installed\"git branch --show-current 2>/dev/null || echo unknowngit status --porcelain 2>/dev/null | head -5find . -maxdepth 1 -name \"CLAUDE.md\" -type ffind . -maxdepth 3 -name \"project-discovery.md\" -type fbash \"${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh\" 2>/dev/null || echo \"$HOME/.claude\"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\nthat returns no file is no personal configuration: continue silently. When that file or the project .han/config.md\nprobe supplies content, apply it per config-rule.md, which governs precedence\nbetween the two files, relative-path resolution, and what to do with a file that reads but cannot be used.
This skill restructures existing production and test code in your working tree. It is an execution skill, not a document\ngenerator. These constraints shape every step and override any instinct to move faster. The canon they derive from, with\nprovenance, is in references/refactoring-discipline.md; pull that reference\nwhen a step needs the full rule or a step feels off.
\n/tdd owns cleanup inside the loop, and restructuring\nwhile a test is red violates the two-hats rule both skills share.Bind the target. Resolve the request to a named target: specific files or directories, a named code smell in a named\nplace, or the refactoring findings in a provided document (a /code-review report, an /architectural-analysis report,\nor equivalent). When a findings document is given, extract only the refactoring-shaped findings (structural suggestions,\nduplication, naming, coupling) and record each finding's ID so the summary can trace back to it. If the request is\nopen-ended (\"clean up the codebase\", \"improve quality\") with no named target, ask the user for one before doing\nanything: open-ended refactoring runs are the documented failure mode this skill exists to avoid, and a wrong guess here\nburns the whole run.
Resolve commands. Read CLAUDE.md's ## Project Discovery section for the test command (under\n### Commands and Tests), the lint command, the build command, language, and framework. If absent, fall back to\nproject-discovery.md. If still absent, run ${CLAUDE_SKILL_DIR}/scripts/detect-refactor-context.sh and parse its\noutput for git state and manifest-inferred commands. A missing test command is a hard blocker: exhaust inference, then\nask the user, because this skill cannot run without a way to verify behavior. Also note any type-check command the\nproject has; where one exists it runs alongside the tests as a second behavior-preservation check.
Resolve standards and decisions. Resolve the coding-standards directory and ADR directory the same way: CLAUDE.md's\n## Project Discovery section, then project-discovery.md, then Glob defaults (docs/, docs/adr/,\ndocs/coding-standards/, docs/decisions/). Also check CLAUDE.md and AGENTS.md for inline standards. Read the\nstandards and ADRs whose titles, paths, or one-line summaries indicate they govern the target area; cap at five\ndocuments. The target's restructured form must conform to these. If none exist, state that plainly and infer conventions\nfrom the surrounding code.
Check the tree. If working tree in Project Context shows failing mid-cycle work or the user describes an in-flight\ntdd loop on this code, stop and say why (the never-alongside-tdd constraint). Uncommitted but complete work is fine;\nrecommend committing it first so refactoring diffs stay clean, then proceed.
Run the full suite. Run the resolved test command with Bash. Paste the runner's summary line. If anything is\nred, stop: a red suite is not a license to refactor. Report the failures and recommend fixing them first (via\n/investigate or /tdd), or re-scoping the target away from the broken area.
Establish coverage of the target. Confirm the target's observable behavior is exercised by the suite: find the tests\nthat drive the target (Glob and Grep for the target's public symbols in test files), and run them scoped if the runner\nsupports it. State plainly which behaviors are covered and which are not. If the target has no meaningful coverage, stop\nand offer two ways forward, and wait for the user's choice: narrow the target to the covered part, or write\ncharacterization tests first using the protocol in\nreferences/refactoring-discipline.md. Characterization tests pin current\nobserved behavior (including current bugs) and are a lower-confidence net than intent-written tests; say so in the\nreport.
\nPlan the whole run before the first edit. Produce a numbered refactoring plan where each item is:
\nOrder the plan so each step leaves the code releasable: small, independent steps first, dependent steps after the steps\nthey need. Report the plan to the user, then continue immediately; this is a report, not a gate. The one exception: if\nthe request explicitly asks to review or approve the plan first, wait for approval.
\nTake the plan items in order. For each:
\nMake the one change. Apply the single named refactoring, touching only the files in its declared blast radius.\nStay in the refactoring hat: no behavior fixes, no extras spotted along the way (record them for the summary\ninstead).
\nRun the full suite (and the type-check command where one was resolved). Paste the runner's summary line.\nPaste full output only when something fails or looks unexpected.
\nGreen: cross the item off and move to the next.
\nRunning collaboratively. When the request asks to review each named refactoring as it lands, which is what\npairing does when it hands work here, stop at this point and hand control back instead of continuing. Present the\nstop in the shape collaborative-stop-rule.md specifies. Absent such a\nrequest, continue as below; an ordinary invocation is unchanged.
Red: revert this step. When git is available and the tree was clean at start, git checkout/git restore the\ntouched files. When git is absent, or the tree was already dirty at start, undo the edits directly instead, so\nreverting this step does not discard the user's other work. Do not patch forward over a red suite; a failed step\nmeans the mechanic was unsafe or the coverage was thinner than it looked. Diagnose, then either retry with a smaller\nstep or defer the item with what you learned.
Stop rules. If the step needed files outside its declared blast radius, or the only way to make it work changes\nobservable behavior, or two consecutive plan items have been reverted: stop, report where things stand (everything\nalready applied is green and stands), and let the user re-scope.
\nIf the user asked for commits, commit after each green step or each logical group of green steps, message naming the\nrefactoring applied, refactoring only.
\nRun the full test suite, the lint command, and the build command from Step 1. Paste the summary line from each. If\nlint or build fails on code this skill touched, fix it and re-run; that is in scope.
\nSummarize for the user:
\n/issue-triage or the next\n/code-review.