OKR Status Rollup

What this skill does

Combines per-objective check-ins (each with KR-level current values and confidence statements) into a single rollup. Output is an executive-ready summary with red/yellow/green status, weighted confidence, and the top three blockers.

Inputs

• checkins_dir: a directory of per-objective YAML files. Each file: objective, owner, quarter, key_results: [{name, target, current, confidence_pct, blocker?}].
• Optional weights_file: weights per objective (otherwise equal).
• Optional quarter_progress: the share of the quarter elapsed (used for "on-pace" judgment).

Steps

1. Load each YAML; validate schema (objective/owner/quarter/key_results present).
2. Per KR, compute attainment = current / target (handle inverse KRs where lower is better).
3. Determine status:
   • green: attainment > quarter_progress and confidence_pct >= 70.
   • yellow: 0.5 * quarter_progress < attainment <= quarter_progress, OR confidence 40-69.
   • red: attainment <= 0.5 * quarter_progress OR confidence < 40 OR explicit blocker present.
4. Per Objective, roll up KRs with weights (default equal): weighted average attainment, worst-case status (red dominates).
5. Compute portfolio rollup across objectives using weights_file or equal weights.
6. Identify top 3 blockers across objectives — each blocker referenced verbatim with its owner.
7. Generate "asks": for each red KR, surface a one-sentence ask (what would unblock the team).
8. Render the markdown summary: portfolio header, per-objective rows, blockers, asks.
9. Save to okr-rollup-<quarter>.md.

Output

okr-rollup-<quarter>.md with: header (portfolio status, weighted attainment), objective table (status, attainment, owner), blockers section, asks. Plus okr-rollup.json for tooling. Stdout prints portfolio status and red KR count.

Verification

Recompute weighted attainment from raw inputs; the report's number must match. For each red KR, confirm a blocker text exists or confidence is genuinely <40 — a "red without reason" is a process gap, not a real red. Re-run check-ins from the prior week and diff: status churn (green->red->green) is itself a signal worth surfacing.

Edge cases

• Objectives without check-ins: surface as stale status; don't average them in the rollup.
• KRs with non-numeric targets ("Launch X"): use a binary 0/100 attainment based on a done boolean.
• Disagreement between owner and KR data (data says green, owner reports red): trust the owner's confidence; surface the divergence.
• Weights summing to != 1: normalize and warn.