用途：goal 是完整功能开发流程的压缩替代方案，通过简短对话式访谈生成单个 goal.md 文档，通常只需 3-6 个问题。它用一份文档代替四份，用平实语言代替正式需求编号，用快速访谈代替多阶段深度调研。
适用场景：基础设施工作（部署、配置、搭建服务）、脚本或小工具开发、技术配置或迁移，以及任何比一次性任务大、但又不是完整产品功能的工作。不适用：完整产品功能应使用 /feature-vision、/feature-requirements、/feature-spec、/feature-plan；简单一次性任务直接做或使用 plan 模式。
文档结构：goal.md 是单个 markdown 文件，含四部分——目标陈述（一段话说明要构建什么、为什么、成功标准）、需求（平实语言的简单要点，不用 REQ-X.X.X 编号或用户故事格式）、技术方案（工具、语言、集成点、关键选择）、计划（带复选框的有序步骤）。目标长度 1-2 页，过长说明想复杂了，应改用完整功能流程。
使用方式：先创建 TODO 列表跟踪三个阶段，第一阶段标记为 in_progress，其余为 pending。阶段一发现（2-3 个问题）：一次只问一个问题，了解做什么和为什么，先检查代码库、记忆和项目文档，能从上下文回答的不要问。阶段二技术方案（1-2 个问题）：了解怎么做，同样一次一问，应基于用户技术栈提出建议并确认，而非开放式提问。阶段三生成文档：默认保存到当前项目根目录下 goals/YYYY-MM-DD-brief-name/goal.md，若当前项目不合适则询问保存位置；生成后标记所有 TODO 阶段完成，并询问是否开始执行计划或先调整。
限制与准则：速度是关键，总访谈 3-6 个问题；一次只问一个问题；要有主见，能建议就不问；使用平实语言；先检查上下文；只产出一份 goal.md，不生成讨论摘要、future.md 或交叉引用；计划步骤应具体可执行并包含验证步骤，不包含时间估算。