从想法到设计

通过自然对话，把想法打磨成 完整设计与规格。

先理解当前项目上下文，再 一次只问一个问题 细化需求；清楚要做什么后，呈现设计并请用户认可。

反模式：「太简单不需要设计」

所有 项目都走本流程。待办列表、单函数小工具、改配置——全部。所谓「简单」项目，往往是 未检验假设 导致返工最多的地方。设计可以很短（真简单时几句话），但必须 呈现并获批。

清单（须逐项建任务并按序完成）

1. 探索项目上下文 — 看文件、文档、近期提交
2. （若将涉及视觉问题）提供视觉伴侣 — 单独一条消息，不与澄清问题混发；见下文「视觉伴侣」
3. 澄清问题 — 一次一个，弄清目的、约束、成功标准
4. 提出 2–3 种方案 — 含权衡与你的推荐
5. 分节呈现设计 — 复杂度决定每节篇幅；每节后询问是否 OK
6. 撰写设计文档 — 保存到 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交（用户若指定其他路径则从其偏好）
7. 规格自检 — 占位符、矛盾、歧义、范围（见下）
8. 用户审阅成文规格 — 请用户读文件后再继续
9. 转入实现规划 — 调用 writing-plans 技能写实现计划

流程说明（要点）

理解想法： 先看仓库现状；若请求包含多个独立大子系统，先 分解 再对 第一个子项目 走完整流程（每子项目：规格 → 计划 → 实现）。

探索方案： 给 2–3 种做法与权衡；推荐其一并说明理由。

呈现设计： 分节讲清架构、组件、数据流、错误处理、测试；每节确认后再继续。

隔离与清晰： 小模块、单职责、接口明确；每个单元能回答：做什么、怎么用、依赖什么。

存量代码： 先摸结构再提案；只围绕当前目标做 有针对性的 改进，不无关大重构。

设计之后

文档： 将Validated 设计写入上述路径；可用清晰写作类技能；提交 git。

规格自检： 扫 TBD/TODO、内部一致性、范围是否过大、是否有歧义；当场改，不必形式主义重审。

用户审阅门： 请用户读已提交规格；有修改则改完再问过；通过后才 进入 writing-plans。

实现： 只 调用 writing-plans。不要调用 frontend-design、mcp-builder 等实现技能。

原则

一次一问、偏好选择题、YAGNI、多方案比较、分步确认设计、必要时回头澄清。

视觉伴侣

浏览器里展示线框、示意图、视觉选项。是工具而非模式；用户同意只表示 可以 在需要时用浏览器，不是每个问题都要用。

提供方式： 当你预期接下来会有 视觉向 问题时，单独一条消息 询问是否愿意用本地 URL 打开浏览器看示意（说明可能较耗 token）。不要 与同条里的其他内容混发。拒绝则纯文本继续。

逐题判断： 即使用户同意，每道题仍要判断：看图是否比读文字更懂？ 概念题用终端；版式对比用浏览器。

用户同意后，细节见技能包内 skills/brainstorming/visual-companion.md。