dev-using-skills

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 最终不适合该情况，你不需要使用它。

指令优先级

当多种指令同时存在时，使用下面的固定优先级：

1. 用户的明确请求（AGENTS.md、CLAUDE.md、直接请求）— 最高优先级
2. 项目级约束，如 AGENTS.md / CLAUDE.md
3. 已触发 skill 的具体流程 — 覆盖默认系统行为
4. 默认行为和个人习惯 — 最低优先级

解释规则：

• 用户决定做什么
• 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 可能适用时，使用此顺序：

1. 流程 skills 优先（头脑风暴、调试）- 这些决定如何接近任务
2. 实现 skills 其次（前端设计、mcp-builder）- 这些指导执行

"让我们构建 X" → 先头脑风暴，然后实现 skills。 "修复这个 bug" → 先调试，然后领域特定 skills。

如果用户显式点名某个 skill，而它和流程 skill 同时适用：

• 先尊重用户点名的 skill
• 如果流程 skill 仍是前置条件，明确说明顺序，而不是静默跳过
• 不要擅自把用户点名 skill 降级为“我记得它大概是什么”

Skill 类型

严格型（TDD、调试）：精确遵循。不要偏离纪律。

灵活型（模式）：根据上下文调整原则。

Skill 本身会告诉你属于哪种。

用户指令

指令说做什么，不是怎么做。"添加 X"或"修复 Y"不意味着跳过工作流。

用户没有显式说要跳过 workflow 时，默认不能跳过。