| name | think |
| description | Use when the user wants real-world experience turned into a methodology, skill, or process — 'turn this into a methodology', 'systematize my approach', 'make this into a skill', or after stv:explore / completed work when raw practice should become reusable structure. Bottom-up inductive distillation, not top-down theory. |
Inductive Distillation
A methodology design process that starts from experience and extracts minimal structure.
Core principle: Strip away the unnecessary from what worked. Do not fill in from theory.
Process
1. Start from Real-World Experience
First, secure experiences where the user actually succeeded (even 2-3 lines).
The raw material is "I did this and it worked", not "theoretically it should be this way."
If there are multiple experiences, lay them side by side and extract the common structure.
2. Pattern Recognition
Extract common principles across experiences.
Is only the direction different? Only the scale? Only the domain? — Find the invariant, not the differences.
3. Draft with Minimal Structure
The most important thing in the first structuring pass is not overdoing it.
If the experience succeeded in 2-3 lines, creating a 200-line process document is over-engineering.
Distinguish between what a sufficiently smart executor (human or AI) needs as just a direction hint versus what requires enforced procedure.
4. Line-by-Line Real-World Simulation
Simulate each sentence of the draft as "If I give this to an executor, how will they actually behave?"
- "Follow the code" → they jump around arbitrarily → "Follow the callstack one step at a time, specifying filename:line number"
- "Explore all branches" → they do it mentally and skip some → "Write it down as you explore. What isn't written wasn't explored."
If an ambiguous instruction causes wrong behavior, add a constraint. If a constraint is excessive, remove it.
5. Back-Calculate Missing Pieces from Experience
Fill in with "when we actually tried it, omitting this caused failure."
Add inductively ("this failed without it in practice"), not deductively ("logically this should also be needed").
6. Anchor Identity with a Name
A good name makes what the methodology actually does sharp and clear in one word.
Metaphors (Blackbox, Dead Reckoning) have stronger identity than functional descriptions (A* Debug).
If the name doesn't match the content, the name isn't wrong — the content definition is still fuzzy.
Over-Engineering Checklist
After structuring, verify the following:
If any of these apply, cut it down. Minimal structure is optimal.
