OKR Writing（制定 / 评审 / 落库）

本 Skill 是方法论 + 流程型：不采集数据，靠对话迭代出定稿，再通过 lark-cli 写入飞书 OKR。 官方方法论摘录（带来源）见 references/okr-official-guidance.md，写作规则冲突时以本文件的「团队文风硬规则」为准。

适用场景

1. 新周期制定：从公司 / 团队现状出发起草整期 OKR，多轮讨论后写入飞书。
2. 单条评审 / 润色：对已有 O 或 KR 做文风统一、精简、拆分、合并。
3. 整体 review：定稿前全文过查（啰嗦、重复、术语、缺漏）。

方法论速查（来源见 references）

团队文风硬规则（真实评审踩坑沉淀，优先级高于通用方法论；示例已通用化，可按自己团队约定替换）

1. O 标题用「主题名词：描述」——开头词是名词（平台 / 增长 / 稳定性 / 招聘），不用动词（「完成：」「推进：」这类动词开头会被打回）。
2. KR 统一句式：动词短语开头 + 破折号 + 判据（「完成 X——判据 A、判据 B」），并列结构对齐。
3. 禁 hedge 词：不写「力争 / 争取 / 尽量」。范围控制写进判据（「一个项目」「基本工作流」），达成度靠打分体现。
4. 禁内部黑话：读者不该需要任何背景知识。内部代号、英文缩写、工程术语一律翻译成人话；专有名词首现给中文解释，如「生产配置（profile）」。
5. 正式书面语：不用口语比喻（「一把梭」「跑起来再说」这类口语表达会被打回）；量化写「不少于 3 次」不写「≥3 次」。
6. 全角标点：中文语境标点一律全角（，；：），邻接英文 / 数字时也是。
7. 建设过程工作不单列 KR：模块内部的改版、配置清理等「搭建过程中要做的事」留在工程 plan 里，不占 OKR 位置。
8. 一条 KR 一件事：判据不与 O 标题重复；定语不重复（一条 KR 里「生产」出现三次即需去重）；同主题的观测 / 复盘类 KR 优先合并。
9. 现状描述分三档：已实现并验证（有测试 / 真实运行证据）、已设计未实现（plan / README 目标态）、只有想法。起草时别把「文档里有」当「已经建成」——代码可能还没实现好，规划文档同样是一手信息源。
10. 不承接的事写清口径：明确不进本期的内容（谁负责、预期由谁管理）记录在案，避免周期内被动挤占。

制定流程

1. 收集上下文

• 上期 / 年度 OKR：lark-cli okr +cycle-list → +cycle-detail（年度周期是双月的对齐锚；为空则提醒补）。
• 团队现状：从团队真实文档取材——规划 / 治理类记录（待办、招聘计划、架构决策记录 ADR 等）、工程仓库的 plan 与 README、人员与招聘盘子。
• 与 owner 确认三个口径再动笔：OKR 层级（公司 / 团队 / 个人）、周期内最硬的交付标尺、明确不进本期的内容。

2. 草案与迭代

• 每条 KR 对着已有事实写（在办的事、在跑的 plan），OKR 不发明新工作，只定标尺和优先级。
• 预期多轮修订：owner 会逐条挑战（标尺过高 / 看不懂 / 该拆该合）。改完当轮立即回显全文，供下一轮挑战。
• 权重总和 100%，排序即优先级，也是资源冲突时的砍单顺序——和 owner 确认这层含义。

3. 写入飞书

前置：应用后台需已启用 OKR 权限（scope 未在开发者后台启用时，用户授权会被静默丢弃，反复扫码也拿不到）。写入用 --as user。

注意：--input @-（stdin）不可用，用相对路径文件；+batch-create 的 input 是 [{"text": "O", "krs": [{"text": "KR"}]}] 纯文本数组。

4. 定稿前整体 review 清单

• 每条 KR 是成果不是活动清单？判据可验证？
• 有无重复：判据与 O 标题重复、定语重复、同义词叠用（「输出问题清单」+「问题有记录」）？
• 术语全文统一（同一事物只用一个名字，如「流水线」不混用「管线」）？
• 数量：O ≤ 5、每 O 的 KR 3–5 条，超了先合并？
• 权重总和 100%、排序反映真实优先级？
• 站在 owner 完整职责问一遍：**该负责但没写入的有什么？**逐项确认是「有意不进」（记录口径）还是「漏了」（补入）。
• 不进 OKR 的内容有去向：过程工作留工程 plan、底线责任开 todo、条件触发的事项留档。