skills/hypotheticals-counterfactuals/SKILL.md
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.
npx skillsauth add lyndonkl/claude hypotheticals-counterfactualsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
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 and resources/methodology.md.
Step 3: Develop each scenario
Describe what's different, trace implications, identify key assumptions. Make it vivid and concrete. See resources/template.md and resources/methodology.md.
Step 4: Identify implications and insights
What does each scenario teach? What assumptions are tested? What risks revealed? See resources/methodology.md.
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.
Step 6: Monitor and update
Track which scenario is unfolding. Update plans as reality diverges from expectations. See resources/methodology.md.
Validate using resources/evaluators/rubric_hypotheticals_counterfactuals.json. Minimum standard: Average score ≥ 3.5.
Pattern 1: Pre-Mortem (Prospective Hindsight)
Pattern 2: Counterfactual Causal Analysis
Pattern 3: Three Scenarios (Optimistic, Baseline, Pessimistic)
Pattern 4: 2×2 Scenario Matrix
Pattern 5: Assumption Reversal
Pattern 6: Stress Test (Extreme Scenarios)
Key requirements:
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.
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.
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.
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").
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.
Time horizon clarity: Specify WHEN in future. "Product fails" is vague. "In 6 months, adoption <1000 users" is concrete. Enables tracking.
Extract actions, not just stories: Scenarios are useless without implications. Always end with "so what should we do?" Prepare, hedge, pivot, or double-down.
Update scenarios: Reality evolves. Quarterly review: which scenario is unfolding? Update probabilities and plans accordingly.
Common pitfalls:
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):
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:
Inputs required:
Outputs produced:
counterfactual-analysis.md: Alternative history analysis with causal insightspre-mortem-risks.md: List of potential failure modes and mitigationsscenarios.md: 2-4 future scenarios with narratives and implicationsaction-plan.md: Decisions and preparations based on scenario insightsdevelopment
--- name: zettel-note description: The note-writing discipline for this vault's evergreen knowledge graph, modeled on a Zettelkasten reading companion and governed by the vault conventions. Enforces declarative-claim titles, one claim per note (atomicity), own-words prose with no block quotes, the piped [[slug|Title]] link form, the labeled link-relationship vocabulary (Confirms/Contradicts/Extends/Context/Prerequisite/Builds-on/Applies/Example-of/Contrasts-with), 3-6 links per note, and search-
development
Plans between-round FIFA World Cup Fantasy transfers — budgets the round's free transfer(s), forces out players whose nation has been eliminated, chases fixture-swing drops, upgrades on value, and decides when a rebuild is large enough to fire the Wildcard instead of spending free transfers one at a time. Ranks candidate in/out pairs by EV gain over each player's remaining survival horizon (delta xEV weighted by progression_carry) MINUS transfer cost (a free transfer is cheap, a points hit is real, churning the squad for marginal swings is a critic flag), and tags forced/fixture/upgrade priority. Emits a `transfer-plan` signal. Use when called by wc-squad-architect (whose transfer work this skill is the engine for) and by the strategists in the populate stage when their candidate is transfer-adjacent rather than a full rebuild.
testing
Reads and updates the FIFA World Cup Fantasy tournament state machine (footballfantasy/context/tournament-state.md) — the temporal backbone tracking phase (pre-tournament → group MD1-3 → R32 → R16 → QF → SF → final), budget ($100m group / $105m knockouts), nation cap (3 group, loosening in knockouts), chips remaining, surviving nations, each owned player's elimination-risk horizon, and deadlines. Validates state on load (count/feasibility checks), applies phase transitions, and appends to the append-only state log (never silent overwrite). Use to load state at the start of a run and to commit state changes after the manager makes a move.
development
Validates and persists FIFA World Cup Fantasy signal files to signals/YYYY-MM-DD-<type>.md. Checks the required frontmatter (type, round, date, emitted_by, confidence, source_urls), range-checks declared numeric signals, confirms every factual claim carries a source URL or "manager-provided", rejects unknown signal types, and refuses to persist a signal that fails validation (logging the failure instead). Keeps the inter-agent signal layer auditable so downstream agents can trust what they read and never re-derive it. Use whenever an agent or skill writes a signal.