outcome-tracker
GitHub用于追踪决策预测并评估框架准确性。在决策时记录可证伪的预测，定期根据实际结果评分（命中/未命中等），并生成按框架和置信度分组的校准报告，以量化不同方法论的预测能力。
Trigger Scenarios
Install
npx skills add mohitagw15856/pm-claude-skills --skill outcome-tracker -g -y
SKILL.md
Frontmatter
{
"name": "outcome-tracker",
"description": "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:
| Field | Rule |
|---|---|
claim |
One sentence, future tense, about a measurable effect ("onboarding redesign lifts activation") |
metric |
The exact instrumented metric, with today's baseline |
predicted |
Direction + magnitude band ("+10-20% relative") — bands beat point estimates |
confidence |
0.5–0.95, from the author, recorded before the outcome is knowable |
check_by |
The date the effect should be visible if real; also the review trigger |
framework |
What 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]
| # | Claim | Metric (baseline) | Predicted | Confidence | Check by | Framework |
|---|---|---|---|---|---|---|
| Untestable claims flagged: [claim → what instrumentation would make it testable] |
Review mode:
Outcome review — [date]
| # | Claim | Predicted | Actual | Outcome | Learning |
|---|---|---|---|---|---|
| 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
Version History
- a38bc30 Current 2026-07-05 11:11
