yinqd3 头脑风暴 → 设计文档
在动手写代码之前，通过结构化对话把想法变成完整设计。
硬门禁（HARD GATE）
在设计获得用户批准之前，禁止调用任何实现技能、写任何代码、搭建任何项目框架。
每个项目都要过这关——Todo 列表、工具函数、配置修改，全都不例外。简单的项目可以有简短的设计，但你必须呈现设计并获取批准。
反模式："这个太简单不需要设计"
每个项目都要走这个流程。"简单"项目恰恰是未经检验的假设造成最多浪费的地方。设计可以短（真正简单的项目只需几句话），但必须呈现并获得批准。
检查清单（按顺序完成）
- 探索项目上下文 — 检查文件、文档、最近的提交记录
- 提出澄清性问题 — 一次只问一个，理解目的、约束、成功标准
- 提出 2-3 个方案 — 带权衡分析和你推荐的方案
- 呈现设计方案 — 按复杂度分节展示，每节获取用户批准
- 编写设计文档 — 保存到
docs/plans/YYYY-MM-DD-<主题>-design.md并提交 - 规格自查 — 快速检查占位符、矛盾、歧义、范围
- 用户审查 — 请用户审查规格文档再继续
- 移交实现 — 调用
writing-plans技能创建实现计划
提问规则
- 每条消息只问一个问题
- 优先使用选择题，开放式也行
- 理解：目的、约束、成功标准、明确不做什么
方案探讨
- 提出 2-3 个不同方案，每个带权衡分析
- 对话式呈现，先说你推荐的，并解释原因
设计呈现
- 确认理解后，呈现设计
- 按复杂度调整每节长度
- 每节问"这看起来对吗？"
- 覆盖：架构、组件、数据流、错误处理、测试策略
关键原则
- 一次一个问题，不要轰炸
- 选择题优先
- YAGNI 无情——移除所有设计中不必要的功能
- 探索替代方案——确定前至少提 2-3 个
- 渐进式验证——呈现设计，获批准，再前进
- 灵活——哪里不对就回去澄清
设计文档
# [功能名称] 设计文档
**目标:** [一句话描述要构建什么]
**架构:** [2-3 句关于方案]
**技术栈:** [关键技术/库]
**文件结构:** [新建/修改的文件，每个文件的职责]
**数据流:** [数据如何流转]
**错误处理:** [错误处理策略]
**测试策略:** [如何测试]
撰写设计文档后
- 占位符扫描 — 有 "TBD"、"TODO"、不完整的部分吗？修复。
- 内部一致性 — 各部分有矛盾吗？架构和功能描述一致吗？
- 范围检查 — 足够聚焦吗？还是需要再分解？
- 歧义检查 — 有需求能有两种解读吗？选定一种并明确。
然后请用户审查，等待批准后再调 writing-plans。