hypotheticals-counterfactuals

$npx mdskill add lyndonkl/claude/hypotheticals-counterfactuals

Challenge assumptions by exploring alternative futures and stress testing decisions.

  • Helps users test 'what if' scenarios and identify hidden risks before acting.
  • Depends on user input defining focal questions and desired alternative outcomes.
  • Recommends specific counterfactuals based on the nature of the initial query.
  • Delivers structured progress tracking and actionable insights through a checklist.

SKILL.md

.github/skills/hypotheticals-counterfactualsView on GitHub ↗
---
name: hypotheticals-counterfactuals
description: Applies "what if" thinking to explore alternative scenarios, test assumptions, understand causal relationships, and prepare for uncertainty. Guides through counterfactual reasoning, scenario exploration, pre-mortem analysis, and stress testing decisions against alternative futures. Use when exploring alternative scenarios, testing assumptions through "what if" questions, understanding causal relationships, conducting pre-mortem analysis, stress testing decisions, or when user mentions counterfactuals, hypothetical scenarios, thought experiments, alternative futures, what-if analysis, or needs to challenge assumptions.
---
# Hypotheticals and Counterfactuals

## Table of Contents
- [Workflow](#workflow)
- [Common Patterns](#common-patterns)
- [Guardrails](#guardrails)
- [Quick Reference](#quick-reference)

## Workflow

Copy this checklist and track your progress:

```
Hypotheticals & Counterfactuals Progress:
- [ ] Step 1: Define the focal question
- [ ] Step 2: Generate counterfactuals or scenarios
- [ ] Step 3: Develop each scenario
- [ ] Step 4: Identify implications and insights
- [ ] Step 5: Extract actions or decisions
- [ ] Step 6: Monitor and update
```

**Step 1: Define the focal question**

What are you exploring? Past decision (counterfactual)? Future possibility (hypothetical)? Assumption to test? See [resources/template.md](resources/template.md#focal-question-template).

**Step 2: Generate counterfactuals or scenarios**

Counterfactual: Change one key factor, ask "what would have happened?" Hypothetical: Imagine future scenarios (2-4 plausible alternatives). See [resources/template.md](resources/template.md#scenario-generation-template) and [resources/methodology.md](resources/methodology.md#1-counterfactual-reasoning).

**Step 3: Develop each scenario**

Describe what's different, trace implications, identify key assumptions. Make it vivid and concrete. See [resources/template.md](resources/template.md#scenario-development-template) and [resources/methodology.md](resources/methodology.md#2-scenario-planning-techniques).

**Step 4: Identify implications and insights**

What does each scenario teach? What assumptions are tested? What risks revealed? See [resources/methodology.md](resources/methodology.md#3-extracting-insights-from-scenarios).

**Step 5: Extract actions or decisions**

What should we do differently based on these scenarios? Hedge against downside? Prepare for upside? See [resources/template.md](resources/template.md#action-extraction-template).

**Step 6: Monitor and update**

Track which scenario is unfolding. Update plans as reality diverges from expectations. See [resources/methodology.md](resources/methodology.md#4-monitoring-and-adaptation).

Validate using [resources/evaluators/rubric_hypotheticals_counterfactuals.json](resources/evaluators/rubric_hypotheticals_counterfactuals.json). **Minimum standard**: Average score ≥ 3.5.

## Common Patterns

**Pattern 1: Pre-Mortem (Prospective Hindsight)**
- **Format**: Imagine it's future date, project failed. List reasons why.
- **Best for**: Project planning, risk identification before launch
- **Process**: (1) Set future date, (2) Assume failure, (3) List causes, (4) Prioritize top 3-5 risks, (5) Mitigate now
- **When**: Before major launch, strategic decision, resource commitment
- **Output**: Risk list with mitigations

**Pattern 2: Counterfactual Causal Analysis**
- **Format**: "What would have happened if we had done X instead of Y?"
- **Best for**: Learning from past decisions, understanding what mattered
- **Process**: (1) Identify decision, (2) Imagine alternative, (3) Trace different outcome, (4) Identify causal factor
- **When**: Post-mortem, retrospective, learning from success/failure
- **Output**: Causal insight (X caused Y because...)

**Pattern 3: Three Scenarios (Optimistic, Baseline, Pessimistic)**
- **Format**: Describe best case, expected case, worst case futures
- **Best for**: Strategic planning, forecasting, resource allocation
- **Process**: (1) Define time horizon, (2) Describe three futures, (3) Assign probabilities, (4) Plan for each
- **When**: Annual planning, market uncertainty, investment decisions
- **Output**: Three detailed scenarios with implications

**Pattern 4: 2×2 Scenario Matrix**
- **Format**: Two key uncertainties create four quadrants (scenarios)
- **Best for**: Exploring interaction of two critical unknowns
- **Process**: (1) Identify two key uncertainties, (2) Define extremes, (3) Develop four scenarios, (4) Name each world
- **When**: Strategic planning with multiple drivers of uncertainty
- **Output**: Four distinct future worlds with narratives

**Pattern 5: Assumption Reversal**
- **Format**: "What if our key assumption is backwards?"
- **Best for**: Challenging mental models, unlocking innovation
- **Process**: (1) List key assumptions, (2) Reverse each, (3) Explore implications, (4) Identify if reversal plausible
- **When**: Stuck in conventional thinking, need breakthrough
- **Output**: New perspectives, potential pivots

**Pattern 6: Stress Test (Extreme Scenarios)**
- **Format**: Push key variables to extremes, test if decision holds
- **Best for**: Risk management, decision robustness testing
- **Process**: (1) Identify decision, (2) List key variables, (3) Set to extremes, (4) Check if decision still valid
- **When**: High-stakes decisions, need to ensure resilience
- **Output**: Decision validation or hedges needed

## Guardrails

**Key requirements:**

1. **Plausibility constraint**: Scenarios must be possible, not just imaginable. "What if gravity reversed?" is not useful counterfactual. Stay within bounds of plausibility given current knowledge.

2. **Minimal rewrite principle** (counterfactuals): Change as little as possible. "What if we had chosen Y instead of X?" not "What if we had chosen Y and market doubled and competitor failed?" Isolate causal factor.

3. **Avoid hindsight bias**: Pre-mortem assumes failure, but don't just list things that went wrong in similar past failures. Generate new failure modes specific to this context.

4. **Specify mechanism**: Don't just state outcome ("sales would be higher"), explain HOW ("sales would be higher because lower price → higher conversion → more customers despite lower margin").

5. **Assign probabilities** (scenarios): Don't treat all scenarios as equally likely. Estimate rough probabilities (e.g., 60% baseline, 25% pessimistic, 15% optimistic). Avoids equal-weight fallacy.

6. **Time horizon clarity**: Specify WHEN in future. "Product fails" is vague. "In 6 months, adoption <1000 users" is concrete. Enables tracking.

7. **Extract actions, not just stories**: Scenarios are useless without implications. Always end with "so what should we do?" Prepare, hedge, pivot, or double-down.

8. **Update scenarios**: Reality evolves. Quarterly review: which scenario is unfolding? Update probabilities and plans accordingly.

**Common pitfalls:**

- ❌ **Confusing counterfactual with fantasy**: "What if we had $100M funding from start?" vs. realistic "What if we had raised $2M seed instead of $1M?"
- ❌ **Too many scenarios**: 10 scenarios = analysis paralysis. Stick to 2-4 meaningful, distinct futures.
- ❌ **Scenarios too similar**: Three scenarios that differ only in magnitude (10% growth, 15% growth, 20% growth). Need qualitatively different worlds.
- ❌ **No causal mechanism**: "Sales would be 2× higher" without explaining why. Must specify how change leads to outcome.
- ❌ **Hindsight bias in pre-mortem**: Just listing past failures. Need to imagine new, context-specific risks.
- ❌ **Ignoring low-probability, high-impact**: "Black swan won't happen" until it does. Include tail risks.

## Quick Reference

**Counterfactual vs. Hypothetical:**

| Type | Direction | Question | Purpose | Example |
|------|-----------|----------|---------|---------|
| **Counterfactual** | Backward (past) | "What would have happened if...?" | Understand causality, learn from past | "What if we had launched in EU first?" |
| **Hypothetical** | Forward (future) | "What could happen if...?" | Explore futures, prepare for uncertainty | "What if competitor launches free tier?" |

**Scenario types:**

| Type | # Scenarios | Structure | Best For |
|------|-------------|-----------|----------|
| **Three scenarios** | 3 | Optimistic, Baseline, Pessimistic | General forecasting, strategic planning |
| **2×2 matrix** | 4 | Two uncertainties create quadrants | Exploring interaction of two drivers |
| **Cone of uncertainty** | Continuous | Range widens over time | Long-term planning (5-10 years) |
| **Pre-mortem** | 1 | Imagine failure, list causes | Risk identification before launch |
| **Stress test** | 2-4 | Extreme scenarios (best/worst) | Decision robustness testing |

**Pre-mortem process** (6 steps):

1. **Set future date**: "It's 6 months from now..."
2. **Assume failure**: "...the project has failed completely."
3. **Individual brainstorm**: Each person writes 3-5 reasons (5 min, silent)
4. **Share and consolidate**: Round-robin sharing, group similar items
5. **Vote on top risks**: Dot voting or force-rank top 5 causes
6. **Mitigate now**: For each top risk, assign owner and mitigation action

**2×2 Scenario Matrix** (example):

**Uncertainties**: (1) Market adoption rate, (2) Regulatory environment

|                     | Slow Adoption | Fast Adoption |
|---------------------|---------------|---------------|
| **Strict Regulation** | "Constrained Growth" | "Regulated Scale" |
| **Loose Regulation** | "Patient Build" | "Wild West Growth" |

**Assumption reversal questions:**

- "What if our biggest advantage is actually a liability?"
- "What if the problem we're solving isn't the real problem?"
- "What if our target customer is wrong?"
- "What if cheaper/slower is better than premium/fast?"
- "What if we're too early/too late, not right on time?"

**Inputs required:**
- **Focal decision or event**: What are you analyzing?
- **Key uncertainties**: What factors most shape outcomes?
- **Time horizon**: How far into future/past?
- **Constraints**: What must remain fixed vs. what can vary?
- **Stakeholders**: Who should contribute scenarios?

**Outputs produced:**
- `counterfactual-analysis.md`: Alternative history analysis with causal insights
- `pre-mortem-risks.md`: List of potential failure modes and mitigations
- `scenarios.md`: 2-4 future scenarios with narratives and implications
- `action-plan.md`: Decisions and preparations based on scenario insights

More from lyndonkl/claude

SkillDescription
abstraction-concrete-examplesBuilds structured abstraction ladders that translate high-level principles into concrete, actionable examples across 3-5 levels. Bridges communication gaps, reveals hidden assumptions, and tests whether abstract ideas work in practice. Use when explaining concepts at different expertise levels, moving between abstract principles and concrete implementation, identifying edge cases by testing ideas against scenarios, designing layered documentation, decomposing complex problems into actionable steps, or bridging strategy-execution gaps.
academic-letter-architectGuides the creation of evidence-based academic recommendation letters, reference letters, and award nominations that combine concrete examples, meaningful comparisons, and genuine enthusiasm. Use when writing recommendation letters for students, postdocs, or colleagues, or when user mentions recommendation letter, reference, nomination, letter of support, endorsement, or needs help with strong advocacy and comparative statements.
adr-architectureDocuments significant architectural and technical decisions with full context, alternatives considered, trade-offs analyzed, and consequences understood. Creates a decision trail that helps teams understand why decisions were made. Use when choosing between technology options, making infrastructure decisions, establishing standards, migrating systems, or when user mentions ADR, architecture decision, technical decision record, or decision documentation.
adverse-selection-priorProduces a Bayesian prior probability that an offered transaction is +EV for the recipient, given that the counterparty chose to propose it. Applies Akerlof market-for-lemons logic -- if they offered it, they believe it is +EV for them, so the prior that it is +EV for us is materially below 50%. Reusable across trade evaluation, waiver drops (another team dropping a player is also adverse selection), job-offer analysis, M&A, and any "someone offered me this" situation. Use when you receive an unsolicited trade/offer/proposal, analyzing incoming trade prior, evaluating why a counterparty proposed a deal, or when user mentions adverse selection, market for lemons, why did they offer this, incoming trade prior, they proposed it, Bayesian adjustment on received offer.
alignment-values-north-starCreates actionable alignment frameworks that give teams a shared North Star (direction), values (guardrails), and decision tenets (behavioral standards). Enables autonomous decision-making while maintaining organizational coherence. Use when starting new teams, scaling organizations, defining culture, establishing product vision, resolving misalignment, creating strategic clarity, or when user mentions North Star, team values, mission, principles, guardrails, decision framework, or cultural alignment.
analogy-weight-checkFor every analogy in a substacker draft, verifies it carries mechanical weight — the analogy does real work explaining the mechanism, not merely decorates it. Cross-references analogy-catalog.md for novelty (is this analogy reused from a prior post?) and domain fit (biology > organizational > sports preferred; physics/military disfavored). Use whenever an analogy appears in the draft. Trigger keywords: analogy weight, decorative, mechanical weight, reused analogy, catalog check, metaphor check.
answer-uncomfortable-questionTakes one strategic question about substacker ("should we launch paid?", "is this section dead?", "are we writing for the wrong audience?") and produces the mandatory evidence + reasoning + downside triad plus a recommendation. Used 3 times per Growth Strategist review. Trigger keywords: uncomfortable question, strategic question, evidence reasoning downside, triad.
attribute-performanceFor each substacker post that materially over- or under-performs the rolling baseline (|z| ≥ 1.0), produces a plain-English attribution paragraph with calibrated confidence (high / medium / low / unexplained). Considers subject-line effect, topic zeitgeist, external share, day-of-week, length effect, and audience-notes signals. Labels unexplained outliers explicitly rather than fabricating a story. Use after compute-baseline when outlier posts exist. Trigger keywords: attribution, why did this post work, outlier explanation, performance analysis.
auction-first-price-shadingComputes the optimal shaded bid for a first-price sealed-bid auction given a true private value, an estimate of the number of competing bidders N, and a value-distribution assumption. Implements the `(N-1)/N` equilibrium shading rule for uniform private values, adjusts for log-normal or empirical value distributions, layers a risk-aversion adjustment, and caps output against the bidder's remaining budget. Domain-neutral auction theory reusable across fantasy sports (baseball FAAB, NBA/NHL waiver auctions), prediction-market limit sizing, sealed procurement bids, and any blind-bid context. Use when user mentions "first-price auction bid", "sealed bid shading", "(N-1)/N", "FAAB bid amount", "auction shading", "optimal bid first-price", "bid for sealed-bid", "blind bid sizing", or when downstream logic needs a principled shade factor rather than an ad-hoc heuristic.
auction-winners-curse-haircutApplies a Bayesian haircut to a bid valuation for common-value auctions where winning is itself evidence the bidder over-estimated. Takes a raw valuation, a value-type classification (common_value / private_value / mixed), the number of informed bidders N, and a signal-dispersion estimate, and returns an adjusted valuation. Domain-neutral and reusable across fantasy FAAB, prediction markets, M&A bids, ad-auction budgets, and any generic bidding context. Use when user mentions "winner's curse", "common value auction", "valuation haircut", "adverse valuation", "Bayesian bid adjustment", or "over-paying in auction".