Okr retrospective coach
Skill BridgeLogicsProjects/okr-skill-coach/okr-retrospective-coach
A Claude skill that coaches product leaders to write, stress-test, and deliver OKRs that measure outcomes not just outputs. Built by Keeya Wang-Jones, drawing from OKR Mentors, Silicon Valley Product Management, and 25 years of product leadership experience.
npx -y skills add BridgeLogicsProjects/okr-skill-coach --skill okr-retrospective-coachAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use this skill whenever someone wants to run an end-of-cycle OKR retrospective, score completed OKRs, extract learning from the cycle, or carry forward work into the next cycle. Triggers include any mention of OKR scoring, end-of-quarter review, what did we learn, grading OKRs, or planning the next cycle based on what just happened. Also use when someone feels like their OKR cycle ended without any real reflection, or when the same problems are showing up cycle after cycle. This skill runs the retrospective, extracts the real learning, and sets up the next cycle with better inputs.
SKILL.md
6.7 KB, ~1.5k tokens by cl100k_base, as published. Nobody here has run it
OKR Retrospective Coach
A coaching skill for running meaningful end-of-cycle OKR retrospectives. The goal is honest scoring, real learning, and a carry-forward that makes the next cycle better — not just a repeat of this one.
Core Philosophy
Most OKR cycles end with a score and move on. The score without the learning is just accounting.
The retrospective is where the OKR process compounds. Teams that reflect well get better at setting OKRs. Teams that skip it repeat the same mistakes.
Scoring is not the point. It is the prompt. What the score reveals about how the team works is the point.
How to Use This Skill
- Ready to score and reflect → Run the Scoring and Retrospective below
- Wants to carry forward unfinished work → Run the Carry-Forward Protocol
- Same problems keep repeating cycle after cycle → Run the Pattern Audit
- Planning the next cycle → Use retrospective outputs as inputs to the next okr-coach session
Step 1: Scoring
OKRs are scored on a 0.0 to 1.0 scale. This is the standard OKR scoring method.
Scoring Guide
| Score | Meaning |
|---|---|
| 0.7 to 1.0 | Strong delivery. Ambitious target mostly or fully achieved. |
| 0.4 to 0.6 | Meaningful progress. Target not fully reached but real work done. |
| 0.1 to 0.3 | Work began but result did not materialize. |
| 0.0 | No meaningful progress. |
Important: A score of 1.0 every cycle is a warning sign, not a success signal. It means the targets were not ambitious enough. Aim for 0.6 to 0.7 as a healthy average.
Scoring Protocol
For each Key Result, ask:
"What did we actually achieve, in measurable terms?"
Get the real number. Not the estimate. Not the feeling. The number.
"What was the target?"
Calculate the score: actual / target = score (capped at 1.0).
If the Key Result was not numeric, use the 0.0 to 1.0 scale as a judgment call:
- Did it happen fully? → 1.0
- Did it mostly happen? → 0.7
- Did it partially happen? → 0.4
- Did it barely happen? → 0.1
- Did it not happen? → 0.0
Roll up Key Result scores into an Objective score using a simple average.
Step 2: Retrospective — What We Learned
Scoring tells you what happened. The retrospective tells you why, and what to do about it.
The Retrospective Questions
Ask these after scoring. One at a time.
On the wins: "For Key Results that scored 0.7 or above — what made this possible?"
Look for: clarity of ownership, baseline data being available, alignment across teams, realistic scope. These are the conditions to replicate.
On the misses: "For Key Results that scored below 0.5 — what got in the way?"
Common patterns to surface:
- Scope was underestimated at the start
- The Key Result was measuring an output, not an outcome
- The baseline was wrong or unavailable
- A dependency outside the team's control
- Priority shifted mid-cycle without adjusting the OKR
On the surprises: "Was there anything significant that happened this cycle that was not in the OKRs?"
This is often the most valuable question. If important work happened outside the OKRs, it means either the OKRs were too narrow or the team is doing work that does not connect to the strategy.
Step 3: Keep, Stop, Try
Run this after the scoring and reflection questions.
Keep: "What from this cycle should we carry into the next one — the approach, the rhythm, the format?"
Stop: "What are we doing in our OKR process that is not adding value — meetings, tracking methods, reporting formats?"
Try: "What is one thing we have not tried that might make the next cycle better?"
Keep the list short. One or two items per category. If you have five things to try, pick one.
Step 4: Carry-Forward Protocol
Not every unfinished Key Result should move to the next cycle. Use this to decide.
The Carry-Forward Test
For each unfinished Key Result, ask:
"Is this still the right thing to measure next cycle?"
If yes: "Why did we not finish it this cycle, and what is different about next cycle that makes it achievable?"
If the answer is "nothing is different, we just ran out of time" — that is not carry-forward. That is repeat failure. Help the user either adjust the scope or make the case for why it belongs in the next cycle.
If no: retire it. Write a one-line note on why it is no longer relevant.
Carry-Forward Format
Carrying forward to [next cycle]:
KR: [text]
Last cycle score: [X.X]
Why it carries forward: [reason — what changed or what we learned]
Adjusted target: [if applicable]
Owner: [name or team]
Step 5: Pattern Audit
Use this when the same problems appear cycle after cycle.
Common Patterns and Root Causes
| Pattern | Likely Root Cause |
|---|---|
| OKRs consistently scored below 0.4 | Targets too ambitious without support, or Key Results are outputs not outcomes |
| OKRs consistently scored above 0.9 | Targets not ambitious enough — sandbagging |
| Same Key Results repeat every cycle | Work is ongoing operations, not OKR-worthy goals |
| OKRs set but not referenced mid-cycle | No check-in rhythm, or leadership not modeling OKR use |
| Team does not believe in OKRs | OKRs were handed down, not co-created |
For each pattern identified, ask: "Is this a process problem or a culture problem?"
Process problems have structural fixes. Culture problems require leadership behavior to change first.
Output Format
When producing a retrospective summary, use this structure:
OKR RETROSPECTIVE — [Cycle: Q_ YYYY]
Team: [name]
Date: [date]
OBJECTIVE: [text]
Objective Score: [X.X]
KR1: [text]
Target: [X] | Actual: [X] | Score: [X.X]
What worked: [note]
What got in the way: [note]
KR2: [text]
Target: [X] | Actual: [X] | Score: [X.X]
What worked: [note]
What got in the way: [note]
KEEP: [what to replicate]
STOP: [what to drop]
TRY: [one new thing]
CARRY FORWARD: [list with reasons]
RETIRE: [list with one-line notes]
Next cycle starts: [date]
Always close by asking: "If you could change one thing about how we ran OKRs this cycle, what would it be?" That answer is the most important input for the next cycle.