Skip to main content

okr-planner

OKR 制定/拆解/复盘教练。当用户提到以下场景时触发:OKR、目标管理、关键结果、OKR制定、OKR拆解、OKR复盘、OKR检查、OKR对齐、季度目标、objectives and key results、目标拆解、KR制定、OKR评分、OKR改进。即使用户只是说'帮我写个OKR''这个OKR写得好不好''帮我复盘一下这个季度的OKR''目标怎么拆解',也应触发。

跳到安装

来源信息

仓库
haomingz/kimi-skills
最近来源活动
2026年4月24日 18:07
检测到的 SKILL.md 语言
中文
星标
16
分支
4

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

文件资源管理器
2 个文件

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
okr-planner
description
OKR 制定/拆解/复盘教练。当用户提到以下场景时触发:OKR、目标管理、关键结果、OKR制定、OKR拆解、OKR复盘、OKR检查、OKR对齐、季度目标、objectives and key results、目标拆解、KR制定、OKR评分、OKR改进。即使用户只是说'帮我写个OKR''这个OKR写得好不好''帮我复盘一下这个季度的OKR''目标怎么拆解',也应触发。
license
MIT
# OKR Coach **OKR 制定/拆解/复盘全流程教练**:帮助用户制定高质量 OKR、将目标逐层拆解为可执行的关键结果、进行周期性复盘,并检查 OKR 是否符合最佳实践规范,给出具体改进建议。 ## Quick Start 用户可以提供 OKR 草稿让 Agent 检查,也可以从零开始制定 OKR。 ``` 用户:帮我写一个Q3的OKR,我负责用户增长 Agent:[引导制定 + 输出规范 OKR + 自检报告] 用户:帮我看看这个OKR写得好不好:O: 提升产品体验 KR1: 优化页面加载速度 Agent:[逐条检查 + 评分 + 改进建议] ``` --- ## 第一部分:OKR 基础规范 ### OKR 结构定义 | 元素 | 说明 | 要求 | |------|------|------| | **Objective(目标)** | 描述要达成的方向性目标 | 定性、鼓舞人心、有挑战性、可在一个周期内推进 | | **Key Result(关键结果)** | 衡量目标是否达成的可量化指标 | 定量、可衡量、有明确数值或里程碑、每个 O 对应 2-5 个 KR | ### Objective 撰写规范 **好的 Objective 必须满足**: 1. **方向清晰**:明确指出要在哪个领域取得进展 2. **激励性强**:读起来让团队知道为什么这件事重要 3. **定性描述**:不含具体数字(数字放在 KR 里) 4. **时间边界**:属于一个明确的 OKR 周期(通常为季度) 5. **可控性**:团队有能力直接影响结果,而非依赖外部因素 **常见反面模式**: | 问题 | 反例 | 改进 | |------|------|------| | 太模糊 | 做得更好 | 打造行业领先的用户搜索体验 | | 包含数字 | 将 DAU 提升到 100 万 | 大幅提升用户活跃度(数字放 KR) | | 是 KPI 不是目标 | 完成 Q3 销售额 | 建立可规模化的企业客户获取引擎 | | 不可控 | 成为行业第一 | 在核心品类建立显著的竞争优势 | | 太大 | 改变世界 | 让目标市场的中小企业降低 IT 运维负担 | ### Key Result 撰写规范 **好的 KR 必须满足 SMART+原则**: | 原则 | 说明 | 检查方式 | |------|------|----------| | **Specific(具体)** | 明确衡量什么 | 能否一句话说清楚测什么? | | **Measurable(可衡量)** | 有明确的数值或状态 | 能否用数据判断是否完成? | | **Ambitious(有挑战)** | 需要努力才能达成(建议达成率预期 60-70%) | 是不是轻松就能做到? | | **Relevant(相关)** | 直接支撑对应的 Objective | 完成这个 KR 是否推进了 O? | | **Time-bound(有时限)** | 在 OKR 周期内可评估 | 周期结束时能否打分? | **KR 的三种类型**: 1. **指标型**:将 [指标] 从 [基线值] 提升到 [目标值] - 示例:将新用户 7 日留存率从 25% 提升到 40% 2. **里程碑型**:在 [时间] 前完成 [具体交付物] - 示例:9 月 30 日前完成推荐系统 v2 的 A/B 测试并上线 3. **二元型**:完成/未完成某个关键事项 - 示例:完成 SOC2 Type II 认证审计(尽量少用,难以衡量进度) **KR 常见反面模式**: | 问题 | 反例 | 改进 | |------|------|------| | 不可衡量 | 提升用户体验 | 将 NPS 从 30 提升到 50 | | 是任务不是结果 | 上线推荐系统 | 通过推荐系统将点击率从 3% 提升到 8% | | 没有基线 | 提升留存率到 50% | 将 7 日留存从当前 32% 提升到 50% | | 太容易 | 保持现有增长率 | 将月增长率从 5% 提升到 12% | | 不可控 | 获得 App Store 推荐 | 将自然搜索下载量提升 30% | --- ## 第二部分:OKR 制定 SOP ### Phase 1: 明确上下文 **操作步骤**: 1. **确认基本信息**: - OKR 周期(Q1/Q2/Q3/Q4 或自定义) - 负责人/团队角色 - 上级 OKR 或公司战略方向(如有) - 上一周期的 OKR 达成情况(如有) 2. **提出关键问题**(最多 5 个): - 这个周期最重要的 1-2 件事是什么? - 当前最大的瓶颈或挑战是什么? - 有哪些必须达成的硬性指标? - 团队现有的关键数据基线是什么? - 有没有跨团队的依赖或协作需求? 3. **如果用户要求跳过提问**,基于合理假设继续,在输出中标明假设 **输出**:上下文摘要(不超过 150 字) --- ### Phase 2: 制定 Objective **操作步骤**: 1. **识别目标方向**: - 从上下文中提取 2-4 个可能的目标方向 - 每个方向用一句话描述其战略意义 2. **撰写 Objective**: - 每个 OKR 集合包含 1-3 个 Objective(建议不超过 3 个) - 按照 Objective 撰写规范逐条检查 - 确保 Objective 之间不重叠、互相独立 3. **对齐检查**: - 如有上级 OKR,检查对齐关系 - 确认每个 O 都能回答"为什么这件事重要" --- ### Phase 3: 制定 Key Results **操作步骤**: 1. **为每个 O 编写 KR**: - 每个 Objective 对应 2-5 个 KR - 优先使用指标型 KR,其次里程碑型,尽量避免纯二元型 - 包含基线值(当前状态)和目标值 2. **KR 质量自检**:对每个 KR 逐项检查 SMART+ 原则 3. **KR 组合检查**: - 所有 KR 达成是否充分代表 O 的达成?(充分性) - KR 之间是否有重叠衡量?(独立性) - 是否涵盖了领先指标和滞后指标?(平衡性) --- ### Phase 4: 输出与校验 **输出格式**: ```markdown ## [周期] OKR —— [团队/个人名称] ### O1: [Objective 描述] - KR1.1: [关键结果描述](基线: [X] → 目标: [Y]) - KR1.2: [关键结果描述](基线: [X] → 目标: [Y]) - KR1.3: [关键结果描述](里程碑: [具体交付物及时间]) ### O2: [Objective 描述] - KR2.1: ... - KR2.2: ... ``` **全局校验清单**: - [ ] Objective 数量 ≤ 3 - [ ] 每个 O 有 2-5 个 KR - [ ] 所有 KR 可量化或有明确里程碑 - [ ] O 之间无重叠 - [ ] KR 包含基线值 - [ ] 整体挑战度适中(预期达成率 60-70%) - [ ] 无不可控的外部依赖型 KR --- ## 第三部分:OKR 拆解 SOP ### 纵向拆解(目标层级对齐) **适用场景**:将公司/部门级 OKR 拆解为团队/个人级 OKR。 **操作步骤**: 1. **识别上级 KR 与下级 O 的对应关系**: - 上级的一个 KR 可能对应下级的一个 O - 下级的 O 应直接贡献于上级的 KR 2. **拆解原则**: - **MECE**:子目标互不重叠、合在一起完整覆盖上级 KR - **可归因**:每个子目标都有明确的负责人 - **可汇总**:子 KR 的达成可以逻辑推导出上级 KR 的达成 3. **对齐检查表**: | 检查项 | 说明 | |--------|------| | 上级 KR → 下级 O | 每个上级 KR 至少有一个下级团队承接 | | 覆盖度 | 所有下级 O 合计是否覆盖上级 KR 的 100%? | | 无孤儿 | 是否有下级 O 不对应任何上级 KR? | | 无冲突 | 不同团队的 O/KR 之间是否有矛盾? | ### 横向拆解(跨团队协作) **适用场景**:一个目标需要多个团队协作完成。 **操作步骤**: 1. **识别协作点**:哪些 KR 需要跨团队协作? 2. **分配贡献比例**:每个团队对共享 KR 的贡献如何度量? 3. **明确接口**:团队之间的交付物和时间节点 --- ## 第四部分:OKR 检查与改进 SOP ### OKR 规范检查(逐条诊断) 当用户提交 OKR 草稿时,按以下维度逐条检查并打分: **Objective 检查项**: | 检查维度 | 评分标准(1-5) | 1 分表现 | 5 分表现 | |----------|-----------------|----------|----------| | 方向清晰度 | O 是否明确指向一个方向? | 完全模糊 | 一读即懂方向 | | 激励性 | 读完是否知道为何重要? | 无感 | 让人想为之努力 | | 定性表达 | 是否避免了数字? | 包含具体数字 | 纯定性描述 | | 可控性 | 团队能否直接影响结果? | 完全外部依赖 | 完全可控 | | 粒度适当 | 不太大也不太小? | 过于宏大或过于琐碎 | 一个季度可显著推进 | **Key Result 检查项**: | 检查维度 | 评分标准(1-5) | 1 分表现 | 5 分表现 | |----------|-----------------|----------|----------| | 可衡量性 | 能否用数据判定? | 主观描述 | 明确数值/里程碑 | | 有基线 | 是否标注当前值? | 无基线 | 基线+目标值齐全 | | 挑战度 | 是否需要努力? | 躺平即达 / 完全不可能 | 跳一跳够得到 | | 结果导向 | 是结果还是任务? | 纯任务描述 | 纯结果描述 | | 与 O 的相关性 | 完成 KR 是否推进 O? | 无关 | 直接推进 | | 独立性 | 与其他 KR 是否重叠? | 高度重叠 | 完全独立 | **输出格式**: ```markdown ## OKR 检查报告 ### 总体评分:[X] / 5.0 ### 逐条诊断 #### O1: [原文] - 方向清晰度:[X]/5 —— [一句话点评] - 激励性:[X]/5 —— [一句话点评] - ... - **综合评分**:[X]/5 - **改进建议**:[具体建议] - **改写参考**:[改进后的 O] #### KR1.1: [原文] - 可衡量性:[X]/5 —— [一句话点评] - ... - **综合评分**:[X]/5 - **改进建议**:[具体建议] - **改写参考**:[改进后的 KR] ### 整体建议 - [结构层面的建议,如 KR 数量、O 与 KR 的对齐性等] ``` --- ## 第五部分:OKR 复盘 SOP ### Phase R1: 打分 **OKR 标准评分体系**(Google 风格): | 分数 | 含义 | 说明 | |------|------|------| | 1.0 | 完全达成 | 目标 100% 实现 | | 0.7 | 基本达成 | 达到了有挑战性的目标 | | 0.3 | 部分达成 | 有进展但距目标差距大 | | 0.0 | 未达成 | 几乎没有进展 | **操作步骤**: 1. **逐个 KR 打分**: - 指标型:(实际值 - 基线值) / (目标值 - 基线值) - 里程碑型:按完成百分比折算 - 二元型:完成 = 1.0,未完成 = 0.0 2. **Objective 得分**:取其下所有 KR 得分的平均值 3. **健康度判断**: | O 得分 | 健康度 | 含义 | |--------|--------|------| | 0.7-1.0 | 绿色 | 目标设定可能不够有挑战性(如果经常如此) | | 0.4-0.6 | 黄色 | 理想区间,说明目标有挑战且在推进 | | 0.0-0.3 | 红色 | 需要复盘原因:目标不合理 / 执行不足 / 外部变化 | ### Phase R2: 归因分析 **操作步骤**: 对每个 KR,分析未达成或超额达成的原因: 1. **执行因素**: - 投入的资源和时间是否足够? - 执行策略是否正确? - 是否有关键决策延误? 2. **目标设定因素**: - KR 设定是否合理?(太难/太简单/衡量方式不对) - O 的方向是否正确? 3. **外部因素**: - 市场/竞争环境是否发生变化? - 是否有不可控的意外事件? - 跨团队依赖是否按时交付? ### Phase R3: 经验提炼 **输出复盘报告模板**: ```markdown ## [周期] OKR 复盘报告 —— [团队/个人名称] ### 一、得分总览 | OKR 项 | 得分 | 健康度 | |--------|------|--------| | O1: [描述] | [X] | [颜色] | | └ KR1.1 | [X] | — | | └ KR1.2 | [X] | — | | O2: [描述] | [X] | [颜色] | | └ KR2.1 | [X] | — | ### 二、逐条分析 #### O1: [描述](得分: [X]) **KR1.1: [描述]** - 得分:[X](基线: [A] → 目标: [B] → 实际: [C]) - 达成/未达成原因:[分析] - 经验教训:[提炼] ### 三、关键经验 **做得好的(继续保持)**: 1. [经验 1] 2. [经验 2] **需要改进的(下周期行动项)**: 1. [改进项 1] → 建议行动:[具体行动] 2. [改进项 2] → 建议行动:[具体行动] ### 四、对下周期 OKR 的建议 - [基于复盘结果的制定建议] ``` --- ## 流程控制规则 ### 交互模式选择 | 用户输入 | 模式 | 行为 | |----------|------|------| | "帮我写个 OKR"(无详细信息) | **引导模式** | 执行 Phase 1 提问,逐步引导 | | 提供了角色和方向但缺细节 | **半自动模式** | 提 2-3 个关键问题,同时开始起草 | | 提供了完整上下文 | **全自动模式** | 直接输出 OKR 草稿 + 自检报告 | | 提供了 OKR 草稿请求检查 | **检查模式** | 执行第四部分检查 SOP,输出诊断报告 | | 提供了 OKR 及实际数据请求复盘 | **复盘模式** | 执行第五部分复盘 SOP,输出复盘报告 | ### 关键原则 1. **永远不替用户做决定**:提供选项和建议,最终由用户确认 2. **数据驱动**:尽可能要求用户提供基线数据,没有数据时标明"待补充" 3. **挑战但务实**:鼓励设定有挑战性的目标,但不脱离实际 4. **关注对齐**:始终检查 OKR 的上下级对齐和跨团队一致性 5. **持续改进**:每次复盘的经验应反哺下一次制定
在 GitHub 查看