用途：这是一套结构化的实现前设计探索流程，用于把模糊的想法、功能请求或问题陈述，转成一份书面规格说明（spec）；在规格写完并获批前不写任何代码、不做方案、不定架构。
主要能力：分五个阶段推进——1) Intake 读取上下文、判断成熟度、复述理解；2) Divergence 用一次一个问题的方式在 7 类维度扩展问题空间；3) Convergence 收敛到具体范围，锁定必做项与非目标；4) Spec Writing 依据收集到的材料写完整规格并跑质量清单；5) Approval 获取用户明确批准并对实现设硬性闸门。每个阶段单独一个文件、逐阶段加载，阶段结束设确认门槛，需用户确认后再进入下一阶段，不跳过、不合并。
使用方式：先加载 Phase 1，用户逐阶段确认后加载下一阶段。通过 /brainstorming 加主题启动，例如 /brainstorming user authentication for a SaaS app、/brainstorming migrate our monolith to services；不带参数时先询问想探索什么。若提供了 $ARGUMENTS，则以它作为初始主题直接进入 Phase 1。
核心规则：规格获批前不得写代码，包括伪代码、脚手架或“随手示例”；每条消息只问一个问题；先开放性问题后封闭性问题；挑战假设而非挑战人；范围由用户界定；非目标与目标同等重要；验收标准必须可测（如“p95 下 200ms 以内”而非“要快”）；深度随复杂度伸缩；锁定范围前先解决矛盾。
适用场景：用户说要构建某物但无书面需求；功能请求只有一两句话；用户在定义 X 之前先问怎么造 X；用户说“来头脑风暴”或“帮我想清楚”；已有问题陈述但解空间未探索。
限制：资料未提供价格、平台、运行环境、依赖安装命令或实测效果等信息。与其它技能的衔接场景包括规格获批后进入 writing-plans、test-driven-development，以及涉及架构、API 设计、数据库设计、产品经理、QA 角色等情形。