Menu
当用户的请求在执行前需要澄清目标或边界时使用：需求抽象、涉及架构或设计决策、影响范围大、存在多种实现路径、可能修改重要文件，或用户明确要求先确认。不要用于简单问答、只读查询、明确的小修小改或可安全直接执行的任务。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
妙搭（Spark/Miaoda）应用开发与托管：应用创建、HTML静态站点发布、本地全栈开发、云端生成迭代。当用户要开发/新建一个系统·工具·平台·应用，或要本地开发 / 云端开发 / 修改 / 部署 / 发布 / 上线 / 拿可分享链接，或用 HTML 做页面·网站·部署到妙搭，或提到妙搭/Spark/Miaoda（应用运行时域名形如 *.aiforce.cloud）、应用数据库、可见范围时使用。不负责普通云盘文件上传（lark-drive）、飞书文档编辑（lark-doc）、原生幻灯片创建（lark-slides）。
飞书云文档（Docx / Wiki 文档，v2 API）：读取和编辑飞书文档内容。当用户给出文档 URL 或 token，或需要查看、创建、编辑文档、插入或下载文档图片附件时使用。文档中嵌入的电子表格、多维表格、画板，先用本 skill 提取 token 再切到对应 skill。当用户给出 doubao.com 的 /docx/ 或 /wiki/ URL/token 时，也应直接使用本 skill；路由依据是 URL 路径模式和 token，而不是域名。不负责文档评论管理，也不负责表格或 Base 的数据操作。
飞书云空间（云盘/云存储）：管理 Drive 文件和文件夹，包含上传/下载、创建文件夹、复制/移动/删除、查看元数据、评论/权限/订阅、标题、版本和本地文件导入。用户需要整理云盘目录、处理云空间资源 URL/token，或导入 Word/Markdown/Excel/CSV/PPTX/.base 为 docx/sheet/bitable/slides 时使用；doubao.com 云空间 URL/token 也按资源路径和 token 路由，不回退 WebFetch。不负责：文档内容编辑（走 lark-doc）、表格/Base 表内数据操作（走 lark-sheets/lark-base）、知识空间节点/成员管理（走 lark-wiki）、原生 Markdown 文件读写/patch/diff（走 lark-markdown）。
Lark/Feishu real-time event listening / subscribing / consuming: stream events as NDJSON via `lark-cli event consume <EventKey>` (covers IM messages/reactions/chat changes, VC meeting ended, Minutes generated, Whiteboard updated, etc.). Use for Lark bots, real-time message processing, long-running subscribers, streaming webhook/push handlers. Supports `--max-events` / `--timeout` bounded runs and a stderr ready-marker contract — designed for AI agents running as subprocesses.
飞书即时通讯：收发消息和管理群聊。发送和回复消息、搜索聊天记录、管理群聊成员、上传下载图片和文件（支持大文件分片下载）、管理表情回复、发送应用内/短信/电话加急。当用户需要发消息、查看或搜索聊天记录、下载聊天中的文件、查看群成员、搜索群、创建群聊或话题群、管理标记数据、管理 Feed 置顶（添加/移除/查询置顶会话）、管理标签数据时使用。
飞书邮箱：Use when user mentions 起草邮件、写邮件、草稿、发送/回复/转发邮件、查阅邮件、看邮件、搜索邮件、邮件文件夹、邮件标签、邮件联系人、监听新邮件、邮件收信规则等；use for mail/email intent only. Do not use for docs/sheets/calendar/auth setup/pure contact lookup/IM chat tasks.
| 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]？
是这个意思吗？
用户：更新 skill，当针对该功能更新时，同样要创建更新文档
Agent：我理解你的意思是：
- 更新 spec-executor skill 的内容
- 在 skill 中增加一条规则：当针对某项功能进行更新时，需要先创建更新 Spec 文档，放在该功能原有 Spec 的同一目录下
是这个意思吗？
用户：帮我处理一下登录的问题
Agent：我理解你遇到了登录相关的问题，但我需要确认具体是哪方面：
**可能是**：
- 登录功能有 bug 需要修复
- 登录流程需要优化或重构
- 登录页面 UI 需要调整
- 登录安全性需要加强
你具体想解决哪个问题？或者能描述一下遇到的具体情况吗？
用户：给项目添加缓存功能
Agent：我理解你希望为项目添加缓存功能。在开始之前，我需要确认几点：
- **缓存范围**：是针对 API 响应缓存，还是数据库查询缓存，或者两者都要？
- **缓存方案**：倾向于使用 Redis 这样的外部缓存，还是内存缓存？
- **缓存策略**：有特定的过期时间或失效策略要求吗？
请告诉我你的想法，我再制定具体方案。
用户：运行一下测试
Agent：[直接执行测试命令，无需确认]
用户：查看 src/api/auth.py 的内容
Agent：[直接读取文件，无需确认]
用户：对的
Agent：好的，我开始执行...
[开始执行任务]
用户：不是，我的意思是...
Agent：明白了，让我重新理解：
- [修正后的理解点1]
- [修正后的理解点2]
这次理解对了吗？
用户：差不多，但还需要考虑...
Agent：收到，我更新一下理解：
- [原有理解点]
- [新增的考虑点]
这样完整了吗？
在创建 Spec 之前，应先确认：
如果 Spec 已经明确，通常无需再次确认，直接执行即可。
如果在确认过程中发现了重要的需求澄清模式，可以考虑记录到战略记忆中。
完成意图确认后，你应该：
/spec-writer - 如果需要创建功能 Spec/memory - 如果发现了值得记录的沟通模式