brainstorming

name	brainstorming
description	仅在用户明确要与代理讨论/共创设计，或需求仍明显不清晰且存在实质性方案权衡、正在进入设计阶段时使用。

将想法共创为设计

概览

通过自然协作对话，把初始想法逐步收敛为可执行的设计与规格。

触发条件（严格）

仅当满足以下任一条件时触发：

1. 用户明确要求讨论、头脑风暴、方案比较或设计共创。
2. 需求仍存在关键不确定性，且方案权衡显著，用户正在进入设计阶段。

不触发场景：

• 用户已给出清晰实现步骤。
• 任务本身是直接实现、修 bug、调试、评审或纯解释。
• 用户明确希望直接执行而非讨论设计。

本技能启用后，在用户批准设计前，禁止写代码、搭脚手架、调用实现型技能或进行实现动作。

执行清单（按序）

1. 探索项目上下文：代码、文档、最近提交。
2. 澄清问题：每轮 2-3 个最关键问题，总数不超过 6 个。
3. 提出 2-3 个可行方案：给出权衡与推荐。
4. 分段呈现设计：覆盖 WHAT/WHY/HOW，并逐段确认。
5. 按需落盘设计文档：仅在用户要求或流程要求时写入 docs/plans/<topic>_YYYYMMDD.md。
6. 仅在用户要求进入实现规划时再切换到规划技能。

对话要求

• 与用户交互默认使用简体中文。
• 优先多选题，必要时开放问答。
• 持续围绕目标、约束、成功标准。

设计输出要求

• 提供 2-3 套方案并明确推荐项及理由。
• 按复杂度控制篇幅：简单简述，复杂项详述。
• 需要时覆盖：架构、模块划分、数据流、异常处理、测试策略。

设计后续

• 仅在用户需要“保存设计产物”时落盘。
• 非用户明确要求，不提交仅文档变更。
• 只有在用户明确“进入实现规划”时，才调用规划类技能。

关键原则

• 少而关键的问题（总计 ≤ 6）。
• 严格增量确认，避免一次性拍板。
• 强制 YAGNI，主动剔除非必要能力。
• 若理解不一致，立即回退澄清。