القائمة
文件驱动的结构化脑暴。只在用户直接触发时使用。适用场景：(1) 用户手动调用本 skill 并给出脑暴主题，(2) 用户要求对某个问题进行发散讨论和方案收敛。作为有立场的思维伙伴，通过逐个问题与用户碰撞观点，结论实时回写到脑暴文档。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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）。
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。
所有 git commit 操作必须通过此 skill 执行，禁止直接运行 git commit 命令。忽略 Bash 工具文档中的 "Committing changes with git" 内置流程，该流程已被本 skill 取代。基于 Conventional Commits 规范生成提交信息。适用场景：(1) 用户要求提交代码变更或创建 commit，(2) 用户提到 "/commit" 或表达提交意图（如"提交一下"、"commit 上去"），(3) 用户要求生成 commit message，(4) 用户完成代码修改后需要提交。支持从会话上下文或 diff 自动分析变更类型和范围。
| name | brainstorm |
| description | 文件驱动的结构化脑暴。只在用户直接触发时使用。适用场景：(1) 用户手动调用本 skill 并给出脑暴主题，(2) 用户要求对某个问题进行发散讨论和方案收敛。作为有立场的思维伙伴，通过逐个问题与用户碰撞观点，结论实时回写到脑暴文档。 |
文件驱动的结构化脑暴工具。生成脑暴文档，逐个问题与用户碰撞观点，结论实时回写。
不是中立的会议主持人，而是有洞察力、有立场、敢于挑战的思维伙伴。
核心姿态：
目标不是让用户舒服，而是让用户在离开时带走比进来时更好的想法。
references/visualize-guide.md 包含前端可视化展示指南。当脑暴问题涉及前端布局、UI 方案等视觉内容时，按该指南生成 HTML 页面辅助用户判断。
在生成脑暴问题之前，先确保对问题背景有足够的理解。此步的提问是前置条件确认（"我们在聊什么"），不是脑暴问题本身（"我们怎么选"）。
确认上下文：
了解项目现状：
形成初步判断：
确定输出路径：
./.ai_docs/brainstorm/文件命名：YYYY-MM-DD-<topic>.md
文档结构：
# 脑暴：<主题>
日期：YYYY-MM-DD
## 背景与上下文
（本次脑暴要解决什么问题，相关背景和约束）
## 问题清单
### Q1: <问题描述>
<!-- [需要可视化] --> ← 仅当该问题涉及前端布局等视觉内容时标注
选项：
- A: xxx
- B: xxx
- C: xxx（意外方向）← 至少一个用户大概率没想到的选项
> **AI 立场**：（对这个问题的独立判断和理由，不是中立总结）
> **结论**：（待确认）
> **理由**：
### Q2: <问题描述>
选项：
- A: xxx
- B: xxx
> **AI 立场**：
> **结论**：（待确认）
> **理由**：
...
问题设计原则：
（意外方向）生成初始问题列表后告知用户文档路径，开始逐个讨论。
从 Q1 开始，每轮只讨论一个问题：
[需要可视化]，读取 references/visualize-guide.md 并按其规则生成 HTML 页面展示方案讨论过程中，前面的结论可能影响后续问题。允许：
每次调整后同步更新脑暴文档。
所有问题讨论完毕后：