@human-avatar/skills-for-humanity 1.0.0

package/skills/play-perspective-reversal/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: play-perspective-reversal
+description: "Fully inhabits the opposing perspective — competitor, critic, user, or adversary — to find what is invisible from your own position. TRIGGERS: 'steelman the opposition', 'think like the competitor', 'play devil's advocate', 'see it from their side', 'role reversal', 'inhabit the other perspective'."
+---
+
+# Play: Perspective Reversal
+
+Every position has a blind spot — things that are invisible precisely because of
+where you're standing. The opposing perspective sees those things clearly. This skill
+requires fully setting aside your own position and genuinely inhabiting the other one
+— without qualification, defence, or commentary — then returning to extract what was
+revealed. Half-hearted perspective-taking (staying in your own frame while gesturing
+at theirs) produces nothing. Full inhabitation produces findings.
+
+---
+
+## Your Process
+
+**Step 1: Name the Opposing Perspective**
+Who is the other position? Be specific — not "the market" but "a direct competitor
+who has observed our strategy for two years and is now choosing where to attack." Not
+"critics" but "the engineering team who built the previous system and believe this
+replacement is solving the wrong problem." Specificity determines how much you can
+genuinely inhabit.
+
+**Step 2: Set Aside Your Own Perspective**
+This step is non-negotiable. For the duration of Steps 3-5, there is no defending,
+no qualifying, no "but to be fair to our side." You are not you. You are them. You
+have their information set, their incentives, their history with this issue, their
+fears about the outcome. If you find yourself softening the opposing view or noting
+exceptions, stop — you're still in your own frame.
+
+**Step 3: From Their Perspective — What Is Wrong?**
+What is wrong with the current approach, plan, or position? What is being missed,
+underestimated, or misunderstood? What assumptions look clearly false from this
+vantage point? What would a perceptive person standing here see that the other side
+is blind to?
+
+**Step 4: What Opportunity Are They Seeing?**
+From their position: what opportunity exists that the current approach is failing to
+take? What gap, weakness, or opening is visible from where they stand? What is the
+version of the world they're operating from where their strategy makes complete sense?
+
+**Step 5: Their Strategy**
+If you were them, what would you do? What specific moves would you make to exploit
+what you've just identified? Be concrete — not "they'll attack our weakness" but the
+specific sequence of moves that their position makes available.
+
+**Step 6: Re-enter and Assess**
+Return to your own perspective. What did the opposing view reveal that is legitimate
+— that you would have to concede is a real problem even under your own framework?
+Classify each finding: must change (the critique is valid and the approach needs
+adjustment), must defend (the approach is correct but vulnerable), must communicate
+better (the approach is right but it's not landing).
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Opposing view only** — fully inhabit the opposite position, skip the reflection and re-integration
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Opposing Perspective:** [who + their vantage point and information set, stated
+fully and fairly]
+
+**What They See That You Don't:** [the specific blind spots and missed assumptions
+visible from their position]
+
+**Their Strategy:** [the specific moves their position makes available — what they
+would do and why]
+
+**Legitimacy Assessment**
+
+| Finding From Their Perspective | Legitimate? | Response Category |
+|---|---|---|
+| [what they see] | [yes / partially / no] | [must change / must defend / must communicate better] |
+
+**Priority Actions**
+- Must change: [what requires genuine adjustment to the approach]
+- Must defend: [what is correct but needs to be made more robust]
+- Must communicate better: [what is right but isn't landing — and the gap]
+
+---
+
+## Notes
+
+The exercise fails if it becomes a performance of the other perspective rather than
+genuine inhabitation. The test is whether you find something that makes you
+uncomfortable — something you would prefer not to be true. If everything from the
+opposing perspective turns out to be wrong or irrelevant, you didn't actually inhabit
+it.

package/skills/play-stimulus-generation/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: play-stimulus-generation
+description: "Introduces a random, unrelated element to break mental fixation — forcing new associations that bypass the groove of familiar thinking. TRIGGERS: 'random stimulus', 'random word technique', 'break the fixation', 'I keep thinking of the same things', 'unstick this', 'force new associations'."
+---
+
+# Play: Stimulus Generation
+
+When thinking is stuck it is usually stuck in a groove — a narrow set of associations
+that keeps returning to the same territory because the same concepts keep activating
+the same networks. A random, unrelated stimulus forces the mind out of that groove by
+requiring it to build a bridge between an irrelevant input and the actual problem.
+The bridges that form are often the most original ideas, because they come from
+outside the problem's own conceptual neighbourhood.
+
+---
+
+## Your Process
+
+**Step 1: State the Stuck Problem**
+What is the problem, and what makes it stuck? What solutions have already been
+considered and found inadequate? What territory keeps getting returned to? Naming
+the groove is the first step to breaking it.
+
+**Step 2: Generate a Random Stimulus**
+Introduce something genuinely unrelated to the problem domain — the less obviously
+connected the better. Options:
+- Open a dictionary, encyclopedia, or any book to a random page; use the first
+  concrete noun
+- Use a recent news headline from a completely unrelated field
+- Name a physical object currently visible in the room
+- Choose a domain entirely unlike the problem: if the problem is software, use
+  marine biology or medieval architecture; if it's business strategy, use cooking
+  or materials science
+
+The stimulus should feel irrelevant. That is the point.
+
+**Step 3: List Attributes and Associations**
+Name 5-7 properties, behaviours, qualities, structures, or associations of the
+stimulus. Go beyond the obvious surface properties — consider how it behaves under
+pressure, what it requires to function, how it fails, what it produces, what
+constrains it, what it optimises for. The richer the attribute list, the more
+bridges are available.
+
+**Step 4: Force Connections**
+For each attribute: ask "how could this apply to the stuck problem?" No filtering,
+no immediate rejection. Some connections will be useless — make them anyway. The
+goal is volume of bridges, not quality filtering at this stage. Quantity first.
+
+**Step 5: Identify Promising Directions**
+Which forced connections suggest a genuinely new direction — even partially? Which
+reframe the problem itself rather than just suggesting a surface solution? A
+connection that reveals a new way of seeing the problem is often more valuable than
+one that suggests a specific solution.
+
+**Step 6: Develop the Most Promising**
+Take the strongest connection and develop it into a concrete idea. What would it
+look like if implemented in the actual problem context? What would need to be true
+for it to work? What is the testable version?
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Three connections only** — strongest forced connections between the stimulus and the problem
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Stuck Problem:** [description of the problem and what the stuck groove looks like]
+
+**Random Stimulus:** [the word, object, headline, or concept introduced]
+
+**Stimulus Attributes:** 1. [attribute] 2. [attribute] 3. [continue to 5-7]
+
+**Forced Connections**
+
+| Attribute | Connection to the Stuck Problem | Worth Developing? |
+|---|---|---|
+| [attribute] | [how it might apply — no filtering] | [yes / no / maybe] |
+
+**Most Promising Direction:** [the connection or reframe worth developing, and why]
+
+**Developed Idea:** [what it looks like as a concrete proposal — specific enough
+to test or act on]
+
+---
+
+## Notes
+
+The random stimulus works not because it contains the answer but because connecting
+to it forces abandonment of the stuck groove. A connection that seems absurd at first
+may open a direction that a rational search would never find. Resist the urge to
+discard connections quickly — the most useful ones often require a second look.

package/skills/play-worst-case-reversal/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: play-worst-case-reversal
+description: "Deliberately designs the worst possible version — then reverses each failure mode into a design principle. Removes the pressure of being right and unlocks creative honesty that polite brainstorming suppresses. TRIGGERS: 'worst possible idea', 'how would you make this terrible', 'reverse brainstorm', 'design the failure', 'how would you deliberately fail'."
+---
+
+# Play: Worst-Case Reversal
+
+Direct brainstorming produces cautious, socially acceptable ideas. Designing the
+worst possible version removes the social cost of being wrong and unlocks the honest
+list of everything that actually fails — which, when reversed, becomes the most direct
+path to the design requirements that matter. The technique works because the
+worst-possible list is easy: everyone knows how to fail. The reversals do the serious
+work.
+
+---
+
+## Your Process
+
+**Step 1: State the Design Challenge**
+What are you designing, building, or solving? Be specific about the intended outcome
+— what would success look like if it worked?
+
+**Step 2: Design the Worst Version**
+Ask: how would you make this as bad as possible? What would guarantee failure,
+alienate users, destroy trust, waste resources, or produce the exact opposite of the
+intended outcome? Generate without filter or politeness. Aim for 8-12 specific ways
+to make it terrible.
+
+Rules for this step:
+- No self-censorship. The worse the better.
+- Be specific, not vague. "Make users wait 10 minutes" not "be slow." "Never
+  acknowledge errors" not "have bad error handling."
+- Include the uncomfortable ones — the ones that reveal real tensions, ignored
+  trade-offs, or problems the current design is quietly making. These are the most
+  valuable entries.
+- If it feels too harsh to say, say it. Those are usually the ones that generate
+  the most useful reversals.
+
+**Step 3: Reverse Each Failure Mode**
+For each terrible idea, state the affirmative inverse as a design principle. The
+reversal should be specific and actionable, not generic. "Make users re-enter the
+same information three times" → "Eliminate all redundant data entry; information
+provided once should propagate automatically." "Never tell users what went wrong"
+→ "Every failure state names what happened and what to do next."
+
+**Step 4: Collect as Design Requirements**
+The reversed principles are design requirements. State them as a clean list,
+affirmatively, in present tense. These are things the design must do.
+
+**Step 5: Audit Against the Existing Design**
+Which requirements were already present and strong? Which were present but weak or
+inconsistent? Which were missing entirely? The missing ones — requirements that never
+appeared in the direct design process — are the primary output.
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Reversal list only** — the failure modes and their direct inverses, skip elaboration
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Challenge:** [what you're designing and what success looks like]
+
+**Worst-Possible List + Reversals**
+
+| Terrible Idea | Reversed Design Principle |
+|---|---|
+| [specific failure mode — concrete and unfiltered] | [affirmative design requirement] |
+
+**Design Requirements Derived:** [clean numbered list of all reversed principles]
+
+**Audit Against Existing Design**
+- Already present and strong: [list]
+- Present but weak or inconsistent: [list — these need tightening]
+- Missing entirely: [list — these are the highest priority findings]
+
+---
+
+## Notes
+
+The uncomfortable entries in the worst-possible list are the most valuable — they
+surface real tensions that politeness has kept invisible. If every item on your list
+feels obvious and safe, you haven't gone far enough. Push into the territory where
+naming it feels a little risky.

package/skills/probability/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: probability
+description: "Entry point for the probability toolkit. Routes to the right probabilistic thinking skill based on your situation. Use when you say 'probability', 'how likely', 'am I overconfident', 'quantify this', 'what's the base rate', 'expected value', 'scenario weighting', or want probabilistic reasoning applied without knowing which specific tool fits."
+---
+
+# Probability
+
+Applies probabilistic thinking to estimates, decisions, and uncertainty. Diagnoses what kind of probability work is needed and applies the right tool.
+
+## Which tool fits
+
+| You need to... | Tool |
+|---|---|
+| Anchor estimates in historical base rates before adjusting | base-rate-anchoring |
+| Test whether stated confidence matches available evidence | confidence-calibration |
+| Calculate expected value to compare options under uncertainty | expected-value-calculation |
+| Assign probabilities to distinct scenarios before deciding | scenario-weighting |
+
+## Routing Decision
+
+- **Estimate feels optimistic — want the outside view** → base-rate-anchoring
+- **Unsure how confident to be, or whether confidence is warranted** → confidence-calibration
+- **Comparing options with different payoffs and probabilities** → expected-value-calculation
+- **Multiple plausible futures and need to think through each** → scenario-weighting
+- **Unclear** → confidence-calibration; establishing what confidence is warranted usually determines what other analysis is needed
+
+## Confirm Direction
+
+After diagnosing which tool fits, present the recommendation before executing:
+
+> My read: **[diagnosed tool]** — one sentence on why it fits.
+
+- **A) Yes, run that tool**
+- **B) Show me all options** — list every skill in this category with one-line descriptions
+- **C) Quick version** — lighter-weight alternative for this situation, if one exists
+- **D) Re-diagnose** — describe the situation differently for a second read
+
+Wait for their selection before proceeding.
+
+---
+
+## Base Rate Anchoring
+
+*Anchors estimates in historical base rates before adjusting for specifics.*
+
+Before adjusting for what makes this situation special, establish what usually happens in situations like this one. Find the reference class: what category of event is this? What is the historical base rate for that category? Now adjust: what specific factors make this situation better or worse than the reference class? The adjustment should be modest unless the specific factors are genuinely exceptional; most people underweight the base rate and overweight the specifics.
+
+**Output:** Reference class identified, base rate established, specific adjustments with justification, and the final calibrated estimate.
+
+---
+
+## Confidence Calibration
+
+*Tests whether stated confidence levels match available evidence.*
+
+State the current confidence level. Now audit it: what is the evidence for this belief? How strong is that evidence? What evidence against have you considered? Are you more confident than the evidence warrants (overconfidence — common) or less confident than it warrants (underconfidence — less common but real)? Good calibration means your 80% confident predictions come true about 80% of the time.
+
+**Output:** Confidence audit — evidence for, evidence against, sources of overconfidence, and a recalibrated confidence level with reasoning.
+
+---
+
+## Expected Value Calculation
+
+*Calculates expected value to compare options under uncertainty.*
+
+For each option: list possible outcomes and their probabilities. Estimate the value (positive or negative) of each outcome. Calculate expected value: sum(probability × value) for each outcome. Compare across options. Identify if any option has asymmetric risk — limited downside, large upside — which expected value captures but intuition often misses.
+
+**Output:** Expected value calculation for each option, comparison table, and interpretation of the asymmetry or risk profile.
+
+---
+
+## Scenario Weighting
+
+*Assigns explicit probabilities to distinct scenarios before making a decision.*
+
+Define 3-5 mutually exclusive, collectively exhaustive scenarios for how this situation could unfold. For each scenario: what are the key conditions that make it happen? Assign a probability to each (they must sum to 100%). For each scenario: what decision is optimal? Now aggregate: given the scenario probabilities, what is the best overall decision?
+
+**Output:** Scenario inventory with probabilities, optimal decision per scenario, and the overall recommendation weighted by scenario probabilities.

package/skills/probability-base-rate-anchoring/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: probability-base-rate-anchoring
+description: "Anchors estimates in historical base rates before adjusting for specific factors. Use when asked 'what's the base rate', 'am I being too optimistic', 'outside view', 'reference class', 'how often does this actually happen', or 'historical frequency'."
+---
+
+# Probability Base Rate Anchoring
+
+The most common forecasting error is treating every situation as unique and ignoring what usually happens. Kahneman called this neglecting the outside view. Before adjusting for what makes this situation special, you must first establish what happens in situations like this one. The base rate is the outside view — the answer to "what fraction of attempts like this one succeed?" — and it is almost always more informative than inside-view reasoning about this particular case.
+
+---
+
+## Your Process
+
+**Step 1: State the Prediction or Estimate**
+Name the specific outcome being predicted and the current estimate or intuition. What is being forecast and at what implied probability?
+
+**Step 2: Find the Reference Class**
+What category of similar situations does this belong to? This is the most important and contested step. The reference class should be: (a) large enough to have stable base rates, (b) genuinely similar in the ways that matter, (c) not cherry-picked to flatter the prediction. If multiple reference classes apply, note them all.
+
+**Step 3: Find the Base Rate**
+How often does this outcome actually occur in that reference class? Use historical data where available. If the exact rate is unknown, estimate a range from the most similar data available. This is the outside view — state it plainly, even if it is uncomfortable.
+
+**Step 4: Adjust for Differentiating Factors**
+What specific, verifiable features of this situation distinguish it from the reference class? For each: does it push the probability up or down from the base rate? Explicitly consider factors that cut against your prior, not only those that support it.
+
+**Step 5: State as a Range**
+Combine the base rate with adjustments to produce a final probability range, not a point estimate. The range should reflect genuine uncertainty.
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Base rate only** — identify the historical rate without Bayesian adjustment
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Prediction:** [the specific outcome + current intuitive estimate]
+
+**Reference Class:** [the category used + why it applies]
+
+**Base Rate:** [historical frequency in this class + data source or basis]
+
+**Adjustment Factors**
+
+| Factor | Direction (↑/↓) | Magnitude | Rationale |
+|--------|----------------|-----------|-----------|
+| | | | |
+
+**Final Estimate:** [range — low to high] — [brief rationale]
+
+**Calibration Note:** [if final estimate differs substantially from base rate, explain why the differentiating factors justify the gap]
+
+---
+
+## Notes
+
+Only adjust from the base rate when you have specific, verifiable reasons — not because the situation feels different. The inside view always feels justified; the outside view is the corrective.

package/skills/probability-confidence-calibration/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: probability-confidence-calibration
+description: "Tests whether stated confidence levels match available evidence — catching overconfidence and underconfidence. Use when asked to 'calibrate my confidence', 'am I overconfident', 'confidence check', 'how sure should I be', or 'is this as certain as it seems'."
+---
+
+# Probability Confidence Calibration
+
+Overconfidence is the most documented and costly bias in judgment. People who say they are 90% confident are right far less than 90% of the time. But underconfidence is also costly — excessive hedging prevents commitment and action when evidence is actually sufficient. Calibration is not about being less confident; it is about having confidence levels that match the available evidence.
+
+---
+
+## Your Process
+
+**Step 1: State the Claim and Current Confidence**
+Name the specific claim — not a vague domain but a specific, falsifiable statement — and state the current confidence level as a percentage.
+
+**Step 2: Audit Supporting Evidence**
+List the evidence supporting the claim. For each piece: classify its strength:
+- **Direct observation:** you or a trusted source directly witnessed this
+- **Inference:** logical or empirical inference from other data
+- **Anecdote:** one or a few cases, not systematic
+- **Assumption:** believed without verification
+
+**Step 3: List Counter-Evidence and Gaps**
+What evidence exists against the claim? What would you expect to see if the claim were true that you do not see? What have you not checked that bears on the claim?
+
+**Step 4: Identify the Most Likely Failure Mode**
+If this claim is wrong, what is the most probable reason? Is that failure mode being appropriately weighted in the current confidence assessment, or is it being minimized?
+
+**Step 5: Apply the Frequency Test**
+At this confidence level, across many similar judgments, you would be right X% of the time. Does that feel right given the quality of evidence? This frequentist reframe often corrects overconfidence.
+
+**Step 6: State Calibrated Confidence**
+Adjust the confidence level to reflect the evidence quality, gaps, and failure mode weight. State direction of adjustment and reason.
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Miscalibrations only** — flag where confidence exceeds evidence, skip well-calibrated claims
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Claim:** [specific, falsifiable statement]
+
+**Original Confidence:** [%]
+
+**Evidence Quality Audit**
+
+| Evidence | Type (observation/inference/anecdote/assumption) | Strength |
+|----------|------------------------------------------------|---------|
+| | | |
+
+**Counter-Evidence and Gaps:** [what works against the claim or has not been checked]
+
+**Most Likely Failure Mode:** [if wrong, why — and is it being weighted correctly?]
+
+**Calibrated Confidence:** [%] — [direction: raised/lowered/unchanged + one-sentence rationale]
+
+---
+
+## Notes
+
+A well-calibrated person is not one who is always uncertain — they are confident when evidence is strong and uncertain when it is weak. The goal is accuracy of confidence, not uniformly lower confidence.

package/skills/probability-expected-value-calculation/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: probability-expected-value-calculation
+description: "Calculates expected value to compare options under uncertainty. Use when asked about 'expected value', 'is this risk worth taking', 'EV calculation', 'compare these options', 'worth the risk', or 'asymmetric risk'."
+---
+
+# Probability Expected Value Calculation
+
+Expected value is the correct framework for comparing options under uncertainty. It multiplies each outcome's value by its probability and sums across all outcomes, producing a single number that accounts for the full distribution rather than just the most likely case. EV analysis forces explicitness about both probabilities and values — and it exposes asymmetric risk that intuition misses. One important constraint: EV math is overridden when any outcome is catastrophic enough to be unacceptable regardless of probability.
+
+---
+
+## Your Process
+
+**Step 1: Define the Options**
+List the options being compared. Include "do nothing" or "wait" as explicit options — they have EVs too.
+
+**Step 2: List Outcomes for Each Option**
+For each option: what are the possible outcomes? Use scenario-weighting to assign probabilities if this has not already been done. Outcomes must be mutually exclusive and exhaustive per option.
+
+**Step 3: Assign Values**
+Assign a value to each outcome in a consistent unit (revenue, cost savings, time, abstract utility). The same unit must apply across all options for comparison to be valid. Negative values for bad outcomes.
+
+**Step 4: Calculate EV**
+For each option: EV = sum of (probability × value) across all outcomes. Show the calculation.
+
+**Step 5: Compare EVs**
+Identify the highest-EV option. Note whether any option has higher EV but worse downside — this is the asymmetric risk check.
+
+**Step 6: Check for Catastrophic Downside**
+Is any outcome bad enough that it would be unacceptable regardless of its probability and regardless of EV? Ruin, existential harm, irreversible loss. If yes: that outcome overrides the EV comparison. Flag it explicitly.
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) EV comparison table only** — final expected values per option, skip the step-by-step breakdown
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**EV Table**
+
+| Option | Outcome | Probability | Value | P × V |
+|--------|---------|-------------|-------|-------|
+| Option A | Outcome 1 | | | |
+| | Outcome 2 | | | |
+| | **EV** | | | **=** |
+| Option B | Outcome 1 | | | |
+| | **EV** | | | **=** |
+
+**Recommended Option:** [highest EV + rationale]
+
+**Catastrophic Downside Flag:** [Y/N — if yes: which outcome, why it overrides EV, revised recommendation]
+
+**Asymmetric Risk Note:** [if any option has high upside but fat downside tail that EV smooths over]
+
+---
+
+## Notes
+
+EV assumes outcomes are fungible and the decision will be made many times — neither is always true. For one-shot decisions with irreversible outcomes, weight catastrophic downside beyond what probability × value captures.

package/skills/probability-scenario-weighting/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: probability-scenario-weighting
+description: "Assigns explicit probabilities to distinct scenarios before making a decision. Use when asked to 'assign probabilities', 'scenario weighting', 'how likely is each outcome', 'quantify the uncertainty', or 'probability distribution'."
+---
+
+# Probability Scenario Weighting
+
+Vague uncertainty — "it might work, it might not" — produces poor decisions. Quantified uncertainty forces precision about what is actually believed and makes implicit assumptions visible. Assigning explicit probabilities to scenarios is not prediction; it is structured belief articulation. The process of assigning and calibrating probabilities often reveals more than the final numbers.
+
+---
+
+## Your Process
+
+**Step 1: List Scenarios**
+Enumerate all scenarios — they must be mutually exclusive (no overlap) and collectively exhaustive (cover all meaningful possibilities). If "other" is significant, make it explicit. Typically 3–5 scenarios; more than 6 reduces usability.
+
+**Step 2: Assign Initial Probabilities**
+Assign a probability to each scenario. They must sum to 100%. Do this before analyzing each scenario in detail — your prior is informative and anchoring matters.
+
+**Step 3: Calibration Check**
+For each probability: would you accept a bet at these odds? If you assigned 70% to a scenario, you should be willing to accept 3:7 odds against it. If the bet feels uncomfortable at those odds, your stated probability is wrong. Adjust.
+
+**Step 4: Identify Key Driver for Each Scenario**
+What would need to be true for each scenario to occur? What is the single most important condition that must hold?
+
+**Step 5: Find the High-Probability and High-Impact Scenarios**
+These may be the same scenario or different ones. If the highest-probability scenario is low-impact and the highest-impact scenario is low-probability, name both — they require different responses.
+
+**Step 6: Identify Most Useful Information**
+What new information would most update these probabilities? This determines what to investigate next. Information that confirms the most likely scenario is usually less valuable than information that discriminates between scenarios.
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Top 3 scenarios only** — most likely, most harmful, most surprising
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Scenario Table**
+
+| Scenario | Probability | Key Driver (must be true) | Primary Implication |
+|----------|-------------|--------------------------|---------------------|
+| | | | |
+| **Total** | **100%** | | |
+
+**Highest-Probability Scenario:** [name + %, implications]
+
+**Highest-Impact Scenario:** [name + %, implications — note if same or different from above]
+
+**Most Useful Information to Gather:** [the question whose answer would most shift these probabilities]
+
+---
+
+## Notes
+
+Resist collapsing scenarios into "optimistic / realistic / pessimistic" — this framing anchors on the most optimistic outcome and treats the middle case as truth. Build scenarios around key uncertainties, not emotional valence.