Menu
当开始任何对话时使用 - 建立如何查找和使用 skills，要求在任何响应（包括澄清问题）之前调用 skill
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
在进行任何创造性工作之前，你必须使用此 skill - 创建功能、构建组件、添加功能或修改行为。在实现之前探索用户意图、需求和设计。
当面对 2 个以上可在无共享状态或顺序依赖下处理的独立任务时使用
当你有一个书面实现计划，需要在带有 review 检查点的独立会话中执行时使用
当实现完成、所有测试通过、且你需要决定如何集成工作时使用 - 通过为合并、PR 或清理呈现结构化选项来指导开发工作的完成
当收到代码审查反馈时使用，在实现建议之前，尤其是当反馈看似不清或在技术上存疑时 - 需要技术严谨性和验证，而非表演性附和或盲目实现
当完成任务、实现主要功能或合并之前使用，以验证工作满足需求
| name | using-superpowers |
| description | 当开始任何对话时使用 - 建立如何查找和使用 skills，要求在任何响应（包括澄清问题）之前调用 skill |
如果某个 skill 适用于你的任务，你没有选择。你必须使用它。
这不可协商。这不是可选项。你无法通过自我合理化来逃避这一点。
Superpowers skills 会覆盖默认的系统提示行为，但用户指令始终优先：
如果 CLAUDE.md、GEMINI.md 或 AGENTS.md 说"不要使用 TDD"，而某个 skill 说"始终使用 TDD"，请遵循用户指令。用户拥有控制权。
绝不使用文件工具手动读取 skill 文件——始终使用你所在平台的 skill 加载机制，这样 skill 才能被正确激活。
在 Claude Code 中： 使用 Skill 工具。当你调用一个 skill 时，其内容会被加载并呈现给你——直接遵循它。
在 Codex 中： Skills 原生加载。遵循 skill 激活时呈现的指令。
在 Copilot CLI 中： 使用 skill 工具。Skills 从已安装的插件中自动发现。
在 Gemini CLI 中： Skills 通过 activate_skill 工具激活。Gemini 在会话开始时加载 skill 元数据，并按需激活完整内容。
在其他环境中： 查阅你所在平台的文档，了解 skills 如何加载。
Skills 以动作表述（"派发一个 subagent"、"创建一个 todo"、"读取一个文件"），而不是命名某个特定运行时的工具。有关各平台的工具等价物和指令文件约定，请参见 claude-code-tools.md、codex-tools.md、copilot-tools.md、gemini-tools.md、pi-tools.md 和 antigravity-tools.md。Gemini CLI 用户通过 GEMINI.md 自动加载工具映射。
在任何响应或动作之前，调用相关或被请求的 skills。 即使只有 1% 的机会某个 skill 可能适用，也意味着你应该调用该 skill 来检查。如果调用的 skill 事后证明不适合当前情况，你不需要使用它。
digraph skill_flow {
"收到用户消息" [shape=doublecircle];
"即将进入 plan mode？" [shape=doublecircle];
"已经 brainstorm 过？" [shape=diamond];
"调用 brainstorming skill" [shape=box];
"可能有 skill 适用？" [shape=diamond];
"调用该 skill" [shape=box];
"宣布：'使用 [skill] 来 [目的]'" [shape=box];
"有检查清单？" [shape=diamond];
"为每项创建一个 todo" [shape=box];
"严格遵循 skill" [shape=box];
"响应（包括澄清）" [shape=doublecircle];
"即将进入 plan mode？" -> "已经 brainstorm 过？";
"已经 brainstorm 过？" -> "调用 brainstorming skill" [label="否"];
"已经 brainstorm 过？" -> "可能有 skill 适用？" [label="是"];
"调用 brainstorming skill" -> "可能有 skill 适用？";
"收到用户消息" -> "可能有 skill 适用？";
"可能有 skill 适用？" -> "调用该 skill" [label="是，即使 1%"];
"可能有 skill 适用？" -> "响应（包括澄清）" [label="绝对没有"];
"调用该 skill" -> "宣布：'使用 [skill] 来 [目的]'";
"宣布：'使用 [skill] 来 [目的]'" -> "有检查清单？";
"有检查清单？" -> "为每项创建一个 todo" [label="是"];
"有检查清单？" -> "严格遵循 skill" [label="否"];
"为每项创建一个 todo" -> "严格遵循 skill";
}
这些想法意味着停下——你在自我合理化：
| 想法 | 现实 |
|---|---|
| "这只是个简单问题" | 问题也是任务。检查是否有适用的 skill。 |
| "我需要先了解更多上下文" | skill 检查发生在提出澄清问题之前。 |
| "让我先探索一下代码库" | Skills 告诉你如何探索。先检查。 |
| "我可以快速检查 git/文件" | 文件缺少对话上下文。检查是否有适用的 skill。 |
| "让我先收集信息" | Skills 告诉你如何收集信息。 |
| "这不需要正式的 skill" | 如果存在适用的 skill，就使用它。 |
| "我记得这个 skill" | Skills 会演进。阅读当前版本。 |
| "这算不上一个任务" | 动作 = 任务。检查是否有适用的 skill。 |
| "这个 skill 小题大做了" | 简单的事情会变复杂。使用它。 |
| "我先只做这一件事" | 在做任何事之前先检查。 |
| "这感觉很高效" | 无纪律的行动会浪费时间。Skills 能防止这种情况。 |
| "我知道那是什么意思" | 知道概念 ≠ 使用 skill。调用它。 |
当多个 skills 可能适用时，使用此顺序：
"让我们构建 X" → 先 brainstorming，再实现 skills。 "修复这个 bug" → 先 systematic-debugging，再领域特定 skills。
刚性（TDD、systematic-debugging）：严格遵循。不要为了省事而放弃纪律。
柔性（模式）：将原则适配到具体情境。
skill 本身会告诉你它属于哪种。
指令说明做什么（WHAT），不是怎么做（HOW）。"添加 X"或"修复 Y"并不意味着跳过工作流。