upaseo-brainstorm

name	upaseo-brainstorm
description	本地脑暴与方案设计技能。融合了 Karpathy 极简原则 (Think Before Coding) 与 Simple 工作流，旨在帮助 Agent 消除疑惑、避免过度设计，并在动手前与用户快速达成共识。

Upaseo Brainstorm (本地脑暴技能)

本技能用于在方案空间尚未收敛时做本地脑暴。它的目标是“在编写任何代码前先思考，保持方案极简，绝不闭门造车”。

触发边界

• 在 using-upaseo 的完整仪式模式中，本技能由主流程强制调用。
• 在 using-upaseo 的微改快速通道或 quick 模式中，不强制调用本技能；除非 Agent 发现需求、验收或技术方向仍不明确，必须升级并先收敛方案。
• 直接调用 /upaseo-brainstorm 时，只做方案收敛，不写代码、不创建脚手架、不修改项目文件。

核心原则

1. Think Before Coding (动码前先思考)：

   • 绝不瞎猜用户的意图。如果你有任何不确定，停下来，通过脑暴明确它。
   • 如果有多种实现路径，必须同时呈现——绝不能默默做主选择其中一种。

2. Simplicity & YAGNI (极简与未需勿增)：

   • Senior 工程师视角：设计只满足眼前需求的最简单方案，严禁为了“未来扩展性”做过度设计 (Speculative Design)。
   • 如果能用 50 行解决，绝不写 200 行。

3. 手术刀原则 (Surgical Changes)：

   • 方案应当是局部的、手术刀式的。不要试图在本次修改中“顺便重构”相邻的无关代码。

---

前置避障读取

执行标准避障前置读取，见 upaseo/references/learnings-precheck.md。本技能相关 category 为 design_flaw|wrong_assumption。提炼出的规则作为后续方案设计的硬约束——任何方案不得违反历史教训中的规则。

---

脑暴执行流程 (Discover -> Propose -> Converge -> Capture)

1. 发现阶段 (Discover)

• 仔细阅读现有的代码上下文、架构约定和依赖。
• 如果需求不明确，整理出最多 3 个关键性的多选题。一次性合并成一条消息发送给用户，绝对不能零碎地进行多轮提问打扰用户。
• 如果意图已经 100% 明确，可直接跳到 Propose 阶段。

2. 方案提出阶段 (Propose)

• 向用户呈现 2 种不同的技术实现方案。
• 对这两种方案进行极简的 Trade-offs (折中与对比)，并附带简短的优缺点说明。
• 给出你作为 Senior 工程师的明确推荐理由。
• 格式模板：

  ## 方案 A: [简短名称]
  - 做法：...
  - 优点：... | 缺点：...
  
  ## 方案 B: [简短名称]
  - 做法：...
  - 优点：... | 缺点：...
  
  ## 推荐方案
  我们推荐方案 [A/B]，因为 [理由]。
  

3. 收敛确认阶段 (Converge)

• 等待用户给予明确的批复（如“同意方案 A”或“按照推荐的来”）。
• 如果用户提出调整，最多进行 2 次修正并重新提出；如果依然无法达成共识，请用户直接指示确切方案。
• 硬性红线：在用户没有明确批复同意具体方向之前，严禁编写任何代码、创建任何临时文件或脚手架。

4. 记录阶段 (Capture)

• 一旦用户批准，将最终选定的方案（What, Why, Key Decisions）记录在计划的 Notes 节点。
• 只有当项目已有代码注释惯例或用户明确要求时，才在代码中添加极简注释；不得为了记录脑暴结论而污染第一个代码文件。