nw-mikado-method
Enhanced Mikado Method for complex architectural refactoring - systematic dependency discovery, tree-based planning, and bottom-up execution
Best use case
nw-mikado-method is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Enhanced Mikado Method for complex architectural refactoring - systematic dependency discovery, tree-based planning, and bottom-up execution
Teams using nw-mikado-method should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/nw-mikado-method/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How nw-mikado-method Compares
| Feature / Agent | nw-mikado-method | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Enhanced Mikado Method for complex architectural refactoring - systematic dependency discovery, tree-based planning, and bottom-up execution
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Mikado Method
Use for complex refactoring where direct implementation causes cascading failures across multiple classes/modules.
## When to Use
- Refactoring goal affects multiple classes/modules | Direct implementation causes cascade of failures
- Dependencies not immediately clear | High risk of breaking existing functionality
## Core Process
Cycle: Set Goal > Experiment > Visualize prerequisites > Revert to working state.
Treat compilation/test failures as valuable information -- each failure reveals a prerequisite node in the dependency graph. Revert keeps codebase shippable at all times.
## Discovery-Tracking Protocol
Commit immediately after each dependency discovery to preserve exploration history and enable interrupt/resume.
### Commit Formats
- Dependency: `Discovery: [Class.Method(params)] requires [Prerequisite] in [File:Line]`
- False leaf: `Discovery: False leaf - [Node] blocked by [Dependency]`
- Exploration complete: `Discovery: No new dependencies found - exploration complete for [GoalArea]`
- Ready: `Ready: True leaves identified - [Count] leaves ready for execution`
## Exhaustive Exploration Algorithm
Sequence: EXPERIMENT > LEARN > GRAPH > COMMIT GRAPH > REVERT
1. **Experiment**: Attempt naive implementation of stated goal
2. **Learn**: Capture ALL compilation and test failures immediately
3. **Graph**: Create concrete prerequisite nodes with exact specifications
4. **Commit Graph**: Commit discovery with mandatory format
5. **Revert**: Revert ALL code changes to maintain clean state
### Termination Criteria
- Every apparent leaf candidate systematically attempted | No new dependencies emerge from leaf attempts
- Tree structure stable across multiple exploration cycles | True leaves confirmed with zero prerequisites
## Concrete Node Specification
Nodes require method-level specificity:
- Method signatures: `ClassName.MethodName(parameter types) -> ReturnType`
- File locations: `src/Services/UserService.cs, line 45`
- Access modifiers: public | private | internal | protected
- Refactoring technique: Extract Method | Move Method | etc.
- Atomic transformation: Rename | Extract | Inline | Move | Safe Delete
- Code smell target: Long Method | Feature Envy | etc.
## Tree File Management
### File Structure
- Directory: `docs/mikado/` | Filename: `<goal-name>.mikado.md`
- Format: `- [ ]` pending, `- [x]` completed | Indentation: 4 spaces per nesting level
- Dependencies indented deeper than dependents
### Tree Structure Rules
1. Root goal at 0 indentation
2. Direct dependencies at 4-space indentation
3. Sub-dependencies at 8-space, continuing per level
4. Child nodes must complete before parent nodes
5. Nodes at same indentation level are independent (parallelizable)
## Two-Mode Operation
### Exploration Mode
1. Attempt naive implementation of refactoring goal
2. Capture compilation/test failures with full details
3. Create concrete prerequisite nodes with method-level specificity
4. Add dependencies to tree file with proper indentation nesting
5. Commit tree discovery only (specific format)
6. Revert code changes completely except tree file
7. Repeat until no new dependencies discovered
### Execution Mode
1. Identify deepest indentation level with incomplete nodes
2. Select only true leaves (most nested, zero prerequisites)
3. Execute one leaf at a time for safety
4. Complete all nodes at current level before moving up
5. Never attempt parent node until all children complete
6. Implement minimal possible change per leaf
7. Validate with full test execution
8. Commit implementation, update tree marking node complete
9. Proceed bottom-up to next true leaf
## Tree Example
```markdown
- [ ] Goal: Replace direct DB calls in OrderController with repository pattern
- [ ] Update OrderController constructor to use IOrderRepository
- [ ] Implement SqlOrderRepository : IOrderRepository
- [ ] Create IOrderRepository interface
- [ ] Define GetOrderById(int orderId) -> Order? method signature
- [ ] Define SaveOrder(Order order) -> Task method signature
- [ ] Add constructor SqlOrderRepository(IDbContext context)
- [ ] Verify IDbContext is registered in DI container
- [ ] Implement GetOrderById method
- [ ] Handle null order case with OrderNotFoundException
- [x] Create OrderNotFoundException class
- [ ] Register IOrderRepository in DI container
- [ ] Remove IDbContext _context field from OrderController
```
Execution order: deepest leaves first, working up level by level.
## Timeboxed Experimentation
10-minute timebox per attempt. If change can't be made in 10 min, it's too complex -- break down further.
- Success: commit, check off node, move to next
- Fail: revert, identify missing prerequisites, write subgoals
## Goal Definition
Convert technical goals to stakeholder-understandable business value:
- Correct: "Customer address is retrieved using the latest version of the third-party API for improved reliability"
- Incorrect: "Update third-party API to version X"
## Integration with TDD
- All Mikado execution steps maintain passing tests (green bar)
- Each leaf execution = one atomic commit with tests passing
- If any step breaks tests, revert immediately and reassess dependencies
- Baby steps rhythm: test-commit-integrate every small changeRelated Skills
nw-tdd-methodology
Deep knowledge for Outside-In TDD - double-loop architecture, ATDD integration, port-to-port testing, walking skeletons, and test doubles policy
nw-research-methodology
Research output templates, distillation workflow, and quality standards for evidence-driven research
nw-mikado
[EXPERIMENTAL] Complex refactoring roadmaps with visual tracking
nw-leanux-methodology
LeanUX backlog management methodology - user story template, story sizing, story states, task types, Definition of Ready/Done, anti-pattern detection and remediation
nw-five-whys-methodology
Toyota 5 Whys methodology with multi-causal branching, evidence requirements, and validation techniques
nw-discovery-methodology
Question-first approach to understanding user journeys. Load when starting a new journey design or when the discovery phase needs deepening.
nw-design-methodology
Apple LeanUX++ design workflow, journey schema, emotional arc patterns, and CLI UX patterns. Load when transitioning from discovery to visualization or when designing journey artifacts.
nw-bdd-methodology
BDD patterns for acceptance test design - Given-When-Then structure, scenario writing rules, pytest-bdd implementation, anti-patterns, and living documentation
nw-ux-web-patterns
Web UI design patterns for product owners. Load when designing web application interfaces, writing web-specific acceptance criteria, or evaluating responsive designs.
nw-ux-tui-patterns
Terminal UI and CLI design patterns for product owners. Load when designing command-line tools, interactive terminal applications, or writing CLI-specific acceptance criteria.
nw-ux-principles
Core UX principles for product owners. Load when evaluating interface designs, writing acceptance criteria with UX requirements, or reviewing wireframes and mockups.
nw-ux-emotional-design
Emotional design and delight patterns for product owners. Load when designing onboarding flows, empty states, first-run experiences, or evaluating the emotional quality of an interface.