intent-discovery

将想法转化为可执行的设计

概述

通过结构化对话，将初步想法逐步完善为完整、明确且经过验证的设计。先了解现有项目的整体情况，再通过有针对性的问题反复深化理解。设计成形后，提交给用户审批。

首要原则

NO IMPLEMENTATION WITHOUT A VALIDATED DESIGN FIRST

没有例外。没有变通办法。没有捷径。

适用场景

以下情况必须使用：

• 创建新功能或组件
• 扩展现有系统的能力
• 更改现有代码的行为
• 启动新项目或模块
• 重构或重新设计现有系统

以下情况可跳过：

• 修正拼写或语法错误
• 按用户明确指定的内容更新导入语句
• 完全按照用户指示进行配置更改
• 删除用户明确指出要删除的文件
• 执行用户明确提供的命令

在提交设计并获得用户批准之前，不得调用任何实现技能、生成任何代码、搭建任何项目，或采取任何实现行动。无论项目看起来多么简单，此要求都适用。

认知陷阱

合理化说辞	实际情况
“这件事太简单，不值得做设计”	最简单的项目往往藏着最多未经检验的假设。即使是一个笔记应用，也需要确定数据模型、存储方式和交互设计。
“用户已经给了精确的规格”	用户描述的是目标，而非设计。挖掘需求，才能弥合用户想要什么与如何实现之间的差距。
“我已经知道最优方案”	你只知道一种方案。展示其他选项能揭示取舍并发现盲点。
“做设计会拖慢进度”	做错东西更耽误时间。花五分钟做设计，可以避免返工两小时。
“这只是个小改动”	方向错误的小改动会不断累积。继续之前，先确认方向。
“用户似乎急着开始”	用户急于得到的是成果，而不是仓促行事。简短的设计讨论有助于建立信任。

每个项目都必须经过这一流程。无论是待办事项列表、实用函数，还是配置微调，都不例外。“简单”项目恰恰最容易因未经检验的假设而造成大量无谓的工作。设计可以简短（真正简单的工作只需几句话），但你必须提交设计并获得批准。

检查清单

你必须为以下每项创建任务，并按顺序完成：

1. 了解项目整体情况——检查文件、文档和近期提交记录
2. 查找参考资料——调用 reference-engine 技能，转到合适的参考系统（外部仓库和库使用 github-search，内部模式使用 codebase-research，视觉主题使用 design-research，UI 使用 ux-patterns，API／模式／测试／基础设施使用内置库）
3. 提出澄清问题——每条消息只问一个问题，弄清目的、限制和成功标准
4. 提出 2–3 种方案——为选项标注 A/B/C 并说明取舍，用星号标出推荐方案
5. 提交设计——按复杂程度划分章节，并在每个章节后征求用户确认（YoloMode：提交后继续）
6. 记录设计文档——保存到 docs/plans/YYYY-MM-DD-<topic>-design.md 并提交
7. 移交实现工作——调用 task-planning 技能，制定实现计划

工作流图

digraph intent_discovery {
    "Survey project landscape" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Present 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User confirms design?" [shape=diamond];
    "Record design document" [shape=box];
    "Invoke task-planning" [shape=doublecircle];

    "Survey project landscape" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Present 2-3 approaches";
    "Present 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User confirms design?";
    "User confirms design?" -> "Present design sections" [label="no, revise"];
    "User confirms design?" -> "Record design document" [label="yes"];
    "Record design document" -> "Invoke task-planning";
}

终止状态是调用 task-planning。 不得调用 ui-engineering 或任何其他实现技能。intent-discovery 之后唯一可以调用的技能是 task-planning。

详细流程

探索想法：

• 首先检查当前项目状态（文件、文档、近期提交）
• 一次提出一个问题，以加深理解
• 实际可行时优先使用选择题，但也可以使用开放式问题
• 每条消息只包含一个问题——如果某个主题需要深入探讨，请分多条消息进行
• 重点关注：目的、约束、成功标准

研究现有解决方案：

• 必需子技能： 使用 godmode:reference-engine 路由到合适的参考系统
• reference-engine 技能会路由到：github-search（外部仓库和库）、codebase-research（内部代码库模式）、design-research（视觉主题）、ux-patterns（UI），或其内置库（API、架构、测试、CI/CD、基础设施）
• 总结发现：“从 [sources] 找到参考资料：[相关内容]”
• 将研究结果融入方案：说明要基于哪些参考资料进行构建、提取或研究

评估方案：

• 提出 2-3 个各不相同的方案，标记为选项 A、B、C，并说明权衡
• 用星号（⭐）标出推荐选项
• 将推荐选项放在最前面，并解释推荐理由
• 引用研究结果：“方案 A 的灵感来自 github.com/x/y（5k 个星标，MIT 许可证）”
• 如果启用了 YoloMode： 仍需展示所有方案，并等待用户选择。不得自动选定方案。

呈现设计：

• 确信设计已明确后，再进行呈现
• 根据复杂程度调整各部分的篇幅：简单部分用几句话说明，复杂部分最多用 200-300 个词
• 每呈现完一部分，都要询问目前看来是否正确
• 涵盖：架构、组件、数据流、错误处理、测试策略
• 如果有不清楚的地方，应准备好重新讨论并澄清
• 如果启用了 YoloMode： 一次性呈现完整设计，然后直接进入记录环节，无需逐部分确认。用户信任推荐方案。

设计获批后

文档：

• 将已确认的设计写入 docs/plans/YYYY-MM-DD-<topic>-design.md
• 将设计文档提交到版本控制系统

实施：

• 调用任务规划技能，生成详细的实施计划
• 不得调用任何其他技能。下一步必须是任务规划。

防护原则

绝不：

• 不得因为工作“简单”就跳过设计——假设往往藏在简单之处
• 听完请求后直接开始编写代码
• 只提供一个方案——始终提供 2-3 个方案并说明权衡
• 将用户批准视为走过场——必须切实采纳反馈
• 在设计文档编写并提交之前开始实施

始终：

• 提供 2-3 个方案，说明权衡并明确给出推荐意见
• 在进入下一步之前，针对每个设计部分获得用户明确批准
• 将设计文档写入 docs/plans/ 并提交
• 下一步调用任务规划（绝不调用实施技能）
• 根据复杂程度调整设计深度——简单问题简要说明，复杂问题充分阐述

指导原则

• 一次只问一个问题——避免一次提出多个问题，让人应接不暇
• 优先选择题——可行时，选择题比开放式问题更容易回答
• 严格遵循 YAGNI——从每个设计中剔除不必要的功能
• 探索备选方案——作出决定之前，始终提出 2-3 个方案
• 增量验证——呈现设计，并在推进之前获得批准
• 保持灵活——遇到不合理之处时，重新讨论并澄清

关联技能

此技能融入更广泛的 GodMode 工作流：

• task-planning -- intent-discovery 之后唯一的下一步。将已验证的设计转化为可执行的实现计划。
• reference-engine -- 在 intent-discovery 期间调用，用于查找与设计相关的参考实现、主题、UX 模式或内置库。
• github-search -- 在研究期间使用，用于在从头构建之前查找现有的开源实现、库和模式。
• codebase-research -- 由 reference-engine 使用，用于查找内部代码库模式、惯例和类似实现。
• specification-first -- 对于需要正式规范的项目，此处生成的设计文档可用于规范驱动的工作流。