复合工程思维风暴
通过协作对话将模糊或宏大的想法转化为规模合适的、仅需求统一计划。
技能要求在执行工作流前运行一个设置脚本，该脚本指示代理遵循其输出，但明确声明技能自身的规则优先。它读取配置文件（config.local.yaml、config.yaml）来决定工件根目录，并且对该根目录进行验证，防止路径逃逸。它指出操作（如发布到Proof、打开浏览器、创建PR）是在用户确认后才执行的。没有发现敏感数据处理或隐蔽数据外泄。然而，发布者身份未经验证，而且该技能涉及执行任意shell命令（设置脚本）。信任扣分是因为缺乏独立的权限审计（未显示最小权限原则的全面应用，因为技能可能在没有任何沙箱的情况下运行任意命令）以及发布者身份未知。总体而言，在静态审查中未发现明显的越权行为。
该技能具有高度结构化的流程，并对配置解析（YAML注释处理）、输出格式解析（`output:`标记）和配置根解析有明确指令。它提供了对失败情况的处理（例如，如果Node不可用则继续，如果无法解析根则回退）。然而，静态审查无法验证脚本是否实际可运行，并且存在复杂的交互规则可能会引入不一致性。未提供测试套件来覆盖技能的关键路径。可靠性扣分是因为缺乏执行证据以及复杂的指令可能存在矛盾。
该技能清晰定义了受众和适用场景（用于头脑风暴、范围界定、盲点检查），并提供明确的非适用边界（不用于执行已指定工作，不用于技术选型判断）。触发条件在描述中细致地定义了。环境适配：该技能似乎不依赖无法访问的海外服务；它主要使用本地工具和可配置的Slack MCP（需要用户认证）。对中文用户没有明显的限制。然而，作为静态读法，尚未验证在目标环境中的实际适配性。
该技能提供了高度结构化的文档，包含渐进式披露（核心文件加上按需加载的参考文件）。它包含详细的配置说明、参数说明（如`output:`标记）、命名稳定性指南（元数据字段名称）以及已知的限制（例如，ce-doc-review仅支持markdown）。它提到许可证（MIT）但并未在技能文件中明确展示。版本控制和变更日志信息在提供的文件中不可见。维护职责未明确分配。由于没有清晰可见的变更日志/版本信息，以及缺少维护者身份，扣分。
该技能声称可以生成需求专用的统一计划，并提供了详细的结构和输出指南。它设定了清晰的产出（`<root>/plans/`下的统一计划工件）和明确的价值主张。然而，在静态审查中，无法验证生成文档的实际质量或直接可用性。成本/收益的合理性似乎不错，因为该技能旨在避免过度设计。由于缺乏实际文本生成的印证，有效性扣分。
该技能的主要声明（它可以生成可靠的统一计划）未由任何测试或第三方执行证据支持。提供了一些可审计的细节（如配置解析、工件结构），但未经过验证。发布者为未知身份，未提供独立的验证。由于缺乏可复现的测试或独立验证，可验证性扣分。
- 发布者身份未经 FollowSkills 企业注册表验证：应谨慎对待权威性声明。
- 技能要求在会话开始时运行任意 shell 脚本：在执行前应检查脚本内容，尤其是在不可信环境中。
- 技能配置读取本地 YAML 文件（.compound-engineering/config.*.yaml）：若使用来自不受信任来源的配置，可能存在路径遍历或错误配置风险。
- 技能可能依赖外部服务（如 Slack MCP、Proof 发布）：这些服务需要额外的认证和网络可达性，在中国大陆可能受限。
- 技能声称生成统一计划工件的准确性和完整性未经独立验证。
这个 Skill 能做什么，适合哪些场景？
ce-brainstorm 是复合工程插件中的一项技能，通过引导式问答帮助用户探索和界定功能或问题。它优先解决“该构建什么”的问题，将产品决策（用户行为、范围边界、成功标准）落实到一份仅需求的统一计划中，为后续的 ce-plan（实现规划）做准备。该技能遵循核心原则，如先评估范围、充当思考伙伴、保持产品合同不包含实现细节，并采用一问一答的交互规则，默认使用平台的阻塞问题工具。它支持多种输出格式（Markdown 或 HTML），并可解析配置以确定工件根目录。该技能适用于软件和非软件领域，但对于非软件领域的头脑风暴，会引导至专门的通用流程。
该技能会扫描仓库以收集背景信息（检查现有类似实现、相关工件），执行产品压力测试，然后通过协作对话引导用户进行一系列界定性问题（一次一个），使用平台原生的阻塞问题工具（如 Claude Code 的 AskUserQuestion 或 Codex 的 request_user_input）。它解决产品决策并起草一份仅需求的统一计划，保存到 <root>/plans/ 目录下，或根据需要生成更简洁的对齐文档。该技能运行一个 Node 脚本以加载技能上下文（在可用的情况下），并在有必要时使用辅助代理进行后台信息收集和事实核查。它通过输入参数支持 Markdown 和 HTML 输出格式。
- 一位产品经理希望对一个模糊的功能想法进行范围界定，并与工程师就应构建什么内容达成一致，然后再进入规划阶段。
- 一位开发人员在一个不熟悉的领域工作，需要有人帮助梳理决策空间并指出盲点，然后再尝试构建功能。
- 一个团队希望快速评估一个大致改进建议的规模，并确定是大任务还是小任务，需要简化的仅需求文档来指导后续规划。
- 在编写实现计划之前，需要一份简短的需求文档或功能简报，作为向 ce-plan 交接的正式工件。
- 一位利益相关者希望验证某个功能想法是否与现有产品形态和成功标准一致，然后再投入开发。
这个 Skill 有哪些优点和局限？
- 通过一次一个问题并使用原生阻塞问题工具，避免了 AI 生成的框架导致过早固定思路的风险。
- 重视范围评估，根据任务的模糊性和大小调整流程，避免不必要的仪式感。
- 将产品决策（做什么）与实现规划（怎么做）分开，实现更清晰的交接。
- 支持 Markdown 和 HTML 输出，可灵活融入现有文档流程。
- 可恢复之前的工作，并在已有工件基础上继续推进，而不是创建重复。
- 高度依赖运行平台的内部机制（如 Claude Code 的 AskUserQuestion 或 Codex 的 request_user_input），这可能在无类似交互原语的平台上限制功能。
- 依赖 Node.js 运行时来加载技能上下文；如果缺少 Node，技能仍可运行，但会缺少部分上下文。
- 需要解析配置以确定工件根目录（`docs_root`）和输出格式；配置错误可能中断流程。
- 该技能有意将实现细节排除在计划之外，要求用户信任后续的规划阶段来补充技术方案。
- 作为更大插件包的一部分，仅安装此单一技能的文件需要手动选择，且不同工具的安装命令差异较大。
如何安装这个 Skill？
要从 GitHub 仓库安装 ce-brainstorm，请按照 README 中的安装说明进行。例如，在 Claude Code 中，运行：
/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering在 Cursor 中，运行：
/add-plugin compound-engineering对于 Codex CLI，首先注册 marketplace：
codex plugin marketplace add EveryInc/compound-engineering-plugin
codex plugin add compound-engineering@compound-engineering-plugin对于其他工具（如 Kimi Code CLI、Cline、Grok Build CLI、Devin CLI、GitHub Copilot、Factory Droid、Qwen Code、OpenCode、Pi、Antigravity CLI），请参阅 README 中的“更多安装选项”部分。安装后，无需额外配置；技能即可通过 /ce-brainstorm 使用。
如何使用这个 Skill？
安装后，在支持的工具中运行 /ce-brainstorm，并提供功能想法或问题作为参数。例如：
/ce-brainstorm 让后台任务重试更安全该技能将引导您完成一系列问答（一次一个问题）。它首先扫描仓库以收集背景信息，然后提出范围界定问题，探讨方法，并在编写计划前确认范围。最终输出是一份保存在 <root>/plans/ 下的仅需求统一计划（默认 docs/plans/）。您可以使用类似 output:html 的参数要求 HTML 输出。该技能会处理不熟悉领域（盲点扫描）、视觉相关功能（视觉探针）以及决定是否应采用某项技术的裁决型问题（路由至 ce-pov）。作为快速通道，如果要求已明确，它会跳过不必要的探索。
这个 Skill 与同类方案有什么区别？
该技能常与同一插件中的 ce-plan 共同使用，ce-plan 从仅需求计划继续推进，增加实施细节。文档中未突出提及此技能与任何其他独立工具的直接比较。