用途：在编写实现计划之前，通过协作式对话探索功能需求与可行方案，回答「要构建什么」，随后交由 /workflows:plan 回答「如何构建」。使用时以 [feature idea or problem to explore] 作为参数传入功能描述；若描述为空，需先询问用户想要探索的功能、问题或改进点，未获得描述前不继续。
主要流程：阶段 0 评估需求清晰度，若已有明确验收标准、可参照的既有模式、确切预期行为与受限范围，可建议直接进入 /workflows:plan 或继续探索；阶段 1 先做轻量仓库调研，运行 Task repo-research-analyst("Understand existing patterns related to: <feature_description>") 了解相似功能、既有模式与 CLAUDE.md 指引，再用 AskUserQuestion 工具一次一个问题地对话，优先使用多选项，从目的与用户等宽泛问题逐步收窄到约束和边界情况，并确认成功标准，直到想法清晰或用户表示 proceed；阶段 2 基于调研与对话提出 2-3 个具体方案，每个含简述、优缺点与适用场景，先给出推荐并说明理由，遵循 YAGNI 偏好更简单的方案，再询问用户选择；阶段 3 将设计写入 docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md，写入前确保目录存在，文档含 What We're Building、Why This Approach、Key Decisions、Open Questions；阶段 4 询问下一步：进入规划运行 /workflows:plan（会自动识别该头脑风暴）、继续打磨设计或暂告段落。完成后输出文档路径、关键决策与下一步提示。
限制与准则：只关注「什么」而非「如何」，实现细节留给计划；一次只问一个问题；应用 YAGNI；每节输出控制在 200-300 词；绝不编写代码。当前年份为 2026，用于标注头脑风暴文档日期。更详细提问技巧、方案探索模式与 YAGNI 原则需加载 brainstorming 技能查阅。该技能的具体安装命令、价格与平台支持信息暂未提供。