use-mcp

Codex 互換性に関する注意：

• Codex では $skill-name を使ってリポジトリのスキルを呼び出してください。このミラーコピーでは、従来の Claude の /skill-name 参照を書き換えています。
• タスクトラッカーに関する必須事項：ワークフローまたはスキルのステップを実行する前に、すべてのステップのタスク追跡を作成または更新し、進捗に応じて同期してください。
• ユーザーへの質問を促す指示がある場合は、Codex でユーザーに直接質問してください。
• Claude 固有のモード切り替え指示がある場合は無視してください。
• 厳格な実行契約：ユーザーがスキルを明示的に呼び出した場合、そのスキルのプロトコルを記載どおりに実行してください。
• サブエージェントの使用許可：ユーザーが呼び出したスキル、または AI が検出したスキルのプロトコルでサブエージェントが必要な場合、そのスキルの有効化により、そのタスクに必要な spawn_agent サブエージェントの使用が許可されます。
• ユーザーが事前に逸脱を承認しない限り、プロトコルのステップを省略、並べ替え、統合しないでください。
• ワークフロー用スキルでは、記載されている子スキルの各ステップを明示的に実行し、各ステップの証拠を報告してください。
• 必須のステップまたはツールをこの環境で実行できない場合は、独自に変更を加える前に停止し、ユーザーに確認してください。

Codex でのプロジェクト参照ドキュメントの読み込み（フックなし）

Codex では、Claude のフックによるドキュメントの自動挿入は行われません。 コーディング、計画、デバッグ、テスト、レビューを行う際は、以下のルートに沿ってプロジェクトのドキュメントを明示的に開いてください。

必ず読むもの：

• docs/project-config.json（プロジェクト固有のパス、コマンド、モジュール、ワークフローおよびテストの設定）
• docs/project-reference/docs-index-reference.md（docs/project-reference/* カタログ全体へのルート）
• docs/project-reference/lessons.md（常時適用されるガードレールとアンチパターン）

状況に応じて読むドキュメント：

• バックエンド／CQRS／API／ドメイン／エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• フロントエンド／UI／スタイル設定／デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 仕様／テストケースの計画または TC のマッピング：feature-docs-reference.md
• 統合テストの実装／レビュー：integration-test-reference.md
• E2E テストの実装／レビュー：e2e-test-reference.md
• コードレビュー／監査作業：変更対象のファイルに応じて、code-review-rules.md と上記のドメインドキュメント

すべてのドキュメントをむやみに読まないでください。まず docs-index-reference.md を確認し、タスクに関連するファイルだけを開いてください。

簡単な概要

目標： MCP（Model Context Protocol）サーバーのツールを利用して、Claude の機能を拡張します。

ワークフロー：

1. 検出 -- 利用可能な MCP ツールとその機能を一覧表示します
2. 選択 -- タスクに適したツールを選びます
3. 実行 -- 適切なパラメーターで MCP ツールを実行します

主なルール：

• ツールを使おうとする前に、利用可能な MCP サーバーを確認してください
• 組み込みツールでは利用できない機能には、MCP ツールを使用してください
• MCP ツールのエラーには、適切な代替手段で対処してください

懐疑的な姿勢を保ち、批判的かつ順序立てて考えてください。すべての主張には、追跡可能な根拠と信頼度（割合）が必要です（Idea は 80% を超える必要があります）。

コンテキストの予算を維持するため、MCP 操作は Gemini CLI 経由で実行してください。

実行手順

1. Gemini CLI でタスクを実行する（MCP をサポートする stdin パイプを使用）：

   # 重要：-p フラグ（非推奨。MCP の初期化をスキップします）ではなく、stdin パイプを使用してください
   echo "$ARGUMENTS. Return JSON only per GEMINI.md instructions." | gemini -y -m gemini-2.5-flash
   

2. 汎用サブエージェントにフォールバックする（Gemini CLI を利用できない場合）：

   • general-purpose サブエージェントを使ってツールを検出し、実行してください
   • サブエージェントで mcp-management スキルのスクリプトに問題が発生した場合は、mcp-builder スキルを使って修正してください
   • 既存の mcp-management／mcp-builder のスクリプトのみを再利用してください。新しいスクリプトは一切作成しないでください
   • サブエージェントは、このタスクを達成するために MCP ツールのみを使用できます
   • サブエージェントが適切なツールを見つけられない場合は、その旨をメインエージェントに報告し、次のステップに進んでください

重要な注意事項

• 必ず stdin パイピングを使用してください - 非推奨の -p フラグを使用すると、MCP の初期化がスキップされます
• -y フラグを使用して、ツールの実行を自動承認してください
• GEMINI.md は自動読み込みされます：Gemini CLI はプロジェクトのルートから GEMINI.md を自動的に読み込み、JSON のみの応答形式を適用します
• 解析可能な出力：応答は構造化 JSON です：{"server":"name","tool":"name","success":true,"result":<data>,"error":null}

アンチパターン（使用しないでください）

# BROKEN - deprecated -p flag skips MCP server connections!
gemini -y -m gemini-2.5-flash -p "..."

---

［重要］ 作業を始める前に、タスク管理を使って、ファイルを読み込むタスクも含め、すべての作業を小さなタスクに分割してください。これにより、長いファイルによるコンテキストの喪失を防げます。単純なタスクの場合は、AI は必ず、タスクを分割せずに進めてよいかユーザーに確認してください。

AI のミスを防ぐ — すべてのタスクで回避すべき失敗パターン：

削除する前に、下流の参照箇所を確認してください。 コンポーネントを削除すると、ドキュメントやコードに古い情報が連鎖的に残ります。削除する前に、参照しているファイルをすべて特定してください。 AI が生成した内容を実際のコードと照合してください。 AI は API、クラス名、メソッドのシグネチャを幻覚することがあります。ドキュメントに記載したり参照したりする前に、必ず grep で存在を確認してください。 編集後は依存関係を最後までたどってください。 定義を変更しても、そこから派生する下流の変数や利用箇所を見落とすことがあります。必ず依存関係を最後までたどってください。 正しさを検証する際は、すべてのコードパスをたどってください。 コードが存在することを確認しても、実行されることを確認したことにはなりません。正常系だけでなく、早期終了、エラー分岐、条件によるスキップも必ずたどってください。 デバッグするときは、修正する前に「どちらの責任か」を確認してください。 バグが呼び出し側（誤ったデータ）にあるのか、呼び出される側（誤った処理）にあるのかをたどってください。責任のあるレイヤーで修正し、症状が現れる箇所だけを修正しないでください。 既存の値は意図的なものだと考え、変更する前に理由を確認してください。 定数、上限、フラグ、パターンを変更する前に、コメントを読み、git blame を確認し、周辺のコードを調べてください。 最初の出力だけでなく、影響を受ける出力をすべて検証してください。 複数のスタックに関わる変更では、すべての出力を検証する必要があります。1 つのチェックが成功しても、すべてのチェックが成功したことにはなりません。 全体を優先するデバッグ — 最も目につく箇所に飛びつかないでください。 失敗を調査するときは、まず前提条件をすべて列挙してください（設定、環境変数、DB 名、エンドポイント、DI 登録、データの前提条件）。次に、コードレイヤーの仮説を立てる前に、それぞれを証拠に照らして検証してください。 変更は最小限に — 差分テストを行ってください。 バグ修正では、変更した各行がそのバグに直接関係している必要があります。周辺コードのスタイルを変更したり、改善したりしないでください。機能強化のタスクでは、改善を実装し、その内容を明示してください。 コーディング前に曖昧さを明らかにし、黙って選択しないでください。 依頼に複数の解釈がある場合は、それぞれを所要時間の見積もりとともに提示し、質問してください。全レコード対象、ファイルベース、またはより複雑な方法だと決めつけないでください。

批判的思考の姿勢 — 批判的思考と段階的な思考を適用してください。すべての主張にはたどって確認できる証拠が必要であり、確信度が 80% を超えてから行動してください。 幻覚の防止： 推測を事実として提示しないでください。すべての主張に根拠を示し、不確実な点は率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を鵜呑みにせず懐疑的でいてください。証拠のない確信こそ、あらゆる幻覚の根本原因です。

必ず批判的思考を適用してください — すべての主張にはたどって確認できる証拠が必要であり、行動するには確信度が 80% を超えている必要があります。幻覚を防ぐため、推測を事実として提示しないでください。

必ずAI のミスを防止してください — 全体を優先したデバッグ、責任のあるレイヤーでの修正、コーディング前の曖昧さの明示、コンパクション後のファイルの再読み込みを徹底してください。

最後に確認すること

重要：必ず 作業を始める前に、タスク管理を使って作業を小さな todo タスクに分割してください 重要：必ず 新しいコードを作成する前に、コードベース内で類似パターンを 3 つ以上検索してください 重要：必ず すべての主張に file:line 形式の証拠を示してください（行動するには確信度が 80% を超えている必要があります） 重要：必ず 作業の品質を検証する最終レビューの todo タスクを追加してください

［タスク計画］ 行動を始める前に、タスクの範囲を分析し、タスク管理を使って作業を小さな todo タスクとサブタスクに体系的に分割してください。

フックレスプロンプトプロトコルミラー（自動同期）

ソース：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須・重要・厳守。いかなる理由があってもスキップしないでください。

汎用的な移植性の境界： 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとします。プロジェクト固有の規約は docs/project-config.json と docs/project-reference/ から確認してください。共有 AI-SDD は shared/sdd-artifact-contract.md を適用します。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されたプロジェクトリファレンスドキュメントを開いてください。共有コンテキストとローカルドキュメントが利用可能であれば、サポートされている AI ツールで実行できます。

1. 検出： プロンプトをワークフローカタログと照合します
2. 分析： 最適なワークフローを見つけ、カスタムのステップの組み合わせのほうが適切かどうかも評価します
3. 確認（必須形式）： ユーザーが明示的にワークフロー／スキルを呼び出し、ローカルプロトコルでその明示的な呼び出しを確認として扱う場合を除き、次の構成で直接ユーザーに質問します：
   • 質問：「どのワークフローを有効にしますか？」
   • 選択肢 1：「[最適なワークフロー] を有効にする（推奨）」
   • 選択肢 2：「カスタムワークフローを有効にする：[step1 → step2 → ...]」（理由を1行で記載）
4. 有効化（確認後）： 標準ワークフローの場合は $workflow-start <workflowId> を呼び出し、カスタムステップは手動で順番に実行します
5. タスクの作成： すべてのワークフローステップについてタスク追跡を行います
6. 実行： 各ステップを順番に実行します [CRITICAL-THINKING-MINDSET] 批判的思考と段階的な思考を適用します。すべての主張には追跡可能な根拠が必要であり、行動するには確信度が80%を超えている必要があります。 ハルシネーション防止の原則： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実な点は率直に認め、出力に誤りがないか自己確認し、独立して相互参照を行い、自分の確信度に懐疑的でいてください。根拠のない確信こそが、あらゆるハルシネーションの根本原因です。 AI の注意原則（初頭効果と新近効果）： 長いプロンプト／プロトコルでは、最も重要な3つのルールを冒頭と末尾の両方に配置し、長いコンテキストウィンドウでも指示への準拠を維持してください。 目標主導の実行： まず成功基準を定義し、検証が完了するまで繰り返し、観測可能なチェックに合格した場合にのみ停止します。 テストで意図を検証する： テストはビジネスルール／不変条件を保護し、現在の動作を単に反映するだけでなく、保護対象の意図が破られたときに失敗する必要があります。

[LESSON-LEARNED-REMINDER] [BLOCKING] タスク計画と継続的改善 — 必須。スキップしないでください。

作業を始める前に、作業を小さなタスクに分けてタスク追跡に追加してください。最後のタスクとして「AI の間違いと教訓を分析する」を追加してください。

教訓の抽出 — 症状への対処ではなく、根本原因のみ：

1. 症状ではなく失敗モード（推論／前提の誤り）に名前を付けます。「誤った列挙値を使用した」ではなく、「ソースを読まずに API が存在すると仮定した」とします。
2. 汎用性を確認します。この失敗モードは3つ以上のコンテキスト／コードベースに当てはまりますか？ 当てはまらない場合は、抽象度を一段階上げます。
3. 普遍的なルールとして記述します。プロジェクト固有の名前／パス／クラスを取り除きます。どのコードベースでも役立つ内容にしてください。
4. 統合します。同じ失敗モードに起因する複数の間違いは、1つの教訓にまとめます。
5. 再発ゲート：「このリマインダーがなければ、今後のセッションで再発しますか？」— いいえの場合は $learn をスキップします。
6. 自動修正ゲート：「$code-review／$code-simplifier／$security／$lint で検出できますか？」— はいの場合は、代わりにレビューのスキルを改善します。
7. 両方のゲートを通過した場合は、ユーザーに $learn の実行を依頼します。 [TASK-PLANNING] [MANDATORY] ワークフローまたはスキルのステップを実行する前に、計画したすべてのステップについてタスク追跡を作成／更新し、各ステップの開始時と完了時に同期を保ってください。