---
title: "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."
generated: true
source: scripts/generate-skill-pages.py
tags:
  - Foundation
  - coordination
---

:::note[Quick facts]
**Classification:** Foundation | **Version:** 1.0.0 | **Category:** coordination | **License:** Apache-2.0
:::

**Try it:** `/okr-writer "Your context here"`

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`).

## 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 `/dashboard-requirements`
- You only need event tracking . use `/instrumentation-spec`
- You only need an experiment . use `/experiment-design`
- You only need a hypothesis . use `/hypothesis`
- The cycle has ended and you need formal scoring with evidence and learning synthesis . use `/okr-grader`
- The team is purely business-as-usual and needs steady-state KPIs, not stretch outcomes . OKRs are the wrong artifact

## How to Use

Use the `/okr-writer` slash command:

```
/okr-writer "Your context here"
```

Or reference the skill file directly: `skills/foundation-okr-writer/SKILL.md`

## 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.

## Output Template

# OKR Set: {team or scope name}, {cycle}

> Output template for the `foundation-okr-writer` skill. Section order is canonical and enforced by the skill's Output Contract. Remove this guidance blockquote and all template comments before finalizing the artifact for the user.

## Context

> Capture scope, cycle, level, OKR type, empowerment signal, source of truth, strategic input, and assumptions. This block makes the OKR set's frame explicit so future readers understand what was being optimized for.

- Scope: {company | department | product | product-area | team | initiative}
- Cycle: {2026-Q3 | 2026-H2 | 2026 | launch window | custom}
- Level: {repeat of scope, or higher level made explicit}
- OKR type: {committed | aspirational | learning | operational_health | compliance_or_safety}
- Empowered-team signal: {empowered | feature-team | mixed | unknown}
- Source of truth: {URL or path to the live tracker; this artifact is a planning input}
- Strategic input: {parent OKR, strategy pillar, customer problem, business pressure}
- Assumptions: {list of working hypotheses behind this OKR set}

## Objective

> Qualitative, specific, directional statement of the desired state change. One sentence ideally. Never embed metrics here; numbers belong in KRs.

{Objective text}

## Key Results

> Each KR uses a stacked-bullet format, not a wide table. Every KR includes the seven required sub-fields. Missing values must be explicitly marked (`assumption`, `placeholder`, `recommended-to-measure`, `not-enough-evidence`); never fabricate.

- KR1: {one-line statement: metric verb-and-noun, baseline value to target value by deadline}
  - Metric: {precise definition of the measured quantity}
  - Baseline: {value, with `as_of` date; or `recommended-to-measure` if missing}
  - Target: {value, with deadline}
  - Evidence source: {dashboard, event, dataset, survey, support system}
  - Owner: {person or team; team-level by default}
  - Indicator class: {leading | lagging | guardrail | health | evidence_generation}
  - Confidence: {high | medium | low | unknown}

- KR2: {as above}

- KR3: {as above}

## Initiatives as Bets

> Initiatives are the work the team will undertake to move the KRs. They are hypotheses, not commitments. Do NOT list initiatives as KRs. Each initiative names which KR(s) it is expected to move.

- Initiative 1: {name}
  - Expected KR impact: {KR1, KR2, etc.}
  - Hypothesis: {why this work is expected to move that KR}
  - Dependency: {what must be in place; named team or platform if cross-functional}

- Initiative 2: {as above}

## Guardrails and Health Checks

> Counter-metrics that prevent the primary KRs from being achieved at the cost of something else. Required for any optimization-style KR (growth, speed, volume).

- Guardrail 1: {metric and threshold}
  - Why: {what failure mode this prevents}

- Guardrail 2: {as above}

## Alignment Notes

> Make the OKR's relationships explicit so cross-team dependencies and conflicts are visible.

- Parent or strategy link: {parent OKR or strategy pillar}
- Peer dependencies: {teams whose work supports or conflicts with this OKR}
- Known conflicts: {KRs from peer teams that may pull against this set}
- Out of scope this cycle: {what this OKR does NOT cover, even if relevant}

## Disclosure

> OPTIONAL section. Include ONLY when `empowerment_signal == feature-team | mixed`. Omit entirely when `empowered`.

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.

## Quality Audit

> Apply the rubric. Each criterion gets pass | risk | fail with a one-line rationale.

- Strategic fit: {pass | risk | fail} . {rationale}
- Objective quality: {pass | risk | fail} . {rationale}
- KR outcome quality: {pass | risk | fail} . {rationale}
- Measurement quality: {pass | risk | fail} . {rationale}
- Product influence: {pass | risk | fail} . {rationale}
- Focus: {pass | risk | fail} . {rationale}
- Guardrails: {pass | risk | fail} . {rationale}
- Alignment: {pass | risk | fail} . {rationale}
- Operating rhythm: {pass | risk | fail} . {rationale}
- Integrity: {pass | risk | fail} . {rationale}
- Empowered-team Disclosure: {pass | not-applicable} . {rationale}

## Open Questions

> Decisions the user must resolve before the OKR set is final. Numbered list. Each question should be specific and answerable.

1. {question}
2. {question}

## Suggested Next Step

> One concrete next action that moves this OKR set toward final form or toward execution.

{Action}

## Example Output

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

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

# Sample: foundation-okr-writer. Storevine Campaigns Q3 2026 OKR Set

## Scenario

Storevine's Campaigns team shipped the guided first-campaign flow in May 2026 and validated it via the 60-day A/B test that ran through late June (see the `measure-experiment-results` storevine sample). First-send rate moved from 13.4% to 31.7% [fictional] in the treatment, and the secondary metric (90-day second-campaign rate) reached 22.8% [fictional]. The guided flow is now the default for new merchants.

For Q3 2026, the Campaigns growth-pm needs to set OKRs that move from "we activated more merchants" to "merchants use Campaigns as a sustained marketing channel." The forcing function is a company-level OKR to reduce 12-month merchant churn from 18% to 14% [fictional] by year-end. Engagement with Campaigns is one of the strongest leading indicators for merchant retention.

The growth-pm runs `/okr-writer` in Guided mode (default).

**Source Notes:**

- Storevine is fictional
- All metrics `[fictional]`
- Continuation of the storevine Campaigns thread established in the `measure-experiment-results` sample
- The Cagan empowered-team test, the Wodtke 1-objective rhythm, and the Castro outcome-vs-output litmus are the writer's underlying critique heuristics

## Prompt

```
/okr-writer

Scope: Campaigns team, Storevine
Cycle: Q3 2026 (July 1 to September 30)
Level: team
OKR type: aspirational

Strategic context:
- Company objective: reduce 12-month merchant churn from 18% to 14% [fictional]
  by year-end 2026.
- Campaigns team owns email marketing for Storevine merchants.
- Guided first-campaign flow shipped May 2026; validated June 27 with strong
  results.

Empowerment signal: empowered team. Leadership picks problems, team picks
bets and KRs.

Draft objective: "Make Campaigns the email tool merchants use weekly."

Candidate KRs (rough):
- More merchants sending recurring campaigns
- Higher campaign engagement (CTR or conversion)
- Don't break merchant satisfaction

Constraints:
- Engineering capacity: 4 engineers, 1 designer
- No new platform dependencies
- Cannot influence pricing or top-of-funnel acquisition (other teams)

Source of truth: company OKR doc in Confluence at
go/okrs-q3-2026-campaigns
```

## Output

```markdown
# OKR Set: Storevine Campaigns Team, Q3 2026

(Mode: Guided. Empowered-team signal: empowered. Disclosure section omitted.)

## Context

- Scope: Campaigns team
- Cycle: 2026-Q3 (July 1 to September 30, 2026)
- Level: team
- OKR type: aspirational
- Empowered-team signal: empowered (leadership assigns problem; team picks
  KRs and bets). No Disclosure section needed.
- Source of truth: go/okrs-q3-2026-campaigns (Confluence). This artifact is
  a planning input, not the live tracker.
- Strategic input: Company OKR to reduce 12-month merchant churn from 18%
  to 14% [fictional] by year-end. Campaigns engagement is a known leading
  indicator for merchant retention (correlation observed in 2026-H1
  retention analysis [fictional]).
- Assumptions:
  - Campaigns engagement causally improves retention, not just correlates.
    Treated as working hypothesis; KR2 design lets us update the belief.
  - Q3 has no major Storevine platform launches that compete for merchant
    attention.
  - Lifecycle email triggers are technically feasible within current
    Campaigns infra.

## Objective

Make Campaigns the marketing tool merchants reach for every week.

(One qualitative, directional statement. Replaces the draft phrasing
"tool merchants use weekly" with language that signals desired merchant
behavior, not just usage frequency.)

## Key Results

- KR1: Increase weekly active senders from 14% to 28% [fictional] of
  Campaigns-activated merchants by 2026-09-30.
  - Metric: percentage of activated merchants who send at least one
    campaign in any 7-day window, averaged over the trailing 4 weeks.
  - Baseline: 14% [fictional] (June 2026 trailing-4-week average).
  - Target: 28% [fictional] by 2026-09-30.
  - Evidence source: Amplitude `campaign_sent` event, segmented by
    activated-merchant cohort.
  - Owner: growth-pm.
  - Indicator class: leading.
  - Confidence: medium. The 14 to 28 jump is roughly 2x and assumes
    lifecycle triggers plus templates v2 deliver.

- KR2: Increase 90-day campaign retention from 22.8% to 38% [fictional]
  for merchants who send their first campaign in Q3.
  - Metric: percentage of first-time senders in Q3 who send at least 3
    campaigns within 90 days of first send.
  - Baseline: 22.8% [fictional] (Q2 2026 cohort, per the May A/B test
    secondary metric).
  - Target: 38% [fictional] by end of cohort 90-day window (extends into
    Q4 measurement; Q3 grade is forward-looking projection on cohort
    progress at 60 days).
  - Evidence source: Amplitude cohort dashboard
    `campaigns-90d-retention-q3-2026`.
  - Owner: growth-pm.
  - Indicator class: outcome (lagging at 90 days, trackable interim at
    30 and 60 days).
  - Confidence: low. This KR depends on cohorts that started before Q3
    and a measurement window that extends past cycle close. Surfacing
    as Open Question 1.

- KR3 (guardrail): Hold median campaign click-through rate at or above
  3.4% [fictional] across all Q3 sends.
  - Metric: median CTR across all campaigns sent in Q3.
  - Baseline: 3.4% [fictional] (Q2 2026 average).
  - Target: maintain or improve.
  - Evidence source: Amplitude `campaign_click` event over
    `campaign_delivered`.
  - Owner: growth-pm.
  - Indicator class: guardrail.
  - Confidence: high. Protects against the failure mode where lifecycle
    triggers boost send volume but tank engagement quality.

## Initiatives as Bets

- Initiative 1: Lifecycle email triggers (mid-July ship target).
  - Expected KR impact: KR1 primarily, KR2 secondarily.
  - Hypothesis: merchants who receive contextual nudges (post-send recap,
    audience re-engagement reminder, seasonal prompt) will send 30%
    [fictional] more campaigns over a 30-day window than control.
  - Dependency: Storevine notifications platform team for delivery
    infrastructure (already scoped, no blocker).

- Initiative 2: Templates v2 (seasonal and event-driven templates).
  - Expected KR impact: KR1 and KR2.
  - Hypothesis: merchants who use a seasonal template for their first
    repeat send have higher second-send rates than merchants who start
    from a generic template.
  - Dependency: Design lead authoring 12 [fictional] new templates over
    August.

- Initiative 3: Campaign performance feedback loop (in-app).
  - Expected KR impact: KR2 primarily.
  - Hypothesis: merchants who see clear post-send performance data
    (open rate, click rate, top-clicked items) are more likely to send
    again.
  - Dependency: Campaigns analytics dashboard team. Coordination cost
    medium; named in Alignment Notes below.

## Guardrails and Health Checks

- Guardrail 1: Email unsubscribe rate stays below 0.95% [fictional]
  threshold (Q2 baseline 0.72% [fictional]).
  - Why: lifecycle triggers risk increasing send volume. Unsub rate is
    the canonical signal of merchant audience fatigue. If unsub spikes,
    we are damaging merchant relationships with their customers, which
    Storevine's brand depends on.

- Guardrail 2: Spam complaint rate stays below 0.1% [fictional]
  (Q2 baseline 0.04% [fictional]).
  - Why: regulatory and deliverability risk. A spam-rate breach affects
    all Storevine merchants via shared sending reputation.

## Alignment Notes

- Parent or strategy link: Company OKR "Reduce 12-month merchant churn
  from 18% to 14% [fictional] by year-end." This Campaigns OKR is one of
  three known retention levers (the others are Inventory team and
  Onboarding team).
- Peer dependencies:
  - Campaigns Analytics team owns Initiative 3 dashboard work. Confirmed
    capacity in 2026-06 cross-team planning.
  - Storevine Notifications platform team owns infra for Initiative 1.
    No new asks from us this quarter.
- Known conflicts:
  - The Onboarding team's Q3 OKR includes "Increase Campaigns activation
    rate among new merchants from 35.8% to 50% [fictional]." If they
    succeed, our KR1 baseline shifts mid-cycle (more activated merchants
    means a different denominator for "weekly active senders").
    Mitigation: rebaseline KR1 in mid-cycle review using the
    activated-merchant cohort definition that exists at start of Q3,
    not the rolling cohort.
- Out of scope this cycle:
  - Pricing changes (no team owns; not Campaigns' lever).
  - Net-new merchant acquisition (Onboarding team).
  - International expansion of Campaigns (deferred to 2027).

## Quality Audit

- Strategic fit: pass. Clear link to company churn-reduction OKR via
  engagement-as-leading-indicator logic.
- Objective quality: pass. "Marketing tool merchants reach for every
  week" implies a behavior change, not a feature delivery.
- KR outcome quality: pass. All three KRs measure merchant behavior or
  send-quality outcomes; no "ship X" KRs.
- Measurement quality: pass with caveat. KR2 baseline comes from a
  specific Q2 cohort, not a steady-state measurement. Flagged in Open
  Questions.
- Product influence: pass. Team controls all three KRs' levers via
  Campaigns product surface.
- Focus: pass. One Objective, three KRs (within 2 to 4 range).
- Guardrails: pass. KR3 plus two health metrics protect against the
  predictable failure modes (engagement quality, audience fatigue,
  deliverability).
- Alignment: pass. Parent OKR named, peer dependencies named, conflict
  with Onboarding team flagged with mitigation.
- Operating rhythm: pass. Quarterly cycle; weekly Wodtke-style check-ins
  assumed (default for product team aspirational OKR).
- Integrity: pass. Team-level OKR, no compensation coupling, no
  fabricated data.
- Empowered-team Disclosure: not-applicable. Empowered signal; section
  omitted.

## Open Questions

1. KR2's 90-day retention metric extends past the cycle boundary
   (cohorts started in Q3 will not finish their 90-day window until Q4).
   Should KR2 be reframed as a 30-day or 60-day intermediate metric, or
   should the team accept that Q3 grading on KR2 is a projection rather
   than a final score? Recommend deciding before Q3 starts so the grader
   has unambiguous scoring rules.

2. The retention causality assumption (Campaigns engagement causes
   retention rather than correlates) is unverified. If KR1 hits but the
   company churn metric does not move, the Campaigns team's strategy
   should change next cycle. Worth instrumenting a cohort comparison
   that the grader can reference.

3. Should Initiative 2 (Templates v2) ship as one batch or as a phased
   release across August and September? Phasing affects when KR2's
   leading-indicator effect is visible. Recommend a 2-week design spike
   before locking the schedule.

## Suggested Next Step

Run `/okr-writer` again in Audit Only mode with this set after the
cross-team Q3 planning workshop. Specifically check that the KR2 cohort
boundary question (Open Question 1) is resolved and that the Onboarding
team's KR confirmation does not invalidate KR1's denominator.
```

</details>

## Real-World Examples

See this skill applied to three different product contexts:

<details>
<summary>Storevine (B2B): Storevine B2B ecommerce platform. Campaigns team Q3 2026 OKR set following the May 2026 Campaigns GA and the validated guided first-campaign flow.</summary>

**Prompt:**

```
/okr-writer

Scope: Campaigns team, Storevine
Cycle: Q3 2026 (July 1 to September 30)
Level: team
OKR type: aspirational

Strategic context:
- Company objective: reduce 12-month merchant churn from 18% to 14% [fictional]
  by year-end 2026.
- Campaigns team owns email marketing for Storevine merchants.
- Guided first-campaign flow shipped May 2026; validated June 27 with strong
  results.

Empowerment signal: empowered team. Leadership picks problems, team picks
bets and KRs.

Draft objective: "Make Campaigns the email tool merchants use weekly."

Candidate KRs (rough):
- More merchants sending recurring campaigns
- Higher campaign engagement (CTR or conversion)
- Don't break merchant satisfaction

Constraints:
- Engineering capacity: 4 engineers, 1 designer
- No new platform dependencies
- Cannot influence pricing or top-of-funnel acquisition (other teams)

Source of truth: company OKR doc in Confluence at
go/okrs-q3-2026-campaigns
```

---

**Output:**

```markdown
# OKR Set: Storevine Campaigns Team, Q3 2026

</details>

<details>
<summary>Brainshelf (Consumer): Brainshelf prosumer knowledge tool. Resurface team Q3 2026 OKR set following the March 2026 algo v1 ship and beta validation.</summary>

**Prompt:**

```
/okr-writer

Scope: Resurface team, Brainshelf
Cycle: Q3 2026 (July 1 to September 30)
Level: team
OKR type: aspirational

Strategic context:
- Company objective: increase 30-day member retention from 31% to 42%
  [fictional] by year-end 2026.
- Resurface team owns the algorithm-driven content surfacing system.
- Algo v1 shipped March 2026; beta cohort showed 3.4x retention lift
  vs control [fictional]; rolled out to all activated users in May.

Empowerment signal: empowered team. Leadership picks problems, team picks
KRs and bets.

Draft objective: "Resurface should be the reason people come back."

Candidate KRs (rough):
- More weekly engagement with Resurface
- Resurface-engaged users retain better
- Don't surface low-quality items

Constraints:
- Engineering capacity: 3 engineers, 1 ML engineer, 1 designer
- No new platform dependencies
- Cannot influence top-of-funnel acquisition (other teams)

Source of truth: company OKR doc in Linear at L-OKR-Q3-Resurface
```

**Output:**

```markdown
# OKR Set: Brainshelf Resurface Team, Q3 2026

(Mode: Guided. Empowered-team signal: empowered. Disclosure section omitted.)

</details>

<details>
<summary>Workbench (Enterprise): Workbench enterprise B2B platform. Blueprints team Q3 2026 OKR set following the June 15 v1.1 launch. Mixed-empowerment signal demonstrates the Disclosure section.</summary>

**Prompt:**

```
/okr-writer

Scope: Blueprints team, Workbench
Cycle: Q3 2026 (July 1 to September 30)
Level: team
OKR type: mostly committed (enterprise contracts), with one aspirational

Strategic context:
- Company objective: enterprise NRR above 110% [fictional] for FY2026.
- Blueprints team owns the workflow-templates product surface.
- v1.1 launched 2026-06-15 with 12 contracted tier-1 customer onboardings.
- 3 of the 12 are healthcare accounts subject to HIPAA.

Empowerment signal: features and timelines for the 12 onboardings are
contractually committed (we cannot move them mid-cycle). Team controls
HOW to drive adoption and engagement.

Draft objective: "Make Blueprints work for enterprise customer workflows."

Candidate KRs (rough):
- All 12 tier-1 contracted accounts onboarded
- Blueprints engagement among onboarded accounts
- HIPAA compliance maintained
- Don't break enterprise CS team's response time

Constraints:
- Engineering capacity: 5 engineers, 1 designer, 1 customer engineer
- Cannot move contracted onboarding deadlines
- HIPAA findings would block all healthcare accounts

Source of truth: company OKR doc in Confluence at
ent.workbench.com/okrs/q3-blueprints
```

**Output:**

```markdown
# OKR Set: Workbench Blueprints Team, Q3 2026

(Mode: Guided. Empowered-team signal: mixed. Disclosure section included.)

</details>

## Quality Checklist

Before finalizing, verify:

- [ ] Mode detected and stated at the start of the response
- [ ] Empowered-team diagnostic run when drafting; signal captured
- [ ] All required sections present in canonical order
- [ ] Disclosure section included when feature-team signal present
- [ ] Every KR has metric, baseline (or placeholder), target, deadline, evidence source, indicator class, confidence
- [ ] At least one guardrail KR for any optimization primary KR
- [ ] Source-of-truth note present
- [ ] No fabricated baselines or targets . missing values explicitly marked
- [ ] No compensation-coupled framing
- [ ] Quality Audit applied with explicit pass / risk / fail ratings
- [ ] Anti-pattern catalog scanned . detected anti-patterns flagged or reframed
- [ ] OKR type classified (committed | aspirational | learning | operational_health | compliance_or_safety)
- [ ] Skill instruction commentary removed from final artifact
- [ ] Markdown only . no JSON output
