メニュー
PR / 分支变更深度解读。全量精读 diff 后在飞书文档中产出一份走查文档——旅程式叙事、画板图解、真实代码片段、排查路标，帮助项目 owner 重建对代码的理解与掌控（只做理解，不做 code review）。硬依赖 lark-cli 与 lark-doc / lark-whiteboard skill。适用场景：(1) 用户要求解读、理解某个 PR、分支或本地 diff 做了什么，(2) 用户给出 GitHub PR 链接或编号要求分析其设计与影响，(3) 大型变更（含 agent 代写的代码）合并前需要系统性摸清关键设计与流程。
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 走读（HTML 输出），已被飞书版 pr-walkthrough 取代。仅在用户明确点名 legacy 版本或明确要求 HTML 报告时使用；常规的 PR / 分支解读请求一律走 pr-walkthrough。产出自包含的 HTML 走读报告——旅程式叙事、真实代码片段逐跳走读、排查路标（只做理解，不做 code review）。
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 自动分析变更类型和范围。
SOC 職業分類に基づく
| name | pr-walkthrough |
| description | PR / 分支变更深度解读。全量精读 diff 后在飞书文档中产出一份走查文档——旅程式叙事、画板图解、真实代码片段、排查路标，帮助项目 owner 重建对代码的理解与掌控（只做理解，不做 code review）。硬依赖 lark-cli 与 lark-doc / lark-whiteboard skill。适用场景：(1) 用户要求解读、理解某个 PR、分支或本地 diff 做了什么，(2) 用户给出 GitHub PR 链接或编号要求分析其设计与影响，(3) 大型变更（含 agent 代写的代码）合并前需要系统性摸清关键设计与流程。 |
产出物不是 diff 摘要，而是「读者心智模型的增量更新」：读者假设没看过这个 PR 的任何 diff，读完能在脑中重建逻辑在代码里的流转路径，将来排查问题知道从哪个文件、哪个函数下手。产出形式是一份飞书文档。
确认以下依赖全部可用，缺任何一项，直接告知用户缺什么、本 skill 无法执行，然后停止。不提供任何替代输出形式。
lark-cli 可执行（command -v lark-cli，找不到再看 /opt/homebrew/bin/lark-cli）。lark-doc 与 lark-whiteboard skill 在当前环境的可用 skill 列表中。| 文件 | 用途 | 何时读 |
|---|---|---|
references/report-spec.md | 读者模型、文档骨架、图文节拍、写作规则 | 第五步动笔前必读 |
references/subagent-prompts.md | 子系统精读 / 文档矿工 / 画板绘制 prompt 模板与编排要点 | 第三步分发 subagent、第六步插画板时必读 |
references/feishu-authoring.md | lark-cli 写入规程与实测坑 | 第五步动笔前必读 |
references/codex-leg.md | Codex 独立分析腿的启动、prompt、结果吸收规程 | 第三步决定启动 Codex 分析腿时必读 |
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 兜底）。
Codex 独立腿默认不起。 只在两种情况下起：用户点名要 Codex / 双视角；或 diff 超过 ~5,000 行时主动问一句"要不要加一条 Codex 独立分析腿追求更全的视角"（问一次即可，用户不要就不起）。起腿时读取 references/codex-leg.md，按其中规程后台运行、输出落 .ai_docs/pr-reads/<slug>/，主力照常推进后续步骤，其产物留到第七步吸收。
subagent 的素材只能当地图——定位哪里重要、结论是什么。文档中出现的每一段代码，必须亲自 Read 过其所在文件后亲手裁剪。 引用二手转述会把文档写成摘要腔，且无法保证代码与叙述对得上。
做法：根据素材确定旅程后，列出旅程途经的核心文件清单（入口、调度器、关键算法等），逐个 Read（大文件可按函数定位后读区段），然后才动笔。
references/report-spec.md 与 references/feishu-authoring.md，并加载 lark-doc skill。正文定稿后规划全文画板，共 3–6 张，每张只回答一个问题；优先给图状信息（状态机、闸门、管线、泳道、时序）。规划产物是每张图的「事实清单 + 结构隐喻」，见 references/subagent-prompts.md 的画板模板。
只做理解，不做 code review：不挑刺、不评风格、不提改进建议。"重要逻辑没有测试兜底"属于事实陈述，写入文档的测试与风险章节。