核心用法
core-brainstorming 是一个结构化创意发散技能，专为软件开发中的设计阶段设计。它通过分阶段协作对话——理解想法→探索方案→呈现设计——将模糊的用户意图转化为可落地的技术规格。
启动时自动分析项目上下文（文件结构、近期提交、现有文档），随后采用「一次一问题」策略逐步澄清需求：优先使用选择题降低认知负荷，必要时辅以开放题深挖约束条件。理解目标后，主动提出 2-3 种架构方案并标注权衡，推荐最优路径并解释理由。
设计呈现阶段采用增量验证机制：将方案拆分为 200-300 字的独立小节，逐节确认正确性，覆盖架构、组件、数据流、错误处理与测试策略。验证通过后自动生成设计文档并存档，可无缝衔接 core-writing-plans 进入实施阶段。
显著优点
- 流程结构化：明确的「理解-探索-呈现」三段式降低沟通摩擦
- 认知友好：单问题交互、选择题优先、小节验证，符合人类工作记忆限制
- 决策透明：强制多方案对比避免过早收敛，推荐方案附理由增强可信度
- 上下文感知：自动读取项目状态，设计贴合实际代码基
- 领域扩展：通过条件钩子支持嵌入式、仿真等垂直领域的专业子技能调用
- YAGNI 内置：设计阶段即过滤非必要功能，减少技术债务
潜在局限
- 同步阻塞：依赖人机回合制对话，不适合批量化或自动化场景
- 经验门槛：方案质量受用户技术视野制约，复杂领域需配合专业子技能
- 文档负担：强制要求存档设计文档，小型变更可能显得过重
- 无版本对比：未内置设计迭代的历史追踪与差异分析能力
适合人群
软件工程师、技术负责人、独立开发者在启动新功能、重构或复杂修改前的设计阶段；尤其适合偏好对话式协作、需要结构化决策记录的团队。
常规风险
- 过度设计：探索阶段若未严格执行 YAGNI，可能产生不必要的抽象层
- 确认偏差：增量验证环节若用户被动确认，可能遗漏关键缺陷
- 上下文遗漏：自动读取的项目状态若未覆盖关键隐式知识，设计可能偏离实际
- 子技能依赖：嵌入式/仿真场景若未触发推荐子技能，方案可能缺乏硬件/物理约束考量