foundation-okr-writer

Files (6)

• HISTORY.md
• SKILL.md
• activation-quarter.md · evals/output-scenarios/
• trigger-fixtures.json · evals/
• EXAMPLE.md · references/
• TEMPLATE.md · references/

SKILL.md (first lines)

<!-- 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 (numbers belong in KRs). It avoids empty adjectives unless the artifact defines what they mean.

8. **Draft or improve Key Results**
   For each KR include: metric definition, baseline (or `recommended-to-measure` if missing), target, deadline, evidence source, owner where appropriate, indicator class (`leading | lagging | guardrail | health | evidence_generation`), and confidence (`high | medium | low | unknown`). Include a guardrail KR for any optimization that could harm a paired metric (engagement vs quality, growth vs retention, speed vs reliability).

   Apply the constraint rules in the next section.

9. **Map initiatives as bets**
   Each initiative names which KR(s) it is expected to move and the assumption underlying that expectation. Initiatives are hypotheses, not commitments. Do not list initiatives as KRs.

10. **Run the OKR Quality Audit**
    Score the draft against the rubric below. Surface issues inline rather than burying them in an appendix. For each `risk` or `fail` rating, include a specific recommendation.

11. **Apply the empowered-team Disclosure** (when needed)
    If `empowerment_signal == feature-team` or `mixed`, add a Disclosure section: "This OKR set frames pre-committed work as outcome bets. If the metrics do not move when the work ships, that is a learning, not a delivery failure. The team's lever this cycle is to keep shipping; the OKR's lever is to update next-cycle planning." Omit this section entirely when the signal is `empowered`.

12. **Surface open questions**
    Capture any decisions the user must make that the skill cannot resolve from context. Examples: KR measurement window extending past cycle close, initiative phasing decisions, cohort definition boundaries.

13. **Note the source of truth**
    The artifact is a planning input, not the canonical OKR system. Include a `source_of_truth` field pointing to the user's actual OKR tracker (company OKR doc, Confluence page, dashboard, dedicated platform, spreadsheet, or wherever the live status lives).

14. **Finalize for direct use**
    Remove all skill instruction commentary from the final artifact. The final output should be reader-facing.

## Project Memory Contract

Active only when `.claude/pm-skills.local.md` exists. With no file, ignore this section entirely
and behave exactly as described above.

- **Reads:** `phase`, `active_initiative`, and any prior `decision` artifacts, so objectives align to what has already been committed rather than restating it.
- **Writes:** the OKR set as a `decision` artifact.
- **Posture:** propose the entry and wait for confirmation before writing, unless
  `memory_auto_append: true` is set, in which case append and echo what was written.
- **Write discipline:** re-read the file immediately before writing, never from the copy that
  produced the proposal. If it changed in between, merge your entry into the current state and
  re-propose rather than overwriting; add only your own entry and leave every other field and
  section byte-identical. Nothing enforces this at runtime and the file is gitignored, so a
  careless whole-file write loses another session's work with no way to recover it.

Memory never supplies a baseline or a target. The refusal to fabricate those stands regardless of what is recorded.
## Constraint Rules (MUST / MUST NOT)

These rules are non-negotiable. The skill enforces them in every mode.

- **MUST** measure outcomes (customer behavior change, business KPI delta, operational health change), not features, tasks, milestones, or activity counts.
- **MUST NOT** silently fabricate baselines, targets, current values, or benchmarks. Mark missing values explicitly as `assumption`, `placeholder`, `recommended-to-measure`, or `not-enough-evidence`.
- **MUST NOT** use OKR scores as individual performance ratings or compensation inputs. If the user requests this, refuse and explain.
- **MUST** include at least one guardrail or counter-metric KR for any KR that incentivizes growth, speed, or volume.
- **MUST** treat the 0.6 to 0.7 sweet spot as applying ONLY to aspirational OKRs. Committed, compliance, safety, reliability, and contractual KRs target 1.0.
- **MUST** default to team-level OKRs. Warn when individual OKRs are requested; explain the sandbagging and false-precision risks.
- **MUST NOT** become the canonical source of truth. Always include a `source_of_truth` pointer to the user's actual OKR tracker.
- **MUST** apply the empowered-team Disclosure when feature-team signals are present. Do NOT refuse the user; adjust the framing.

## Quality Audit Rubric

The skill applies this rubric to every OKR set it drafts or reviews. Each criterion gets `pass`, `risk`, or `fail` with a one-line rationale.

From product-on-purpose/pm-skills, Apache-2.0.

More from product-on-purpose/pm-skills