nw-mikado-method

Enhanced Mikado Method for complex architectural refactoring - systematic dependency discovery, tree-based planning, and bottom-up execution

322 stars

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

$curl -o ~/.claude/skills/nw-mikado-method/SKILL.md --create-dirs "https://raw.githubusercontent.com/nWave-ai/nWave/main/nWave/skills/nw-mikado-method/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/nw-mikado-method/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How nw-mikado-method Compares

Feature / Agentnw-mikado-methodStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/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 change

Related Skills

nw-tdd-methodology

322
from nWave-ai/nWave

Deep knowledge for Outside-In TDD - double-loop architecture, ATDD integration, port-to-port testing, walking skeletons, and test doubles policy

nw-research-methodology

322
from nWave-ai/nWave

Research output templates, distillation workflow, and quality standards for evidence-driven research

nw-mikado

322
from nWave-ai/nWave

[EXPERIMENTAL] Complex refactoring roadmaps with visual tracking

nw-leanux-methodology

322
from nWave-ai/nWave

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

322
from nWave-ai/nWave

Toyota 5 Whys methodology with multi-causal branching, evidence requirements, and validation techniques

nw-discovery-methodology

322
from nWave-ai/nWave

Question-first approach to understanding user journeys. Load when starting a new journey design or when the discovery phase needs deepening.

nw-design-methodology

322
from nWave-ai/nWave

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

322
from nWave-ai/nWave

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

322
from nWave-ai/nWave

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

322
from nWave-ai/nWave

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

322
from nWave-ai/nWave

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

322
from nWave-ai/nWave

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.