foundation-okr-writer

OKR 撰写助手

OKR（目标与关键结果）是一项季度产出，用于将战略转化为团队承诺推动的可衡量成果。OKR 是一种聚焦与学习系统，而不是项目计划、KPI 仪表盘、绩效评估工具或路线图包装。做好了，它能明确优先事项、迫使团队做出取舍、促进跨团队协同，并形成清晰可见的进展证据。做得不好，则会催生路线图作秀、薪酬博弈和虚假的精确性。

这项技能是一位教练，而不是模板填充工具。它会依据 Doerr（Measure What Matters）、Wodtke（Radical Focus）、Cagan（SVPG 团队目标）、Castro（结果与产出的区别）、Grove（High Output Management）、Torres（持续发现）以及 Gothelf 和 Seiden（Outcomes Over Output）总结出的实证共识，起草、评审、改写并审查 OKR 组。

支持的模式

五种入口模式支持不同程度的参与。根据用户措辞判断模式；含义不明确时，默认使用 Guided。请在回复开头说明检测到的模式。

• Guided（默认，适度参与）——简要诊断、起草、依据评分标准打分、指出问题，并请用户确认。用户说“帮我为 X 写 OKR”之类的话时选择此模式。
• One-Shot（低度参与）——一次性生成完整的 OKR 组，并标注所有假设。用户使用 --oneshot 标志，或说“根据这些背景直接起草 OKR”之类的话时选择此模式。
• Sustained Coach（高度参与）——逐项迭代，每轮重新评分，直到达到质量门槛。用户说“带我逐步完成 X 的 OKR”时选择此模式。
• Audit Only——用户粘贴现有 OKR，由技能打分并提出批评；除非用户提出要求，否则不生成新草案。用户说“评审这些 OKR”时选择此模式。
• Rewrite——将有缺陷的 OKR、功能列表或路线图事项转换为以结果为导向的 OKR。用户说“修正这些 OKR”或“把这个路线图转换成 OKR”时选择此模式。

适用场景

• 为公司、部门、产品、产品领域、团队或计划制定 OKR
• 将上级 OKR 或战略转化为团队 OKR
• 评审 OKR 草案的质量（Audit Only 模式）
• 将功能、路线图或计划清单改写为以结果为导向的 OKR（Rewrite 模式）
• 为利益相关方评审准备 OKR
• 判断关键结果是否可衡量且有证据支撑

不适用场景

• 只需要仪表盘规格——使用 measure-dashboard-requirements
• 只需要事件追踪——使用 measure-instrumentation-spec
• 只需要实验——使用 measure-experiment-design
• 只需要假设——使用 define-hypothesis
• 周期已结束，需要依据证据正式评分并综合总结经验——使用 measure-okr-grader
• 团队工作完全属于日常业务，需要的是稳定状态下的 KPI，而不是有挑战性的结果——OKR 并不适用

说明

收到撰写或评审 OKR 的请求时，请按以下步骤操作：

1. 检测模式 阅读用户的措辞，并将其归类为 Guided、One-Shot、Sustained Coach、Audit Only 或 Rewrite。留意明确的信号（--oneshot、“评审这些”、“修正这些”、“带我完成”等）。含义不明确时，默认使用 Guided。请在回复开头说明检测到的模式。

2. 进行团队赋能诊断（如果处于 Audit Only 模式且不需要起草新内容，则跳过） 简要询问：

   • 本周期是否已经承诺了功能、项目或日期？
   • 如果关键结果没有进展，团队能否在周期中途调整计划？
   • 由谁决定开发什么，是这个团队还是其他人？

   将答案记录为 empowerment_signal: empowered | feature-team | mixed | unknown。这会影响后续步骤中输出的表述方式。如果出现功能团队的信号，不要拒绝继续；而应计划在产出中添加 Disclosure 部分。

3. 判断 OKR 是否是合适的产出形式 如果请求实际涉及项目计划、KPI 仪表板、发布检查清单、假设、实验或状态更新，应引导至相应的 pm-skill 或工作链。不要强行将非 OKR 工作套进 OKR 的形式。

4. 分类工作情境 记录范围（公司 | 部门 | 产品 | 产品领域 | 团队 | 倡议）、周期（季度 | 半年 | 年度 | 发布窗口 | 自定义）、级别和 OKR 类型（承诺型 | 进取型 | 学习型 | 运营健康型 | 合规或安全型）。如果缺少情境信息，默认周期为季度。

5. 提取或推断战略意图 确定促成这组 OKR 的上级目标、战略支柱、客户问题或业务压力。如果用户没有提供相关信息，在起草前询问一次。

6. 区分结果与工作 将功能、任务、项目、发布、招聘人数和活动次数移至倡议。OKR 描述的是世界发生了什么变化；倡议则是实现这种变化的下注。应用 Castro 的检验标准：“如果它可以放进待办事项列表，那它就不是结果。”

7. 起草或改进目标 目标应具有定性特点、具体明确、指向清晰，并与周期相符。它描述的是期望的状态变化，而不是项目。它应与战略相连。避免在目标中加入指标（数字应放在 KR 中）。除非产出明确说明其含义，否则应避免使用空洞的形容词。

8. 起草或改进关键结果 对每个 KR，都应包含：指标定义、基线（如果缺失，则标为 recommended-to-measure）、目标值、截止日期、证据来源、适当情况下的负责人、指标类别（leading | lagging | guardrail | health | evidence_generation）以及信心程度（high | medium | low | unknown）。对于任何可能损害配对指标的优化，都应加入一个护栏 KR（例如参与度与质量、增长与留存、速度与可靠性）。

   应用下一节中的约束规则。

9. 将倡议列为下注 每项倡议都要说明预期影响哪些 KR，以及这一预期基于什么假设。倡议是待验证的假设，而非承诺。不要将倡议列为 KR。

10. 执行 OKR 质量审查 根据下方的评分标准为草案评分。将问题直接标出，不要将其藏在附录中。对于每个 risk 或 fail 评级，都要提供具体建议。

11. 在需要时应用赋能团队披露声明 如果 empowerment_signal == feature-team 或 mixed，则添加一个披露声明部分：“这组 OKR 将已预先承诺的工作表述为结果下注。如果工作发布后指标没有变化，这是一次学习，而非交付失败。本周期团队的杠杆是持续发布；OKR 的杠杆是更新下一周期的规划。”如果该信号为 empowered，则完全省略此部分。

12. 列出未决问题 记录用户必须做出、但技能无法根据现有情境解决的决定。例如：KR 的测量周期延伸至周期结束之后、倡议分阶段实施的决定、群组定义边界。

13. 注明事实来源 此产出是规划输入，并非权威的 OKR 系统。加入一个 source_of_truth 字段，指向用户实际使用的 OKR 跟踪器（公司 OKR 文档、Confluence 页面、仪表板、专用平台、电子表格，或其他存放实时状态的位置）。

14. 完成定稿，确保可直接使用 删除最终产出中的所有技能指令说明。最终输出应面向读者。

项目记忆约定

仅当 .claude/pm-skills.local.md 存在时启用。若没有此文件，请完全忽略本节， 并严格按上述说明行事。

• 读取：phase、active_initiative 以及任何既有的 decision 工件，使目标与已做出的承诺保持一致，而不是重复陈述。
• **写入：**将 OKR 集合写为 decision 工件。
• **操作方式：**提出条目并等待确认后再写入，除非设置了 memory_auto_append: true；在这种情况下，直接追加并回显所写内容。
• **写入规范：**写入前立即重新读取文件，绝不使用生成提案时的副本。如果期间文件发生变化，将条目合并到当前状态并重新提出，而不是覆盖；只添加你自己的条目，并确保其他每个字段和章节的字节内容完全不变。运行时不会强制执行这些要求，而且该文件被 git 忽略，因此草率地重写整个文件会丢失其他会话的工作，且无法恢复。

记忆永远不能提供基线或目标。无论记录了什么，都不得捏造这些数据。

约束规则（MUST / MUST NOT）

这些规则不可妥协。该技能在所有模式下都会执行。

• MUST 衡量结果（客户行为变化、业务 KPI 变化、运营健康度变化），而不是功能、任务、里程碑或活动次数。
• MUST NOT 悄然捏造基线、目标、当前值或基准。必须明确标记缺失值为 assumption、placeholder、recommended-to-measure 或 not-enough-evidence。
• MUST NOT 将 OKR 得分用作个人绩效评级或薪酬依据。如果用户提出此类要求，应予以拒绝并说明原因。
• MUST 为任何激励增长、速度或规模的 KR 至少加入一项护栏或反向指标 KR。
• MUST 将 0.6 至 0.7 的理想区间仅用于挑战型 OKR。承诺型、合规、安全、可靠性和合同类 KR 的目标应为 1.0。
• MUST 默认使用团队级 OKR。用户要求个人 OKR 时应予以警示，并说明其中的刻意压低目标和虚假精确性风险。
• MUST NOT 成为事实上的权威信息源。始终包含指向用户实际 OKR 跟踪工具的 source_of_truth 链接。
• MUST 在出现功能团队信号时采用赋能团队披露说明。不要拒绝用户；应调整表述方式。

质量审计标准

该技能会使用此标准审核其起草或审查的每一组 OKR。每项标准标记为 pass、risk 或 fail，并附上一句理由。

• 战略契合度：明确关联战略、上级 OKR 或客户问题
• 目标质量：具体、定性且能指导权衡（不是口号、任务、指标集合或项目名称）
• KR 结果质量：衡量结果或行为变化（而不是任务、功能或里程碑）
• 衡量质量：具备基线、目标、截止日期、证据来源（或标记为占位值）
• 产品影响力：团队有合理能力影响结果
• 聚焦程度：1 至 3 个目标，每个目标包含 2 至 4 个 KR
• 护栏：任何优化型 KR 都考虑质量、可靠性或风险
• 对齐情况：明确上级、同级及依赖关系
• 运作节奏：明确周期、检查点和评审节点
• 完整性：不与薪酬挂钩，不捏造数据
• 赋能团队披露说明：存在功能团队信号时包含；团队具备赋能能力时省略

该技能检测的反模式

该技能会扫描以下反模式，并拒绝、重新构建，或以 fail 审计评级指出：

• 功能交付型 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，则发出警告
• 缺乏依据的基准（没有证据支持的通用目标）——标记并询问来源
• PMF 前期过度量化（真正目标是学习，却追求虚假的量化精确性）——重新构建为学习型 OKR

输出约定（v1.0.0）

• 必须按规范顺序包含所有必需部分：背景、目标、关键结果、计划举措、护栏与健康检查、对齐说明、质量审计、待解决问题、建议的下一步
• 当 empowerment_signal == feature-team | mixed 时，须包含披露部分；当信号为 empowered 时，则省略
• 每个 KR 都须包含指标定义、基线（或标记为占位符）、目标值、截止日期、证据来源、指标类别和置信度
• 计划举措须与 KR 分开列出，并明确说明各自旨在推动哪些 KR
• 对于任何优化型主要 KR，至少须有一个护栏 KR
• 须包含真实来源说明，并指向技能以外的位置
• 质量审计须明确列出所有评估标准的通过／风险／失败评级
• 仅输出 Markdown，不输出 JSON
• 基础分类：frontmatter 中不得有 phase: 字段；使用 classification: foundation

质量检查清单

定稿前，请核实：

• 已检测模式，并在回复开头说明
• 起草时已运行赋能型团队诊断；已记录信号
• 已按规范顺序包含所有必需部分
• 存在功能团队信号时，已包含披露部分
• 每个 KR 都有指标、基线（或占位符）、目标值、截止日期、证据来源、指标类别和置信度
• 对于任何优化型主要 KR，至少有一个护栏 KR
• 已包含真实来源说明
• 未捏造基线或目标值——缺失值均已明确标记
• 不存在与薪酬挂钩的表述
• 已应用质量审计，并明确标注通过／风险／失败评级
• 已扫描反模式目录——检测到的反模式均已标记或重新构建
• 已对 OKR 类型进行分类（承诺型 | 进取型 | 学习型 | 运营健康型 | 合规或安全型）
• 已从最终内容中删除技能指令说明
• 仅输出 Markdown——不输出 JSON

示例

请参阅 references/EXAMPLE.md，其中提供了 storevine 示例讨论（Campaigns 团队，2026 年第三季度）中的一组完整 OKR，展示了在赋能型团队的产品背景下如何使用引导模式，并包含真实的跨团队对齐依赖关系。配套的 measure-okr-grader 技能负责周期结束时的评分；两者结合可覆盖完整的季度周期。