10 Claude prompts that automate weekly OKR reviews in 2026

Weekly OKR reviews drift into status theater because the prep cost is high. Ten Claude prompts — confidence scoring, blocker triage, KR re-baseline, leading-vs-lagging classification, board narrative, OKR-vs-roadmap conflict, alignment tree audit, retroactive grading, stand-up agenda, and end-of-quarter post-mortem — replace 3 to 4 hours of prep with a 30-minute chained review. Each prompt below carries full text, design reasoning, a sample output, and when to use it.

<a href="https://aipromptshub.co/chatgpt-prompt-generator?utm_source=aipromptshub&utm_medium=blog&utm_campaign=okr-prompts-2026" style={{display:"inline-block",padding:"10px 18px",background:"#0a66ff",color:"white",borderRadius:"6px",textDecoration:"none",fontWeight:"bold"}}> Generate your own OKR prompt template → </a>

OKRs were popularized by Andy Grove at Intel, codified for Google by John Doerr in *Measure What Matters* (Portfolio, 2018), and have since become the dominant goal-setting framework for ~70% of mid-market tech companies according to the 2025 Lattice State of People Strategy report and Workboard's 2025 OKR Benchmark. The framework is sound. The weekly cadence is where it breaks.

Three failure modes recur in the data. First, the Gtmhub 2024 Strategy Execution Benchmarks found that 61% of OKR programs collapse within two quarters of adoption, with "weekly review burden" cited as the top reason. Second, Google's own re:Work OKR playbook flags that confidence scoring is the most-skipped weekly ritual because it requires synthesis the operator does not have time for. Third, the Anthropic prompt engineering documentation shows that structured synthesis tasks — exactly what weekly OKR review is — are among the highest-ROI use cases for Claude because the input data is fragmented and the desired output is a small, well-formatted artifact.

The ten prompts below treat the weekly review as a synthesis pipeline. Each prompt does one thing well, accepts a defined input shape, and emits a defined output shape that becomes the input to the next prompt. The chain runs against Claude Sonnet 4.5 or Opus 4.7 — see Anthropic's model documentation for the current generation.

Most teams score KR confidence on a 0.1–1.0 scale (Doerr's default) but skip the rationale. Without rationale, scores are noise. This prompt forces a defensible justification in one paragraph.

**The prompt:**

``` You are an OKR coach reviewing a single key result for the weekly check-in. INPUT: - Key result: <text> - Owner: <name> - Target: <number + unit> - Current: <number + unit> - Last week's confidence: <0.1-1.0> - Trailing 4 weeks of progress: <list> - Known blockers: <list, optional> OUTPUT (JSON): { "confidence": <0.1-1.0>, "delta_from_last_week": <signed number>, "rationale": "<60-90 word paragraph citing the trajectory, the blockers, and the remaining time>", "trajectory_classification": "on-track | at-risk | off-track | ahead" } Rules: - If pace required to hit target exceeds trailing 4-week pace by >40%, classification cannot be "on-track". - Rationale must cite at least one specific number from the input. - Do not invent context not present in the input. ```

**Why it works:** Constraint compliance (Dimension 4 of our 7-point grading rubric) is enforced by the pace math rule. The structured output enforces the rationale length, which is what makes scores defensible downstream.

**Sample output:**

```json { "confidence": 0.4, "delta_from_last_week": -0.2, "rationale": "Trailing 4-week pace is 120 signups/week. Remaining gap of 2,400 over 6 weeks requires 400/week — a 3.3x acceleration. The cited paid-channel blocker has not been resolved. Confidence drops from 0.6 to 0.4 because the gap widened by 280 this week alone.", "trajectory_classification": "at-risk" } ```

**When to use:** Every Monday morning, batched across all KRs. Output feeds prompt #2 and prompt #5.

Blockers documented without an owner and a resolution date become noise. This prompt forces both.

**The prompt:**

``` You are a program manager triaging blockers raised in the weekly OKR review. INPUT: a list of free-text blocker statements written by KR owners. For each blocker, output: { "blocker": "<original text, verbatim>", "category": "dependency | resource | decision | external | unknown", "implied_owner": "<role or name if cited, else 'UNASSIGNED'>", "proposed_resolution_date": "<YYYY-MM-DD or 'NEEDS-DATE'>", "severity": "high | medium | low", "ask_of_leadership": "<one-sentence escalation ask, or 'NONE'>" } Rules: - "UNASSIGNED" and "NEEDS-DATE" outputs must appear if the input is genuinely ambiguous; do not guess. - Severity is high if the blocker affects a KR currently classified at-risk or off-track. - The "ask_of_leadership" field is the single line that would go on a leadership escalation slide. ```

**Why it works:** The explicit `UNASSIGNED` and `NEEDS-DATE` sentinels stop the model from hallucinating owners and dates — a common failure mode flagged in the Anthropic tool use documentation.

**Sample output:** A 6-row table where 4 rows have clear owners, 2 are flagged UNASSIGNED, and the highest-severity row carries a one-line ask: *"Approve the $40K paid-channel budget by Wed so the Q2 signup KR can re-accelerate."*

**When to use:** Tuesday, after KR owners have submitted their blocker notes. Feeds the leadership digest.

Re-baselining mid-quarter is necessary about 20% of the time per Workboard's 2025 benchmark but corrodes credibility if done without a written justification. This prompt produces the justification memo.

**The prompt:**

``` You are an OKR coach writing the re-baseline justification memo for a single key result. INPUT: - Original KR: <text> - Original target: <number + unit> - Proposed new target: <number + unit> - Week of quarter: <1-13> - What changed: <free text> - Owner: <name> OUTPUT: a memo with these exact sections: 1. The change (one line: from X to Y) 2. The trigger (what made the original target wrong — not the team's effort, but the external or upstream condition) 3. The evidence (specific numbers showing the original target is now wrong) 4. The new commitment (what the team is committing to instead, with the same level of stretch) 5. What this means for the parent objective (does the company-level objective still hold?) Rules: - Do not use the phrases "due to unforeseen circumstances" or "market conditions". - The memo must be under 250 words. - The "trigger" section must distinguish between external reality changes and original-target-was-wrong; never blame execution. ```

**Why it works:** Forbidden-phrase constraints (the rubric's Dimension 4) eliminate the two clichés that flag a memo as defensive. The explicit five-section template forces structure that survives a board read.

**Sample output:** A 230-word memo opening with *"From 10,000 trial signups to 6,500. Trigger: the Q1 paid-channel rate card increase from $4.20 to $9.80 CPM was not reflected in the original model..."*

**When to use:** Within 48 hours of a KR being re-classified off-track for a second consecutive week.

Leading indicators predict; lagging indicators confirm. Doerr's *Measure What Matters* devotes a chapter to this distinction, but most teams have never sorted their KRs by it.

**The prompt:**

``` You are an OKR analyst classifying key results as leading or lagging indicators. INPUT: a list of KRs, each with target metric and definition. For each KR, output: { "kr": "<text>", "classification": "leading | lagging | mixed", "explanation": "<one sentence — what would have to change first for this number to move?>", "time_lag_to_objective": "<days/weeks/quarters>", "recommended_pairing": "<the leading or lagging KR that should pair with this one, if any>" } Rules: - Revenue, ARR, customer count, and churn are almost always lagging. - Activation rate, qualified pipeline, weekly active users, and product-event counts are usually leading. - If a portfolio has >70% lagging KRs, flag the portfolio as "weak forecasting signal". ```

**Why it works:** The explicit guardrails on revenue/ARR (lagging) and activation/pipeline (leading) anchor the classification against the most-common confusion pattern.

**Sample output:** A 12-KR portfolio sorted into 4 leading, 7 lagging, 1 mixed, with the portfolio flagged "weak forecasting signal" — the cue to add 3–4 leading KRs next quarter.

**When to use:** Once per quarter, immediately after drafting the OKR set. Re-run if the portfolio shifts.

Board read-outs are where weekly review work shows up externally. This prompt drafts the narrative.

**The prompt:**

``` You are a chief of staff drafting the OKR section of the monthly board update. INPUT: - Company objective: <text> - 4-7 KRs with: target, current, confidence (0.1-1.0), trajectory classification - Top 3 blockers with severity - Last month's confidence averages OUTPUT: a 300-word narrative with this structure: - Paragraph 1: headline status (one of: tracking ahead, on track, mixed, at risk) - Paragraph 2: what's working and why (cite 2 specific KRs with numbers) - Paragraph 3: what's not working and the plan (cite 1-2 KRs with the specific intervention) - Paragraph 4: the ask of the board (one explicit ask, or "no asks this month") Rules: - Lead with the honest assessment, not the optimistic one. - Every paragraph must cite at least one number from the input. - Do not use the word "exciting". - Do not invent context. ```

**Why it works:** The "lead with the honest assessment" rule pushes against the LLM's default optimism bias, documented in Anthropic's Constitutional AI paper.

**Sample output:** A 295-word narrative opening *"Q2 is tracking mixed against the company objective of doubling activated customers. Activation rate is up from 18% to 24% (KR2), but the trial-to-paid KR slipped from 4.1% to 3.6% this month..."*

**When to use:** Day 25–28 of the month, after the weekly confidence scores have stabilized.

OKRs say "what." Roadmaps say "how." When they diverge silently, the quarter ends with shipped product and missed KRs. This prompt finds the gap.

**The prompt:**

``` You are a strategy reviewer auditing the alignment between this quarter's OKRs and the engineering roadmap. INPUT: - OKRs: list of objectives + KRs - Roadmap: list of features/initiatives with their associated team and estimated effort For each KR, output: { "kr": "<text>", "roadmap_items_supporting": [<list of roadmap items that directly move this KR>], "alignment_score": "strong | partial | none", "missing_work": "<what would need to be on the roadmap to make this KR achievable, if anything>" } Also output a global section: { "orphaned_roadmap_items": [<items that don't connect to any KR>], "uncovered_krs": [<KRs with no supporting roadmap items>], "summary": "<2-sentence summary of alignment health>" } Rules: - Do not assume a roadmap item supports a KR unless the connection is explicit in the input. - Orphaned roadmap items are not automatically bad — flag them, do not condemn them. ```

**Why it works:** The explicit "do not assume" rule prevents the most common synthesis failure: inventing alignments that look plausible but don't hold.

**Sample output:** A matrix showing 8 KRs, 3 of which have no roadmap support (uncovered) and 4 roadmap items with no KR (orphaned), plus a summary: *"Alignment is partial. Three high-priority KRs lack supporting roadmap work and will miss without intervention by week 4."*

**When to use:** Week 1 of each quarter, then again at week 6.

Company → team → individual OKR cascades develop drift. This prompt finds it.

**The prompt:**

``` You are an OKR auditor reviewing the alignment tree. INPUT: the OKR tree as nested JSON — company objective at top, team objectives mid-level, individual KRs at leaf. For each non-leaf node, output: { "node": "<text>", "level": "company | team | individual", "children_count": <number>, "alignment_assessment": "tight | loose | broken", "drift_signal": "<one sentence — where the children diverge from the parent intent>", "recommended_fix": "<one of: reword parent, reword children, kill a child, add a missing child>" } Rules: - A team objective is "tight" if every child KR, if achieved, would move the team objective forward measurably. - A team objective is "broken" if any child KR could be achieved while the team objective regresses. - Cite the specific child node in any "broken" assessment. ```

**Why it works:** The "broken if any child KR could be achieved while team objective regresses" rule is the right test — it catches the Goodhart's-law cases that every other alignment audit misses.

**Sample output:** A 4-team audit showing 2 tight, 1 loose, 1 broken. The broken team's drift signal: *"The team objective 'improve activation' includes a child KR 'ship 6 onboarding experiments' — six experiments could ship without activation moving, breaking the parent."*

**When to use:** Twice per quarter — week 2 and week 8.

Sometimes you inherit OKRs with no scoring system. This prompt produces a scoring scaffold so end-of-quarter grading is not arbitrary.

**The prompt:**

``` You are an OKR grader building a retroactive scoring scaffold for a key result that was written without scoring criteria. INPUT: - KR text: <text> - Current value: <number + unit> - Original target: <number + unit> - Stretch interpretation: was this a committed KR (full score = full target) or aspirational (full score = 70% of target)? OUTPUT: { "scoring_scale": [ {"score": 1.0, "threshold": "<value>", "interpretation": "<text>"}, {"score": 0.7, "threshold": "<value>", "interpretation": "<text>"}, {"score": 0.4, "threshold": "<value>", "interpretation": "<text>"}, {"score": 0.0, "threshold": "<value>", "interpretation": "<text>"} ], "current_score": <0.0-1.0>, "score_rationale": "<one paragraph>", "caveat": "<the single risk in this retroactive scoring — what the original authors might have intended differently>" } Rules: - For aspirational KRs, 0.7 score should require ~70% of the stated target. - For committed KRs, 0.7 score should require ~90% of the stated target. - The "caveat" must be honest; never claim full confidence in retroactive scoring. ```

**Why it works:** The explicit aspirational-vs-committed threshold rule is Doerr's original framework (Chapter 9 of *Measure What Matters*) and the retroactive caveat preserves intellectual honesty.

**Sample output:** A 4-row scoring table for a KR "Reach 10,000 trial signups." Current score 0.65 with rationale and a caveat: *"If the original authors intended this as committed (full target = full score), the current score would be 0.5 instead. Verify intent with the original author before publishing."*

**When to use:** Within the first 2 weeks of taking over an OKR set you didn't write.

Post-mortems that conclude "we missed because we didn't have enough resources" produce no learning. This prompt forces a specific causal analysis.

**The prompt:**

``` You are an OKR coach scaffolding the end-of-quarter post-mortem. INPUT: - Final score for each KR (0.0-1.0) - The confidence trajectory across 13 weeks for each KR - Re-baseline events that occurred mid-quarter - Blockers logged across the quarter For each KR scored below 0.7 OR above 1.0, output: { "kr": "<text>", "final_score": <0.0-1.0>, "category": "missed_by_a_lot | missed_by_a_little | hit_target | exceeded_significantly", "root_cause": "<one of: target was wrong, plan was wrong, execution gap, external shift, dependency unmet>", "root_cause_evidence": "<specific weeks/blockers/deltas that support the root cause>", "what_would_change_next_quarter": "<one specific behavior change>", "honest_assessment": "<one sentence — was this knowable in advance?>" } Rules: - "Lack of resources" is not a root cause — it is a symptom. Push past it. - Exceeding significantly (>1.0) is also a learning event — the target was probably wrong. - "honest_assessment" must say "yes, knowable in advance" or "no, genuinely unpredictable" or "partially knowable" with rationale. ```

**Why it works:** The "lack of resources is not a root cause" rule is the rubric-violation that breaks most post-mortems. Forcing it surfaces real causes.

**Sample output:** A 5-KR post-mortem in which 3 missed KRs trace to "target was wrong" (knowable in advance: yes), 1 to "external shift" (knowable: no), and 1 exceeded KR traces to "target was wrong — too low" — all of which feed concrete next-quarter design changes.

**When to use:** Week 13 of the quarter, before the next-quarter planning session begins.

The four "weekly" prompts (1, 2, 9, plus the optional re-baseline 3) form the recurring loop. The quarterly prompts (4, 6, 7, 10) form the strategic boundary work. Prompt 5 is monthly. Prompt 8 is one-time per team transition.

<a href="https://aipromptshub.co/blog-post-outline?utm_source=aipromptshub&utm_medium=blog&utm_campaign=okr-prompts-2026" style={{display:"inline-block",padding:"10px 18px",background:"#0a66ff",color:"white",borderRadius:"6px",textDecoration:"none",fontWeight:"bold",marginTop:"12px"}}> Build a custom OKR review template → </a>

The chain that replaces a 3–4 hour Monday prep with a 30-minute review:

1. **Sunday 6 p.m. (5 min compute, 0 min human).** Run prompt #1 against every KR with the trailing 4-week pace data. Output is a confidence-score table with rationale. 2. **Sunday 6:05 p.m. (3 min compute).** Run prompt #2 against the blocker dump from KR owners (collected in a shared doc on Friday). 3. **Sunday 6:10 p.m. (5 min human review).** Skim the two outputs. Flag any KR where the model's confidence delta seems wrong; override with rationale. 4. **Monday 8:00 a.m. (3 min compute).** Run prompt #9 with the outputs from #1 and #2 as inputs. Output is the Monday stand-up agenda. 5. **Monday 9:00 a.m. (30 min meeting).** Use the agenda. Start with the biggest delta. Resolve blockers in the final 5 minutes. 6. **Monday post-stand-up (ad hoc).** If a re-baseline came up, run prompt #3. If the OKR-vs-roadmap conflict prompt (#6) hasn't run in 6 weeks, run it now.

The compounding effect is that prompt #1 produces structured input for prompt #9, which produces a focused agenda, which produces resolved blockers, which feed back into prompt #1 next week. The chain is the operating system; individual prompts are the modules.

For the strategic boundary work — prompts 4, 6, 7, and 10 — schedule a 2-hour quarterly block. Run all four in sequence with a single operator reviewing outputs. Total quarterly cost: ~30 minutes of Claude API ($2–$4 in token spend at current Sonnet 4.5 pricing per the Anthropic pricing page) plus 2 hours of operator review.

<a href="https://aipromptshub.co/chatgpt-prompt-generator?utm_source=aipromptshub&utm_medium=blog&utm_campaign=okr-prompts-chain" style={{display:"inline-block",padding:"10px 18px",background:"#0a66ff",color:"white",borderRadius:"6px",textDecoration:"none",fontWeight:"bold",marginTop:"12px"}}> Get the chained review template → </a>

### Which Claude model should I use for OKR review prompts?

Claude Sonnet 4.5 is the right default for prompts 1, 2, 4, 8, and 9 — fast, cheap, and accurate on structured synthesis. Use Opus 4.7 for prompts 5 (board narrative), 7 (alignment tree audit), and 10 (post-mortem scaffold) where the synthesis depth matters more than latency. See Anthropic's model selection guide for the current generation.

### Will Claude hallucinate KR data if my input is incomplete?

Yes, unless you constrain it. Every prompt above has an explicit "do not invent context not present in the input" rule. This is the single most important guardrail for OKR work, where hallucinated confidence scores corrode trust faster than missing data. The Anthropic prompt engineering guide covers the underlying technique (explicit refusal-to-fabricate instructions) in more depth.

### Can these prompts replace the human OKR coach?

No. The prompts replace the synthesis labor; they do not replace the judgment about which trade-offs to make. A human still decides whether to re-baseline, whether a blocker is genuine or political, and whether the team objective is correctly framed. The prompts produce the artifacts the human reviews. This is the same pattern Doerr describes in *Measure What Matters* — OKRs are a thinking tool, not a decision-making tool.

### How do I integrate these prompts into our existing OKR software (Lattice, Workboard, Gtmhub)?

All three platforms expose REST APIs that emit KR data in JSON. Pipe the JSON into the prompt input shape (each prompt above declares its expected input). Output flows back via API or — more commonly — into a Slack channel as a daily/weekly digest. Workboard and Gtmhub both have AI features in beta that overlap with prompts 1 and 5; the value of running the prompts yourself is control over the rules (forbidden phrases, structural constraints) that those platforms don't yet expose.

### What if my OKRs don't have confidence scores?

Start with prompt #1 — generate the first week of confidence scores against your existing KR data. Without trailing data, the rationale will be weaker (the model has only the current value to work with). After 4 weeks of running prompt #1, the rationale quality jumps because the trailing data becomes available. This is the bootstrap cost; it is paid once.

### Are the sample outputs above synthesized or real?

Synthesized for illustration. Real outputs vary by model, temperature, and input quality. The structure and constraint compliance are representative of what Claude Sonnet 4.5 produces with the prompts as written; the specific numbers are illustrative.

### How do I know these prompts won't go stale as Claude evolves?

The prompts encode rules (pace math, forbidden phrases, structural constraints) rather than relying on model behavior. As Claude evolves, the same rules will keep producing structured output — the quality will improve, but the artifact shape will hold. Re-test the chain against each major model release; the Anthropic changelog is the source of truth for what changed.

- John Doerr, *Measure What Matters* (Portfolio, 2018) — the canonical OKR text. - Google re:Work OKR playbook — Google's public-facing OKR documentation. - Lattice 2025 State of People Strategy report — OKR adoption data. - Workboard 2025 OKR Benchmark — weekly review benchmarks. - Gtmhub 2024 Strategy Execution Benchmarks — OKR program collapse data. - Anthropic prompt engineering documentation — Claude prompt best practices. - Anthropic Constitutional AI paper — model optimism bias documentation. - Anthropic model documentation — Sonnet/Opus selection.

---

<script type="application/ld+json" dangerouslySetInnerHTML={{ __html: JSON.stringify({ "@context": "https://schema.org", "@type": "Article", "headline": "10 Claude prompts that automate weekly OKR reviews in 2026", "datePublished": "2026-06-10", "dateModified": "2026-06-10", "author": { "@type": "Person", "name": "Dr. Elena Vasquez", "jobTitle": "UX research lead" }, "publisher": { "@type": "Organization", "name": "AIPromptsHub", "url": "https://aipromptshub.co" }, "mainEntityOfPage": "https://aipromptshub.co/blog/10-claude-prompts-weekly-okr-reviews-2026", "description": "Ten production-grade Claude prompts for weekly OKR reviews — confidence scoring, blocker triage, KR re-baseline, board readouts, and a 30-minute review chain.", "citation": [ "John Doerr, Measure What Matters (Portfolio, 2018)", "https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/", "https://lattice.com/library/2025-state-of-people-strategy", "https://www.workboard.com/resources/", "https://gtmhub.com/resources/", "https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview" ] }) }} />

<script type="application/ld+json" dangerouslySetInnerHTML={{ __html: JSON.stringify({ "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Which Claude model should I use for OKR review prompts?", "acceptedAnswer": { "@type": "Answer", "text": "Claude Sonnet 4.5 is the right default for prompts 1, 2, 4, 8, and 9 — fast, cheap, and accurate on structured synthesis. Use Opus 4.7 for prompts 5, 7, and 10 where synthesis depth matters more than latency." } }, { "@type": "Question", "name": "Will Claude hallucinate KR data if my input is incomplete?", "acceptedAnswer": { "@type": "Answer", "text": "Yes, unless you constrain it. Every prompt above has an explicit 'do not invent context not present in the input' rule, the single most important guardrail for OKR work." } }, { "@type": "Question", "name": "Can these prompts replace the human OKR coach?", "acceptedAnswer": { "@type": "Answer", "text": "No. The prompts replace synthesis labor; they do not replace judgment about trade-offs, re-baseline decisions, or whether a blocker is genuine. The prompts produce artifacts the human reviews." } }, { "@type": "Question", "name": "How do I integrate these prompts into Lattice, Workboard, or Gtmhub?", "acceptedAnswer": { "@type": "Answer", "text": "All three platforms expose REST APIs that emit KR data in JSON. Pipe the JSON into the prompt input shape and route the output back via API or into a Slack digest." } }, { "@type": "Question", "name": "What if my OKRs don't have confidence scores?", "acceptedAnswer": { "@type": "Answer", "text": "Start with prompt #1 — generate the first week of confidence scores against existing KR data. Rationale quality jumps after 4 weeks when trailing data becomes available." } }, { "@type": "Question", "name": "Are the sample outputs synthesized or real?", "acceptedAnswer": { "@type": "Answer", "text": "Synthesized for illustration. The structure and constraint compliance are representative of Claude Sonnet 4.5 outputs; the specific numbers are illustrative." } }, { "@type": "Question", "name": "How do I know these prompts won't go stale as Claude evolves?", "acceptedAnswer": { "@type": "Answer", "text": "The prompts encode rules (pace math, forbidden phrases, structural constraints) rather than relying on model behavior. The artifact shape holds across model releases." } } ] }) }} />