ai-agents

AI エージェント開発 — アーキテクチャハブ

このスキルは、ワークフローをエージェントにすべきか、どのエージェント形式が適しているか、どのプロトコル境界を使うべきか、本番環境への導入前にどのような制御が必要かを判断するために使用します。

基本方針：明示的な制御フロー、範囲を限定したツール、型付きコントラクト、監査可能な状態、高リスクな操作に対する人間の承認、そして初日からのテレメトリーです。

このファイルは簡潔に保ちます。必要に応じて、references/index.md、assets/、および関連するスキルから詳細を参照してください。

このスキルを使う場面

次のことをユーザーから依頼された場合に、このスキルを使用します。

• エージェントのアーキテクチャや運用モデルに関する判断
• エージェントを構築すべきかどうかの評価
• MCP と A2A のプロトコル選択
• 既存のエージェントシステムの本番運用準備状況のレビュー
• 評価、可観測性、段階的な導入、安全性の計画
• 要件がすでに明確な場合のフレームワーク選定
• 新しいエージェント仕様の開始用テンプレート
• グラフエンジニアリング、エージェント／ワークフローのグラフ、ステートマシンによるオーケストレーション、循環グラフ、または DAG とループの設計
• ループエンジニアリング、完了するまで実行するコーディングエージェント、自己改善型ワークフロー、評価器のフィードバックループ、または範囲を限定した自律的な反復
• 「グラフ」が実行制御フロー、改善ネットワーク、ナレッジ／コンテキストグラフのどれを指すのかが不明な場合

詳細には他のスキルを使う

• 複数のエージェントが利用する共有プラットフォーム（LLM ゲートウェイ、モデルルーティング、エージェント ID、MCP ゲートウェイ、トレーシング、コスト、EU／UK 分類）→ ai-agent-platform
• プロンプトコントラクトと構造化出力 → ../ai-prompt-engineering/SKILL.md
• 検索、チャンク分割、再ランキング、検索品質 → ../ai-rag/SKILL.md
• ベクトルブレインの実装、スキーマ、取り込みスクリプト、マニフェスト、検索ツールのコントラクト → ../ai-vector-brain/SKILL.md
• ボット構築（サポート、セールス、会話設計、LangGraph）→ ../ai-bot-builder/SKILL.md
• 音声ボット（STT／TTS パイプライン、テレフォニー、レイテンシー）→ ../ai-voice-bots/SKILL.md
• MCP サーバーのセットアップ、トランスポート、サーバー構築 → ../agents-mcp/SKILL.md
• サブエージェント、委任コントラクト、最小権限のツール → ../agents-subagents/SKILL.md
• CLI ベースのツール（非対話型、冪等、エージェントに適したパターン）→ ../software-devtools/SKILL.md
• 評価ハーネス、攻撃テストスイート、リグレッションゲート → ../qa-agent-testing/SKILL.md
• デプロイのガードレールとモデル運用 → ../ai-mlops/SKILL.md
• アプリケーションセキュリティと高リスク操作の制御 → ../software-security-appsec/SKILL.md
• モデルと推論のコスト調整 → ../ops-cost-optimization/references/ai-api-cost-guide.md、../ai-llm-inference/SKILL.md
• ナレッジ／コンテキストグラフ、検索アーキテクチャ、グラフを活用したメモリ → ../ai-context-layer/SKILL.md、../ai-rag/SKILL.md、../ai-vector-brain/SKILL.md

デフォルトのワークフロー

1. 構築するかどうかの判断ゲートを実行します。よりシンプルなワークフロー、フォーム、またはツールで対応できる場合は、エージェントを構築せず、自律性が正当化される場合にのみ先へ進みます。
2. タスク環境を定義します。評価指標、環境、知覚情報／センサー、アクション／ツール、可観測性、決定性、時間的範囲、単一エージェントかマルチエージェントかの相互作用を明確にします。
3. 制御フローを選択します。本番環境では、ワークフロー／FSM／DAGをデフォルトとします。
4. プロトコルの境界を選択します。ツール／データにはMCPを、エージェント間の引き継ぎにはA2Aを使用します。
5. 契約を定義します。ツールスキーマ、引き継ぎペイロード（委任の深さの上限を含む：references/multi-agent-patterns.md）、状態モデル、成功基準を定めます。
6. リリース前に評価とテレメトリーを追加します。
7. 取り消せないアクションには、人間による承認、ロールバック、緊急停止スイッチを追加します。
8. テンプレートから始め、実装を掘り下げる際には専門スキルに進みます。

トポロジー昇格ゲート

境界の明確なワークフローまたはエージェントを1つから始め、それを制御対象として維持します。独立して実行可能な分岐がある場合、ツールの権限が実質的に異なる場合、または検証者を生成者から分離する必要がある場合に限り、マルチエージェントへ昇格させます。昇格する前に、単一エージェントでの失敗、提案する引き継ぎ契約、追加のレイテンシとコストの予算を記録します。同じタスクセットで目標とする成果が向上し、未解決の引き継ぎ失敗が増えない場合にのみ、そのトポロジーを採用します。それ以外の場合は、よりシンプルな制御を維持します。

昇格の前にコストを測定します。同じタスクセットを両方の方法で実行し、成果の差とともにトークン数とレイテンシの倍率を記録します。成果の向上が、その倍率に見合う価値を現在の価格で得られる場合にのみ昇格させます。価格は記憶に頼らず、現在のプロバイダーの料金ページ（../ops-cost-optimization/references/ai-api-cost-guide.mdを参照）から取得してください。

よくある落とし穴

• ワークフロー、フォーム、または単純なツール呼び出しのほうが簡単なのに、「エージェント」をデフォルトの対話パターンとして扱う
• ツールとリソースの統合レイヤーではなく、全体的なエージェントアーキテクチャとしてMCPを使用する
• 出典情報（A13）、保持ポリシー、訂正フロー（A11 — 忘却経路）、ユーザー価値の立証なしに長期記憶を追加する。パターンの選択にはai-context-layer/patterns-catalog.mdを、網羅的な確認にはai-context-layer/anti-patterns-catalog.mdを使用してください
• 明示的なステップ数、予算、エスカレーションの上限なしにプランナーループを再帰させる。ステップ数の上限では、振動や捏造された観測を検出できません。references/agent-debugging-patterns.mdを参照して、ループの失敗を診断してください
• 評価範囲、ロールバック制御、人間による承認経路が整う前に、自律的なアクションをリリースする
• 推論負荷の高い作業で、同じトークン予算なら強力な単一エージェントでも同等以上の成果を出せる可能性があるのに、マルチエージェントのトポロジーをデフォルトにする。複数のエージェントに分担させる前に、タスクが本当に並列化可能か、またはツール／役割に多様性が必要かを確認してください。根拠と適用範囲の制限については../agents-subagents/SKILL.md § 強力な単一エージェントがチームに勝る場合を参照してください

よくあるアンチパターン

• 状態モデル、契約、アクション境界のない、チャット優先のエージェント設計
• 単一エージェントの失敗モードを把握する前に、マルチエージェントのトポロジーを導入する
• 最小権限ではなく、利便性を基準にツールの利用範囲を定義する
• リリースゲートとしてではなく、可観測性を取り繕うためにリリース後に評価を追加する
• 誇大な宣伝、ベンチマークのスクリーンショット、またはマーケティング上の分類だけを根拠に、プロバイダーやフレームワークを選定する

クイックリファレンス

質問	デフォルト
これはエージェントにするべきですか？	references/build-vs-not-decision.mdを確認してください。自律性を正当化できるだけの処理量、曖昧さ、価値が明らかになるまでは、デフォルトの回答は「いいえ」です。
タスクの環境とは何ですか？	フレームワークを選ぶ前に、評価指標、環境、知覚情報／センサー、アクション／ツール、観測可能性、決定性、期間、その他のエージェントを明示してください。
どの制御フローが適していますか？	ワークフロー／FSM／DAGを優先してください。分岐を明示的にモデル化できない場合に限り、プランナー／実行者を使用してください。
MCPとA2Aのどちらですか？	外部ツール／データにはMCP、エージェント間の連携にはA2A、マルチエージェントシステムがツールも必要とする場合は両方を使用してください。
マルチエージェントを使うのはどんな場合ですか？	役割、引き継ぎの契約、検証者の責任が明確な場合に限ります。
長期メモリを追加するのはどんな場合ですか？	来歴、保持ルール、ユーザーの同意、明確な価値がそろっている場合に限ります。ai-context-layer/patterns-catalog.mdから名前付きパターンを選んでください（アプリケーションがオーケストレーションする場合はP2、自己編集型の場合はP3、時間的な情報を扱う場合はP4、会話型の場合はP6）。アンチパターンの確認を実施してください。A1（生のトランスクリプトを使わない）、A11（忘却の経路が必須）、A13（来歴が必須）。
ロールアウト前に何が必要ですか？	評価スイート、テレメトリ、アクションの制限、人間へのエスカレーション、ロールバックの経路、キルスイッチです。
これは「グラフエンジニアリング」ですか、それとも「ループエンジニアリング」ですか？	references/graph-and-loop-engineering.mdから始め、ランタイムやデータストアを選ぶ前に、グラフの目的を特定してください。

自律性の形態 — エージェントを24時間365日稼働させる方法

エージェントを継続的に実行するための3つのデプロイ形態です。フレームワークではなく、トリガーモデルに基づいて選択してください。

形態	トリガー	用途	主なガイド
A — トリガー型／ホスト型実行	Webhook、キュー、スケジュール、/fire	イベントごとのエージェント作業、スケジュールジョブ、外部ソースからのファンアウト	../ai-coding-agents-state/references/webhook-and-queue-triggers.md + ../ai-coding-agents-state/references/durable-trigger-integration.md
B — 常時稼働ボット／音声サーバー	セッション、WebSocket、SIP 通話	会話状態を維持するサポート／営業／音声ボット	../ai-bot-builder/references/production-deployment.md + ../ai-bot-builder/references/stateful-rollout-and-blue-green.md + ../ai-voice-bots/references/production-deployment.md
C — 自律ループ	PRD + 受け入れ条件を満たすまでループドライバーを実行	リファクタリング、移行、調査、Ralph-Loop クラスなど、長期にわたる作業	references/autonomous-loop-patterns.md

ホスト型またはセルフホスト型のループ：カスタムサンドボックスやアウトバウンド通信ポリシー、プライベートネットワーク上のツール、データレジデンシー、決定論的なリプレイが必要な場合はセルフホストにしてください。それ以外の場合は、ベンダーがホストするエージェントランタイムを優先してください。導入を決める前に、ベンダーのドキュメントでセッションの永続性、アイドル時の課金、サンドボックスの制限を確認してください。

形態を問わない要件：

• 予算とキルスイッチの適用：../agents-hooks/references/budget-and-loop-hooks.md
• 24時間365日の運用モデル（SLO、オンコール、ランブック）：references/24-7-operating-model.md
• プロバイダーのフェイルオーバーとシークレットのローテーション：../ai-bot-builder/references/secret-rotation-and-model-fallback.md
• ホスティング先（Vercel / Fly.io / Railway / Cloudflare / Render）：../software-paas-hosting/SKILL.md および ../software-paas-hosting/references/agent-hosting-matrix.md

アーキテクチャの選定

要件	デフォルトのエージェント形態	備考
決定論的なビジネスプロセス	ワークフローエージェント	監査可能な本番環境の動作に適した、最良のデフォルトです。
範囲を限定した外部操作	ツール使用型エージェント	ツールの範囲を狭くし、型を定め、権限を限定してください。
ナレッジに基づく回答	RAG エージェント	引用、ACL を考慮した検索、根拠がない場合の回答拒否を必須にしてください。
分岐を伴う長い複数ステップの作業	プランナー／エグゼキューター	ステップ数の厳格な上限、チェックポイント、再計画の上限を設定してください。
担当範囲が明確な専門的役割	マルチエージェントオーケストレーター	引き継ぎは API です。早い段階で検証役／評価役を追加してください。MAST の障害分類（Cemri et al., 2025, arXiv:2503.13657）に照らして設計を評価してください。これを再導出しないでください：../agents-subagents/references/mast-failure-taxonomy.md。
デスクトップまたはブラウザーの制御	OS エージェント	サンドボックス化、UI の検証、アクションのゲート制御を必須にしてください。
コード変更と CI のフィードバック	SWE エージェント	リポジトリの分離、テスト、レビューゲート、ロールバックを必須にしてください。
コード、プロンプト、成果物の自律的な改善	調査／実験エージェント	評価指標を固定し、変更範囲を限定して、採用／差し戻しのループを維持してください。

自律的な改善ループ

研究／実験エージェントが自律的に反復します。変更を提案 → 適用 → 評価 → 維持または取り消し → 繰り返し。このパターンは、測定可能な評価関数があるものなら何にでも適用できます。

コンポーネント	目的	例
変更対象	エージェントが変更できるもの	1 つのファイル（train.py）、1 つのプロンプト、1 つの設定
評価関数	結果の採点方法	val_bpb、はい／いいえのチェックリスト（3～6 個の質問）、レイテンシ測定
維持／取り消しのルール	変更を維持する条件	スコアが向上したら維持し、悪化したら取り消す
終了条件	停止するタイミング	N ラウンド、目標スコアの達成、または手動停止
記録簿	実験の履歴	Git コミット、results.tsv、理由を記載した変更履歴

設計上の制約：

• 変更対象を小さく保ちます（1 つのファイル、1 つのプロンプト）。対象が広いと、気づきにくいリグレッションが積み重なります。
• 主観的な評価ではなく、二値またはスカラーの指標を使います。「見出しに具体的な数値が含まれているか？」は、「見出しの品質を 1～10 で評価する」より適しています。
• 評価基準は 3～6 個が最適です。多すぎると評価の抜け道を探すようになり、少なすぎると障害モードを見落とします。
• 変更履歴を保持します。後続のモデルは、前のエージェントが残した地点から作業を再開できます。

参照：autoresearch（ML トレーニング）、Lehmann によるスキル最適化への応用（プロンプト／スキルの改善）。

プロトコルの選択

システムに必要な機能	使用するもの
ツール呼び出し、データベースアクセス、ファイルアクセス、プロンプト、リソース	MCP
タスクの引き継ぎ、エージェントカード、マルチエージェントのルーティング	A2A
ツールと連携するエージェントの両方	MCP + A2A

プロトコルのデフォルト：

• MCP はツール／データの統合レイヤーとして扱い、エージェントアーキテクチャそのものとして扱わないでください。
• A2A の引き継ぎは、スキーマ検証と trace_id の伝播を備えた、バージョン管理された API として扱ってください。
• MCP には stdio と Streamable HTTP という 2 つの標準トランスポートがあります。SSE のみを使うサーバーはレガシーです。A2A のディスカバリーは /.well-known/agent-card.json にある Agent Card です。タスク ID と状態の列挙型を持たない引き継ぎは、何と呼ばれていようと A2A ではありません。ワイヤーレベルで検証済みの事実については、references/protocol-decision-tree.md § 仕様に照らして検証したプロトコルの事実を参照してください。
• リモート MCP では、認可とアイデンティティの範囲を明示してください。ネットワークへの信頼だけに依存しないでください。
• stdio サーバーの設定は、クライアントが実行するコマンドです。信頼できない入力から構築してはならず、サーバーを起動するホストをサンドボックス化してください。ローカルトランスポートのセキュリティ制御については、../agents-mcp/references/mcp-security.md § ローカルの stdioを参照してください。

エージェントをコードとして扱うパターン

エージェントのペルソナを、専門知識、制約、期待される出力を明示した、構造化されバージョン管理された成果物として定義します。このパターンでは、エージェントの定義を場当たり的なプロンプト文字列ではなく、レビュー可能なコードとして扱います。

適切に定義されたエージェント仕様には、次の項目が含まれます。

フィールド	目的
役割	エージェントが担当する内容（例：「アーキテクト」、「QA レビュアー」）
専門知識	ドメイン知識と能力
制約	実行してはならないこと、権限の境界
期待される出力	生成する成果物（仕様、レビュー、計画、コード）
対話ルール	他のエージェントや人間とのコミュニケーション方法

利点：エージェントを PR でレビューし、バージョン間で差分を比較し、明確な役割の境界を設けてチームに組み込めます。

現在の提供方法と、GSD、BMAD、Spec Kit、OpenSpec、MADD、AI-SDLC から知見を取り入れるタイミングについては、references/agent-delivery-methods.mdを参照してください。

タスクの複雑さに応じたエージェントの構成

タスクの複雑さに合わせて、エージェントの高度さを調整してください。バグ修正に完全なマルチエージェントオーケストレーションを使ったり、プラットフォーム移行に単一のプロンプトを使ったりしないでください。

タスクの複雑さ	エージェントのアプローチ
設定変更、誤字	直接プロンプトを使用し、エージェントのインフラストラクチャは使わない
バグ修正、小規模な機能	ツールを限定した単一のエージェント
複数モジュールにまたがる機能	リードエージェント＋専門ワーカー 2～3 個
複数サービスにまたがる移行	ペルソナ定義、議論、検証を含む完全なオーケストレーション

規模を拡大するかどうかは、想定した複雑さではなく、実際に確認された曖昧さに基づいて判断してください。

本番環境でのデフォルト設定

• 状態を明示的かつシリアライズ可能にし、再生可能にしてください。
• すべての状態をファイルに外部化してください。計画、進捗、決定事項、依存関係の出力を構造化ファイルに保持することで、コンテキストを継承しなくても、どのエージェントセッションからでも再開できるようにします。
• ツールの公開範囲を絞り、バックエンドの複雑さをそのまま公開するのではなく、タスクを公開してください。
• 再試行回数、予算、コンテキストサイズ、再帰の深さに上限を設けてください。
• 取得したコンテンツやツールの出力は、信頼できない入力として扱ってください。
• 信頼できないコンテンツ、プライベートデータ、データ持ち出しが可能なツールを、同じモデルコンテキストに決して含めないでください。生の信頼できないテキストを見ない特権を持つプランナーと、出力を命令ではなくデータとして扱う隔離されたリーダーに分割してください（Debenedetti et al., 2025、CaMeL）。インジェクション分類器は第 2 層であり、境界の代わりにはなりません。
• LLM の呼び出し、検索、メモリ操作、ツール呼び出しに、一貫したトレーシングを設定してください。
• データベースへの書き込み、金融取引、法律・コンプライアンス関連の操作、破壊的な操作は、人間の承認を必須にしてください。
• 安全でないフォールバックを隠すより、拒否するか、機能を縮退させることを優先してください。

新しいコンテキストで動作するワーカー、永続状態、セッションとプロジェクトの境界については、references/context-rotation-and-state.md を参照してください。

テンプレートとエントリーポイント

• 標準エージェント仕様 → assets/core/agent-template-standard.md
• クイックプロトタイプ仕様 → assets/core/agent-template-quick.md
• 特化型エージェント仕様 → assets/core/agent-template-specialized.md
• AI ネイティブ SDLC ランブック → assets/agent-template-ainative-sdlc.md
• 安全性ゲート → assets/checklists/agent-safety-checklist.md
• ツールスキーマのテンプレート → assets/tools/tool-definition.md
• ツール検証チェックリスト → assets/tools/tool-validation-checklist.md
• マルチエージェントのスターターパターン → assets/multi-agent/manager-worker-template.md、assets/multi-agent/evaluator-router-template.md
• RAG のスターターテンプレート → ../ai-rag/SKILL.md の assets/。エージェント側の検索ルール → references/rag-patterns.md。ナレッジベースの構成 → assets/knowledge-base/kb-architecture.md
• Usage-report の --pricing ファイル → assets/pricing-template.json（料金情報は含まれていません）

スクリプト

スクリプト	目的
scripts/agent_eval_runner.py	JSONL 形式のタスク／期待値／実際の結果の組を読み込み、合格率を報告します（オフライン）。フェイルクローズ方式で動作し、不正または不完全なレコードは失敗としてカウントします。敵対的なテストスイートや複数ターンのハーネスについては、../qa-agent-testing/SKILL.md に委任してください。
scripts/claude-usage.py	各セッション内のサブエージェントのトランスクリプトも含めて Claude Code の使用状況ログを解析し、各 API レスポンスを一度だけカウントするトークンレポートを生成します（メッセージ ID とリクエスト ID の組み合わせで行を重複排除します）。料金を計算するには --pricing <file> を指定します（プロバイダーの料金ページからコピーした料金を使用し、スキーマは assets/pricing-template.json にあります）。指定しない場合、料金は unpriced になります。指定した場合でも、不明なモデルや、独自の 1 時間レートが設定されていない 1 時間のキャッシュ書き込みは unpriced になり（終了コード 3）、デフォルトの料金で計算されることはありません。stats-cache.json の daily には料金計算用のトークンが含まれないため、--pricing を指定すると終了コード 3 になります。models --pricing は代わりにログを読み込み、キャッシュ書き込みの TTL 区分を参照します。
scripts/codex-usage.py	Codex の使用状況ログを解析してトークンレポートを生成し、再送されたトークンイベントをスキップします。料金を計算するには --pricing <file> を指定します。フェイルクローズのルールと終了コード 3 は同じです。各レポートは traces と同様に、イベントごとに料金を計算します。Codex のログにはサービス階層やコンテキストクラスが記録されていないため、このスクリプトは標準階層と基本コンテキストを仮定し、その旨を表示して料金を estimated とマークします。

ナビゲーション

• 全体を詳しく把握するためのマップ → references/index.md
• これを構築すべきか？ → references/build-vs-not-decision.md
• MCP と A2A の比較 → references/protocol-decision-tree.md
• 現在の運用におけるデフォルト → references/modern-best-practices.md
• デリバリー方法と計画システム → references/agent-delivery-methods.md
• 評価とテレメトリー → references/evaluation-and-observability.md
• CLI の使用状況の追跡 → references/coding-agent-usage-tracking.md
• コンテキストのローテーションと永続状態 → references/context-rotation-and-state.md
• デプロイの安全性 → references/deployment-ci-cd-and-safety.md
• 自律ループ／Ralph-Loop クラス → references/autonomous-loop-patterns.md
• グラフエンジニアリング、ループエンジニアリング、グラフタイプの区別 → references/graph-and-loop-engineering.md
• 24 時間 365 日の運用モデル（SLO、オンコール、ランブック） → references/24-7-operating-model.md
• ツールのスキーマと契約 → references/tool-design-specs.md、references/api-contracts-for-agents.md
• 意思決定と経済性 → エージェントの経済性と ROI、成熟度とフリートガバナンス、フレームワークの概況
• アーキテクチャ → AI エンジンのレイヤー、OODA ループアーキテクチャ、受信トレイエンジン（イベント駆動型の取り込み）、OS エージェントの機能、コード／SWE エージェント、音声・マルチモーダルエージェント
• 調整 → A2A ハンドオフパターン、マルチエージェントパターン、マルチエージェントシステムのゲーム理論、プリンシパル・エージェント理論
• コンテキストとメモリー → コンテキストエンジニアリング、コンテキストグラフのパターン、メモリーシステムのクイックリファレンス
• SDK のパターン → Claude Agent SDK、Pydantic AI
• 運用と安全性 → エージェント運用、ガードレールの実装、エスカレーションパターン
• 厳選した外部ソース → data/sources.json。ブラウジングが利用できない場合は、フレームワークのランキング、ライフサイクル、トランスポート／認証、A2A の成熟度、価格に関する質問にこの情報をもとに回答し、前提を明示したうえで、主張が未検証であることを示してください

関連スキル

• エージェントと単一呼び出し、RAG、ファインチューニングの選択、および幅広いLLMシステム設計 → ../ai-architecture-advisor/SKILL.md
• LangGraphボットの実装 → ../ai-bot-builder/SKILL.md
• RAGの実装 → ../ai-rag/SKILL.md
• Vector-brainの実装 → ../ai-vector-brain/SKILL.md
• MCPの実装 → ../agents-mcp/SKILL.md
• サブエージェントのオーケストレーション → ../agents-subagents/SKILL.md
• Swarmと並列ディスパッチ → ../agents-swarm-orchestration/SKILL.md
• フックのガードレールとライフサイクル → ../agents-hooks/SKILL.md
• スキルのパッケージ化 → ../agents-skills/SKILL.md
• プロジェクトメモリ → ../agents-memory/SKILL.md
• 評価ハーネス → ../qa-agent-testing/SKILL.md
• オブザーバビリティ → ../qa-observability/SKILL.md
• セキュリティとAppSec → ../software-security-appsec/SKILL.md

使用上の注意

• 詳細な実装手順ではなく、アーキテクチャと本番運用の方針を確認する際は、まずここから始めてください。
• 古くなったフレームワークのランキングより、安定した機能に関する指針を優先してください。
• ユーザーの方向性が明確になってから、詳細なリファレンスを参照してください。
• 推奨事項は、契約、障害モード、ゲート、テレメトリー、ロールバックなど、運用に役立つ内容にしてください。

学びのループ

過去の決定や落とし穴が関係する場合は、learnings.consolidated.md があれば参照してください。必要な履歴を確認する場合、または利用可能な代替手段としてのみ、learnings.md を使用してください。それ以外の場合は、どちらも参照しないでください。

適用後、記憶に値するパターン、再発防止が必要なミス、または意外だった分野の事実に遭遇した場合は、agents-skills-feedback-loop/scripts/append_learning.py を使用して、日付入りの箇条書きを1つ learnings.md に追記してください。SKILL.md 自体は変更しないでください。