The Factory or The Workshop?

Michi has two operating modes. The factory is the full planning → session → debrief lifecycle — plan docs, verification scenarios, structured review. The workshop is the same discipline with less ceremony — surface assumptions, agree on a plan, verify, capture what you learned.

The distinction matters because not all work needs the full factory.

The workshop: everyday carry

A bug fix. A small feature. A quick investigation. A focused refactor. Work that fits in your head, where a formal plan doc and scenario co-design would cost more than the work itself.

The workshop (/michi-workshop) keeps the five Michi disciplines without the artifacts:

1. Surface assumptions — before acting, say what you’re assuming
2. Plan and agree — state what you’ll do, get a nod before starting
3. Verify before claiming done — how will you know? how will you prove it?
4. Capture decisions — what was decided, what were the alternatives
5. Know when to escalate — the hardest one

The plan might be three bullets in the conversation. The verification might be “run the test suite and show me it passes.” The capture might be a commit message. That’s fine. The discipline is in the questions, not the documents.

The factory: sustained work

Multiple milestones. Cross-cutting changes. Work that spans sessions, touches multiple packages, or needs verification beyond “tests pass.” Work where you need a durable record because the conversation won’t survive context compaction.

The factory (/michi-planning → /michi-session → /michi-debrief) adds:

• Plan docs that survive compaction and serve as implementation contracts
• Co-designed scenarios that define “done” before work begins
• Structured debrief that curates learnings into the right places
• Sustainability checks that catch drift between milestones

The overhead is real — and it earns its place when the work is large enough.

How to choose

Signal	Use the workshop	Use the factory
Can you hold the whole task in your head?	Yes	No
Will it take more than one session?	No	Probably
Does it touch multiple packages or systems?	No	Yes
Do you need verification beyond “tests pass”?	No	Yes
Will someone else review this work later?	Unlikely	Yes
Are there decisions that affect future work?	Minor ones	Significant ones

When in doubt, start with the workshop. If the work grows — scope expanding, decisions accumulating, verification getting complex — escalate to the factory. That transition is a feature, not a failure.

The escalation in practice

In one project, a session started with /michi-workshop to investigate porting a Python export tool to JavaScript. Simple question: “should it move to JS and add tests?” The investigation confirmed yes, the scope grew (new package, new tests, new CI), and the human initiated a transition: workshop → bootstrap → planning → session → debrief.

The workshop’s “know when to escalate” discipline is what makes this work. The skill explicitly asks: is the scope expanding beyond what you planned? Are you making decisions that affect things outside this task? If yes, flag it. The human decides whether to switch.

They share the same core

Both the factory and the workshop surface assumptions, verify before claiming done, and capture decisions. The factory adds structure around these habits; the workshop trusts you to maintain them without the structure.

The question isn’t “do I need discipline?” — you always do. The question is “do I need the artifacts that enforce it?”

For most daily work, the answer is no. For sustained, multi-milestone efforts, the answer is yes. The S-M-L-XL principle applies: match the process weight to the work weight.