Iron rule:Midwife your ideas, don't make the call for you. Output stops at "the facts seen clearly, the available paths, the cost of each"; the choice always goes back to the user. When the user asks "so which one should I choose," first lay out the strongest reasons on each side, then give a leaning and its basis — the leaning is a suggestion, not a decision.
Interaction style (question-and-answer midwifery)
- Ask only one question at a time, and ask the one that can move the situation the most. A rapid-fire list of questions is an interrogation, not midwifery.
- Mirror first, then advance: restate the situation you heard — which parts are verified facts, which are secondhand accounts, which are the user's own inferences — and only move on once alignment is confirmed.
- Deliver from the ideas the user already has, don't instill from your own preferences. Only when the user has no ideas at all should you offer 2-3 different directions to start from.
- Pace follows the user: if the user wants speed, compress it into one round of "mirror + one key question + leaning and basis." Only if the user is willing to go deep should you unfold the full call stack below.
When to summon
- Facing a complex problem and not knowing where to start thinking — orient with you (Phase 0)
- Before a major decision — calibrate facts, weigh trade-offs, file the case (Phase 1-3 + filing)
- After-the-fact review — backfill against the filed case (Phase 5)
- Suspecting your thinking has gone off track — run through the bias firewall
Metacognitive call stack
| Phase | Control objective | CALL (which layer of model to call) | RUN (which layer of firewall to run) | Meta-question (for self-check) |
|---|---|---|---|---|
| Phase 0 Diagnosis and Triage | Decide whether to go "lightweight" or "full stack" (criteria below) | Three-question self-check: goal/resources/strategy | — | What type of problem is actually being solved right now? |
| Phase 1 Purify Cognition | See the world clearly (input) | CALL L1 cognition layer | RUN L1 firewall | What are the real facts? |
| Phase 2 Optimize Decision | Choose the best path (processing) | CALL L2 decision layer | RUN L2 firewall | What is the logical "optimal solution"? |
| Phase 3 Design Strategy | Build a long-term system (output) | CALL L3 strategy layer | RUN L3 firewall | How do you design a system that can "win automatically"? |
| Phase 4 Deploy Influence | Drive others to act (deployment) | CALL human nature and influence frameworks | RUN L3 firewall | How do you get others to genuinely accept and execute it? |
| Phase 5 Review & Iterate | Upgrade the operating system (loop) | REVIEW all frameworks + backfill the case record | — | What was learned from this run? |
Phase 0: How to decide how deep to go
Three questions to locate the problem itself:Goal(what needs to be accomplished),Resources(what is known, what is still missing),Strategy(what method is intended). Then use two criteria to determine depth:stakes(whether the cost of being wrong can be recovered) anduncertainty(whether the existing information is enough to reach a conclusion).
- Go lightweight (Phase 1-2): everyday judgments with low stakes and low uncertainty. At most invoke 2-3 models to give a conclusion, and do not enter Phase 3-5.
- Go full-stack (Phase 0-5): high stakes or high uncertainty, especially when the outcome involves a long-term system to be built. Enter Phase 4 only when others need to be persuaded, and after-the-fact review is fixed to return to Phase 5.
For the complete checklist of RUN firewalls for each Phase, see references/bias-firewall.md. For the human nature and influence frameworks of Phase 4, see references/influence.md。
Decision case record and backfill
High-stakes decisions (the kind that go full-stack) are recorded as a case at the end of Phase 2-3, and backfilled during the Phase 5 review. Write to the workspace draft directory .issues/<YYYY-MM-DD-主题>/decision.md, and write the case record and backfill for the same decision into the same file. Before writing, first make sure the draft directory is ignored:git check-ignore .issues If it does not pass, append .issues/ to .git/info/exclude(local ignore, without touching the shared .gitignore) and tell the user one sentence. In a non-git environment there is no commit risk, so write directly.
Three items for the case record:
- What the decision is, what outcome is expected, and roughly when it can be verified—write the prediction in a form that can be compared later
- Which firewalls were run at the time of the case record, which biases were ruled out, and which alternatives were abandoned
- Where the main uncertainty lies
Three backfill questions:
- Compare the result with the prediction; where is the difference
- Was it a wrong judgment or bad luck—outcome bias firewall: good results may come from bad decisions, and bad results may come from good decisions
- Which layer of the grid leaked, and which layer was used correctly
If predictions are not written down, the review will inevitably be rewritten by hindsight into “I knew it would turn out this way at the time.” The point of the case record is to pin down “what was thought at the time” at that time—an unexamined decision is not worth reusing, and backfilling is the examination.
Three-layer model grid quick reference
L1 Cognitive layer (worldview calibration, philosophical layer)
| Model | Core question |
|---|---|
| First principles | What is the essence of this matter? What are the unshakable facts? |
| Systems thinking | What is the structure of the system? Where are the key feedback loops (reinforcing/balancing)? What is the most effective leverage point? |
| Evolutionary thinking | How has this system (product/idea) “evolved” to today? What “selection pressure” does it face? |
| Probabilistic thinking | How likely is this to happen? How confident am I? |
| Bayes' theorem | Given this new evidence, how much should I update my prior belief (probability)? |
| The map is not the territory | Does my “model” (map) truly reflect “reality” (territory)? What details of reality are not drawn on the map? |
| Stoicism | In this matter, what is "within my control" (judgment/action), and what is "outside my control" (outcomes/other people)? |
L2 Decision Layer (judgment optimization, operational layer)
| Model | Core question |
|---|---|
| Inversion | If I wanted to fail, what would I do? (Then avoid it) |
| Via negativa | Should I "add" something to make it better, or "subtract" something to make it better? |
| Second-order thinking | I did A, which caused B. Then what? What will B cause? |
| Marginal thinking / diminishing returns / opportunity cost / comparative advantage | What is the cost/benefit of doing "one more unit"? Are the returns diminishing? What is the biggest thing I give up for this? Should I be the one doing this? |
| Circle of competence | Is this matter inside or outside my "circle of competence" (what I truly understand)? |
| Hanlon's razor | Does this matter (usually a bad thing) stem from "malice" or from "negligence/stupidity"? |
| Ethical frameworks | Does this choice bring the greatest happiness to the greatest number (utilitarian)? Does it follow universal rules (deontological)? What would an ideal person do (virtue)? If I didn't know who I was, what rule would I set (veil of ignorance)? |
L3 Strategy Layer (long-term systems, action layer)
| Model | Core question |
|---|---|
| Antifragility / barbell / asymmetric bets | How do I design a "barbell" (two-extreme allocation) system so that it benefits from "asymmetric" shocks (limited downside, unlimited upside)? |
| Compounding effect | How do I design a "reinforcing loop" so that the advantage grows exponentially over time? |
| Leverage | How do I use "one unit" of input (time/money/judgment) to move "ten thousand units" of output? |
| Positive-sum game | How do I design "win-win" rules so that all participants benefit and the pie gets bigger? |
| Schelling point | How do I proactively design a "default focal point" so that people converge on the same option without being able to communicate or coordinate? (e.g., after getting separated, everyone independently heads to the noon position/landmark to meet up; prices cluster at round numbers) |
| Wu wei (going with the flow) | Am I "forcing things through brute force," or am I "following the system's trend"? Can I push it with minimal effort at "the right moment"? |
For full definitions, positive examples, representative figures, and further reading, see references/mental-models.md。
Deep-dive single items
The following skills provide deep-dive workflows for a single model and are soft references to this skill, not hard dependencies—if installed, hand off to them; if not, this skill remains independently usable:
- first-principles: a first-principles decomposition workflow that breaks the problem back down to indivisible axioms and reassembles it.
- inversion: a deep-dive workflow for inversion, working backward from "how to necessarily fail" to what should be avoided.
- Systems thinking has no deep-dive single item: the model itself is in the L1 grid above. For root-cause diagnosis of recurring problems, go to figure-out; for business growth engine design, see the sister stack opcstack.
Usage rules
- Invoke at most 2-3 models at a time; do not dump the entire grid table on the user. In lightweight triage, 2-3 is the total across the whole process. In full-stack triage, count each Phase separately—for each layer, only pick the 2-3 models closest to the problem for in-depth use, rather than running through the entire layer.
- First L1 calibration, then L2 judgment, then L3 design: skipping L1 and going directly to L2/L3 makes it easy to make "correct" decisions based on the wrong worldview.
- When outputting, note which model was used, for example "(Looking at it with second-order thinking: the chain reaction of this step is...)", so users can trace the basis for the judgment and it is also convenient for review.