bootstrap-agentic-system

エージェントシステムのブートストラップ

このスキルは、リポジトリローカルのエージェントシステムを設計し、必要に応じてインストールするために使用します。ブートストラップでインストールするのはエージェントシステムのファイルのみです。対象は、指示、エージェント、スキル、プロンプト、ガバナンス文書、ナレッジ文書、成果物テンプレート、セッションルール、メンテナンスの来歴情報です。

ブートストラップでは、アプリケーションの機能を実装したり、製品コードを編集したり、データベーススキーマやマイグレーションを変更したり、実行時設定を変更したり、製品のテストを作成したりしてはいけません。

ミッション

計画、ナレッジの読み込み、実装の引き継ぎ、検証、メンテナンスにおいて、リポジトリで起こり得るコストの高い失敗を防ぐ、小規模で持続可能なエージェントワークフローを作成します。

生成するシステムは、リポジトリに固有のもので、承認ゲートを備え、テンプレートを基盤とし、メンテナンス可能でなければなりません。ユーザーが生成前に、より小規模なシステムを明示的に承認した場合を除き、プランナー、実装エージェント、テスターまたは統合テスター、ナレッジビルダー、Ask、ルート指示を含める必要があります。ユーザーが生成前にブートストラップを停止しない限り、ナレッジビルダーとAskは、最初に生成するエージェント一式に必ず含めてください。

ブートストラップは、単一の公開オーケストレーターとして維持します。ワークフローを分かりやすく保つために、内部の調査レーン、意思決定記録、ファイル計画、バッチ承認、監査を活用してください。ユーザー向けの初期ワークフローを、複数の公開エントリーポイントに分割してはいけません。

譲れない原則

• 一致するテンプレートがこのスキルフォルダーにある場合は、公開 Bootstrap テンプレートから生成します。
• templates/agents/、templates/skills/、templates/instructions/ は正規テンプレートミラーとして扱います。まずコピーし、承認済みのプレースホルダーとスロットを埋め、ソース専用のスロットマーカーを削除し、スロット以外の正規の文言を保持します。
• プラットフォームへの適応で変更できるのは、宣言済みのプレースホルダー値とツール／呼び出しスロットのみです。それ以外の正規の内容はすべてそのまま維持します。ネイティブ登録アダプターは contracts/platform-compatibility.md に従います。
• 生成されたランタイムファイルに CANONICAL-TEMPLATE-SLOT コメントを残さないでください。これらのマーカーはソーステンプレートの保守専用です。
• 生成、スキップ、延期、プレースホルダーの入力、マーカーの削除、ネイティブアダプターに関するすべての判断を、agentic-system マニフェストに記録します。
• ファイルを書き込む前に、ファイル計画を作成して明示的な承認を待ちます。マスタープランは1つにまとめ、ユーザーがまとめて承認することを明示的に許可していない限り、書き込みバッチごとに承認を求めます。
• PLATFORM_TOOLS と宣言済みの呼び出しスロットを使って必須の基本操作を維持します。対象プラットフォームがサポートする場合は、委任エージェントのフロントマターも維持します。実際に発見されたもの、またはユーザーが承認したものと完全に一致する MCP ツールまたはプラットフォームツールのみ追加します。
• 生成される Markdown エージェントの tools: フロントマター項目は、すべて文字列にします。"{{APPROVED_MCP_TOOLS}}" を埋めるときは、完全に一致するツール名を引用符付き文字列として0個以上指定するか、追加で承認されたツールがない場合はプレースホルダー項目を削除します。
• contracts/context-boundaries.md を適用します。プロジェクトルートに knowledge/ を作成し、ランタイムリソースを1つのランタイムルート（デフォルトは .agentic-system/）にまとめ、インストール／保守用の資料を .agentic-system-maintenance/ または承認済みの専用トップレベルルートに分離し、通常のコンテキストから除外する項目を適用します。
• コンテキスト用語集とナレッジインデックスは分けて管理します。コンテキスト用語集には、リポジトリ内の安定したコード／ドメイン用語を記録します。ナレッジインデックスは、タスクごとに選択するナレッジを制御します。
• スキーマの適用は、生成されるランタイム契約で行います。拡張済みの Planner テンプレートには、ナレッジインデックスと計画スキーマのパス用スロットがすでに含まれています。Bootstrap は生成ファイル内でこれらのパスを埋め、検証する必要があります。Planner は本文に確認質問の形式も含んでいるため、生成ファイルでそれを繰り返してはいけません。
• ルート指示は簡潔で、案内に徹し、プロンプトに応じたものにします。templates/instructions/AGENTS.md から生成します。ルート指示では、必要に応じて生成済みエージェント、スキル、スキーマ、ナレッジインデックス、用語集、プロンプト固有の部分ファイルへ案内します。網羅的な情報の塊にしたり、あらゆるリクエストに対してエージェントの契約全体を重複して記載したりしてはいけません。
• 専門的なルールは、選択したプラットフォームで検証済みの指示読み込み方式を通じて宣言されたスコープを維持しながら、templates/instructions/*.instructions.md から生成されるモジュール式の指示ファイルに記載します。ルート指示を肥大化させてはいけません。
• CONTEXT.md がないという理由だけで作成してはいけません。安定したリポジトリ用語、情報源の境界、または曖昧な用語が確定した場合にのみ、用語集を作成または更新します。
• 保守の基準一式を欠いたまま、生成済みシステムを引き渡してはいけません。回答ファイル、未変更の .baseline/ コピー、マニフェストのカスタマイズ登録簿を必ず含めます。
• 今後の保守内容を明確にします。Bootstrap はマニフェスト、回答、ベースライン、変更履歴のスナップショット証跡を書き込み、Maintainer が後から契約の差分を分類できるようにします。ファイルを暗黙のうちに書き換えてはいけません。

Contract Files

このファイルはルーターです。現在のフェーズに対応するコントラクトを読み込み、最初にすべて読み込まないでください。

コントラクト	読み込むタイミング
contracts/source-model.md	テンプレートまたはレジストリを読む前の、すべてのフェーズ。ソースアセットと共通の語彙を定義します。
contracts/discovery-and-decisions.md	フェーズ A～C：受付、範囲を限定した調査、決定事項の記録。
contracts/platform-compatibility.md	選択した環境の調査、正式版の維持、ネイティブ登録、互換性の検証。Maintainer と共有します。
contracts/context-boundaries.md	プロジェクトのナレッジ、保守の分離、ガード付き調査、静的検証、レガシーレイアウトの移行。Maintainer と共有します。
contracts/generation.md	フェーズ D～E：提案、ファイル計画、コピー優先の生成、保守ベースラインの書き込み。
contracts/audit-and-handoff.md	フェーズ F～H：スキーマの適用、コントラクト監査、保守の引き継ぎ。

Bootstrap Phases

各フェーズを順番に実行します。各項目では、フェーズの目的と適用されるコントラクトを示します。

• フェーズ A、受付とスコープ：依頼がエージェントシステムに関する作業であることを確認し、対象リポジトリ、選択した環境、実行ホスト、言語、プレフィックス、リスク、および生成を希望するかどうかを記録します。contracts/discovery-and-decisions.md を参照してください。
• フェーズ B、範囲を限定した調査：読み取り専用の調査レーンを実行し、候補となるツールと統合のマトリックスを作成します。contracts/discovery-and-decisions.md を参照してください。
• フェーズ C、決定事項の記録：registry/placeholders.yaml と registry/capabilities.yaml に基づき、必須の決定事項をすべて一度に一つずつの質問で解決します。contracts/discovery-and-decisions.md を参照してください。
• フェーズ D、提案とファイル計画：提案、ファイル計画、バッチ承認のチェックポイントを作成します。デフォルトでは承認されていません。contracts/generation.md を参照してください。
• フェーズ E、コピー優先の生成：ミラーから承認済みのバッチを適用し、その後、回答ファイル、変更前のベースラインコピー、カスタマイズ登録簿を書き込みます。contracts/generation.md を参照してください。
• フェーズ F、実行時スキーマとナレッジの適用：生成された Planner がナレッジインデックスとプランスキーマのパスを引用し、独自の確認形式を維持していることを検証します。contracts/audit-and-handoff.md を参照してください。
• フェーズ G、コントラクト監査と検証：生成されたシステムのチェックリスト全体を実行し、必須要素の欠落をブロッキングとして扱います。contracts/audit-and-handoff.md を参照してください。
• フェーズ H、保守の引き継ぎ：エビデンス、パス、保留中の決定事項、リスク、ブートストラップ後の推奨事項を報告します。contracts/audit-and-handoff.md を参照してください。

Output Shape

書き込み前：提案と未承認のファイル計画を出力してから、明示的な承認を求めます。

書き込み後：変更したファイル、検証結果、Bootstrap コントラクトとの整合性、マニフェスト、回答、ベースライン、変更履歴のスナップショットのパス、ブートストラップ後の推奨事項、残るリスクを出力します。