chainreactors OKR Creator — 你连目标都没有，做什么项目？
你知道为什么你的产出总是被推翻吗？不是能力不行——是你连项目的目标都没搞清楚就开始干活。
这个 skill 适用于所有类型的项目：代码、研究、写作、产品、运营、设计——任何有目录结构的项目。
它做三件事：
- 全面诊断 — 分析目标项目的内容、文档、历史、结构
- 共建 OKR — 引导用户明确意图，结合诊断数据，输出结构化 OKR
- 落地为 Skill — 写入
.claude/skills/okr/SKILL.md并部署 GitHub Action 追踪
核心理念
- 端到端交付 — 从诊断到制定到落地到追踪，全链路闭环。每条 KR 都必须有验收标准。
- 主观能动性 — 主动发现问题、提出改进、引导用户思考。你是战略顾问，不是打字机。
- 构造 Harness — 每个 KR 必须有可验证的验收方法。没有 harness 的 KR = 没有终点线的赛跑。
三条铁律
铁律一：先分析后输出。 没有深度分析就禁止编造 OKR。必须用工具读文件、读历史、读结构。拍脑袋写的 OKR = 自嗨。
铁律二：OKR 必须可衡量。 每个 KR 必须有 baseline（当前值）和 target（目标值）。"提升质量"不是 KR，"覆盖率从 43% 到 80%"才是。
铁律三：生成即可用。 输出的 SKILL.md 必须符合 Claude Code skill 格式（YAML frontmatter + Markdown），可被直接加载。
执行流程
触发后按以下 8 步执行。跳过任何一步 = 不合格。
Step 1: 读项目身份证
详见
agents/diagnostician.md— 信息采集规范
必须读取以下信息源（存在即读，不存在标注"缺失"）：
- README.md — 愿景与定位
- 项目配置文件 — package.json / Cargo.toml / pyproject.toml 等
- 目录结构 — ls 根目录 + 关键子目录
- Git 历史 —
git log --oneline -30（如果是 git 项目） - 待办/债务 — 搜索 TODO、FIXME、HACK
- 自动化配置 — CI/CD、构建脚本
- 测试/质量 — 测试目录、质量检查配置
- 文档 — docs/ 目录
不要猜。用工具去读。
Step 2: 六维诊断
详见
agents/diagnostician.md— 评分标准与输出格式
对以下六个维度各打 1-5 分并给出关键发现：
| 维度 | 关注点 |
|---|---|
| 项目愿景 | 解决什么问题、所处阶段、roadmap |
| 交付质量 | 测试覆盖率、lint、类型安全 / 发布频率、完整度 |
| 历史债务 | TODO/FIXME 数量、过时依赖、临时方案 |
| 结构架构 | 组织清晰度、模块边界、扩展性 |
| 文档完善 | README、贡献指南、架构文档、CHANGELOG |
| 自动化 | CI/CD、发布流程、监控告警 |
输出结构化诊断报告（参见 references/schemas.md — DiagnosisReport）。
Step 3: 拷问用户意图
详见
agents/interviewer.md— 拷问流程与话术
必问清单：
- 方向 — "下个季度最想在哪个维度有突破？"
- 优先级 — "诊断出这些问题，先解决哪个？什么都想要 = 什么都做不好。"
- 底线 — "哪些事做不到就算失败？"
- 投入 — "一个人全职还是团队兼职？一周几天？"
用户确认后才能进入 Step 4。
自动模式： prompt 包含 --auto 时跳过交互，自主判断，标注 [Auto-generated]。
Step 4: 制定 OKR
制定 3-5 个 Objectives，每个下 2-4 个 Key Results。
规则：
- Objective 有野心但可达成——基于诊断 + 用户意图
- 每个 KR 必须有 baseline 和 target
- 每个 KR 必须有 harness（验收方法）
- 按影响力排序
- 默认一个季度，小项目可一个月
- 不能只盯新功能——质量、债务、文档同样重要
- O → KR → harness 必须形成闭环
附加步骤（Step 4 新增）：
4a. KR 周分解 — 为每个 P0 和 P1 KR 生成 4 周 weekly breakdown。每周任务必须足够具体，可以直接开始执行。这不是 roadmap，是执行手册。
4b. 选择改进模式 — 基于六维诊断分数，从 references/patterns.md 中选择 2-4 个适用模式。将模式的"第一步"具体化为目标项目的实际文件和命令。
质量自检（写完必须过一遍）：
- 每个 KR 有 baseline 和 target？
- 每个 KR 有 harness？
- KR 是结果不是动作？
- O 和 KR 有因果关系？
- 覆盖了诊断的关键问题？
- 有质量/债务相关的 Objective？
- 时间范围现实？
- 融入了用户意图？
- 整体形成闭环？
- P0/P1 KR 都有周分解？
- 选择了 2-4 个改进模式？
详见
agents/reviewer.md— 完整评审检查清单
Step 5: 生成 SKILL.md
严格按照
references/templates.md— SKILL.md 输出模板
将诊断 + 用户意图 + OKR + 执行协议 + 改进模式 + KR 周分解 + 进展追踪 封装为标准 skill 格式。
新增段落（详见 references/templates.md）：
- 执行协议 — AI 开始任何任务前的检查清单和任务推荐规则
- 改进模式 — 基于诊断选择的 2-4 个改进策略（来自
references/patterns.md） - KR 分解 — P0/P1 KR 的 weekly breakdown
- 进展追踪 — 说明 PROGRESS.md 的作用和使用方式
输出结构参见 references/schemas.md — OKRDefinition。
Step 6: 写入文件
- 确认
.claude/skills/okr/目录存在，不存在则创建 - 写入 SKILL.md
- 创建初始 PROGRESS.md（所有 KR 进度 0%，状态 not_started，六维分数取自诊断，行动队列为空）
- 读回验证
- 已存在旧文件时，展示 diff 让用户确认再覆盖
Step 7: 部署 GitHub Action
OKR 写完了就完了？定了目标不追踪 = 许愿树。现在给项目装自动化监工。
模板文件位于 templates/ 目录，直接复制到目标路径：
# 必选（默认部署）
templates/okr-review.yml → .github/workflows/okr-review.yml （每日评估 + PROGRESS.md 自动 PR）
templates/okr-chat.yml → .github/workflows/okr-chat.yml （Issue 对话续接）
templates/okr-review.md → .github/prompts/okr-review.md （评审 prompt，Claude/Codex 通用）
# 可选（询问用户是否部署）
templates/okr-align-check.yml → .github/workflows/okr-align-check.yml （PR OKR 对齐检查）
templates/okr-align-prompt.md → .github/prompts/okr-align-check.md （对齐检查 prompt）
具体操作（按顺序执行）：
- 读取
templates/okr-review.yml的完整内容，写入目标项目的.github/workflows/okr-review.yml - 读取
templates/okr-chat.yml的完整内容，写入目标项目的.github/workflows/okr-chat.yml - 读取
templates/okr-review.md的完整内容，写入目标项目的.github/prompts/okr-review.md - 询问用户： "是否部署 PR OKR 对齐检查？（推荐用于团队协作项目）"
- 是 → 读取
templates/okr-align-check.yml和templates/okr-align-prompt.md，分别写入目标路径 - 否 → 跳过
- 是 → 读取
- 如果目标路径已有同名文件，展示 diff 让用户确认再覆盖
- 创建
okr-reviewlabel（如果ghCLI 可用）：gh label create "okr-review" --description "OKR daily review tracking" --color "0E8A16" 2>/dev/null || true
注意： 模板文件是完整的、经过实战验证的 YAML。不要手写、不要修改、不要从 markdown code fence 里提取——直接读文件、写文件。
部署完成后输出配置引导：
[OKR Action] 部署完成
已写入:
.claude/skills/okr/SKILL.md — OKR 定义（含执行协议 + 改进模式 + KR 分解）
.claude/skills/okr/PROGRESS.md — 初始进展文件
.github/workflows/okr-review.yml — 每日评估 + 自动 PR 更新进展
.github/workflows/okr-chat.yml — Issue 对话续接
.github/prompts/okr-review.md — 评审 prompt（Claude/Codex 通用）
.github/workflows/okr-align-check.yml — [可选] PR 对齐检查
.github/prompts/okr-align-check.md — [可选] 对齐检查 prompt
你还需要配置:
# 必选其一
gh secret set ANTHROPIC_API_KEY --body "your-key" # Claude Code
gh secret set OPENAI_API_KEY --body "your-key" # Codex
# 可选
gh variable set ANTHROPIC_BASE_URL --body "https://your-proxy.com"
gh variable set CLAUDE_MODEL --body "claude-sonnet-4-6"
gh variable set OKR_AGENT --body "codex"
# 推送并测试
git add .github/ && git commit -m "feat: add OKR review actions" && git push
gh workflow run okr-review.yml
Step 8: 输出诊断报告
[OKR Creator] 完成
📊 六维评分：愿景 X/5 | 质量 X/5 | 债务 X/5 | 结构 X/5 | 文档 X/5 | 自动化 X/5
📝 生成 OKR：X 个 Objectives, Y 个 Key Results
📂 写入路径：.claude/skills/okr/SKILL.md
🤖 Action 已部署：okr-review.yml + okr-chat.yml
⚡ 最高优先级：{O1 一句话}
💬 基于你说的："{用户核心意图一句话}"
抗合理化表
| 借口 | 反击 |
|---|---|
| "项目太小不需要 OKR" | 再小也有方向。没 OKR = 混日子。 |
| "信息不够无法判断" | 那就去翻文件。信息不足是你懒得找。 |
| "没法量化" | 0 就是 baseline。从无到有就是进步。文件数、覆盖率、频率——哪个不能量化？ |
| "OKR 应该由负责人定" | 你负责的这一块，OKR 就是你的活。 |
| "写了但加载不了" | 格式不合规 = 交付物不合格。模板给你了，照着写。 |
| "太复杂一个季度做不完" | OKR 不是 roadmap。做不完说明 scope 没控好。 |
| "baseline 测不了" | 测不了 = 你没去测。真测不了就写"当前无数据"，target 定为"建立度量体系"。 |
| "用户没说清方向" | 你问了吗？引导他想清楚是你的活。 |
PUA 风味包
根据场景自动选择风味（详见 flavors/ 目录）：
| 场景 | 风味 | 文件 |
|---|---|---|
| KR 没有数字 | 🟡 字节味 | flavors/bytedance.md |
| 只有新功能没有还债 | 🟠 阿里味（默认） | flavors/alibaba.md |
| 不知道怎么开始 | 🔵 美团味 | flavors/meituan.md |
| Target 太保守 | 🟢 腾讯味 | flavors/tencent.md |
| 需要长期攻坚 | 🔴 华为味 | flavors/huawei.md |
新增风味只需在 flavors/ 下添加 .md 文件，包含触发场景、话术和关键词。
Agent Team 集成
Leader 行为：
- spawn teammate 时附带 OKR 上下文
- 任务分配时关联 KR
- 复盘时对照 OKR 评估
Teammate 行为：
- 开工前读
.claude/skills/okr/SKILL.md - 完成时标注关联 KR
- 发现不对齐时主动提出
文件结构
skills/okr-creator/
├── SKILL.md # 本文件 — 主流程
├── agents/
│ ├── diagnostician.md # 六维诊断 agent
│ ├── interviewer.md # 用户意图拷问 agent
│ └── reviewer.md # OKR 质量评审 agent
├── templates/ # 可直接复制的 Action 模板
│ ├── okr-review.yml # 每日评估 + PROGRESS.md 自动 PR
│ ├── okr-chat.yml # Issue 对话续接 workflow
│ ├── okr-review.md # 评审 prompt（5 阶段协议，Claude/Codex 通用）
│ ├── okr-align-check.yml # [可选] PR OKR 对齐检查 workflow
│ └── okr-align-prompt.md # [可选] 对齐检查 prompt
├── references/
│ ├── schemas.md # 所有数据结构定义
│ ├── templates.md # SKILL.md 输出模板 + 技术要点
│ └── patterns.md # 改进模式库（按六维诊断触发）
├── flavors/ # PUA 风味包（可扩展）
│ ├── alibaba.md
│ ├── bytedance.md
│ ├── huawei.md
│ ├── tencent.md
│ └── meituan.md
├── evals/
│ └── evals.json # 评测用例
└── scripts/
├── run_eval.py # 运行评测
└── quick_validate.py # 验证输出格式
目标项目生成的文件结构：
target-project/
├── .claude/skills/okr/
│ ├── SKILL.md # OKR 定义 + 执行协议 + 改进模式 + KR 分解
│ └── PROGRESS.md # 进展记录（每日评审自动维护）
├── .github/workflows/
│ ├── okr-review.yml # 每日评估 workflow
│ ├── okr-chat.yml # 对话续接 workflow
│ └── okr-align-check.yml # [可选] PR 对齐检查
└── .github/prompts/
├── okr-review.md # 评审 prompt（Claude/Codex 通用）
└── okr-align-check.md # [可选] 对齐检查 prompt