القائمة
探索需求和方案，支持 [P]/[P+] 多视角讨论，并写出可继续规划的 brainstorm 文档
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Fork Overlay：Task Bundle 持久化 + Failure FSM 集成。在 ce:work 基础上增加 state.md 读写和状态机转换。使用时机：执行 ce:work 时，如果任务有对应的 Task Bundle（docs/tasks/<id>/），加载此 skill 以启用持久化和状态追踪。
Fork Overlay：Codex-first 外部执行器策略。按任务特征路由到 Claude 或 Codex，Codex-first（非品牌路由）。使用时机：需要决定是否将当前任务派发给 Codex 时加载此 skill。
Fork Overlay：经验分层沉淀升级阶梯。检测是否值得将 solution 升级为 pattern 或 skill。使用时机：ce:compound 完成后手动调用，分析 docs/solutions/ 中的重复模式。（不会自动触发，需主动加载此 skill）
Fork Overlay：外部模型调用前置检查门控。调用 Codex/Gemini 之前运行五项检查，防止调用失败浪费时间。使用时机：任何调用外部模型（Codex [C]、Gemini [G]）之前自动运行。
Fork Overlay：ce:work 意图分类门控。在执行前识别任务意图（实现/修复/重构/探索），设定对应的执行策略。使用时机：ce:work Phase 0（环境扫描）之后、Phase 1（Quick Start）之前。
Fork Overlay：Codex Patch Approval 咨询版。当 Codex 返回 patch 时，Claude 审批后才写入文件。使用时机：Codex 以 patch/diff 格式返回代码变更时，由 Claude 作为审批层。
| name | workflows-brainstorm |
| description | 探索需求和方案，支持 [P]/[P+] 多视角讨论，并写出可继续规划的 brainstorm 文档 |
用于在实现前澄清做什么，而不是直接进入编码。
这是 Codex 中的 brainstorm 主入口。它不尝试复刻 Claude Code 的完整运行时，而是用明确状态机保留高价值能力：
[P] 触发 3 个核心视角的多轮讨论，并模拟 party-mode 的 emoji + 角色名 + 相互质疑体验[P+] 触发 8-12 个视角的深度发散和挑战收敛[R] 强制历史经验检索；未传 [R] 时，Standard/Deep 场景自动做历史检索不要调用 Codex CLI。 不要调用 Gemini CLI。
通过协作对话、轻量仓库研究、历史经验检索和方案比较，产出一份可继续规划的 brainstorm 文档：
docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md
[P]：3 个核心视角，适合普通复杂度[P+]：8-12 个视角，适合模糊、高风险或架构性问题[R]：强制检索 docs/solutions/ 历史经验如果用户没有给出清晰主题，先追问，不要直接写文档。
如果用户传入旧的外部 AI 咨询标记，只说明本 Codex brainstorm 入口不处理外部 AI 咨询，清洗掉该标记后继续主流程。
开始时先解析参数，并向用户回显：
PARTY_MODE = none|quick|deepHISTORICAL_RESEARCH = auto|force|skip规则：
[P+] -> PARTY_MODE = deep[P] -> PARTY_MODE = quick[R] -> HISTORICAL_RESEARCH = force[R] 时，先按 Phase 0 判断范围；Standard/Deep 软件或仓库改动场景使用 HISTORICAL_RESEARCH = autoskip先判断是否真的需要 brainstorm：
$workflows-plan[P+] 级别，即使用户只传 [P]如果需求已经非常清晰，不要硬拖长讨论；但仍要确认是否需要持久化 brainstorm 文档。
先做轻量研究，了解：
如果 $repo-research-analyst 可用，优先使用它。
如果不可用，直接用本地搜索完成同等最小研究：rg 查主题关键词、相关 skill、相关 docs、相关 tests。
[R] 的含义是：强制查历史经验。它不是联网搜索，也不是外部 AI 咨询。
历史检索来源：
docs/solutions/docs/brainstorms/docs/plans/执行规则：
HISTORICAL_RESEARCH = force：必须检索HISTORICAL_RESEARCH = auto：Standard/Deep 场景自动检索HISTORICAL_RESEARCH = skip：只在 Lightweight 或明显无历史价值时跳过如果 $learnings-researcher 可用，自动运行 $learnings-researcher。
如果不可用，用 rg 搜索 docs/solutions/ 和相关文档，提炼 3-5 条历史约束、坑点或可复用经验。
输出到后续讨论时，标注：
No relevant learnings found如果 PARTY_MODE = none：
如果 PARTY_MODE = quick：
party-mode 的核心体验：emoji + 角色名 + 角色人格发言，而不是普通 bullet list如果 PARTY_MODE = deep：
party-mode 的全量体验：emoji + 角色名 + 跨角色碰撞每轮讨论必须包含：
每轮结束后必须暂停，向用户提供编号选项并等待回应：
只有用户明确选择收敛、结束、进入计划，或只给出纯执行指令时，才退出 Party Mode。
在写方案前检查覆盖矩阵。不要只因为已经有几个角色发言就宣布完成。
| 维度 | 必须回答的问题 |
|---|---|
| Problem | 真正要解决的问题是什么？不做会怎样？ |
| Users | 谁受影响？他们当前如何完成这件事？ |
| Outcome | 成功标准是什么？如何判断体验变好？ |
| Scope | 本轮做什么，不做什么？ |
| Constraints | 有哪些技术、流程、时间或兼容约束？ |
| Existing Patterns | 仓库里有哪些相近实现、协议或约定？ |
| Historical Lessons | 历史文档里有哪些坑、决策或可复用经验？ |
| Alternatives | 至少 2 个可行方案和 1 个更简单方案是什么？ |
| Risks | 失败模式、边界条件、长期维护成本是什么？ |
| Open Questions | 哪些问题必须现在问用户，哪些可交给 plan 阶段？ |
如果任一关键维度为空，优先补问用户或补做本地研究，不要直接写文档。
基于研究与对话，提出 2-3 个具体方案。
每个方案至少要写：
要明确给出推荐方案，并解释为什么。
如果其中一个方案明显过度工程，要指出它的维护成本。 如果存在低成本高收益的增强项，可以作为 challenger option，而不是默认方案。
写文档前执行完成度门禁。
只有全部满足时，才能写入 brainstorm 文档：
Resolve Before Planning 中没有仍需用户裁决的阻塞问题如果门禁未通过：
Resolve Before Planning写入：
docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md
如果已存在同主题文档，不要直接覆盖。 应先让用户决定：
文档至少包含以下章节：
## What We're Building## Problem Frame## Requirements
### P1 — Must Have### P2 — Should Have### P3 — Could Have### P4 — Later / Parking Lot## Reuse / Build Boundary## Why This Approach## Approaches Considered## Key Decisions## Scope Boundaries## Historical Context## Open Questions## Next Step如果启用 Party Mode，还必须补充：
## Party Mode Summary## Areas Of Agreement## Areas Of Disagreement## Coverage Matrix## Candidate PrioritiesRequirements 中的 P1-P4 表示优先级，R1/R2/R3 表示稳定需求编号；两者必须同时保留。Reuse / Build Boundary 必须说明 Existing capabilities to reuse、Glue code we expect to write、Net-new behavior、Explicit non-goals。
文档要简洁，但必须保留：
完成后向用户展示：
$workflows-plan如果仍有 Resolve Before Planning 问题，不要建议直接进入计划；建议继续 $workflows-brainstorm 解决阻塞问题。