← LeaderboardThe Skill Leaderboard

outcome-tracker

Record the testable predictions inside a decision, then score them against reality later — so frameworks earn trust from outcomes, not vibes. Use when committing to a prioritisation, forecast, or plan (to log what it predicts), when asked to review what actually happened, or to compute how well-calibrated past RICE scores, forecasts, or bets have been. Produces a prediction record at decision time, and a calibration report with per-framework hit rates at review time.

Published by mohitagw15856 ↗mohitagw15856/pm-claude-skills

Try your first task

outcome-tracker

Start a fresh conversation. Replace the highlighted placeholders.

Use outcome-tracker to turn [decision artifact] into falsifiable prediction records in [record location], flagging claims that lack a measurable metric, range, confidence, or review date.

Required inputs

  • [decision artifact]
  • [record location]

User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗

SKILL.md

name: outcome-trackerdescription: "Record the testable predictions inside a decision, then score them against reality later — so frameworks earn trust from outcomes, not vibes. Use when committing to a prioritisation, forecast, or plan (to log what it predicts), when asked to review what actually happened, or to compute how well-calibrated past RICE scores, forecasts, or bets have been. Produces a prediction record at decision time, and a calibration report with per-framework hit rates at review time."

Outcome Tracker Skill

Every prioritisation, forecast, and launch plan makes predictions — then everyone forgets to check them. This skill closes the loop: extract the predictions at decision time, park them somewhere durable, and score them against reality on a schedule. Over time it answers the question no one can answer today: which of our frameworks actually predict outcomes?

What This Skill Produces

  • At decision time: a prediction record — each claim made falsifiable, with a metric, a direction/target, a check-by date, and a stated confidence
  • At review time: an outcome scoring of due predictions (hit / miss / partial / unresolvable), with what was learned
  • On demand: a calibration report — per-framework and per-confidence-band hit rates from the accumulated records

Required Inputs

Ask for (if not already provided):

  • Mode — record (new decision), review (score due predictions), or calibrate (analyse the history)
  • Record mode: the decision artifact (RICE table, forecast, launch plan, OKR set) and where records live (a predictions/ folder in the Brain, or a JSON/markdown file in the repo)
  • Review mode: the stored predictions plus current metric values for the due ones
  • Calibrate mode: the prediction history (the calculator below reads it as JSON)

Making Claims Falsifiable (record mode)

Walk the artifact and force each implicit claim into this shape — a prediction that can't fill the row doesn't get recorded, it gets flagged as untestable:

FieldRule
claimOne sentence, future tense, about a measurable effect ("onboarding redesign lifts activation")
metricThe exact instrumented metric, with today's baseline
predictedDirection + magnitude band ("+10-20% relative") — bands beat point estimates
confidence0.5–0.95, from the author, recorded before the outcome is knowable
check_byThe date the effect should be visible if real; also the review trigger
frameworkWhat produced the claim (rice-prioritisation, gut call, sales-forecasting-model…) — this is what calibration is about

Typical yields: a RICE table → one prediction per top-3 item (impact claims); a forecast → the quarter's number; a launch plan → its success metrics; an OKR set → each KR's target.

Scoring (review mode)

For each prediction past its check_by: hit (actual within the predicted band), partial (right direction, wrong magnitude), miss (wrong direction or no effect), unresolvable (metric never instrumented, or confounded by a simultaneous change — record why; a pile of unresolvables is itself a finding about how the team instruments its bets). Never rescore or reinterpret the original claim to make it a hit — the record is append-only.

Programmatic Helper

scripts/outcome_calibration.py (stdlib-only) computes the calibration report from a JSON array of prediction records:

python3 scripts/outcome_calibration.py predictions.json
echo '[{"framework":"rice-prioritisation","confidence":0.8,"outcome":"hit"}]' | python3 scripts/outcome_calibration.py -

It reports per-framework hit rates (hits + half-credit partials over resolved), per-confidence-band calibration (do 80%-confidence claims land ~80% of the time?), and flags overconfident bands. Use the computed numbers; don't estimate them.

Brain Integration

If a professional-brain (brain/) exists, records live in brain/predictions/<id>.md (one file per prediction, fields as frontmatter, [hunch]/[data] provenance on the baseline) and review mode starts by listing files with check_by in the past. Pair with schedule-recipe to run review mode monthly — outcome tracking only works as a ritual, not an intention.

Output Format

Record mode:

Predictions registered: [decision] — [date]

#ClaimMetric (baseline)PredictedConfidenceCheck byFramework
Untestable claims flagged: [claim → what instrumentation would make it testable]

Review mode:

Outcome review — [date]

#ClaimPredictedActualOutcomeLearning
Now due next: [next check_by dates]

Calibrate mode: the calculator's report plus 2-3 sentences of interpretation — which framework has earned trust, where the team is overconfident, and the single instrumentation fix that would resolve the most unresolvables.

Quality Checks

  • Every recorded prediction has all six fields — no "improve activation" without a metric, band, and date
  • Confidence was stated before the outcome was knowable, never backfilled
  • Review scored every due prediction, including the embarrassing ones — no silent skips
  • Unresolvables carry a reason, and the calibration report counts them separately from misses
  • Calibration numbers come from the calculator, not estimation

Anti-Patterns

  • Do not reinterpret a claim after the fact so it scores as a hit — the original wording is the contract
  • Do not record point estimates when the author thinks in ranges — bands are honest, points are theatre
  • Do not let a framework take credit for hits and blame "execution" for misses — score the prediction as made
  • Do not compute calibration on fewer than ~10 resolved predictions per framework — report "insufficient history" instead
  • Do not skip recording because the decision feels obvious — obvious bets that miss are the most valuable calibration data

Example Trigger Phrases

  • "Log what this plan predicts."
  • "Review what actually happened."
  • "Score last quarter's forecast against reality."
  • "Did our prioritisation framework work?"