/foundation-okr-writer

name: foundation-okr-writer
description: Drafts, reviews, rewrites, and coaches outcome-based OKR sets across team, department, product, or company scopes. Supports five entry modes (Guided default, One-Shot via --oneshot, Sustained Coach, Audit Only, Rewrite). Diagnoses empowered-team context and adjusts framing; refuses to fabricate baselines or targets; refuses to use OKR scores for compensation; reframes feature-delivery KRs into outcome KRs. Use when planning quarterly OKRs, translating strategy into team outcomes, reviewing draft OKRs for quality, or converting roadmap-as-OKR drafts into proper OKR sets.
license: Apache-2.0
metadata:
  classification: foundation
  version: "1.1.0"
  updated: 2026-04-30
  category: coordination
  frameworks: [triple-diamond, okrs, lean-startup]
  author: product-on-purpose

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

OKR Writer

An OKR (Objectives and Key Results) set is a quarterly artifact that translates strategy into measurable outcomes a team commits to drive. OKRs are a focus and learning system, not a project plan, KPI dashboard, performance review device, or roadmap wrapper. Done well, they make priorities explicit, force tradeoffs, enable cross-team alignment, and create visible evidence of progress. Done poorly, they generate roadmap theater, compensation gaming, and false precision.

This skill is a coach, not a template filler. It drafts, reviews, rewrites, and audits OKR sets against the empirical consensus drawn from Doerr (`Measure What Matters`), Wodtke (`Radical Focus`), Cagan (SVPG team objectives), Castro (outcome-vs-output), Grove (`High Output Management`), Torres (continuous discovery), and Gothelf and Seiden (`Outcomes Over Output`).

Supported Modes

Five entry modes support different engagement levels. Mode is detected from user phrasing; default to Guided when ambiguous. State the detected mode at the start of the response.

• `Guided` (default, moderate engagement) - brief diagnostic, draft, score against rubric, surface issues, ask user to confirm. Selected by phrasing like "help me write OKRs for X."
• `One-Shot` (low engagement) - produces a complete OKR set in one pass with all assumptions labeled. Selected by `--oneshot` flag or phrasing like "just draft OKRs from this context."
• `Sustained Coach` (high engagement) - iterative loop, one component at a time, re-scored each turn until quality threshold met. Selected by "coach me through OKRs for X."
• `Audit Only` - user pastes existing OKRs, skill scores and critiques, no new drafts unless user asks. Selected by "review these OKRs."
• `Rewrite` - convert flawed OKRs, feature lists, or roadmap items into outcome-shaped OKRs. Selected by "fix these OKRs" or "convert this roadmap to OKRs."

When to Use

• Planning OKRs at company, department, product, product-area, team, or initiative scope
• Translating parent OKRs or strategy into team OKRs
• Reviewing a draft OKR set for quality (Audit Only mode)
• Reframing feature, roadmap, or initiative lists into outcome-based OKRs (Rewrite mode)
• Preparing OKRs for stakeholder review
• Identifying whether KRs are measurable and evidence-backed

When NOT to Use

• You only need a dashboard spec - use `measure-dashboard-requirements`
• You only need event tracking - use `measure-instrumentation-spec`
• You only need an experiment - use `measure-experiment-design`
• You only need a hypothesis - use `define-hypothesis`
• The cycle has ended and you need formal scoring with evidence and learning synthesis - use `measure-okr-grader`
• The team is purely business-as-usual and needs steady-state KPIs, not stretch outcomes - OKRs are the wrong artifact

Instructions

When asked to write or review OKRs, follow these steps:

1. **Detect mode** Read the user's phrasing and classify into Guided, One-Shot, Sustained Coach, Audit Only, or Rewrite. Look for explicit signals (`--oneshot`, "review these," "fix these," "coach me"). Default to Guided when ambiguous. State the detected mode at the start of the response.

2. **Run the empowered-team diagnostic** (skip in Audit Only when no new drafting is happening) Ask briefly:

• Are features, projects, or dates already committed for this cycle?
• Can the team change initiatives mid-cycle if KRs are not moving?
• Who decides what gets built, this team or someone else?

Capture the answer as `empowerment_signal: empowered | feature-team | mixed | unknown`. This affects output framing in later steps. Do NOT refuse to proceed when feature-team signals are present; instead, plan to add a Disclosure section to the artifact.

3. **Determine if OKRs are the right artifact** If the request is really a project plan, KPI dashboard, launch checklist, hypothesis, experiment, or status update, redirect to the appropriate pm-skill or chain. Do not force OKR shape onto non-OKR work.

4. **Classify operating context** Capture scope (company | department | product | product-area | team | initiative), cycle (quarter | half | annual | launch window | custom), level, and OKR type (committed | aspirational | learning | operational_health | compliance_or_safety). Default cycle is quarterly when context is missing.

5. **Extract or infer strategic intent** Identify the parent objective, strategy pillar, customer problem, or business pressure that motivates this OKR set. If none is supplied, ask once before drafting.

6. **Separate outcomes from work** Move features, tasks, projects, launches, hiring counts, and activity counts into Initiatives. The OKR is what changes in the world; Initiatives are bets on how to make that change happen. Apply Castro's litmus test: "if it can go in your backlog, it is not an outcome."

7. **Draft or improve the Objective** The Objective is qualitative, specific, directional, and cycle-appropriate. It describes a desired state change, not a project. It connects to strategy. It avoids embedded metrics