activation

現在のタスクにスキルが関連する可能性が少しでもある場合は、直ちに必ず呼び出してください。

関連するスキルを省略することはできません。必ず使用してください。

この要件は絶対です。理由をつけて回避したり、後回しにしたりすることはできません。

スキルへのアクセス

プラグインのインストール（標準設定）： Skill ツールからスキルを直接呼び出します。すべてのプロトコルは自動的に登録されます。 例：Skill("godmode:intent-discovery")

Skill ツールでプロトコルが見つからない場合： Read ツールでファイルを直接読み込みます。

1. プロトコルは次の場所にあります：[plugin-root]/skills/
2. 各プロトコルの定義ファイルは次の場所にあります：[plugin-root]/skills/[protocol-name]/SKILL.md
3. プラグインのルートディレクトリを特定する方法：

• リポジトリから実行する場合：作業ディレクトリがプラグインのルートディレクトリです
• プラグインとしてインストールされている場合：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. 3番目に参照スキル（reference-engine は ux-patterns、design-research、github-search、codebase-research、system-design、deployment-advisor に振り分けます）— 設計前に実証済みの解決策を探します
4. 4番目に設計スキル（ui-engineering、design-integration、specification-first）— 参照情報をもとに意思決定します
5. 5番目に実装スキル（test-first、project-bootstrap、pattern-matching、environment-awareness）— 実行を推進します
6. 6番目に品質スキル（quality-enforcement、security-protocol、completion-gate、comprehension-check、error-recovery）— 基準を徹底します
7. オーケストレーションスキル（team-orchestration、delegated-execution）— 並列処理を活用します

「Xを作ろう」→ rationale → intent-discovery → reference-engine（適切な参照スキルに振り分け）→ 設計スキル → 実装スキル。 「ウェブサイトを作って」→ rationale → intent-discovery → reference-engine → design-research + ux-patterns → ui-engineering → 実装。 「このバグを修正して」→ まず fault-diagnosis を実行し、その後、対象領域に適したスキルを使用します。（バグの場合、rationale は省略します） 「大規模なプロジェクト」→ rationale → intent-discovery → reference-engine → task-planning → 必要に応じて team-orchestration。 「エージェントが行き詰まっている」→ 失敗回数の検出に基づき、error-recovery が自動的に起動します。 「どのデータベース／ホスティングを使えばよいですか？」→ environment-awareness → deployment-advisor → system-design。

実行モードのガイダンス

ユーザーがタスクに「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が重視するのは速度であり、無謀さではありません。デザイン上の選択についてはエージェントの提案を信頼しますが、安全性の確認についてはそうではありません。

ユーザーの指示

ユーザーの指示は、何をするかを指定するものであり、どのようにするかを指定するものではありません。「Xを追加して」や「Yを修正して」という指示は、確立されたワークフローを省略してよいという意味ではありません。