agentsclimarketplace

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.

Install
npx -y skills add BridgeLogicsProjects/okr-skill-coach --skill okr-retrospective-coach

Assembled 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

  1. Ready to score and reflect → Run the Scoring and Retrospective below
  2. Wants to carry forward unfinished work → Run the Carry-Forward Protocol
  3. Same problems keep repeating cycle after cycle → Run the Pattern Audit
  4. 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

ScoreMeaning
0.7 to 1.0Strong delivery. Ambitious target mostly or fully achieved.
0.4 to 0.6Meaningful progress. Target not fully reached but real work done.
0.1 to 0.3Work began but result did not materialize.
0.0No 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

PatternLikely Root Cause
OKRs consistently scored below 0.4Targets too ambitious without support, or Key Results are outputs not outcomes
OKRs consistently scored above 0.9Targets not ambitious enough — sandbagging
Same Key Results repeat every cycleWork is ongoing operations, not OKR-worthy goals
OKRs set but not referenced mid-cycleNo check-in rhythm, or leadership not modeling OKR use
Team does not believe in OKRsOKRs 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.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.