ワンクリックで
intent-confirmation
当用户的请求在执行前需要澄清目标或边界时使用:需求抽象、涉及架构或设计决策、影响范围大、存在多种实现路径、可能修改重要文件,或用户明确要求先确认。不要用于简单问答、只读查询、明确的小修小改或可安全直接执行的任务。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
当用户的请求在执行前需要澄清目标或边界时使用:需求抽象、涉及架构或设计决策、影响范围大、存在多种实现路径、可能修改重要文件,或用户明确要求先确认。不要用于简单问答、只读查询、明确的小修小改或可安全直接执行的任务。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
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 - 如果发现了值得记录的沟通模式