using-superpowers

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

⚠️ NON-NEGOTIABLE RULE

If you think there is even a 1% chance a skill might apply to your task, you MUST read the skill.

IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.

This is not negotiable. This is not optional. You cannot rationalize your way out of this.

⚠️ 不可协商规则

如果你认为哪怕只有1%的概率有skill适用于你的任务，你必须阅读该skill。

如果有skill适用于你的任务，你没有选择余地，必须使用它。

这一点不可协商，也不是可选项，你没有任何理由可以规避这一要求。

Using Skills

使用Skills

The Rule

规则

Check for skills BEFORE ANY RESPONSE. This includes clarifying questions. Even 1% chance means invoke the Skill tool first.

dot

digraph skill_flow {
    "User message received" [shape=doublecircle];
    "Might any skill apply?" [shape=diamond];
    "Invoke Skill tool" [shape=box];
    "Announce: 'Using [skill] to [purpose]'" [shape=box];
    "Has checklist?" [shape=diamond];
    "Create TodoWrite todo per item" [shape=box];
    "Follow skill exactly" [shape=box];
    "Respond (including clarifications)" [shape=doublecircle];

    "User message received" -> "Might any skill apply?";
    "Might any skill apply?" -> "Invoke Skill tool" [label="yes, even 1%"];
    "Might any skill apply?" -> "Respond (including clarifications)" [label="definitely not"];
    "Invoke Skill tool" -> "Announce: 'Using [skill] to [purpose]'";
    "Announce: 'Using [skill] to [purpose]'" -> "Has checklist?";
    "Has checklist?" -> "Create TodoWrite todo per item" [label="yes"];
    "Has checklist?" -> "Follow skill exactly" [label="no"];
    "Create TodoWrite todo per item" -> "Follow skill exactly";
}

在做出任何回复前先检查是否有适用的skill，这包括澄清类问题。哪怕只有1%的适用概率，也要先调用Skill工具。

dot

digraph skill_flow {
    "User message received" [shape=doublecircle];
    "Might any skill apply?" [shape=diamond];
    "Invoke Skill tool" [shape=box];
    "Announce: 'Using [skill] to [purpose]'" [shape=box];
    "Has checklist?" [shape=diamond];
    "Create TodoWrite todo per item" [shape=box];
    "Follow skill exactly" [shape=box];
    "Respond (including clarifications)" [shape=doublecircle];

    "User message received" -> "Might any skill apply?";
    "Might any skill apply?" -> "Invoke Skill tool" [label="yes, even 1%"];
    "Might any skill apply?" -> "Respond (including clarifications)" [label="definitely not"];
    "Invoke Skill tool" -> "Announce: 'Using [skill] to [purpose]'";
    "Announce: 'Using [skill] to [purpose]'" -> "Has checklist?";
    "Has checklist?" -> "Create TodoWrite todo per item" [label="yes"];
    "Has checklist?" -> "Follow skill exactly" [label="no"];
    "Create TodoWrite todo per item" -> "Follow skill exactly";
}

Red Flags

危险信号

These thoughts mean STOP—you're rationalizing:

Thought	Reality
"This is just a simple question"	Questions are tasks. Check for skills.
"I need more context first"	Skill check comes BEFORE clarifying questions.
"Let me explore the codebase first"	Skills tell you HOW to explore. Check first.
"I can check git/files quickly"	Files lack conversation context. Check for skills.
"Let me gather information first"	Skills tell you HOW to gather information.
"This doesn't need a formal skill"	If a skill exists, use it.
"I remember this skill"	Skills evolve. Read current version.
"This doesn't count as a task"	Action = task. Check for skills.
"The skill is overkill"	Simple things become complex. Use it.
"I'll just do this one thing first"	Check BEFORE doing anything.
"This feels productive"	Undisciplined action wastes time. Skills prevent this.

以下这些想法意味着你需要立刻停下——你正在试图找理由规避规则：

想法	实际情况
"这只是个简单的问题"	问题也是任务，先检查skill。
"我需要先获取更多上下文"	skill检查优先级高于澄清类问题。
"我先浏览一下代码库再说"	skill会告诉你如何浏览代码，先做检查。
"我可以快速查看git/文件"	文件不包含对话上下文，先检查skill。
"我先收集一下信息再说"	skill会告诉你如何收集信息。
"这个不需要用到正式的skill"	只要有对应的skill存在，就使用它。
"我记得这个skill的内容"	skill会迭代更新，请阅读当前最新版本。
"这个不算任务"	只要需要执行动作就属于任务，先检查skill。
"用这个skill太小题大做了"	简单的事情也会变复杂，使用它。
"我先做这一件小事就行"	做任何操作前都要先检查。
"这样做看起来效率很高"	无规范的操作会浪费时间，skill可以避免这种情况。

Skill Priority

Skill优先级

When multiple skills could apply, use this order:

Process skills first (brainstorming, debugging) - these determine HOW to approach the task
Implementation skills second (frontend-design, mcp-builder) - these guide execution

"Let's build X" → brainstorming first, then implementation skills. "Fix this bug" → debugging first, then domain-specific skills.

当有多个skill都适用时，按照以下顺序选择：

优先使用流程类skill（头脑风暴、调试）——这类skill决定了处理任务的方式
其次使用实现类skill（frontend-design、mcp-builder）——这类skill指导执行过程

"我们来搭建X" → 先使用头脑风暴skill，再使用实现类skill。 "修复这个bug" → 先使用调试skill，再使用领域特定skill。

Skill Types

Skill类型

Rigid (TDD, debugging): Follow exactly. Don't adapt away discipline.

Flexible (patterns): Adapt principles to context.

The skill itself tells you which.

刚性（TDD、调试）：严格遵循，不要随意调整规则。

灵活（设计模式）：根据场景适配原则。

skill本身会说明它属于哪一类。

User Instructions ≠ Permission to Skip Workflows

用户指令不等于可以跳过工作流

Your human partner's specific instructions describe WHAT to accomplish, not HOW to accomplish it.

"Add X" or "Fix Y" = the goal, NOT permission to skip brainstorming, TDD, debugging workflows, or other skill-defined processes.

Red flags indicating you're about to rationalize:

"The instruction was specific" → Specific instructions need disciplined process, not shortcuts
"This seems simple" → Simple instructions trigger the most rationalizations
"The workflow feels overkill" → Workflows exist because simple tasks become complex

Why this matters: Specific instructions mean clear requirements—this is exactly when structured workflows prevent mistakes and save time. Skipping process on "simple" tasks is how simple tasks become complex problems.

你的人类协作方给出的具体指令描述的是需要完成的目标，而非完成目标的方式。

"添加X"或"修复Y" = 仅代表目标，不代表你可以跳过头脑风暴、TDD、调试工作流或其他skill定义的流程。

表明你即将试图找理由规避规则的危险信号：

"指令很明确" → 明确的指令更需要规范的流程，而非走捷径
"这个看起来很简单" → 简单的指令最容易让人找理由跳过流程
"这个工作流太小题大做了" → 工作流存在的意义就是预防简单任务变复杂

为什么这很重要： 明确的指令意味着清晰的需求——这种情况下结构化的工作流正好可以预防错误、节省时间。在处理"简单"任务时跳过流程，就是简单任务演变成复杂问题的原因。