Menú
当用户的请求在执行前需要澄清目标或边界时使用：需求抽象、涉及架构或设计决策、影响范围大、存在多种实现路径、可能修改重要文件，或用户明确要求先确认。不要用于简单问答、只读查询、明确的小修小改或可安全直接执行的任务。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
妙搭（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 - 如果发现了值得记录的沟通模式