| disable-model-invocation | true |
| name | intent-confirmation |
| description | 当用户的请求在执行前需要澄清目标或边界时使用：需求抽象、涉及架构或设计决策、影响范围大、存在多种实现路径、可能修改重要文件，或用户明确要求先确认。不要用于简单问答、只读查询、明确的小修小改或可安全直接执行的任务。 |
| allowed-tools | AskUserQuestion |
意图确认规范
概述
本 Skill 定义了 Agent 在执行任务前确认用户意图的标准流程。目的是避免因理解偏差导致的无效工作，确保 Agent 与用户对任务目标达成一致。
核心原则
先确认，后执行 - 在执行任何非简单任务前，必须先复述用户意图并获得确认。
确认流程
用户提出需求
↓
判断是否需要确认（见「触发条件」）
↓
┌─ 需要确认 ─────────────────────────┐
│ 1. 复述用户意图 │
│ 2. 列出关键理解点 │
│ 3. 询问"是这个意思吗？" │
│ 4. 等待用户确认 │
│ ├─ 确认正确 → 开始执行 │
│ └─ 需要修正 → 重新理解后再确认 │
└────────────────────────────────────┘
↓
┌─ 无需确认 ─────────────────────────┐
│ 直接执行任务 │
└────────────────────────────────────┘
触发条件
需要确认的场景
| 场景 | 说明 | 示例 |
|---|
| 抽象需求 | 需求描述较为抽象或模糊 | "优化一下这个功能" |
| 设计决策 | 涉及架构变更或设计选择 | "重构用户认证模块" |
| 多义表达 | 用户表达可能有多种理解 | "更新文档"（哪个文档？更新什么？） |
| 大范围影响 | 任务影响范围较大 | "统一项目的错误处理方式" |
| 隐含假设 | 需要做出假设才能执行 | "添加一个新功能"（具体什么功能？） |
| 多步骤任务 | 涉及多个步骤的复杂任务 | "实现用户注册流程" |
无需确认的场景（例外情况）
| 场景 | 说明 | 示例 |
|---|
| 明确简单任务 | 任务明确且简单 | "提交代码"、"运行测试" |
| 详细 Spec | 用户已给出详细的 Spec 文档 | "按照 plan.md 执行" |
| 信息查询 | 纯粹的信息查询 | "这个函数是做什么的？" |
| 单文件操作 | 针对特定文件的简单操作 | "修复 login.js 第 42 行的拼写错误" |
| 用户明确指示 | 用户明确表示不需要确认 | "直接做，不用问我" |
确认话术模板
标准模板
我理解你的意思是：
- [理解点1]
- [理解点2]
- [理解点3（如有）]
是这个意思吗？
带选项的模板（当存在多种可能理解时）
我理解你的需求，但有几种可能的实现方式：
**理解 A**：
- [描述理解 A]
**理解 B**：
- [描述理解 B]
你希望采用哪种方式？或者有其他想法？
带补充问题的模板（当需要更多信息时）
我理解你的意思是：
- [理解点1]
- [理解点2]
在开始之前，我需要确认几个问题：
1. [问题1]？
2. [问题2]？
是这个意思吗？
示例
示例 1：抽象需求
用户：更新 skill，当针对该功能更新时，同样要创建更新文档
Agent：我理解你的意思是：
- 更新 spec-executor skill 的内容
- 在 skill 中增加一条规则：当针对某项功能进行更新时，需要先创建更新 Spec 文档，放在该功能原有 Spec 的同一目录下
是这个意思吗？
示例 2：多义表达
用户：帮我处理一下登录的问题
Agent：我理解你遇到了登录相关的问题，但我需要确认具体是哪方面：
**可能是**：
- 登录功能有 bug 需要修复
- 登录流程需要优化或重构
- 登录页面 UI 需要调整
- 登录安全性需要加强
你具体想解决哪个问题？或者能描述一下遇到的具体情况吗？
示例 3：设计决策
用户：给项目添加缓存功能
Agent：我理解你希望为项目添加缓存功能。在开始之前，我需要确认几点：
- **缓存范围**：是针对 API 响应缓存，还是数据库查询缓存，或者两者都要？
- **缓存方案**：倾向于使用 Redis 这样的外部缓存，还是内存缓存？
- **缓存策略**：有特定的过期时间或失效策略要求吗？
请告诉我你的想法，我再制定具体方案。
示例 4：无需确认
用户：运行一下测试
Agent：[直接执行测试命令，无需确认]
用户：查看 src/api/auth.py 的内容
Agent：[直接读取文件，无需确认]
确认后的行为
用户确认正确
用户：对的
Agent：好的，我开始执行...
[开始执行任务]
用户指出理解偏差
用户：不是，我的意思是...
Agent：明白了，让我重新理解：
- [修正后的理解点1]
- [修正后的理解点2]
这次理解对了吗？
用户补充信息
用户：差不多，但还需要考虑...
Agent：收到，我更新一下理解：
- [原有理解点]
- [新增的考虑点]
这样完整了吗？
质量标准
好的确认
- 准确捕捉用户的核心意图
- 用具体、可执行的语言描述
- 主动识别潜在的歧义点
- 适当提出需要澄清的问题
差的确认
- 简单重复用户的话（没有理解转化）
- 遗漏关键信息
- 过度确认简单任务（浪费时间）
- 确认内容过于冗长
与其他 Skill 的协作
与 spec-writer 协作
在创建 Spec 之前，应先确认：
与 spec-executor 协作
如果 Spec 已经明确，通常无需再次确认，直接执行即可。
与 project-memory 协作
如果在确认过程中发现了重要的需求澄清模式，可以考虑记录到战略记忆中。
后续动作（工具记忆）
完成意图确认后，你应该：
如果用户确认理解正确
- 立即开始执行任务
- 如果是复杂任务，使用 TodoWrite 工具规划步骤
- 执行过程中如遇新的歧义，再次确认
如果用户指出理解偏差
- 仔细阅读用户的修正说明
- 重新组织理解并再次确认
- 不要在未确认的情况下开始执行
相关 Skill
/spec-writer - 如果需要创建功能 Spec/memory - 如果发现了值得记录的沟通模式
