Menu
开始开发编程相关对话时使用 - 建立如何查找和使用 skills，在做出任何响应前要求先检查适用的 skill
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional 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 时，默认不能跳过。