Skip to content

Research: the Mikado Method for refactoring - #228

Draft
mxriverlynn wants to merge 3 commits into
v6.0.0-betafrom
research/mikado-method-refactor
Draft

mxriverlynn wants to merge 3 commits into
v6.0.0-betafrom
research/mikado-method-refactor

Conversation

@mxriverlynn

@mxriverlynn mxriverlynn commented Oct 15, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

Research report on whether, and how, to add the Mikado Method to han-coding:refactor, produced with /han-research:research (medium band, strict evidence mode, adversarially validated).

  • Report: docs/research/mikado-method-refactor.md

Findings

  • Fix the refactor skill's undo step first, independent of Mikado. On a red step it restores touched files with git whenever the tree was clean at the start of the run. Commits are optional, so when two steps share a file with no commit between them, undoing the second also discards the first, finished step. That contradicts the skill's own "everything already applied is green and stands."
  • Add only a thin Mikado slice. Extend the skill's existing "defer with what you learned" behavior to its scope and two-undo stops: undo the offending step and list what blocked it as prerequisites in the stop report and summary.
  • Do not add the full method (as a mode, inside plan-a-change, or as a separate skill). Its discover-by-breaking loop conflicts with three rules the skill rests on: plan before editing, scope as a contract, and stop after two undos.

Confidence: Medium. The Mikado evidence is practitioner accounts only, with no measured studies, and nothing in the repo shows people hitting the scope stop today.

No skill or doc changes yet. This PR carries the research only.

🤖 Generated with Claude Code

mxriverlynn and others added 3 commits October 15, 2026 14:24
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
mxriverlynn added a commit that referenced this pull request Oct 15, 2026
## Summary

The refactor skill's red-step revert could throw away finished work.

**The bug.** On a red suite, the skill ran `git checkout`/`git restore`
on the touched files whenever git was available and the tree was clean
*at the start of the run*. Commits during a run only happen if you ask
for them, and even then can be grouped. Git restores a file to its last
commit, so when two steps touch the same file with no commit between
them, reverting the second step also discarded the first, already-green
step. That contradicted the skill's own stop-rule promise that
"everything already applied is green and stands."

**The fix.** A red step now undoes only its own edits directly: reverse
each edit, delete any file the step created, and move renamed or moved
files back. The skill never restores files from git to undo a step,
never runs `git reset --hard`, `git clean`, or `git stash` for it, and
re-runs the suite to show the revert is back to green.

## Changes

- `han-coding/skills/refactor/SKILL.md`: Step 4, item 4 rewritten.
- `han-coding/docs/skills/refactor.md`: the "what you get" bullet now
says a revert touches only that step's edits.

Found during the Mikado Method research in #228. That research's Mikado
recommendations are deliberately out of scope here.

## Test plan

- [x] `npm run lint` passes
- [x] `npm test` passes
- [ ] Manual: run `/refactor` on a target where two planned steps edit
the same file, with no commits requested, and force the second step red;
confirm the first step's change survives the revert.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
@mxriverlynn mxriverlynn changed the title Research: adding the Mikado Method to the refactor skill Research: the Mikado Method for refactoring Oct 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants