Menu
旧版 PR 走读（HTML 输出），已被飞书版 pr-walkthrough 取代。仅在用户明确点名 legacy 版本或明确要求 HTML 报告时使用；常规的 PR / 分支解读请求一律走 pr-walkthrough。产出自包含的 HTML 走读报告——旅程式叙事、真实代码片段逐跳走读、排查路标（只做理解，不做 code review）。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 行的摘要 + 文件路径，重点结论（如合并前必办事项）点出来。