菜单
旧版 PR 走读（HTML 输出），已被飞书版 pr-walkthrough 取代。仅在用户明确点名 legacy 版本或明确要求 HTML 报告时使用；常规的 PR / 分支解读请求一律走 pr-walkthrough。产出自包含的 HTML 走读报告——旅程式叙事、真实代码片段逐跳走读、排查路标（只做理解，不做 code review）。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Claude 与 Codex 双视角 Code Review。并行执行 Claude review 和 Codex review（通过 codex exec CLI），对比分析后输出综合报告到 `.ai_docs/review/`。适用场景：(1) 用户要求双 agent 协作 review，(2) 用户手动明确触发该 skill。codex 永远不使用本 skill。
Claude 与 Codex CLI 协作编程模式。Claude 负责调研、规划、编写 prompt，所有代码编辑通过 Codex exec 执行。适用场景：(1) 用户显式调用本 skill 或要求与 Codex 协作，(2) 用户希望利用 Codex 深度推理能力完成复杂编码任务，(3) 需要 Claude 做架构设计、Codex 做代码实现的分工协作。进入后持续运行，直到用户明确退出。
PR / 分支变更深度解读。全量精读 diff 后在飞书文档中产出一份走查文档——旅程式叙事、画板图解、真实代码片段、排查路标，帮助项目 owner 重建对代码的理解与掌控（只做理解，不做 code review）。硬依赖 lark-cli 与 lark-doc / lark-whiteboard skill。适用场景：(1) 用户要求解读、理解某个 PR、分支或本地 diff 做了什么，(2) 用户给出 GitHub PR 链接或编号要求分析其设计与影响，(3) 大型变更（含 agent 代写的代码）合并前需要系统性摸清关键设计与流程。
Claude 与 Codex 双视角 Spec Review（代码驱动）。并行审查需求/设计产出物（proposal、specs、design、tasks 等），各自独立探索项目代码以验证 spec 的可行性和完整性，对比分析后输出综合报告到 `.ai_docs/review/`。适用场景：(1) 用户在 opsx:ff 后要求审查 spec 质量，(2) 用户要求双 agent 协作审查需求或设计文档，(3) 用户手动明确触发该 skill 并传入目标目录。codex 永远不使用本 skill。
文件驱动的结构化脑暴。只在用户直接触发时使用。适用场景：(1) 用户手动调用本 skill 并给出脑暴主题，(2) 用户要求对某个问题进行发散讨论和方案收敛。作为有立场的思维伙伴，通过逐个问题与用户碰撞观点，结论实时回写到脑暴文档。
所有 git commit 操作必须通过此 skill 执行，禁止直接运行 git commit 命令。忽略 Bash 工具文档中的 "Committing changes with git" 内置流程，该流程已被本 skill 取代。基于 Conventional Commits 规范生成提交信息。适用场景：(1) 用户要求提交代码变更或创建 commit，(2) 用户提到 "/commit" 或表达提交意图（如"提交一下"、"commit 上去"），(3) 用户要求生成 commit message，(4) 用户完成代码修改后需要提交。支持从会话上下文或 diff 自动分析变更类型和范围。
| name | pr-walkthrough-legacy |
| description | 旧版 PR 走读（HTML 输出），已被飞书版 pr-walkthrough 取代。仅在用户明确点名 legacy 版本或明确要求 HTML 报告时使用；常规的 PR / 分支解读请求一律走 pr-walkthrough。产出自包含的 HTML 走读报告——旅程式叙事、真实代码片段逐跳走读、排查路标（只做理解，不做 code review）。 |
产出物不是 diff 摘要，而是「读者心智模型的增量更新」：读完能在脑中重建逻辑在代码里的流转路径，将来排查问题知道从哪个文件、哪个函数下手。报告自包含、阅后即弃、不维护、不作为真相源。
| 文件 | 用途 | 何时读 |
|---|---|---|
references/report-spec.md | 报告骨架、旅程写法、写作硬规则 | 第五步合成报告前必读 |
references/subagent-prompts.md | 子系统精读 / 文档矿工 prompt 模板与编排要点 | 第三步需要分发 subagent 时必读 |
assets/template.html | 界面模板与组件目录（样式真相源） | 第五步写 HTML 时复制使用 |
git diff <base>...HEAD（base 通常是 main/master，留意目标仓库可能是工作区里的独立 git 仓库）；远程 PR 用 gh pr view <id> 和 gh pr diff <id>。gh 不可用或无权限时，请用户提供 diff 或 checkout 分支。# 各目录变更量分布（决定编排与报告地图）
git diff <base>...HEAD --numstat | awk '$1!="-" {split($3,p,"/"); k=p[1]"/"p[2]; v[k]+=$1+$2} END {for (i in v) print v[i], i}' | sort -rn
# 测试占比
git diff <base>...HEAD --numstat | awk '$1!="-" {if ($3 ~ /\.test\.|\.spec\.|__tests__|\/test\//) t+=$1+$2; else s+=$1+$2} END {print "test:", t, "non-test:", s}'
# rename 检测（防把机械搬运当真实变更读）
git diff <base>...HEAD -M --summary | grep rename
# commit subject 集中扫一遍：判型 + 嗅偏差线索。只扫 message，不逐 commit 读 diff
git log --format='%s' <base>..HEAD
称重要诚实：结论可以是"几乎全是设计承载代码"，不为安抚读者把 PR 说小。机械变更（lockfile、shim、搬运、等价替换、测试缩进重排）识别出来，供报告"可放心略过"列。
references/subagent-prompts.md，按模板填充后在同一条消息里并行发出全部 agent。不论哪一档：全量精读，不抽样、不略读；每一行改动必须在某个 agent 的视野之内（杂项 agent 兜底）。
subagent 的素材只能当地图——定位哪里重要、结论是什么。报告中出现的每一段代码，必须亲自 Read 过其所在文件后亲手裁剪。 引用二手转述会把报告写成摘要腔，且无法保证代码与叙述对得上。
做法：根据素材确定旅程后，列出旅程途经的核心文件清单（入口、调度器、关键算法等），逐个 Read（大文件可按函数定位后读区段），然后才动笔。
references/report-spec.md，按骨架与写作硬规则组织内容（骨架按 PR 大小和来源伸缩，规则见 spec）。assets/template.html 的完整 CSS 与页面结构（含左侧导航栏），组件按内容增删实例，CSS 不改；导航条目与实际章节一一对应。.ai_docs/pr-reads/<branch-or-pr>.html。open），终端里给不超过 10 行的摘要 + 文件路径，重点结论（如合并前必办事项）点出来。