mcp-builder

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 を確認し、タスクに関連するファイルのみを開いてください。

クイックサマリー

目標： LLM が適切に設計されたツールを通じて外部サービスと連携できる、高品質な MCP（Model Context Protocol）サーバーを作成します。

ワークフロー：

1. 詳細な調査 — エージェント中心の設計原則、MCP プロトコル、SDK ドキュメント、API ドキュメントを徹底的に調査します
2. 実装計画 — ツールの選定、共有ユーティリティ、入出力の設計、エラー処理
3. 実装 — プロジェクト構成、コアインフラストラクチャ、適切なスキーマとドキュメントを備えたツール、言語固有のベストプラクティス
4. レビューと改善 — コード品質のレビュー（DRY、合成可能性、一貫性）、テストとビルド
5. 評価の作成 — 現実的で複雑な読み取り専用の評価用質問を 10 件作成し、回答を検証します

主なルール：

• ワークフローに合わせて構築する：単なる API ラッパーではなく、関連する操作を統合します
• コンテキストを最適化する：重要度の高い情報を返し、簡潔な形式と詳細な形式をサポートします
• 実行可能なエラーを返す：具体的な提案によって、エージェントが正しい使い方をできるよう導きます
• スクリプトを優先する：検出／取得／分析スクリプトを実行し、トークン消費をゼロに抑えます

懐疑的な姿勢を保ち、批判的思考と段階的思考を適用してください。すべての主張には追跡可能な根拠を示し、確信度をパーセンテージで示してください（Idea は 80% を超える必要があります）。

MCP サーバー開発ガイド

概要

LLM が外部サービスと効果的に連携できる高品質な MCP（Model Context Protocol）サーバーを作成するには、このスキルを使用してください。MCP サーバーは、LLM が外部サービスや API にアクセスするためのツールを提供します。MCP サーバーの品質は、提供されたツールを使用して LLM が実際のタスクをどれだけ達成できるかによって決まります。

---

プロセス

🚀 ハイレベルなワークフロー

高品質な MCP サーバーの作成には、主に4つのフェーズがあります。

フェーズ1：徹底的な調査と計画

1.1 エージェント中心の設計原則を理解する

実装に取りかかる前に、以下の原則を確認して、AI エージェント向けのツール設計方法を理解してください。

API エンドポイントだけでなく、ワークフローに合わせて構築する：

• 既存の API エンドポイントを単純に1対1でラップするのではなく、よく考えられた、効果の高いワークフローツールを構築します
• 関連する操作をまとめます（例：空き状況の確認とイベントの作成を行う schedule_event）
• 個々の API 呼び出しだけでなく、タスク全体を完了できるツールに重点を置きます
• エージェントが実際にどのようなワークフローを完了する必要があるかを検討します

限られたコンテキストに最適化する：

• エージェントのコンテキストウィンドウには制限があるため、すべてのトークンを有効活用します
• 網羅的なデータの羅列ではなく、重要な情報を返します
• 「簡潔」と「詳細」の応答形式を選べるようにします
• 技術的なコードより、人が読みやすい識別子（ID より名前）をデフォルトにします
• エージェントのコンテキスト予算は限られたリソースであることを考慮します

実行につながるエラーメッセージを設計する：

• エラーメッセージは、正しい使用方法をエージェントに示すものにします
• 「結果を絞り込むには、filter='active_only' をお試しください」のように、具体的な次の手順を提案します
• エラーを単なる診断ではなく、学びにつながるものにします
• 明確なフィードバックを通じて、エージェントが適切なツールの使い方を学べるようにします

自然なタスクの区分に従う：

• ツール名には、人がタスクを考えるときの表現を反映させます
• 関連するツールを一貫性のある接頭辞でグループ化し、見つけやすくします
• API の構造だけでなく、自然なワークフローに沿ってツールを設計します

評価主導の開発を行う：

• 現実的な評価シナリオを早い段階で作成します
• エージェントからのフィードバックをもとに、ツールを改善します
• すばやくプロトタイプを作成し、実際のエージェントのパフォーマンスに基づいて反復します

1.3 MCP プロトコルのドキュメントを確認する

最新の MCP プロトコルのドキュメントを取得します：

WebFetch を使って、https://modelcontextprotocol.io/llms-full.txt を読み込みます。

この包括的なドキュメントには、MCP の完全な仕様とガイドラインが記載されています。

1.4 フレームワークのドキュメントを確認する

次のリファレンスファイルを読み込み、確認します：

• MCP のベストプラクティス：📋 ベストプラクティスを見る — すべての MCP サーバーに共通する基本的なガイドライン

Python で実装する場合は、以下も読み込みます：

• Python SDK のドキュメント：WebFetch を使って https://raw.githubusercontent.com/modelcontextprotocol/python-sdk/main/README.md を読み込みます
• 🐍 Python 実装ガイド — Python 固有のベストプラクティスと例

Node/TypeScript で実装する場合は、以下も読み込みます：

• TypeScript SDK のドキュメント：WebFetch を使って https://raw.githubusercontent.com/modelcontextprotocol/typescript-sdk/main/README.md を読み込みます
• ⚡ TypeScript 実装ガイド — Node/TypeScript 固有のベストプラクティスと例

1.5 API のドキュメントを徹底的に確認する

サービスを統合するには、利用可能な API ドキュメントをすべて確認します。

• 公式 API リファレンスドキュメント
• 認証と認可の要件
• レート制限とページネーションのパターン
• エラーレスポンスとステータスコード
• 利用可能なエンドポイントとそのパラメーター
• データモデルとスキーマ

包括的な情報を収集するには、必要に応じてウェブ検索と WebFetch ツールを使用します。

1.6 包括的な実装計画を作成する

調査結果に基づいて、次の内容を含む詳細な計画を作成します。

ツールの選定：

• 実装する価値が最も高いエンドポイント／操作をリストアップします
• 最も一般的で重要なユースケースを可能にするツールを優先します
• 複雑なワークフローを実現するために、どのツールを組み合わせて使うかを検討します

共通ユーティリティとヘルパー：

• 共通する API リクエストのパターンを特定します
• ページネーション用ヘルパーを計画します
• フィルタリングとフォーマット用ユーティリティを設計します
• エラー処理の方針を計画します

入出力の設計：

• 入力検証モデルを定義します（Python では Pydantic、TypeScript では Zod）
• 一貫性のあるレスポンス形式（例：JSON または Markdown）と、設定可能な詳細度（例：詳細または簡潔）を設計します
• 大規模な利用（数千人のユーザー／リソース）に備えます
• 文字数制限と切り詰めの方針（例：25,000 トークン）を実装します

エラー処理の方針：

• 適切なフォールバック動作を計画します
• 次のアクションを促す、明確で実行可能かつ LLM に適した自然言語のエラーメッセージを設計します
• レート制限やタイムアウトが発生した場合を検討します
• 認証エラーと認可エラーに対処します

---

フェーズ 2：実装

包括的な計画ができたら、言語ごとのベストプラクティスに従って実装を開始します。

2.1 プロジェクト構成を設定する

Python の場合：

• .py ファイルを 1 つ作成するか、複雑な場合はモジュールに分割します（🐍 Python ガイドを参照）
• MCP Python SDK を使用してツールを登録します
• 入力検証用の Pydantic モデルを定義します

Node／TypeScript の場合：

• 適切なプロジェクト構成を作成します（⚡ TypeScript ガイドを参照）
• package.json と tsconfig.json を設定します
• MCP TypeScript SDK を使用します
• 入力検証用の Zod スキーマを定義します

2.2 まずコアインフラストラクチャを実装する

実装を始める前に、ツールを実装するより先に共通ユーティリティを作成します：

• API リクエスト用のヘルパー関数
• エラー処理用ユーティリティ
• レスポンスのフォーマット関数（JSON と Markdown）
• ページネーション用ヘルパー
• 認証／トークン管理

2.3 ツールを体系的に実装する

計画に含めた各ツールについて、次の作業を行います。

入力スキーマを定義する：

• 検証には Pydantic（Python）または Zod（TypeScript）を使用します
• 適切な制約（最小／最大文字数、正規表現パターン、最小／最大値、範囲）を含めます
• 明確で説明的なフィールドの説明を記載します
• フィールドの説明に多様な例を含めます

包括的な docstring／説明を記述する：

• ツールの機能を一行で要約します
• 目的と機能を詳しく説明します
• 例を含む明示的なパラメーター型を記載します
• 完全な戻り値の型スキーマを記載します
• 使用例（使用する場合と使用しない場合）を記載します
• 特定のエラーが発生した場合の対処方法を示すエラー処理の説明を記載します

ツールのロジックを実装する：

• 共通ユーティリティを使ってコードの重複を避けます
• すべての I/O 処理で async/await パターンに従います
• 適切なエラー処理を実装します
• 複数のレスポンス形式（JSON と Markdown）に対応します
• ページネーションのパラメーターを尊重します
• 文字数制限を確認し、適切に切り詰めます

ツールのアノテーションを追加する：

• readOnlyHint: true（読み取り専用の操作の場合）
• destructiveHint: false（破壊的でない操作の場合）
• idempotentHint: true（呼び出しを繰り返しても同じ結果になる場合）
• openWorldHint: true（外部システムと連携する場合）

2.4 言語固有のベストプラクティスに従う

この時点で、適切な言語ガイドを読み込んでください：

Python の場合：🐍 Python Implementation Guide を読み込み、以下を徹底してください：

• 適切なツール登録で MCP Python SDK を使用する
• model_config を使用した Pydantic v2 モデル
• 全体を通じた型ヒントの使用
• すべての I/O 操作で async/await を使用する
• 適切に整理されたインポート
• モジュールレベルの定数（CHARACTER_LIMIT、API_BASE_URL）

Node/TypeScript の場合：⚡ TypeScript Implementation Guide を読み込み、以下を徹底してください：

• server.registerTool を適切に使用する
• .strict() を使用した Zod スキーマ
• TypeScript の strict モードを有効にする
• any 型を使用せず、適切な型を使う
• Promise<T> の戻り値の型を明示する
• ビルドプロセスを設定する（npm run build）

---

フェーズ 3：レビューと改善

初期実装の完了後：

3.1 コード品質レビュー

品質を確保するため、コードをレビューして以下を確認してください：

• DRY 原則：ツール間でコードが重複していない
• 構成可能性：共通ロジックが関数として切り出されている
• 一貫性：類似した操作が類似した形式で結果を返す
• エラー処理：すべての外部呼び出しでエラー処理を行う
• 型安全性：型が全面的にカバーされている（Python の型ヒント、TypeScript の型）
• ドキュメント：すべてのツールに包括的な docstring／説明がある

3.2 テストとビルド

重要： MCP サーバーは、stdio/stdin または sse/http 経由のリクエストを待機する長時間実行プロセスです。メインプロセスで直接実行すると（例：python server.py または node dist/index.js）、プロセスが無期限に停止したような状態になります。

サーバーを安全にテストする方法：

• 評価ハーネスを使用する（フェーズ 4 を参照）。推奨される方法です
• tmux でサーバーを実行し、メインプロセスの外で動作させる
• テスト時にタイムアウトを使用する：timeout 5s python server.py

Python の場合：

• Python の構文を検証する：python -m py_compile your_server.py
• ファイルを確認し、インポートが正しく動作することを確認する
• 手動でテストする場合：tmux でサーバーを実行し、メインプロセスで評価ハーネスを使ってテストする
• または評価ハーネスを直接使用する（stdio トランスポート用にサーバーを管理します）

Node/TypeScript の場合：

• npm run build を実行し、エラーなく完了することを確認する
• dist/index.js が作成されたことを確認する
• 手動でテストする場合：tmux でサーバーを実行し、メインプロセスで評価ハーネスを使ってテストする
• または評価ハーネスを直接使用する（stdio トランスポート用にサーバーを管理します）

3.3 品質チェックリストを使用する

実装の品質を検証するには、言語固有のガイドから適切なチェックリストを読み込んでください：

• Python：🐍 Python Guide の「Quality Checklist」を参照してください
• Node/TypeScript：⚡ TypeScript Guide の「Quality Checklist」を参照してください

---

フェーズ 4：評価を作成する

MCP サーバーを実装した後、その有効性をテストするための包括的な評価を作成してください。

完全な評価ガイドラインについては、✅ Evaluation Guide を読み込んでください。

4.1 評価の目的を理解する

評価では、LLM が MCP サーバーを効果的に使用して、現実的で複雑な質問に回答できるかをテストします。

4.2 評価用の質問を 10 個作成する

効果的な評価を作成するには、評価ガイドに記載された手順に従ってください：

1. ツールの確認：利用可能なツールを一覧表示し、その機能を把握する
2. コンテンツの探索：読み取り専用の操作で利用可能なデータを探索する
3. 質問の作成：複雑で現実的な質問を 10 個作成する
4. 回答の検証：各質問を自分で解き、回答を検証する

4.3 評価の要件

各質問は、以下を満たす必要があります：

• 独立している：他の質問に依存しない
• 読み取り専用である：非破壊的な操作のみを必要とする
• 複雑である：複数のツール呼び出しと深い探索を必要とする
• 現実的である：人々が関心を持つ実際のユースケースに基づいている
• 検証可能である：文字列比較で検証できる、明確で一意な回答がある
• 安定している：時間が経っても回答が変わらない

4.4 出力形式

次の構造で XML ファイルを作成します。

<evaluation>
  <qa_pair>
    <question>Find discussions about AI model launches with animal codenames. One model needed a specific safety designation that uses the format ASL-X. What number X was being determined for the model named after a spotted wild cat?</question>
    <answer>3</answer>
  </qa_pair>

</evaluation>

---

参照ファイル

📚 ドキュメントライブラリ

開発中に必要に応じて、以下のリソースを読み込みます。

MCP のコアドキュメント（最初に読み込み）

• MCP プロトコル：https://modelcontextprotocol.io/llms-full.txt から取得します。MCP の完全な仕様です。
• 📋 MCP のベストプラクティス：以下を含む、MCP 全般のガイドラインです。
  • サーバーとツールの命名規則
  • 応答形式のガイドライン（JSON と Markdown の比較）
  • ページネーションのベストプラクティス
  • 文字数制限と切り捨ての方針
  • ツール開発のガイドライン
  • セキュリティとエラー処理の基準

SDK のドキュメント（フェーズ 1/2 で読み込み）

• Python SDK：https://raw.githubusercontent.com/modelcontextprotocol/python-sdk/main/README.md から取得します。
• TypeScript SDK：https://raw.githubusercontent.com/modelcontextprotocol/typescript-sdk/main/README.md から取得します。

言語別の実装ガイド（フェーズ 2 で読み込み）

• 🐍 Python 実装ガイド：以下を含む、Python/FastMCP の包括的なガイドです。

  • サーバー初期化のパターン
  • Pydantic モデルの例
  • @mcp.tool を使ったツールの登録
  • 完全に動作するサンプル
  • 品質チェックリスト

• ⚡ TypeScript 実装ガイド：以下を含む、TypeScript の包括的なガイドです。

  • プロジェクト構成
  • Zod スキーマのパターン
  • server.registerTool を使ったツールの登録
  • 完全に動作するサンプル
  • 品質チェックリスト

評価ガイド（フェーズ 4 で読み込み）

• ✅ 評価ガイド：以下を含む、評価作成の包括的なガイドです。
  • 質問作成のガイドライン
  • 回答を検証する方法
  • XML 形式の仕様
  • 質問と回答の例
  • 提供されているスクリプトを使った評価の実行方法

関連

• mcp-management
• claude-code

---

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

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

批判的思考の姿勢 — 批判的思考と順序立てた思考を適用してください。実行に移すには、すべての主張に追跡可能な証拠があり、確信度が80％を超えている必要があります。 幻覚防止： 推測を事実として述べないでください。すべての主張に出典を示し、不確実性は率直に認め、出力に誤りがないか自己確認し、独立して相互参照し、自分の確信にも懐疑的でいてください。証拠のない確信が、あらゆる幻覚の根本原因です。

MUST ATTENTION 批判的思考を適用してください。すべての主張に追跡可能な証拠があり、実行に移すには確信度が80％を超えている必要があります。幻覚防止：推測を事実として述べないでください。

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

最後に確認すること

IMPORTANT MUST ATTENTION 作業を始める前に、タスク管理を使って作業を小さな todo タスクに分割してください IMPORTANT MUST ATTENTION 新しいコードを作成する前に、コードベースから類似パターンを3件以上検索してください IMPORTANT MUST ATTENTION すべての主張に file:line の証拠を示してください（実行に移すには確信度が80％を超えていること） IMPORTANT MUST ATTENTION 作業の品質を検証するため、最終レビューの todo タスクを追加してください

[TASK-PLANNING] 作業を始める前に、タスクの範囲を分析し、タスク管理を使って作業を体系的に小さな todo タスクとサブタスクに分割してください。

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

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

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

汎用的な移植性の境界： 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとします。プロジェクト固有の規約は、docs/project-config.json と docs/project-reference/ から確認してください。shared/sdd-artifact-contract.md の共通 AI-SDD を適用します。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 つ以上のコンテキスト／コードベースに当てはまりますか？ 当てはまらない場合は、抽象度を 1 段階上げます。
3. 普遍的なルールとして記述します。プロジェクト固有の名前／パス／クラスを除き、どのコードベースでも役立つ内容にします。
4. 統合します。同じ失敗モードを共有する複数のミスは、1 つの教訓にまとめます。
5. 再発判定：「この注意書きがなければ、今後のセッションで再発するか？」いいえの場合は $learn を省略します。
6. 自動修正判定：「$code-review／$code-simplifier／$security／$lint で検出できるか？」はいの場合は、代わりにレビュー用スキルを改善します。
7. 両方の判定を通過した場合： $learn を実行するようユーザーに依頼します。 [TASK-PLANNING] [MANDATORY] ワークフローまたはスキルのステップを実行する前に、予定されているすべてのステップのタスク追跡を作成／更新し、各ステップの開始時と完了時に内容を同期してください。