modeling-thinking

name

modeling-thinking

description

Structured multi-model analysis for complex non-mathematical, non-programming problems. Use when the user explicitly asks to "model", "analyze with models", or "use modeling thinking". Also offer to use this skill (wait for confirmation) when encountering: complex decisions with many interacting factors, strategic planning, social or organizational dynamics, prediction problems in ambiguous domains, or any "what should I do?" that requires reasoning through system-level effects. Do NOT invoke for mathematical (e.g., "solve this equation") or programming tasks — those are already well-served without this skill. For borderline cases (e.g., a life decision that might not need modeling), ask the user first. Never invoke silently. If you think this skill applies, say: "This seems like a good candidate for structured modeling — want me to approach it that way?"

Language

All outputs — including model files, any files saved to disk, and communication with the user — must be written in the same language the user is using. If the user writes in Chinese, write in Chinese. If in English, write in English. Internal reasoning can be in any language, but everything saved to disk and shown to the user must match the user's language.

---

What this skill does

You build several independent models of the user's problem, reason through each rigorously, then converge on a single best answer. The process has two rounds:

Round 1: Build initial models → discover what information is missing → ask the user targeted questions Round 2: Incorporate the user's answers → refine models → give the final answer

The goal is not to "cover all perspectives." The goal is to find the model that most efficiently explains the problem and gives the user a concrete, actionable answer.

---

When to use sub-agents vs. sequential modeling

If you have sub-agent capability:

• Tell the user the default is 3 parallel modeling agents, and ask if they want more or fewer (range: 2–5)
• Spawn all modeling agents in parallel in Round 1, each assigned a distinct modeling lens
• Each agent saves its output as a Markdown file in a local session folder

If you don't have sub-agents:

• Plan N approaches (default 3) before starting any of them
• Execute one at a time, saving each to a Markdown file
• Synthesize after all are done

---

Step 1: Problem framing

Before picking model types, identify:

• The decision or question: What is the user trying to figure out?
• The key uncertainty: What's the thing they don't know that matters most?
• The relevant variables: What can change? What's fixed?
• The time horizon and stakes: Short-term vs. long-term? Reversible vs. irreversible?

Save a problem_framing.md to the session folder immediately. This becomes the shared reference across all models.

---

Step 2: Choose modeling lenses

Assign each modeling slot a distinct lens. Prioritize lenses that can be made mathematical or semi-formal, because formalization forces precision and reveals hidden assumptions.

Strongly prefer (in order):

1. Optimization / objective function (what is being maximized/minimized, under what constraints?)
2. Probabilistic / Bayesian (uncertain variables, priors, evidence updates)
3. Game theory / strategic interaction (players, incentives, equilibrium)
4. Dynamical systems / feedback loops (how variables change each other over time)
5. Causal DAG (what causes what, confounders, which levers actually work)
6. Expected value / decision tree (branches, probabilities, payoffs)
7. Network / graph (nodes, edges, flows)

Use qualitative models when necessary:

• Agent-based thinking (actors following local rules)
• Narrative / counterfactual (what would have to be true for outcome X?)

Each model should commit to one lens and build it out — not hedge between multiple frameworks.

---

Step 3: Round 1 — build initial models and save everything

For each model:

1. State the model explicitly: Write out variables, relationships, and assumptions. Write equations or probability distributions where possible.

2. Derive something non-obvious: Don't just describe — compute or reason forward. What does this model predict? What would have to be true for the opposite conclusion?

3. Identify critical missing information: After building the model, note which inputs or parameters you had to assume because you don't know them — and whether the conclusion would change if those assumptions were wrong. These are the "load-bearing unknowns."

4. Save to a Markdown file: model_1_<lens>.md in the session folder. Include: the model, key derivations, preliminary conclusion, blind spots, and most importantly — what you needed to assume that you wish you knew.

Save all work immediately as you go. Don't wait until the end. The files are working memory — if anything is lost, the reasoning can be reconstructed from them.

---

Step 4: Identify critical questions and ask the user

After all initial models are built, review the load-bearing unknowns across all models. Find the 2–4 questions whose answers would most change the conclusion — not questions you're merely curious about, but questions where the answer genuinely shifts which model wins or what the winning model recommends.

Surface these questions to the user clearly. Explain briefly why each question matters (one sentence each). Don't ask more than 4 questions — if you have more, prioritize by impact on the conclusion.

Save the questions to questions.md in the session folder before asking the user, so there's a record.

Example format:

在给出最终分析之前，有几个关键信息会显著影响结论，请帮我确认：

1. [问题] — 原因：如果[A]，结论偏向X；如果[B]，结论偏向Y。
2. [问题] — 原因：这直接影响[模型名]的核心参数估计。

---

Step 5: Round 2 — refine with new information and deliver final answer

Once the user answers, update the models. You don't need to rebuild from scratch — update the relevant parameters, re-run the key derivations, and note where the user's answers changed the model outputs vs. where they confirmed your original assumptions.

Save updates to model_<N>_<lens>_updated.md (or annotate the original files with a clearly marked "Update" section).

Then:

Select the best model using an MDL-inspired criterion: the best model is the one where (model complexity + residuals) is minimized. Intuitively:

• A model that explains most of what matters with few assumptions beats a complex model that explains slightly more
• "Residuals" = how much of the key dynamics does this model fail to account for?
• If the model's conclusion would reverse with a small change to its assumptions, that's high residual uncertainty
• Prefer models that make contact with the user's actual decision

Write the final answer to final_answer.md:

• Which model you chose and why it beats the others (MDL reasoning)
• A concrete conclusion or recommendation — not a hedge
• The most important thing the winning model still misses
• Written as a direct answer, not a literature review

---

File organization

modeling_session_<topic>/
├── problem_framing.md       ← saved immediately in Step 1
├── questions.md             ← saved before asking user in Step 4
├── model_1_<lens>.md        ← Round 1
├── model_2_<lens>.md
├── model_3_<lens>.md
├── model_1_<lens>_updated.md   ← Round 2 (or update sections in originals)
├── model_2_<lens>_updated.md
├── model_3_<lens>_updated.md
└── final_answer.md

Save aggressively. Every time you finish a model, write it to disk before moving to the next. Every time the user provides information, save the updated model before continuing. The files are the single source of truth — not your context window.

---

Tone and communication

• Be direct. Don't add complexity with hedged, both-sides language.
• When asking questions in Step 4, be specific — not "tell me more about the company" but "what percentage equity are you being offered, and has it been written into a formal offer?"
• When you pick a winning model, explain why in plain terms.
• The final answer should feel like a conclusion, not a literature review.