菜单
基于当前与历史飞书 OKR、上级目标、同事目标、绩效总结、自评和工作材料，生成、改写、审阅、写入并艾特协作者的 Objective / Key Result。用户要求写 OKR、制定目标、拆解 KR、承接上级目标、检查对齐关系、优化 OKR 表述，或将草稿保存到飞书时使用。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/TongyiDai/feishu-okr-drafter --skill feishu-okr-drafter命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | feishu-okr-drafter |
| description | 基于当前与历史飞书 OKR、上级目标、同事目标、绩效总结、自评和工作材料，生成、改写、审阅、写入并艾特协作者的 Objective / Key Result。用户要求写 OKR、制定目标、拆解 KR、承接上级目标、检查对齐关系、优化 OKR 表述，或将草稿保存到飞书时使用。 |
把多源工作事实整理成可讨论、可衡量、可对齐的飞书 OKR，并在用户明确授权后写入草稿、艾特对应协作者。接口用于提速，飞书页面、历史文档、截图、用户粘贴内容和工作总结同样是有效输入。默认先完成判断和草稿，不创建、不发布、不修改现有 OKR。
遵守三条底线：
[待确认]。识别用户要做的是：
没有明确写入意图时，停留在只读和草稿模式。
先阅读 lark-shared 和 lark-okr 的当前版本说明。需要读飞书内容时，执行身份、租户和权限核验：
lark-cli auth status --json --verify
lark-cli contact +get-user --as user
支持 auth status --json --verify 的环境必须确认 identity=user、verified=true。当前 CLI 构建若没有 auth 子命令，可退回 contact +get-user --as user 解析当前用户；需要继续草稿模式时，再用 task +get-my-tasks --as user 证明 user-context 可读。真正写入 OKR 或 @ 协作者前，仍要确认目标用户和租户。
按以下顺序选择可用资料路径，不能把“接口不可用”当作任务终点：
control-in-app-browser。优先接管用户当前已打开的 OKR 页面；没有可用页面时，只做一次明确的飞书 OKR 入口导航。依据可见页面读取，不猜测 URL、字段顺序或按钮含义。接口成功时也要结合页面或原文核验关键状态；页面成功时也要保留页面事实，不因无法形成 API ID 就丢弃证据。
按需获取：
okr +cycle-list；okr +cycle-detail；objective.indicators list、key_result.indicators list；objective.alignments list；okr +progress-list；OKR、制定、撰写、对齐、填写助手，优先读取当前租户可访问的规范与示例。周期判断以起止日期与当前日期的重叠为首要条件，再参考周期状态；用户没有明确要求时，不把年度周期当作默认当前周期。
若 OKR 专用 scope 缺失，停止盲目重试，说明缺失的 scope 和影响。可继续基于用户提供的工作材料及有权限读取的飞书文档生成标注了上下文边界的草稿。
历史 OKR 是重点参考项。至少检查最近一个已完成周期，条件允许时再看更早周期、进展记录、评分、评论、绩效总结和 H1 自评。
把历史内容分成四类：
建立简短的来源台账：事实 → 来源 → 时间 → 对新 O/KR 的作用 → 是否仍需确认。把过去的成绩和未来的承诺分开。
写当前周期 OKR 前，固定检查以下四类关系；缺少接口时通过飞书 OKR 页面、截图、用户粘贴内容或可访问文档补齐：
建立关系台账：关系类型 → 来源对象 → O/KR → 对方/协作者 → 事实或期待 → 本周期处理 → 是否已确认。四类信息分别作为“历史结果”“协作输入”“协作回溯”“纵向承接”使用，避免混成一张待办清单。
至少确认：周期、角色或责任范围、要达成的业务结果、已知基线、目标值或判断标准、主要协作方、约束和敏感信息。
已有上级或团队 OKR 时，先识别：
若存在直属上级，直属上级当前周期 OKR 是纵向承接的首要参照；团队 OKR、同级 OKR 和被 @ 内容用于补充承接范围与协作边界。被 @、@ 他人和“看起来相关”都只能形成候选关系，只有内容、主责、周期和双方确认共同成立时，才报告为已对齐。
缺少关键输入时，用最少的问题补齐；仍无法确认时继续产出，但把不确定性显式放入 [待确认]。
当用户一次列出多件项目或战役时，先按业务结果聚类，再决定 O 的数量。项目名称通常进入 KR、实现路径或证据栏；只有代表独立结果主线时才单独成为 O。常见聚类方向包括客户/商业结果、端到端流程效率、产品化与复制、组织机制与影响力。
[目标值待确认]。【客户价值】、【流程提效】，避免把多条主线揉成一条。优先按以下结构组织一条 KR：
【关键方面】通过[必要路径]，于[时间节点]达到[可观察结果/目标值]，由[主责]负责，@ [协作者]协同。
路径过长时删减；结果、时间和验收标准必须保留。
逐条检查 O 和 KR，并把问题分成“阻塞发布”和“建议优化”。详细规则见 references/okr-writing-principles.md。
重点检查：
按以下顺序交付：
周期与上下文：使用了哪些周期、上级 O、文档和用户输入；说明读取边界。OKR 草稿：每个 O 下列出 KR、结果标准、时间、主责、协作方和证据来源。历史承接：哪些历史事实变成基线，哪些事项延续，哪些成果被提升为复制或规模化结果。关系与承接清单：上周期完成度、本周期被 @、上周期 @ 他人、直属上级承接、建议 @ 的对象、冲突和待沟通事项。质量诊断：阻塞项、建议优化项、尚未验证的假设。待确认：只列会改变目标含义、结果标准或系统写入的事项。禁止用一套看似完整的数字掩盖不确定性。质量判断应解释“为什么这条 KR 能证明 O 达成”。
只有用户明确要求写入或保存时才执行写操作。写入前：
lark-cli contact +search-user 解析为 open_id。命中多个候选、跨租户或身份信息不足时暂停该条 @，要求确认，不能猜选；--dry-run 检查请求；simple 风格；需要精确控制 @ 位置时使用 richtext 的 mention 元素；okr +batch-create，单个 O 或 KR 使用 okr +create；将 mention 写在对应 O/KR 上，避免把所有人集中 @ 在一个目标里；mention 是真实用户 ID，不是正文中的 @姓名 字符串。接口路径将 mention: ["ou_xxx"] 放入对应 O/KR；页面路径使用用户选择器，并回读页面中的真实用户标签。已创建/已保存、已艾特、未艾特及原因、未发布。任何一项没有读回证据，都保留为待核验。接口无法写入时，可在已登录的飞书 OKR 页面使用“批量粘贴 OKR”或页面编辑控件保存草稿。页面路径必须遵守以下顺序：
@姓名；对齐关系只作用于 Objective。创建对齐前确认两个目标属于不同目标、周期存在时间重叠且确有承接或协作关系；不要把“相关”直接写成“已对齐”。完整流程见 references/okr-alignment-review.md。