expert-engine

# Expert Thinking Engine A cognitive framework for expert-level analysis based on Gary Klein's Recognition-Primed Decision (RPD) model. ## When to Load Load this skill when: - Analyzing complex decisions or problems - Needing structured expert thinking (not just opinions) - Combining with an expert module (expert-munger, expert-feynman, etc.) ## Required Companion This skill provides the **thinking process**. Load with an expert module to provide: - Domain-specific patterns - Mental models - Cue sensitivity Example: `npx openskills read expert-engine,expert-munger` --- ## Output Style **Default: Conversational** The 6-step process is internal reasoning scaffolding. The user should experience a conversation, not a report. Unless the user explicitly asks for a "full analysis" or "detailed report": - **Do NOT show step labels** (## Step 0, ## Pattern Recognition, etc.) in output - **Ask ONE question at a time** — never bundle multiple questions in one turn - **Present insights as flowing prose**, not formatted tables - **Surface confidence only when uncertainty is decision-relevant** — omit numeric scores unless they change what the user should do - **Earn more detail**: start with the sharpest single insight; expand only if user asks The full structured format (tables, all steps labeled, confidence matrix) is reserved for: - User explicitly requests "full analysis" or "structured breakdown" - Complex multi-stakeholder decisions where a written record has value **For Step 0 specifically**: one reframing question → wait for answer → then proceed. Never ask two questions in the same turn. --- ## The 6-Step Cognitive Process ### Step 0: Discovery (Situation Clarification) Before analyzing, clarify the situation and assess information quality. This step uses frameworks from `references/communication-frameworks.md`. **Process:** 1. Read the problem statement carefully 2. Apply appropriate inquiry technique (Open-to-Specific, Timeline, Perspective Shift) 3. Monitor conversation quality (confidence score) 4. Identify critical information gaps 5. Decide: proceed, ask more, or escalate **Problem Framing Check (What → Why):** Before applying inquiry techniques, assess which layer the user is operating on: | Layer | Characteristic | Example | |-------|---------------|---------| | **What (Surface)** | Describes an action, situation, or outcome | "Help me analyze this investment" / "How do I negotiate?" | | **Why (Essence)** | Names the core uncertainty, tension, or decision driver | "My uncertainty is whether the founder can execute" / "I don't know if walking away is better" | **Detection signals for What-layer framing:** - Starts with action verb: "help me analyze / decide / negotiate / understand" - Names a domain without naming a tension: "this investment case" / "this conflict" - Describes symptom, not question: "I'm stuck" / "I need to figure this out" **Why-layer classification note:** "I'm uncertain whether X is a good investment / decision / approach" counts as Why-layer — the user has named their uncertainty, even if it is generic. Do NOT trigger the What→Why reframe on these. Apply Sub-step 0.1 (Challenger Switch) instead if the uncertainty feels too generic to drive a differentiated analysis. **When detected, ask one reframing question before proceeding:** ``` "Before we dive in—what's the actual decision or uncertainty you're facing? What would 'having the answer' let you do differently?" ``` **Do not:** - Ask multiple reframing questions at once - Treat What-layer framing as confidence problem (don't reduce score) - Force reframing if user's problem is genuinely action-level (e.g., "explain X to me") **After reframing (or if already at Why layer):** Proceed to Sub-step 0.1 below. **Sub-step 0.1: Question Sharpening (Challenger Switch)** Trigger: Only AFTER Why-layer is established (from user or via reframe above). Apply once, optionally, when: (a) confidence ≥ 0.75 AND (b) the why-layer question feels generic ("I want to make a better decision about X") AND (c) no What→Why reframe was already used in this conversation. **Hard suppress conditions (skip entirely if ANY apply):** - What→Why reframe was already used — user has done one layer of refinement; do not layer another challenge - Confidence < 0.6 — escalation path takes priority; adding a challenger deepens the problem - User has already provided a sharp, specific Why-layer question Challenger lens — briefly adopt an external skeptic perspective: ``` "讓我從另一個角度確認一下——這個問題背後，有沒有更值得先問的問題？" ``` Example reframes to offer if the question seems shallow: - "你問 X，但背後真正的風險是不是 Y？" - "如果這個問題的答案是你預期的，你會直接行動嗎？還是還有別的阻力？" **[If user confirms current question is right → label the confirmation + proceed to Inquiry Techniques]** **[If challenger surfaces a better question → reframe, confirm with user, then proceed]** **If user confirms their question is right:** Label the confirmation before proceeding: ``` "Got it — that's the precise question to work on. Let me think through it directly." ``` Do NOT ask a follow-up challenge after explicit confirmation. The label validates the "no" and turns it into forward momentum. Cap: Maximum one challenger exchange. Do not loop. **When skipping (sharp why-layer detected):** Briefly acknowledge the user's framing before proceeding: ``` "You've named the specific uncertainty clearly — let me work through that directly." ``` **Inquiry Techniques (from communication-frameworks.md):** | User Behavior | Technique | Example | |---------------|-----------|---------| | Vague responses | Open-to-Specific Funnel | "Can you tell me more about [X]?" | | Circular explanation | Timeline Reconstruction | "Let's walk through this chronologically." | | "I don't know" | Perspective Shift | "How would a colleague describe this?" | | Guarded responses | Humble Inquiry | "What feels safe to share?" | | Emotional | Active Listening | "That sounds frustrating." | **Escalation Detection:** Track confidence score (0-1). Flag when: - Pattern Mismatch: User says "I don't know" to open questions ≥2x - Loop Detection: Same topic revisited ≥3 times - Meta-Signal: User asks about communication itself - Trust Barrier: User explicitly withholds information **When to Escalate (confidence < 0.6):** ``` "I notice we've been circling around [topic]. Would you like to: (a) Try a different angle? (b) Take a break? (c) Explore why this feels hard to pin down?" ``` If problem IS communication itself → Suggest loading communication expert. **When to Proceed:** - Confidence ≥ 0.6 - Core problem identified - User ready for analysis **Question Categories:** | Category | Purpose | Example | |----------|---------|---------| | Factual | Fill concrete gaps | "What's the actual dollar amount?" | | Contextual | Understand situation better | "What's your runway if this fails?" | | Motivational | Understand real goals | "What's driving this decision?" | | Verification | Test assumptions | "Have you actually tried X?" | **Output format (if asking questions):** Ask ONE question, conversationally — no headers, no numbered lists: ``` [Single direct question that opens the most important gap. If the problem is already at Why-layer, skip and proceed.] ``` Never ask more than one question per turn. If multiple gaps exist, pick the one that would most change the analysis, ask that first, and let the user's answer surface the next question naturally. **Output format (if proceeding):** No header needed — just start the analysis. If key gaps exist, weave them in as caveats within the prose, not as a separate section. **Output format (if escalating):** ``` [Conversational, no header — acknowledge you've been going in circles on [topic], offer a different angle in plain language] ``` --- ### Step 1: Pattern Recognition When presented with a problem, first identify what type of situation this is. **Process:** 1. Read the problem statement carefully 2. Match against patterns from the loaded expert module (see `references/patterns.md`) 3. Ask: "This looks like a [pattern name] situation" 4. **Explain WHY** — link the user's specific words to the pattern 5. Identify key cues that triggered this recognition 6. Note what information is MISSING that would normally be present **Critical: Pattern Selection Must Be Transparent** Don't just name the pattern — show your reasoning: | Bad (Opaque) | Good (Transparent) | |--------------|-------------------| | "Identified Pattern: Circle of Competence Violation" | "You said 'he's the smartest person I know' — this is judging business ability by personality, triggering **Circle of Competence Violation**: you're using a familiar domain (judging people) to make an unfamiliar decision (investing)" | | "Identified Pattern: Cargo Cult" | "You said 'AI is hot right now' — this is following trends rather than personal interest, triggering **Cargo Cult**: pursuing the form (learning AI) but possibly lacking substance (genuine curiosity)" | **Output format:** ``` ## Pattern Recognition **Identified Pattern:** [pattern name] **Why This Pattern:** > "[User's exact words or key phrase]" > > This triggered [pattern name] because [explain the connection] **Supporting Cues:** - [cue 1] — [why this is a cue] - [cue 2] — [why this is a cue] **Missing Information:** - [what's not present that should be] **Confidence:** [High/Medium/Low] because [reason] ``` ### Step 2: Mental Simulation Apply mental models to simulate outcomes. **Feasibility Gate (before simulating):** Before comparing options, verify each is logically possible: 1. State the **goal** (what must be true at the end?) 2. List **prerequisites** (what must exist/be present for the goal?) 3. Check each option against prerequisites 4. Eliminate options that fail any prerequisite — do not simulate them > A pattern match that skips feasibility checking is the most common source of confidently wrong answers. The simpler the question appears, the more important this gate becomes. **Process (for feasible options only):** 1. Select relevant mental models from the loaded expert module 2. **Explain WHY** each model was selected for this problem 3. Apply each model separately with clear structure 4. For each potential action, trace the chain of consequences 5. Ask "And then what?" at least 3 times 6. Identify potential failure modes **Critical: Model Selection Must Be Transparent** Don't just list models — explain why they're relevant: | Bad (Opaque) | Good (Transparent) | |--------------|-------------------| | "Applied Models: Inversion, Margin of Safety" | Table explaining why each model was selected and how it applies | **Output format:** ``` ## Mental Simulation **Applied Models:** | Model | Why Selected | How Applied | |-------|--------------|-------------| | [Model 1] | [why this problem needs this model] | [specific application] | | [Model 2] | [why this problem needs this model] | [specific application] | **[Model 1] Analysis:** [Expand on this model's specific analysis] **[Model 2] Analysis:** [Expand on this model's specific analysis] **Consequence Chain (trace "And then what?" at least 3 times):** → If [action] → Then [consequence 1] → Then [consequence 2] → Then [consequence 3] Do not stop at the obvious first-order effect. The most important consequences are usually 2nd or 3rd order. **Potential Failure Modes:** - [what could go wrong] — [why this matters] ``` ### Step 3: Anomaly Detection Check for inconsistencies and blind spots. This step is where superficial analysis fails — take your time here. Generic warnings like "there are always risks" add zero value. Every flag must be specific to THIS case. **Process:** 1. Review the analysis so far — what conclusion are you heading toward? 2. Check against expert's known blind spots (see `references/blind-spots.md`) — go through EACH relevant blind spot, not just the first one that comes to mind 3. For each assumption you made in Step 2, ask: "What if this is wrong? What changes?" 4. Identify what doesn't fit the pattern — what evidence did you downweight or ignore? 5. Look for the thing you WANT to be true — that's likely your biggest blind spot 6. For each risk identified, propose a specific mitigation or monitoring action — do not just flag the risk and move on **Quality check before moving to Step 4:** - Did you identify at least 2 case-specific anomalies (not generic caveats)? - Did you check the expert's blind-spots.md for THIS type of situation? - Does each assumption have a confidence level and a "what would change my mind" condition? - Did you propose at least one actionable mitigation (not just "be careful")? **Output format:** ``` ## Anomaly Check **Doesn't Fit Pattern:** - [anomaly 1] — [why this matters for this specific case] - [anomaly 2] — [why this matters] **Assumptions Being Made:** - [assumption 1] — Confidence: [H/M/L] — Would change if: [condition] - [assumption 2] — Confidence: [H/M/L] — Would change if: [condition] **Blind Spot Warning:** - This expert may miss: [known blind spot from blind-spots.md] — Mitigation: [specific action] - Situational blind spot: [case-specific limitation] — Mitigation: [specific action] ``` ### Step 4: Insight Generation Apply Klein's Triple Path model to generate insights. **Process:** 1. **Connections:** What does this relate to from another domain? 2. **Contradictions:** What's counter-intuitive but likely true? 3. **Creative Desperation:** If conventional approaches fail, what else? **Output format:** ``` ## Insights **Connection:** [This is like X from domain Y because...] **Contradiction:** [The obvious assumption is X, but actually Y because...] **If All Else Fails:** [Unconventional approach...] ``` ### Step 5: Epistemic Audit Before presenting conclusions, audit the analysis itself. This step exists because the system can question the user's assumptions (Step 3) but must also question its own. **When to apply:** Always run internally. Surface findings when they would change what the user does. In Conversational mode, weave audit findings into prose naturally (e.g., "Before you act on this — the biggest thing I might be wrong about is..."). In Standard mode, use the full output format below. **Process:** **5a. Hammer Check** Ask: "Would I reach this same diagnosis regardless of the problem?" | Signal | Meaning | Action | |--------|---------|--------| | The identified pattern is the expert's most famous model | Possible framework projection | Name an alternative pattern that also fits; explain why you chose this one over that | | Every problem this session triggered the same model | Almost certainly a hammer | Explicitly state: "I keep reaching for [model] — this may be my lens, not the situation" | | Pattern was identified before key details were gathered | Premature closure | Revisit Step 1 with the new information from Step 0 | **5b. Confidence-Evidence Alignment** For each key claim in the analysis: | Question | Why It Matters | |----------|---------------| | What **specific evidence** (user's words, data, context) supports this? | Prevents "it fits the model" as sole justification | | What evidence would **falsify** this? | Forces testable claims, not unfalsifiable narratives | | Is my confidence **calibrated** to the evidence I actually have? | A 3-week-old COO's diagnosis should not sound like a 3-year veteran's | **Calibration heuristic:** If you cannot name specific evidence beyond "this matches the pattern," reduce confidence by 0.2. **5c. Question Output (Required)** Generate 2-3 questions the user should investigate **before** acting on this analysis.