القائمة
开始开发编程相关对话时使用 - 建立如何查找和使用 skills，在做出任何响应前要求先检查适用的 skill
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
何时使用需要为编程项目、monorepo 或多级目录创建/更新 AGENTS.md、CLAUDE.md 软链接、项目级 agent 操作手册、子目录局部规则、验证命令和 Coding Agent 上下文边界时使用。
分析代码库结构并生成中文 token-lean 架构文档。
用于构建或维护个人 LLM 驱动的知识库。触发词：将资料导入 wiki、查询 wiki 知识、检查 wiki 质量、'添加到 wiki'、'我了解什么关于'，或任何提到 'LLM wiki' 的场景。
当有书面实施计划要在单独会话中执行并带审查检查点时使用
用户明确要求隔离工作区、并行分支验证或临时试验时使用 - 创建隔离的 git worktree
更新本项目的上游 submodule，并基于真实 git 变更分析生成文档报告。用于用户要求同步 `upstream/` 下仓库、检查上游最近更新、梳理新增内容、在 `docs/` 写更新说明，或筛选哪些更新值得优先吸收和推荐时。
| name | dev-using-skills |
| description | 开始开发编程相关对话时使用 - 建立如何查找和使用 skills，在做出任何响应前要求先检查适用的 skill |
<极其重要> 如果你认为某个 skill 有哪怕 1% 的几率适用于你正在做的事情，你必须绝对调用该 skill。
如果某个 skill 适用于你的任务，你别无选择。你必须使用它。
这是不可协商的。这不是可选的。你不能用合理化来逃避。 </极其重要>
在 Kimi CLI 中： 使用 /skill:name 命令。当你调用 skill 时，其内容会被加载并呈现给你——直接遵循它。不要对 skill 文件使用 Read 工具。
在其他环境中： 查看平台文档了解如何加载 skills。
在做出任何响应或行动前先调用相关或请求的 skills。 即使 skill 只有 1% 的几率适用，你也应该调用它来检查。如果调用的 skill 最终不适合该情况，你不需要使用它。
当多种指令同时存在时，使用下面的固定优先级：
AGENTS.md、CLAUDE.md、直接请求）— 最高优先级AGENTS.md / CLAUDE.md解释规则：
AGENTS.md / CLAUDE.md 决定当前项目的硬约束AGENTS.md / CLAUDE.md 冲突，项目约束优先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。调用它。 |
当多个 skills 可能适用时，使用此顺序：
"让我们构建 X" → 先头脑风暴，然后实现 skills。 "修复这个 bug" → 先调试，然后领域特定 skills。
如果用户显式点名某个 skill，而它和流程 skill 同时适用：
严格型（TDD、调试）：精确遵循。不要偏离纪律。
灵活型（模式）：根据上下文调整原则。
Skill 本身会告诉你属于哪种。
指令说做什么，不是怎么做。"添加 X"或"修复 Y"不意味着跳过工作流。
用户没有显式说要跳过 workflow 时，默认不能跳过。