activation

当某项技能哪怕只有极小的可能与当前任务相关时，你都必须立即调用它。

你不能选择跳过相关技能。必须调用。

此要求是绝对的。不能通过推理规避或推迟。

访问技能

插件安装（标准设置）： 通过 Skill 工具直接调用技能。所有协议都会自动注册。 示例：Skill("godmode:intent-discovery")

当 Skill 工具无法找到协议时： 改为使用 Read 工具直接读取文件：

1. 协议位于：[plugin-root]/skills/
2. 每个协议都有一个定义文件：[plugin-root]/skills/[protocol-name]/SKILL.md
3. 读取 SKILL.md 并按照其中的说明执行

定位插件根目录：

• 从仓库运行：工作目录就是插件根目录
• 作为插件安装：CLAUDE_PLUGIN_ROOT 环境变量包含该路径

其他平台： 请查阅平台特定的技能加载机制文档。

使用技能

强制要求

在生成任何回复或采取任何行动之前，调用适用的技能。 即使只有极小的相关可能，也足以构成调用理由。如果调用后发现技能不适用，可以直接继续。

digraph protocol_flow {
    "Message arrives" [shape=doublecircle];
    "About to enter planning?" [shape=doublecircle];
    "Intent discovery done?" [shape=diamond];
    "Run intent-discovery" [shape=box];
    "Could any skill apply?" [shape=diamond];
    "Invoke Skill tool" [shape=box];
    "Skill tool errored?" [shape=diamond];
    "Read SKILL.md fallback" [shape=box];
    "Announce: 'Applying [skill] for [goal]'" [shape=box];
    "Contains checklist?" [shape=diamond];
    "Track each checklist item" [shape=box];
    "Execute skill instructions" [shape=box];
    "Generate response" [shape=doublecircle];

    "About to enter planning?" -> "Intent discovery done?";
    "Intent discovery done?" -> "Run intent-discovery" [label="no"];
    "Intent discovery done?" -> "Could any skill apply?" [label="yes"];
    "Run intent-discovery" -> "Could any skill apply?";

    "Message arrives" -> "Could any skill apply?";
    "Could any skill apply?" -> "Invoke Skill tool" [label="yes, any chance"];
    "Could any skill apply?" -> "Generate response" [label="clearly not"];
    "Invoke Skill tool" -> "Skill tool errored?";
    "Skill tool errored?" -> "Read SKILL.md fallback" [label="yes"];
    "Skill tool errored?" -> "Announce: 'Applying [skill] for [goal]'" [label="no"];
    "Read SKILL.md fallback" -> "Announce: 'Applying [skill] for [goal]'";
    "Announce: 'Applying [skill] for [goal]'" -> "Contains checklist?";
    "Contains checklist?" -> "Track each checklist item" [label="yes"];
    "Contains checklist?" -> "Execute skill instructions" [label="no"];
    "Track each checklist item" -> "Execute skill instructions";
}

防护措施

以下这些想法都是你在为自己找借口的警示信号：

想法	事实
“这是个简单的问题”	问题也是任务。寻找适用的技能。
“我应该先收集更多背景信息”	先调用技能，再澄清。
“让我先扫一遍代码库”	技能会定义如何扫描。先调用技能。
“我可以快速检查文件和历史记录”	文件不包含对话上下文。调用技能。
“让我先收集一些数据”	技能会规定数据收集方法。
“这不值得正式调用技能”	如果存在匹配的技能，就必须使用。
“我记得这个技能的内容”	技能会更新。请阅读当前版本。
“这其实不算任务”	任何行动都是任务。寻找技能。
“这个技能对这件事来说太繁琐了”	看似简单的任务往往隐藏着复杂性。使用它。
“我先做这一件事”	先调用，再做任何事。
“我进展得很顺利”	没有方向的努力会造成浪费。技能能避免这种情况。
“我已经理解这个概念了”	理解一个概念不等于遵循技能。调用它。

技能排序

当多个技能可能相关时，请按以下顺序执行：

1. 先使用挑战类技能（rationale）——在着手之前，先判断这项工作是否值得做
2. 再使用流程类技能（intent-discovery、fault-diagnosis）——确定执行方法
3. 第三步使用参考类技能（reference-engine 路由至：ux-patterns、design-research、github-search、codebase-research、system-design、deployment-advisor）——在设计之前寻找经过验证的解决方案
4. 第四步使用设计类技能（ui-engineering、design-integration、specification-first）——参考已有方案来指导决策
5. 第五步使用实施类技能（test-first、project-bootstrap、pattern-matching、environment-awareness）——推动执行
6. 第六步使用质量类技能（quality-enforcement、security-protocol、completion-gate、comprehension-check、error-recovery）——确保符合标准
7. 编排类技能（team-orchestration、delegated-execution）——利用并行处理

“Let's build X” -> rationale -> intent-discovery -> reference-engine（路由至适当的参考资源）-> 设计类技能 -> 实施类技能。 “Build a website” -> rationale -> intent-discovery -> reference-engine -> design-research + ux-patterns -> ui-engineering -> 实施。 “Fix this bug” -> 首先使用 fault-diagnosis，然后使用适合该领域的技能。（跳过 rationale） “Big project” -> rationale -> intent-discovery -> reference-engine -> task-planning -> team-orchestration（适用时）。 “Agent is stuck” -> 根据失败次数检测结果主动启用 error-recovery。 “What database/hosting should I use?” -> environment-awareness -> deployment-advisor -> system-design。

执行模式指南

当用户要求在任务中“use godmode”时，评估任务并建议最佳执行策略：

digraph execution_guidance {
    "Evaluate task" [shape=box];
    "Single atomic step?" [shape=diamond];
    "Handle directly" [shape=box];
    "Multiple independent parts?" [shape=diamond];
    "Requires peer coordination?" [shape=diamond];
    "Suggest Agent Teams" [shape=box style=filled fillcolor=lightgreen];
    "Suggest Parallel Delegation" [shape=box];
    "Multi-step sequence?" [shape=diamond];
    "Suggest Delegated Execution" [shape=box];
    "Suggest single-agent workflow" [shape=box];

    "Evaluate task" -> "Single atomic step?";
    "Single atomic step?" -> "Handle directly" [label="yes"];
    "Single atomic step?" -> "Multiple independent parts?" [label="no"];
    "Multiple independent parts?" -> "Requires peer coordination?" [label="yes"];
    "Multiple independent parts?" -> "Multi-step sequence?" [label="no"];
    "Requires peer coordination?" -> "Suggest Agent Teams" [label="yes"];
    "Requires peer coordination?" -> "Suggest Parallel Delegation" [label="no"];
    "Multi-step sequence?" -> "Suggest Delegated Execution" [label="yes"];
    "Multi-step sequence?" -> "Suggest single-agent workflow" [label="no"];
}

先提出建议，再开始执行：

Based on my analysis, I suggest:

[Suggested strategy] because [reasoning]

- Agent Teams: [X] agents collaborating on [modules] concurrently
- OR Delegated Execution: [N] sequential tasks with review gates
- OR Parallel Delegation: [N] independent tasks running simultaneously
- OR Single agent: manageable enough to handle in one flow

Shall I proceed this way, or do you prefer a different approach?

技能类别

严格型（test-first、fault-diagnosis）：严格遵循。不得偏离其规范。

灵活型（设计模式）：根据具体情况调整原则。

技能定义本身会说明其所属类别。

YoloMode

当用户表示希望自主执行时，跳过所有确认提示并精简工作流，但绝不自动选择带标签的选项。

触发短语（不区分大小写）：

• “yolo”、“yolomode”、“yolo mode”
• “just go”、“just do it”、“go for it”
• “skip the questions”、“don't ask”
• “auto-pick”、“you decide”

启用时的行为：

• 提供 A/B/C/D 选项的技能必须始终暂停并等待用户选择，没有例外
• 精简 intent-discovery：调查 + 研究 + 提出推荐方案，跳过逐节确认
• 仍会进行 rationale 分析（安全检查），但会予以精简——简洁地呈现分析和选项
• 绝不跳过 completion-gate 和测试验证（质量不可妥协）

技能如何引用 YoloMode：

If YoloMode is active:
  -> State: "YoloMode active — proceeding with recommendation [X] because [reason]"
  -> Execute immediately
  -> Log which option was auto-selected

If YoloMode is NOT active:
  -> Present options with labels and recommendation
  -> Wait for user selection

YoloMode 不会绕过：

• 测试执行（completion-gate）
• 安全检查（security-protocol）
• 破坏性操作（merge-protocol 的放弃确认）
• 质量保证（quality-enforcement）

YoloMode 追求速度，而非鲁莽。它信任 Agent 对设计选择的建议，但不会让 Agent 决定是否执行安全检查。

用户指令

用户指令规定需要做什么，而不是如何做。“Add X”或“Fix Y”并不意味着可以绕过既定工作流。