FAQ
Isn’t this overkill for a bug fix?
Section titled “Isn’t this overkill for a bug fix?”Michi scales. The michi-workshop skill is five minutes of discipline for a bug fix — surface your assumptions, verify before claiming done, capture what you learned. The full planning → session → debrief lifecycle is for multi-milestone epics. Pick the weight that fits the work. This is the S-M-L-XL principle: small work gets small process, large work gets large process.
What if I don’t use Claude Code?
Section titled “What if I don’t use Claude Code?”The principles — iteration cycles, verification layers, plan docs, progressive trust — are tool-agnostic. Any agent-assisted workflow benefits from asking “how will we verify this?” before writing code.
The skills (slash commands) are Claude Code-specific. If you use a different tool, the principles travel; the skills don’t. Yet. The methodology could be adapted for other agents, but I haven’t done that work.
How is this different from just having a good CLAUDE.md?
Section titled “How is this different from just having a good CLAUDE.md?”CLAUDE.md provides rules. Michi provides process.
A good CLAUDE.md tells the agent your conventions and preferences. Michi adds: structured planning that surfaces assumptions before code gets written, rigid execution with verification gates, knowledge capture that compounds across sessions, and a debrief that improves the next iteration. Rules without enforcement degrade. Michi enforces through structure.
Does this work for teams?
Section titled “Does this work for teams?”Michi is designed for an individual practitioner working with a Claude Code agent. The principles and documentation structure would generalize to teams, but coordination patterns (multiple agents, shared state, review workflows) are future work. If you’re looking for team-scale AI coding practices, this isn’t there yet.
Is this only for code?
Section titled “Is this only for code?”No. Michi has been used for code (building a CLI tool, API services, web components), knowledge work (analyzing 1,350 documents for a personal knowledge base), infrastructure planning (Kubernetes deployment on Oracle Cloud), and project evaluation (assessing Notion database structures). The same discipline — surface assumptions, plan before acting, verify outcomes, capture learnings — applies regardless of whether the deliverable is code or a document.
The michi-explore skill is the primary non-code tool. michi-session supports non-code targets with a different core loop (Explore → Synthesize → Checkpoint instead of Implement → Test → Repeat).
What languages and stacks does this support?
Section titled “What languages and stacks does this support?”Michi is stack-agnostic at the process level. It’s been tested primarily on JavaScript/Node.js/React projects, but nothing in the methodology is language-specific. The verification approach adapts per project type — a REST API is more automatable than a mobile app.
How mature is this?
Section titled “How mature is this?”Pre-1.0. Built from one major experiment, refined through several real projects. The principles are solid — they’ve survived multiple codebases and project types. The tooling is still being refined. The verification approach (the hardest part) is designed but not fully battle-tested at layers 3-4.
I’ll be honest about what’s unsolved rather than pretend everything is polished.
I already use superpowers. Should I switch?
Section titled “I already use superpowers. Should I switch?”Not necessarily. Superpowers is excellent — well-designed, battle-tested, and covers a lot of the same ground. I used it before building Michi and would still recommend it as a starting point.
Michi grew out of wanting more structure around verification, documentation, and the iteration cycle across sessions. If superpowers gives you what you need, keep using it. If you find yourself wanting more process around verification, planning, and knowledge capture, Michi might fill those gaps. Some people use both.