菜单
探索需求和方案，支持 [P]/[P+] 多视角讨论，并写出可继续规划的 brainstorm 文档
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| 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 解决阻塞问题。
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 作为审批层。