Using Superpowers 0.1.0 — 使用 Superpowers 0.1.0

如果你认为某个技能有1%的可能适用于你正在做的事情，你绝对必须调用该技能。 如果一个技能适用于你的任务，你没有选择的余地。你必须使用它。这不是可商量的。这不是可选的。你不能通过合理化的方式避免这一点。 如何访问技能 在 Claude Code 中：使用 Skill 工具。当你调用一个技能时，其内容会被加载并呈现给你——直接按照它。永远不要使用 Read 工具来读取技能文件。 在其他环境中：查看你的平台文档，了解如何加载技能。 使用技能 规则 在任何响应或行动之前调用相关或请求的技能。即使有1%的可能一个技能会适用，也应该调用该技能来检查。如果调用一个技能结果证明它不适用于这种情况，你不需要使用它。 digraph skill_flow { "用户消息接收" [shape=doublecircle]; "是否有技能适用？" [shape=diamond]; "调用 Skill 工具" [shape=box]; "宣布：'使用 [skill] 来 [purpose]' " [shape=box]; "是否有清单？" [shape=diamond]; "创建 TodoWrite 每个项目" [shape=box]; "严格遵循技能" [shape=box]; "响应（包括澄清）" [shape=doublecircle]; "用户消息接收" -> "是否有技能适用？"; "是否有技能适用？" -> "调用 Skill 工具" [label="是，即使只有1%的可能"]; "是否有技能适用？" -> "响应（包括澄清）" [label="绝对不"]; "调用 Skill 工具" -> "宣布：'使用 [skill] 来 [purpose]' "; "宣布：'使用 [skill] 来 [purpose]' " -> "是否有清单？"; "是否有清单？" -> "创建 TodoWrite 每个项目" [label="是"]; "是否有清单？" -> "严格遵循技能" [label="否"]; "创建 TodoWrite 每个项目" -> "严格遵循技能"; } 红旗 这些想法意味着停止——你正在合理化： 思维 现实 "这是一个简单的问题" 问题是任务。检查技能。 "我需要更多上下文" 技能检查在澄清问题之前。 "让我先探索代码库" 技能告诉你如何探索。先检查。 "我可以快速检查 git/文件" 文件缺乏对话上下文。检查技能。 "让我先收集信息" 技能告诉你如何收集信息。 "这不需要正式技能" 如果技能存在，使用它。 "我记得这个技能" 技能会演变。阅读当前版本。 "这不算作任务" 动作 = 任务。检查技能。 "技能是过度的" 简单的事情会变得复杂。使用它。 "我先做这件事" 在做任何事情之前检查。 "这感觉很有成效" 不受纪律约束的行动浪费时间。技能可以防止这种情况。 "我知道那是什么意思" 了解概念 ≠ 使用技能。调用它。 技能优先级 当多个技能可能适用时，使用以下顺序： 首先使用流程技能（brainstorming，debugging）- 这些决定如何处理任务 其次使用实现技能（frontend-design，mcp-builder）- 这些指导执行 "让我们构建 X" → 首先进行头脑风暴，然后使用实现技能。 "修复这个 bug" → 首先进行调试，然后使用特定领域的技能。 技能类型 严格的（TDD，debugging）：严格遵循。不要适应性地偏离纪律。 灵活的（模式）：将原则适应于上下文。技能本身会告诉你哪一个。 用户指令 指令说明了什么，而不是如何。"添加 X" 或 "修复 Y" 不意味着跳过工作流程。