メニュー
收到用户消息后、进行任何响应或行动之前使用——检查是否有适用的 skill 需要调用，确保不跳过关键工作流
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | using-skills |
| description | 收到用户消息后、进行任何响应或行动之前使用——检查是否有适用的 skill 需要调用，确保不跳过关键工作流 |
如果一个 skill 适用于你的任务，你没有选择。你必须使用它。
这不可协商。这不是可选的。你不能为自己找借口绕过这个。
Skill 覆盖默认系统提示行为，但用户指令始终优先：
如果 CLAUDE.md、GEMINI.md 或 AGENTS.md 说"不使用 TDD"而某个 skill 说"始终使用 TDD"，遵循用户的指令。用户掌控一切。
在 Claude Code 中： 使用 Skill 工具。当你调用一个 skill 时，其内容会被加载并展示给你——直接遵循即可。不要使用 Read 工具读取 skill 文件。
在 Gemini CLI 中： Skill 通过 activate_skill 工具激活。Gemini 在会话开始时加载 skill 元数据，按需激活完整内容。
在其他环境中： 查阅你的平台文档了解 skill 如何加载。
Skill 使用 Claude Code 工具名称。非 CC 平台：参见 references/codex-tools.md（Codex）了解工具映射。Gemini CLI 用户通过 GEMINI.md 自动加载工具映射。
在任何响应或行动之前调用相关或被请求的 skill。 即使只有 1% 的可能性某个 skill 适用，你也应该调用它来检查。如果调用后发现 skill 不适合当前情况，你不需要使用它。
触发确认： 在回复的开头用一行简短声明确认本 skill 已触发，格式：[using-skills] 已检查 skill 列表 → 调用: <skill 名称> 或 [using-skills] 已检查 skill 列表 → 无匹配。
digraph skill_flow {
"收到用户消息" [shape=doublecircle];
"即将进入 EnterPlanMode？" [shape=doublecircle];
"已经头脑风暴过？" [shape=diamond];
"调用 brainstorming skill" [shape=box];
"可能有 skill 适用？" [shape=diamond];
"调用 Skill 工具" [shape=box];
"声明：'使用 [skill] 来 [目的]'" [shape=box];
"有检查清单？" [shape=diamond];
"为每项创建 TodoWrite" [shape=box];
"严格遵循 skill" [shape=box];
"回应（包括澄清问题）" [shape=doublecircle];
"即将进入 EnterPlanMode？" -> "已经头脑风暴过？";
"已经头脑风暴过？" -> "调用 brainstorming skill" [label="否"];
"已经头脑风暴过？" -> "可能有 skill 适用？" [label="是"];
"调用 brainstorming skill" -> "可能有 skill 适用？";
"收到用户消息" -> "可能有 skill 适用？";
"可能有 skill 适用？" -> "调用 Skill 工具" [label="是，哪怕 1%"];
"可能有 skill 适用？" -> "回应（包括澄清问题）" [label="确定没有"];
"调用 Skill 工具" -> "声明：'使用 [skill] 来 [目的]'";
"声明：'使用 [skill] 来 [目的]'" -> "有检查清单？";
"有检查清单？" -> "为每项创建 TodoWrite" [label="是"];
"有检查清单？" -> "严格遵循 skill" [label="否"];
"为每项创建 TodoWrite" -> "严格遵循 skill";
}
这些想法意味着停下来——你在合理化借口：
| 想法 | 现实 |
|---|---|
| "这只是个简单问题" | 问题就是任务。检查 skill。 |
| "我需要先了解更多上下文" | Skill 检查在澄清问题之前。 |
| "让我先探索代码库" | Skill 告诉你如何探索。先检查。 |
| "我可以快速看看 git/文件" | 文件缺乏对话上下文。检查 skill。 |
| "让我先收集信息" | Skill 告诉你如何收集信息。 |
| "这不需要正式的 skill" | 如果 skill 存在，就使用它。 |
| "我记得这个 skill" | Skill 会演进。读当前版本。 |
| "这不算一个任务" | 行动 = 任务。检查 skill。 |
| "这个 skill 太重了" | 简单的事情会变复杂。用它。 |
| "我先做这一件事" | 做任何事之前先检查。 |
| "这感觉很高效" | 无纪律的行动浪费时间。Skill 防止这种情况。 |
| "我知道那是什么意思" | 知道概念 ≠ 使用 skill。调用它。 |
当多个 skill 可能适用时，使用此顺序：
"让我们构建 X" → 先头脑风暴，再用实现 skill。 "修复这个 bug" → 先调试，再用领域特定 skill。
刚性的（TDD、调试）：严格遵循。不要为了灵活而放弃纪律。
柔性的（模式）：根据上下文调整原则。
Skill 本身会告诉你它是哪种。
指令说的是做什么，不是怎么做。"添加 X"或"修复 Y"不意味着跳过工作流。
在进行任何创造性工作前必须使用——创建功能、构建组件、添加新功能或修改行为。在实现之前先探索用户意图、需求和设计。
TypeScript 和 React 开发的编码标准与最佳实践。在编写或审查代码时激活。提供命名、类型、组件设计、Hook 提取、状态管理等规范。
在用户确认要提交代码变更时使用——安全检查 diff 中的敏感数据后执行 git commit
在面对 2 个以上互不依赖、无共享状态的独立任务时使用
当有已编写的实现计划需要在独立会话中执行时使用，包含评审检查点
在实现完成、测试通过后，引导决定如何集成工作——提供合并、PR 或清理的结构化选项