| name | dev-using-skills |
| description | 开始开发编程相关对话时使用 - 建立如何查找和使用 skills,在做出任何响应前要求先检查适用的 skill |
如果你是被派发来执行特定任务的子 agent,跳过此 skill。
<极其重要>
如果你认为某个 skill 有哪怕 1% 的几率适用于你正在做的事情,你必须绝对调用该 skill。
如果某个 skill 适用于你的任务,你别无选择。你必须使用它。
这是不可协商的。这不是可选的。你不能用合理化来逃避。
</极其重要>
如何访问 Skills
在 Kimi CLI 中: 使用 /skill:name 命令。当你调用 skill 时,其内容会被加载并呈现给你——直接遵循它。不要对 skill 文件使用 Read 工具。
在其他环境中: 查看平台文档了解如何加载 skills。
使用 Skills
规则
在做出任何响应或行动前先调用相关或请求的 skills。 即使 skill 只有 1% 的几率适用,你也应该调用它来检查。如果调用的 skill 最终不适合该情况,你不需要使用它。
指令优先级
当多种指令同时存在时,使用下面的固定优先级:
- 用户的明确请求(
AGENTS.md、CLAUDE.md、直接请求)— 最高优先级
- 项目级约束,如
AGENTS.md / CLAUDE.md
- 已触发 skill 的具体流程 — 覆盖默认系统行为
- 默认行为和个人习惯 — 最低优先级
解释规则:
- 用户决定做什么
AGENTS.md / CLAUDE.md 决定当前项目的硬约束
- skill 决定在这些约束内,应该如何执行
- 如果 skill 与用户明确要求冲突,用户要求优先
- 如果 skill 与
AGENTS.md / CLAUDE.md 冲突,项目约束优先
- 不能用"我在遵循 skill"来覆盖用户已经明确提出的边界
digraph skill_flow {
"收到用户消息" [shape=doublecircle];
"即将进入计划模式?" [shape=doublecircle];
"已调用过 dev-brainstorming?" [shape=diamond];
"调用 dev-brainstorming" [shape=box];
"可能有 skill 适用?" [shape=diamond];
"调用 /skill:命令" [shape=box];
"宣布:'正在使用 [skill] 来 [目的]'" [shape=box];
"有检查清单?" [shape=diamond];
"为每项创建 TodoWrite" [shape=box];
"精确遵循 skill" [shape=box];
"响应(包括澄清问题)" [shape=doublecircle];
"即将进入计划模式?" -> "已调用过 dev-brainstorming?";
"已调用过 dev-brainstorming?" -> "调用 dev-brainstorming" [label="否"];
"已调用过 dev-brainstorming?" -> "可能有 skill 适用?" [label="是"];
"调用 dev-brainstorming" -> "可能有 skill 适用?";
"收到用户消息" -> "可能有 skill 适用?";
"可能有 skill 适用?" -> "调用 /skill:命令" [label="是,即使 1%"];
"可能有 skill 适用?" -> "响应(包括澄清问题)" [label="绝对不是"];
"调用 /skill:命令" -> "宣布:'正在使用 [skill] 来 [目的]'";
"宣布:'正在使用 [skill] 来 [目的]'" -> "有检查清单?";
"有检查清单?" -> "为每项创建 TodoWrite" [label="是"];
"有检查清单?" -> "精确遵循 skill" [label="否"];
"为每项创建 TodoWrite" -> "精确遵循 skill";
}
红旗
这些想法意味着停止——你在合理化:
| 想法 | 现实 |
|---|
| "这只是个简单问题" | 问题是任务。检查 skills。 |
| "我需要先了解更多上下文" | Skill 检查在澄清问题之前。 |
| "让我先探索代码库" | Skills 告诉你如何探索。先检查。 |
| "我可以快速检查 git/文件" | 文件缺乏对话上下文。检查 skills。 |
| "让我先收集信息" | Skills 告诉你如何收集信息。 |
| "这不需要正式 skill" | 如果 skill 存在,使用它。 |
| "我记得这个 skill" | Skills 会演变。阅读当前版本。 |
| "这不算任务" | 行动 = 任务。检查 skills。 |
| "这 skill 太过分了" | 简单事会变复杂。使用它。 |
| "我先做这个" | 在做任何事之前检查。 |
| "这感觉有成效" | 无纪律的行动浪费时间。Skills 防止这个。 |
| "我知道那是什么意思" | 知道概念 ≠ 使用 skill。调用它。 |
Skill 优先级
当多个 skills 可能适用时,使用此顺序:
- 流程 skills 优先(头脑风暴、调试)- 这些决定如何接近任务
- 实现 skills 其次(前端设计、mcp-builder)- 这些指导执行
"让我们构建 X" → 先头脑风暴,然后实现 skills。
"修复这个 bug" → 先调试,然后领域特定 skills。
如果用户显式点名某个 skill,而它和流程 skill 同时适用:
- 先尊重用户点名的 skill
- 如果流程 skill 仍是前置条件,明确说明顺序,而不是静默跳过
- 不要擅自把用户点名 skill 降级为“我记得它大概是什么”
Skill 类型
严格型(TDD、调试):精确遵循。不要偏离纪律。
灵活型(模式):根据上下文调整原则。
Skill 本身会告诉你属于哪种。
用户指令
指令说做什么,不是怎么做。"添加 X"或"修复 Y"不意味着跳过工作流。
用户没有显式说要跳过 workflow 时,默认不能跳过。