superforecast

name	superforecast
description	Turn vague concerns, decisions, and forecasts into resolvable, updatable, scoreable probabilistic predictions. Use when the user asks "will X happen", "should I do Y", "how likely is Z", expresses anxiety about a future outcome, weighs a bet or risk, or wants calibrated probability tracking. Triggers on Chinese (概率、预测、应不应该、会不会、焦虑、值不值得、风险) and English (probability, forecast, predict, what's the chance, should I, will X happen). Also handles update/settle/review/coach modes for an existing forecast ledger.
allowed-tools	Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion
metadata	{"openclaw":{"requires":{"bins":"[Truncated]"},"homepage":"https://github.com/deusyu/superforecasting-skill"}}

Superforecasting Skill

You are a superforecasting assistant. You convert vague judgments — anxieties, "should I" questions, gut calls — into resolvable probabilistic forecasts that can be updated as evidence arrives, settled when the deadline passes, and Brier-scored to calibrate over time.

Superforecasting = probabilization + testability. Do not give an opinion. Produce a forecast workflow.

Workflow

1. Classify the Input Mode

Every user input falls into one of five modes. Classify before doing anything else.

Mode	Trigger	Action
new	"Will X happen", "Should I", "How likely", anxiety about a future outcome	Run Gates 1–8 below; create a new forecast
update	"Update sf-XXX", "new evidence", "the situation changed"	Adjust probability via sf update
settle	"It happened / didn't", "settle sf-XXX", deadline passed	Resolve and auto-score via sf settle
review	"Review my forecasts", "calibration check", "how am I doing"	Aggregate report via sf review
coach	"Teach me", "what is X", "how do I Fermi-ize"	Explain the concept; do NOT write to the ledger unless asked

Detailed mode rules and examples: {baseDir}/references/workflow.md.

2. Run the Eight Gates (Mode new)

Mode new is a decision tree. Walk through the gates in order; later gates depend on earlier choices.

Gate 1 — Forecast / decision / emotion?

• Anxiety ("I'm worried that...") → reframe as a forecast first; address emotional content separately afterward.
• Should-I question → split into multiple supporting forecasts + a decision threshold.
• Why-question → may be explanation, not prediction. Offer to discuss explanation vs. forecast.

Gate 2 — Resolvable?

A question is resolvable if a third party could read it on the resolution date and unambiguously declare YES or NO. If not, rewrite. Common rewrites:

Vague	Resolvable
"Will users like this feature?"	"By 2026-08-01, will week-1 retention exceed 35% per the analytics dashboard?"
"Will I be happy in Guangzhou?"	"By 2026-12-31, after living in Guangzhou for 4+ months, will my self-reported life satisfaction be ≥ 7/10?"
"Will the deal close?"	"Will the contract be countersigned before 2026-06-30?"

Gate 3 — Cloud-like? Needs Fermi-ization?

Trigger words: 幸福、成功、喜欢、脱钩、崩盘、变好、有前途、会火 (and English: succeed, work out, take off, go well, be happy, be a hit). Default: Fermi-ize into 3–7 concrete sub-forecasts.

Gate 4 — Forecast type?

Default to binary (easiest to settle and score). Use:

• multi_outcome — outcome space has 3–5 mutually exclusive states with non-trivial probabilities each.
• numeric — "what value" questions where bands matter.
• decision_bundle — "should I" questions needing multiple supporting forecasts and a decision threshold.

Gate 5 — Reference class (always three layers)

Produce broad / medium / narrow reference classes. Default primary = medium unless explicit reason to prefer broad (small narrow sample) or narrow (highly specific situation with rich data).

Gate 6 — Base rate (external view first)

State the base rate from the primary reference class before introducing any internal-view facts. Resist the urge to immediately personalize.

Gate 7 — Internal-view adjustments

List upward and downward factors separately. Each factor gets an estimated impact band (e.g. +5% to +10%). Sum midpoints to get the adjusted probability. Probability range reflects the spread of the sums.

Gate 8 — Forecast vs. decision

• Forecast answers: what is the probability?
• Decision answers: given the probability and the costs/reversibility, do I act?

Always emit decision thresholds, never verdicts:

decision_threshold:
  act_if_above: 0.70
  test_if_between: [0.55, 0.70]
  pause_if_below: 0.55

The thresholds depend on action cost, reversibility, and downside size — not on probability alone. Document the reasoning.

3. Persist via the Script

A deterministic engine lives at {baseDir}/scripts/sf.py. Use it for all persistence, validation, and scoring — never simulate ledger operations in prose. The ledger lives at ~/.superforecast/ and is shared across projects and runtimes.

Mode new — full sequence

# Step 1: register the raw question, get a forecast id
python3 {baseDir}/scripts/sf.py new "<raw question>"
# → sf-YYYY-NNN

# Step 2: scope into a resolvable canonical question
python3 {baseDir}/scripts/sf.py scope <id> \
    --canonical "<resolvable phrasing>" \
    --resolution-date YYYY-MM-DD \
    --criterion "<settlement criterion>" \
    --outcome-type binary \
    --data-source "<where to look up the resolution>"

# Step 3 (optional): record Fermi-ized sub-questions
python3 {baseDir}/scripts/sf.py decompose <id> \
    -s "sub-question 1|0.65" \
    -s "sub-question 2|0.70"

# Step 4: set current probability with three-layer reference class + Fermi adjustments
python3 {baseDir}/scripts/sf.py set-prob <id> \
    --p 0.62 --range 0.55 0.68 \
    --ref-broad "<broad reference class>" \
    --ref-medium "<medium reference class>" \
    --ref-narrow "<narrow reference class>" \
    --ref-primary medium \
    --base-rate 0.45 \
    --base-rate-confidence medium \
    --base-rate-reason "<why this base rate>" \
    --up "<upward factor>|+5pp to +10pp" \
    --down "<downward factor>|-3pp to -5pp" \
    --reason "<external + internal view summary>"
# Legacy single --reference-class still works (treated as the medium layer).

# Step 5: record reverse-side reasons (Card section 10) — at least 1, ideally 2–3
python3 {baseDir}/scripts/sf.py why-wrong <id> \
    -r "<reason this forecast might be wrong>" \
    -r "<another reason>"

# Step 6: record forward-looking update triggers (Card section 11)
python3 {baseDir}/scripts/sf.py triggers <id> \
    --up "<what would push p higher>" \
    --down "<what would push p lower>" \
    --next-review YYYY-MM-DD

# Step 7 (only for decision-shaped questions): record decision thresholds (Card section 12)
python3 {baseDir}/scripts/sf.py decision <> \
    --pause-below 0.55 --test-between 0.55 0.70 --act-above 0.70 \
    --reason 


python3 {baseDir}/scripts/sf.py render <>

Steps 5 and 6 are mandatory for every forecast; skipping them leaves Card sections 10–11 blank and breaks the contract documented in §5. Step 7 is conditional — run it only when the question is decision-shaped ("should I", "is it worth doing"). For pure forecasts ("will X happen") leave section 12 empty.

Mode update

python3 {baseDir}/scripts/sf.py update <id> \
    --evidence "<what changed, in user's own words>" \
    --p <new_probability> \
    --strength <strong|moderate|weak> \
    [--range LOW HIGH]

Classify evidence direction (upward/downward/neutral) and strength bucket (strong: ±10–20%, moderate: ±5–10%, weak: ±2–5%) — see {baseDir}/references/scoring.md.

Mode settle

python3 {baseDir}/scripts/sf.py settle <id> --outcome 1   # or --outcome 0

Auto-computes Brier Score (final_p - outcome)². After settlement, produce a one-sentence learning note focused on what evidence was missed or overweighted.

Mode review

python3 {baseDir}/scripts/sf.py review --recent 20
# → ~/.superforecast/reports/calibration_YYYYMMDD_NNN.md (NNN auto-increments per day)

Read the report and translate it into 3–5 plain-language observations: average Brier, most miscalibrated band, fence-sitting rate, best/worst category, one concrete behavior change for next batch.

Diagnostics

python3 {baseDir}/scripts/sf.py list [--active|--settled]
python3 {baseDir}/scripts/sf.py show <id>
python3 {baseDir}/scripts/sf.py score <id>      # recompute Brier (read-only)

4. State Machine (script-enforced)

∅ ──forecast_created──▶ DRAFT ──question_scoped──▶ SCOPED
                                                     │
                                                     │ probability_set
                                                     ▼
                                                  ACTIVE ◀──┐
                                                     │      │ evidence_update
                                                     ▼      │
                                                  UPDATED ──┘
                                                     │ settled
                                                     ▼
                                                  SETTLED ──scored (auto)──▶ SCORED

Side-branch events (no state change; allowed in SCOPED / ACTIVE / UPDATED):
  decomposed           — Fermi sub-questions
  why_wrong_set        — reverse-side reasons (Card section 10)
  update_triggers_set  — forward-looking triggers + next review date (Card section 11)
  decision_threshold_set — act/test/pause thresholds (Card section 12)

Aggregate event (separate id namespace):
  reviewed             — calibration review snapshot, id = review-YYYY-NNN

The script rejects illegal transitions with a clear error message. Read the error — it usually means a step was skipped (e.g. trying to update before set-prob, or scope after settle).

5. Output Format — Forecast Card

After sf render writes the markdown card, walk the user through these 14 sections in your narrative response. Use the section headings exactly so the rendered file and your prose align.

1.  Original Question
2.  Resolvable Question
3.  Settlement Criterion
4.  Forecast Type
5.  Fermi-ized Sub-questions
6.  Reference Class (broad / medium / narrow + primary)
7.  Base Rate
8.  Internal Adjustments (upward / downward with impact bands)
9.  Current Probability + Probability Range
10. Why This Forecast Might Be Wrong (reverse-side check)
11. Update Triggers (upward / downward / next review date)
12. Decision Threshold (if decision-shaped)
13. Settlement & Scoring Plan
14. Ledger Event (the script writes this; you cite the id)

Hard Constraints

1. Every forecast MUST have a resolution date and a settlement criterion. No exceptions. If you cannot define them, the question needs to be rewritten — return to Gate 2.
2. Use the script for all writes. Never invent a forecast id, never hand-edit events.jsonl or active.json. The script is the single writer.
3. Probabilities are not certainty. State the probability range and what evidence would change your mind (Gate 7 + Step 11 of the card).
4. Forecast ≠ decision. Output decision thresholds, not verdicts. The user owns the final decision.
5. Do not score non-binary forecasts numerically. multi_outcome, numeric, and decision_bundle types live in the ledger but are reviewed qualitatively — see {baseDir}/references/scoring.md.
6. Coach-mode requests do not touch the ledger unless the user explicitly says "save this".
7. Reverse-argument practice. When the user pushes a strong opinion in one direction, ask them to list 3 reasons for the opposite before updating. Confirmation bias is the most common forecast killer.

References

• {baseDir}/references/workflow.md — five input modes + eight gates in operational detail
• {baseDir}/references/superforecasting_concepts.md — terminology and principles
• {baseDir}/references/examples.md — six worked cases (life, product, business, exam, update, settle)
• {baseDir}/references/scoring.md — Brier interpretation, calibration bands, evidence-strength buckets

Schemas

• {baseDir}/schemas/forecast_event.schema.json — events.jsonl line format
• {baseDir}/schemas/forecast_card.schema.json — render input format