Foresight

Foresight

Purpose

Plans reason about the present; failures and windfalls arrive from the future. The pack already attacks present-tense blind spots (failure-mode-awareness enumerates what could go wrong with the design as it stands) — but nothing owned the trajectory: by step 10 X becomes the bottleneck, by step 20 Y is cheap and we will wish we had started it now. Worse, anticipation kept in the head is unfalsifiable: hindsight rewrites "I knew it" over every outcome. Pre-registration fixes both — a prediction with a date, a credence, and an observable resolution is an asset: it can steer today's decision, and when it resolves it measures how far ahead we can actually see. Origin (operator, 2026-07-11): "I kept having to give you the ideas — you should see what's coming 5, 10, 20 steps from now."

When to use this skill

• Commit points: a plan approved, an architecture chosen, a build started, a direction picked over alternatives.
• Scaling-shaped decisions: growth targets, hiring, infra, pricing, market entry.
• Shipping anything whose failure modes surface on a delay (integrations, data models, public APIs, contracts, content).
• Reviewing a plan whose risks are all present-tense.

When NOT to use

• Trivial or fully reversible work — a projection pass on a one-line fix is theater.
• As a substitute for failure-mode-awareness (present-design risks) or plan-gate (the plan itself) — this runs WITH them, on the time axis.
• To manufacture certainty: a 0.6 prediction is not a roadmap commitment, and foresight entries are not promises.

The procedure

1. Walk the trajectory, not the snapshot. At the commit point, project along the axis that matters (steps, scale, time): what does this look like at 5, 10, 20 steps ahead? At each horizon ask four questions: what breaks? what becomes necessary? what becomes cheap or possible? what will we wish we had started now?
2. Pre-register 3–7 predictions. Each carries: the claim, a credence (0–1), a resolve-by date, and the OBSERVABLE that resolves it. Vague predictions ("things will get complex") are inadmissible — if no observation could score it, rewrite it or drop it. Log them where the project's hypotheses live (the hypothesis queue, class foresight, or the plan doc).
3. Keep the horizons distinct. Near entries (≈5 steps) protect the current build; far entries (≈20) are allowed to be weird — they are where the value is, because a high-credence far prediction with a cheap present-day hedge is a TASK, not a note (start the data collection now; reserve the name now; design the schema for the split now).
4. Include positive foresight. Opportunities, compounding assets, and options-worth-buying — not only failures. Foresight is not pessimism with dates.
5. Resolve on arrival. When a resolve-by date passes, score the prediction (right / wrong / unresolvable-as-written) BEFORE writing new ones. Unresolved predictions past their date are debt; calibration only accrues from resolved ones.
6. Feed the result back. Resolved predictions are evidence: wrong ones go to self-improvement-loop (what did the projection miss?); patterns across resolutions become extract-approach notes; systematically over- or under-confident horizons recalibrate the next round's credences.