foundation-okr-writer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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

OKR（目标与关键结果）集合是一种季度性成果文件，用于将战略转化为团队承诺达成的可衡量成果。OKR是一种聚焦与学习体系，而非项目计划、KPI仪表盘、绩效评估工具或路线图包装器。使用得当的话，它能明确优先级、倒逼取舍、促进跨团队对齐，并创建可见的进度证明。使用不当则会催生“路线图形式主义”、薪酬博弈和虚假精准。

本技能是一个指导工具，而非模板填充器。它会依据Doerr（《Measure What Matters》）、Wodtke（《Radical Focus》）、Cagan（SVPG团队目标）、Castro（成果vs产出）、Grove（《High Output Management》）、Torres（持续探索）以及Gothelf和Seiden（《Outcomes Over Output》）的实证共识，来起草、审核、重写和审计OKR集合。

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

五种输入模式对应不同的参与程度。模式会根据用户表述自动识别；当表述模糊时默认使用引导模式。需在回复开头说明识别出的模式。

```
Guided
```
（默认，中等参与度）：简短诊断、起草、按评分标准打分、指出问题、请用户确认。适用于类似“帮我为X撰写OKR”的表述。
```
One-Shot
```
（低参与度）：一次性生成完整的OKR集合，并标注所有假设。通过
```
--oneshot
```
标志或类似“直接根据此上下文起草OKR”的表述触发。
```
Sustained Coach
```
（高参与度）：迭代循环，一次处理一个组件，每轮重新打分直至达到质量阈值。适用于类似“指导我完成X的OKR制定”的表述。
```
Audit Only
```
：用户粘贴现有OKR，本技能进行打分和点评，除非用户要求否则不生成新草稿。适用于类似“审核这些OKR”的表述。
```
Rewrite
```
：将有缺陷的OKR、功能列表或路线图条目转化为以成果为导向的OKR。适用于类似“修正这些OKR”或“将此路线图转化为OKR”的表述。

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

在公司、部门、产品、产品领域、团队或项目层面制定OKR
将上级OKR或战略转化为团队OKR
审核OKR草稿的质量（仅审核模式）
将功能、路线图或项目列表重构为基于成果的OKR（重写模式）
准备OKR以供利益相关者审核
判断关键结果（KR）是否可衡量且有证据支持

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

仅需仪表盘规格：使用
```
/dashboard-requirements
```
仅需事件追踪：使用
```
/instrumentation-spec
```
仅需实验方案：使用
```
/experiment-design
```
仅需假设：使用
```
/hypothesis
```
周期已结束，需要结合证据和学习总结进行正式打分：使用
```
/okr-grader
```
团队仅需维持日常业务稳定，需要稳态KPI而非挑战性成果：OKR并非合适工具

Instructions

操作步骤

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

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.
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.
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.
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.
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.
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."
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.
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.
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.
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.
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
```
.
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.
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).
Finalize for direct use Remove all skill instruction commentary from the final artifact. The final output should be reader-facing.

当被要求撰写或审核OKR时，请遵循以下步骤：

识别模式 阅读用户表述，将其归类为引导模式、一次性模式、持续指导模式、仅审核模式或重写模式。留意明确信号（如
```
--oneshot
```
、“审核这些”、“修正这些”、“指导我”）。当表述模糊时默认使用引导模式。需在回复开头说明识别出的模式。
开展赋能团队诊断（仅审核模式且无需起草新OKR时跳过）简要询问：
- 本周期是否已承诺开发特定功能、项目或设定截止日期？
- 如果KR未达预期，团队能否在周期中途调整项目？
- 由谁决定开发内容，是团队自身还是其他方？
将答案记录为
```
empowerment_signal: empowered | feature-team | mixed | unknown
```
。这会影响后续步骤中的输出框架。当检测到feature-team信号时，请勿拒绝继续操作；相反，需计划在成果文件中添加“披露”部分。
判断OKR是否为合适工具 如果请求实际是要制定项目计划、KPI仪表盘、发布检查表、假设、实验方案或状态更新，请引导至对应的pm-skill或流程。请勿将非OKR工作强行套入OKR框架。
归类运营背景 记录范围（公司|部门|产品|产品领域|团队|项目）、周期（季度|半年|年度|发布窗口|自定义）、层级以及OKR类型（承诺型|进取型|学习型|运营健康型|合规或安全型）。当背景信息缺失时，默认周期为季度。
提取或推断战略意图 确定驱动本次OKR制定的上级目标、战略支柱、客户问题或业务压力。如果未提供相关信息，在起草前询问一次。
区分成果与工作内容 将功能、任务、项目、发布、招聘人数和活动次数归入“项目举措”。OKR代表世界发生的变化；项目举措是实现该变化的尝试。应用Castro的检验标准：“如果某项内容可放入待办清单，那它就不是成果。”
起草或优化目标（Objective） 目标需具备定性、具体、方向性且符合周期特点。它描述的是期望达成的状态变化，而非项目。它需与战略挂钩。避免嵌入指标（数字应放在KR中）。避免使用空泛形容词，除非成果文件对其含义有明确界定。
起草或优化关键结果（Key Results） 每个KR需包含：指标定义、基线（若缺失则标记为
```
recommended-to-measure
```
）、目标值、截止日期、证据来源、相关负责人（如有）、指标类别（
```
leading | lagging | guardrail | health | evidence_generation
```
）以及置信度（
```
high | medium | low | unknown
```
）。对于任何可能损害对应指标的优化（如参与度vs质量、增长vs留存、速度vs可靠性），需添加一个防护性KR。
需遵循下一节的约束规则。
将项目举措映射为尝试性方案 每个项目举措需明确说明预期影响哪些KR，以及背后的假设。项目举措是假设，而非承诺。请勿将项目举措列为KR。
开展OKR质量审计 根据下方的评分标准对草稿进行打分。将问题直接在内容中指出，而非隐藏在附录中。对于每个“风险”或“不合格”评级，需给出具体建议。
添加赋能团队披露（必要时） 如果
```
empowerment_signal == feature-team
```
或
```
mixed
```
，添加披露部分：“本OKR集合将预先承诺的工作框架为成果尝试。若工作完成后指标未发生变化，这是一次学习，而非交付失败。本周期团队的可控因素是持续交付；OKR的作用是优化下一周期的规划。”当信号为
```
empowered
```
时，完全省略此部分。
提出未解决问题 记录用户必须做出的、本技能无法根据现有背景解决的决策。例如：KR测量窗口超出周期结束时间、项目举措分阶段决策、群组定义边界。
注明真实数据源 本成果文件是规划输入，而非标准OKR系统。需包含
```
source_of_truth
```
字段，指向用户实际使用的OKR跟踪工具（如公司OKR文档、Confluence页面、仪表盘、专用平台、电子表格或其他实时状态记录位置）。
优化为可直接使用的版本 从最终成果文件中移除所有技能操作说明。最终输出需面向读者。

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.

这些规则不容协商。本技能在所有模式下均会强制执行。

必须衡量成果（客户行为变化、业务KPI变化、运营健康状况变化），而非功能、任务、里程碑或活动次数。
禁止擅自编造基线、目标值、当前值或基准。缺失值需明确标记为
```
assumption
```
、
```
placeholder
```
、
```
recommended-to-measure
```
或
```
not-enough-evidence
```
。
禁止将OKR分数用作个人绩效评级或薪酬评定的依据。如果用户提出此要求，需拒绝并解释原因。
必须为任何激励增长、速度或数量的KR添加至少一个防护性或对应指标KR。
必须仅将0.6至0.7的最佳区间应用于进取型OKR。承诺型、合规型、安全型、可靠性型和合同型KR的目标值为1.0。
必须默认制定团队层面的OKR。当用户要求制定个人OKR时，需发出警告；解释可能出现的“留一手”和虚假精准风险。
禁止成为标准数据源。始终包含
```
source_of_truth
```
指针，指向用户实际使用的OKR跟踪工具。
必须在检测到feature-team信号时添加赋能团队披露。请勿拒绝用户请求；需调整表述框架。

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.

Strategic fit: clear link to strategy, parent OKR, or customer problem
Objective quality: specific, qualitative, tradeoff-guiding (not a slogan, task, metric bundle, or project name)
KR outcome quality: measures outcome or behavior change (not tasks, features, or milestones)
Measurement quality: baseline, target, deadline, evidence source present (or marked placeholder)
Product influence: team can plausibly influence the outcome
Focus: 1 to 3 objectives, 2 to 4 KRs each
Guardrails: quality, reliability, or risk considered for any optimization KR
Alignment: parent, peer, dependency relationships clear
Operating rhythm: cycle, check-ins, review points explicit
Integrity: no compensation coupling, no fabricated data
Empowered-team Disclosure: included when feature-team signal present, omitted when empowered

本技能会对所有起草或审核的OKR集合应用此评分标准。每个标准会被评为“合格”、“风险”或“不合格”，并附带一句理由。

战略契合度：与战略、上级OKR或客户问题有明确关联
目标质量：具体、定性、能指导取舍（而非口号、任务、指标组合或项目名称）
KR成果质量：衡量成果或行为变化（而非任务、功能或里程碑）
测量质量：包含基线、目标值、截止日期、证据来源（或标记为占位符）
产品影响力：团队能够合理影响成果
聚焦度：1至3个目标，每个目标对应2至4个KR
防护措施：针对任何优化型KR，已考虑质量、可靠性或风险因素
对齐度：上级、同级和依赖关系清晰
运营节奏：周期、检查点、评审点明确
完整性：未与薪酬挂钩，无编造数据
赋能团队披露：检测到feature-team信号时已包含，empowered信号时已省略

Anti-Patterns the Skill Detects

本技能检测的反模式

The skill scans for these and either refuses, reframes, or surfaces them with a

fail

audit rating:

Feature-delivery KR ("Launch X" instead of "Increase Y from A to B") . reframe into outcome KR; move feature to Initiatives
Task-count KR ("Complete 10 interviews" without a learning outcome) . reframe or move to evidence-generation type
Vanity metric KR (metric improves without customer or business value) . flag and propose alternative
Activity objective (objective describes work, not change) . reframe
Metric-stuffed objective (objective is just KPIs glued together) . reframe
Too many OKRs (more than 3 objectives, more than 4 KRs per objective) . force ranking
Cascading theater (parent KR copied locally without ownership logic) . rewrite as networked alignment
Roadmap wrapper (OKRs reformat the roadmap) . full Rewrite mode
Missing baseline (target uninterpretable) . mark
```
recommended-to-measure
```
Missing evidence source (no one knows where the score will come from) . mark
```
not-enough-evidence
```
Lag-only product OKR (team owns revenue without product outcome) . add a leading product-outcome KR
No guardrail (optimization may damage quality, trust, retention) . add guardrail KR
Compensation coupling (people will sandbag or hide learning) . refuse and explain
Individual OKR default . default to team OKRs; warn if individual OKRs are requested
Unsupported benchmark (universal target without evidence) . flag and ask for source
Pre-PMF over-metricization (false quantitative precision when learning is the real objective) . reframe as learning OKR

本技能会扫描以下反模式，并采取拒绝、重构或标记为“不合格”审计评级的处理方式：

功能交付型KR（如“发布X”而非“将Y从A提升至B”）：重构为成果型KR；将功能移至项目举措
任务数量型KR（如“完成10次访谈”但无学习成果）：重构或归类为证据生成类型
虚荣指标型KR（指标提升但无客户或业务价值）：标记并提出替代方案
活动型目标（目标描述的是工作内容，而非变化）：重构
指标堆砌型目标（目标只是多个KPI的组合）：重构
OKR数量过多（超过3个目标，每个目标超过4个KR）：强制排序
形式主义对齐（直接复制上级KR但无所有权逻辑）：重写为网络化对齐
路线图包装器（OKR只是路线图的重新格式化）：启用完全重写模式
缺失基线（目标值无法解读）：标记为
```
recommended-to-measure
```
缺失证据来源（无人知晓分数来源）：标记为
```
not-enough-evidence
```
仅滞后指标的产品OKR（团队负责收入但无产品成果）：添加领先型产品成果KR
无防护措施（优化可能损害质量、信任、留存）：添加防护性KR
与薪酬挂钩（人员可能留一手或隐瞒学习成果）：拒绝并解释原因
默认个人OKR：默认制定团队OKR；若用户要求个人OKR则发出警告
无依据的基准（通用目标但无证据支持）：标记并要求提供来源
产品适配前过度指标化（实际目标是学习却追求虚假量化精准）：重构为学习型OKR

Output Contract (v1.0.0)

输出规范（v1.0.0）

All required sections present in canonical order: Context, Objective, Key Results, Initiatives as Bets, Guardrails and Health Checks, Alignment Notes, Quality Audit, Open Questions, Suggested Next Step

Disclosure section is present when

empowerment_signal == feature-team | mixed

, omitted when

empowered

Every KR includes metric definition, baseline (or marked placeholder), target, deadline, evidence source, indicator class, and confidence
Initiatives are listed separately from KRs and explicitly tied to which KR(s) they aim to move
At least one guardrail KR exists for any optimization-style primary KR
Source-of-truth note is present and points to a non-skill location
Quality Audit covers all rubric criteria with explicit pass / risk / fail ratings
Markdown only output. No JSON.
Foundation classification: no
```
phase:
```
field in frontmatter; uses
```
classification: foundation
```

所有必填部分按标准顺序呈现：背景、目标、关键结果、作为尝试性方案的项目举措、防护措施与健康检查、对齐说明、质量审计、未解决问题、建议下一步行动
当
```
empowerment_signal == feature-team | mixed
```
时包含披露部分，empowered时省略
每个KR包含指标定义、基线（或标记为占位符）、目标值、截止日期、证据来源、指标类别和置信度
项目举措与KR分开列出，并明确说明预期影响哪些KR
任何优化型主KR至少对应一个防护性KR
包含真实数据源说明，指向非本技能的位置
质量审计覆盖所有评分标准，明确给出合格/风险/不合格评级
仅输出Markdown格式，不输出JSON
基础分类：前置内容中无
```
phase:
```
字段；使用
```
classification: foundation
```

Quality Checklist

质量检查清单

Examples

示例

See

references/EXAMPLE.md

for a completed OKR set in the storevine sample thread (Campaigns team, Q3 2026), demonstrating Guided mode on an empowered-team product context with a real cross-team alignment dependency. The companion

measure-okr-grader

skill handles end-of-cycle scoring; together they cover the full quarterly arc.

请查看

references/EXAMPLE.md

，其中包含Storevine示例线程（营销活动团队，2026年第三季度）中的完整OKR集合，展示了在赋能团队产品背景下使用引导模式的情况，且存在真实的跨团队对齐依赖。配套的

measure-okr-grader

技能负责周期结束时的打分；两者共同覆盖完整的季度流程。