If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke 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.
How to Access Skills
In Claude Code: Use the Skill tool. When you invoke a skill, its content is loaded and presented to you—follow it directly. Never use the Read tool on skill files.
In other environments: Check your platform's documentation for how skills are loaded.
Using Skills
The Rule
Invoke relevant or requested skills BEFORE any response or action. Even a 1% chance a skill might apply means that you should invoke the skill to check. If an invoked skill turns out to be wrong for the situation, you don't need to use it.
CODEBLOCK0
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. |
| "I know what that means" | Knowing the concept ≠ using the skill. Invoke it. |
Skill Priority
When multiple skills could apply, use this order:
- 1. 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 Types
Rigid (TDD, debugging): Follow exactly. Don't adapt away discipline.
Flexible (patterns): Adapt principles to context.
The skill itself tells you which.
User Instructions
Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.
如果你认为某个技能有哪怕1%的可能性适用于你当前正在做的事情,你绝对必须调用该技能。
如果某个技能适用于你的任务,你没有选择。你必须使用它。
这一点没有商量余地,不是可选项。你不能通过合理化来逃避这一点。
如何访问技能
在 Claude Code 中: 使用 Skill 工具。当你调用一个技能时,其内容会被加载并呈现给你——请直接遵循。切勿对技能文件使用 Read 工具。
在其他环境中: 请查阅你所在平台的文档,了解技能是如何加载的。
使用技能
规则
在任何响应或行动之前,先调用相关或请求的技能。 即使只有1%的可能性某个技能适用,你也应该调用该技能来检查。如果调用的技能最终不适用于当前情况,则无需使用它。
dot
digraph skill_flow {
收到用户消息 [shape=doublecircle];
是否有技能可能适用? [shape=diamond];
调用 Skill 工具 [shape=box];
声明:使用 [技能] 来 [目的] [shape=box];
有检查清单吗? [shape=diamond];
为每个项目创建 TodoWrite 待办事项 [shape=box];
精确遵循技能 [shape=box];
响应(包括澄清说明) [shape=doublecircle];
收到用户消息 -> 是否有技能可能适用?;
是否有技能可能适用? -> 调用 Skill 工具 [label=是,即使只有1%];
是否有技能可能适用? -> 响应(包括澄清说明) [label=绝对不适用];
调用 Skill 工具 -> 声明:使用 [技能] 来 [目的];
声明:使用 [技能] 来 [目的] -> 有检查清单吗?;
有检查清单吗? -> 为每个项目创建 TodoWrite 待办事项 [label=是];
有检查清单吗? -> 精确遵循技能 [label=否];
为每个项目创建 TodoWrite 待办事项 -> 精确遵循技能;
}
警示信号
这些想法意味着停止——你正在合理化:
| 想法 | 现实 |
|---|
| 这只是一个简单的问题 | 问题也是任务。检查是否有技能适用。 |
| 我需要更多上下文 |
技能检查在提出澄清问题之前。 |
| 让我先探索一下代码库 | 技能告诉你如何探索。先检查。 |
| 我可以快速检查 git/文件 | 文件缺少对话上下文。检查是否有技能适用。 |
| 让我先收集信息 | 技能告诉你如何收集信息。 |
| 这不需要正式技能 | 如果技能存在,就使用它。 |
| 我记得这个技能 | 技能会演变。阅读当前版本。 |
| 这不算一个任务 | 行动 = 任务。检查是否有技能适用。 |
| 这个技能有点大材小用 | 简单的事情会变得复杂。使用它。 |
| 我先做这一件事 | 在做任何事之前先检查。 |
| 这感觉很有成效 | 无纪律的行动浪费时间。技能可以防止这种情况。 |
| 我知道那是什么意思 | 知道概念 ≠ 使用技能。调用它。 |
技能优先级
当多个技能可能适用时,请按此顺序使用:
- 1. 首先处理流程技能(头脑风暴、调试)——这些决定了如何完成任务
- 其次处理实现技能(前端设计、MCP 构建器)——这些指导执行
让我们构建 X → 先进行头脑风暴,然后使用实现技能。
修复这个 bug → 先进行调试,然后使用领域特定技能。
技能类型
刚性(TDD、调试):精确遵循。不要为了适应而放弃纪律。
灵活(模式):根据上下文调整原则。
技能本身会告诉你它属于哪种类型。
用户指令
指令说明做什么,而不是怎么做。添加 X 或 修复 Y 并不意味着可以跳过工作流程。