cold-start

コールドスタート：Memory Bank + エージェントのブートストラップ（グリーンフィールドおよびブラウンフィールド）

概要

注記：cold-start は、すべてをまとめてブートストラップするためのパッケージスキルです。 生成されたプロジェクトコマンド /cold-start と混同しないでください。このコマンドは、対象リポジトリ内でスケルトンを作成した後に使用する、軽量なルーターです。 モジュールごとに使用する場合は、個別のスキルを推奨します：mb-init（スケルトン）、mb-analysis（任意のアイデア探索）、mb-from-prd（グリーンフィールド）、mb-map-codebase（ブラウンフィールド）、mb-review（レビュー）、mb-execute（実装）、mb-verify（UAT）、mb-red-verify（意味的な敵対的検証）。

• 実行内容： Memory Bank のスケルトンを作成し、エージェントのエントリーポイントを記述して、リポジトリを適切なワークフローに振り分けます。
• 使用する場面： PRD のある新規プロジェクト、または最初にマッピングが必要な既存のコードベースのいずれかに対して、単一のエントリーポイントを使用したい場合。
• 入力： リポジトリのルートと、prd.md／要件テキストまたは既存のコードベースのいずれか。
• 出力： .memory-bank/、.tasks/、.protocols/、エージェントのエントリーファイル、そしてグリーンフィールドまたはブラウンフィールド作業の次のステップ。

サポートされるシナリオ：

• アイデアのみ：リポジトリに未整理のアイデアはあるものの、まだ安定した PRD がない場合。必要に応じて /analysis、/brainstorm、/brief を経由します。
• 明確な構想：リポジトリにプロダクトブリーフを作成できるだけの方向性がある場合。通常は /brief を実行し、プロジェクトの原則がすでに ratified|partial でない場合に限り、その後 /constitution を実行してから /write-prd を実行します。
• グリーンフィールド：リポジトリに prd.md または要件テキストがあるものの、まだコードがない場合。
• ブラウンフィールド：リポジトリにすでにコードがあり、変更計画を立てる前に現状のまま文書化する必要がある場合。

---

必須原則

1) オーケストレーターとワーカー

• あなた（メインエージェント）はオーケストレーターです。 計画を立て、調整します。
• ワーカー（サブエージェント）が主要な作業を担います（多数のファイルのスキャン、長いレポートの作成）。
• 最大深度 = 2：オーケストレーター → サブエージェント。サブサブエージェントは禁止です。

2) .tasks/ はランタイムメモリ（Memory Bank ではありません）

• エージェントの各プロセスには、一意のタスクフォルダー .tasks/TASK-XXX/ が割り当てられます。
• サブエージェントはそこに詳細な出力を書き込み、オーケストレーターには短い要約のみを返します。

3) 設計によって競合を回避

• 作業を重複しないファイルセットに分割します。
• 重複を避けられない場合は、エージェントごとに Git ブランチまたはワークツリーを使用し、後でマージします。

4) 並列実行の上限

• 最大 5～7 個のサブエージェントを並列で実行します。
• ランタイムが複数ツールの呼び出しに対応している場合は、1 回のオーケストレーターターンでサブエージェントを並列起動します。

5) ドキュメントを優先

意味のある作業単位を完了するたびに：

1. コンテキストが新しいうちに Memory Bank を更新します。
2. その後、コードを変更／コミットします。

---

必ず作成・維持する出力

リポジトリのルート

• AGENTS.md（正規のファイル。簡潔に、約 100 行）
• CLAUDE.md → AGENTS.md へのシンボリックリンク（またはコピー）
• (任意) GEMINI.md → AGENTS.md へのシンボリックリンク（またはコピー）

リポジトリのフォルダー

• .memory-bank/ — 永続的なナレッジベース
• .tasks/ — 運用上のランタイムメモリ
• .protocols/ — ファイルベースのプロトコル（計画／意思決定ログ／再開）

ステップ 0 — 環境を検出する（推測しない）

1. 利用可能なツールを確認します：

   • Codex は利用できますか？（Codex CLI / MCP ツール）
   • Claude Code は利用できますか？（CLI claude、サブエージェント）
   • ブラウザーツールは利用できますか？（Playwright / agent-browser / CDP MCP）

2. 主なエンジンを決定します：

   • Codex 内で作業している場合：実装とレビューには gpt-5.2-high を使用します（重要なレビューでは、新しいセッションを優先します）。
   • Claude Code 内で作業している場合：分析にはサブエージェントを使用し、統合には Opus を使用します。必要に応じて、別の意見や構造化レビューを得るため、シェルから Codex を呼び出します。
   • Codex と Claude の両方を利用できる場合（デュアルエンジン）：広範なコンテキストのスキャンと統合には Claude を、構造化レビューと実装には Codex を使用します。重要な出力（MB コンプライアンス、アーキテクチャ）は、もう一方のエンジンでレビュー手順を実行して相互検証します。ハイブリッドワークフローについては、ステップ 4 を参照してください。

UI から Codex のモデル選択を制御できない場合は、プロジェクトの .codex/config.toml プロファイルセットを作成してください（ステップ 1.5 を参照）。

---

ステップ 1 — 骨組みをセットアップする

1.1 ディレクトリを作成する

存在しない場合は、次を作成します：

• .memory-bank/

  • mbb/
  • architecture/
  • guides/
  • adrs/
  • tech-specs/
  • domains/ (任意ですが、推奨)
  • contracts/ (任意ですが、推奨)
  • states/ (任意ですが、推奨)
  • runbooks/ (任意ですが、推奨)
  • workflows/ (任意。すでに使用している場合は wfs/ のままでもかまいません)
  • quality/ (任意ですが、推奨)
  • testing/
  • skills/
  • epics/
  • features/
  • schemas/ (タスクレコードを含む JSON スキーマ)
  • tasks/ (/prd-to-tasks を実行するまで空の JSON タスクインデックス。インデックス化されたタスクレコードと計画を格納します)
  • commands/ (人間／エージェントが使用するスラッシュコマンドの仕様)
  • agents/ (サブエージェントのプロンプトライブラリ)
  • archive/
  • bugs/

• .tasks/

• .protocols/

1.2 コアファイルを作成する（テンプレートを使用）

次のテンプレートを使用します：

• ./references/shared-structure-template.md

最低限、次を作成する必要があります：

• AGENTS.md
• CLAUDE.md シンボリックリンク／コピー
• .memory-bank/index.md
• .memory-bank/constitution.md
• .memory-bank/mbb/index.md
• .memory-bank/spec-index.md
• .memory-bank/glossary.md
• .memory-bank/invariants.md
• .memory-bank/product.md
• .memory-bank/requirements.md
• .memory-bank/schemas/task.schema.json
• .memory-bank/tasks/index.json
• .memory-bank/testing/index.md

また、.memory-bank/commands/ 以下にコマンド仕様を作成します（references/commands/* を使用）。 パッケージ内にコマンド仕様がある場合は、任意の分析コマンド（analysis.md、brainstorm.md、brief.md）も含めます。 また、.memory-bank/constitution.md を作成または更新する /constitution コマンド用に、constitution.md も含めます。

1.2.1 ネイティブスキルを作成する（プロキシコマンド）

各ランタイムでコマンドをネイティブに使えるよう、薄いプロキシスキルを作成します：

• .claude/skills/<name>/SKILL.md → Claude Code + OpenCode
• .agents/skills/<name>/SKILL.md → Codex CLI + OpenCode

各プロキシには、次の内容だけを記述します：.memory-bank/commands/<name>.md の指示を読み、それに従ってください。 これにより、3 つすべてのツールでコマンド（/mb、/constitution、/prd、/execute など）をネイティブに利用できるようになります。

init-mb.js スクリプトが、両方のセットを自動的に作成します。

エージェントはプライミングの早い段階で .memory-bank/constitution.md を読み込みます。これはプロジェクトの意思決定を司る短い原則レイヤーであり、.memory-bank/invariants.md、.memory-bank/contracts/*、.memory-bank/spec-index.md、またはティア／ワークフローポリシーの代替ではありません。

1.3 フロントマターのルールを徹底する

.memory-bank/ 内のすべての Markdown ファイルには、少なくとも次の項目を含む YAML フロントマターが必要です：

• description: ...
• status: draft|active|deprecated|archived

1.4 .tasks/ プロトコルを作成する

今回の実行用のタスクフォルダーを作成します（新しい ID を選びます）：

• .tasks/TASK-MB-INIT/

その中に、次を作成します：

• TASK-MB-INIT-S-00-orchestrator-plan.md — 実施内容と使用するサブエージェント

1.5 任意：Codex プロファイルのプリセット

Codex を使用する場合は、プロファイルを設定した .codex/config.toml を作成します。

• default：coding（gpt-5.2、high）
• プロファイル deep-review：review（gpt-5.2、xhigh）

（リポジトリを共有している場合は、ローカルに保持するか、.memory-bank/runbooks/ に記載することを検討してください。）

---

ステップ 2 — シナリオを選択する

判断基準

• リポジトリに十分な量のコード（src/、package.json、go.mod、Cargo.toml など）がある場合 → Brownfield（ステップ 3B）。
• リポジトリがほぼ空で、prd.md がある場合 → Greenfield（ステップ 3A）。プロジェクトの原則が未承認または一部承認の場合は、/write-prd の前に /constitution を推奨します。
• リポジトリがほぼ空で、アイデアまたは大まかなコンセプトしかない場合 → 必要に応じて、まず Analysis を実行します。アイデアがまだ曖昧な場合は /analysis、/brainstorm を実行し、続いて /brief を実行します。その後、プロジェクトの原則がすでに ratified|partial でない場合に限り、/write-prd の前に /constitution を実行します。
• 両方がある場合：Brownfield + PRD 差分 として扱います（ステップ 3B）。
• リポジトリが空、または新規で、prd.md がない場合 → Skeleton-only（ステップ 3C）。

シナリオを次のファイルに記録します。

• .tasks/TASK-MB-INIT/TASK-MB-INIT-S-00-orchestrator-plan.md

---

ステップ 3A — Greenfield ワークフロー（PRD → Memory Bank）

3A.1 明確化した PRD を作成する

• プロジェクトの原則がまだフレームワークのデフォルト、スキップ済み、または未設定の場合は、/write-prd の前に /constitution を実行します。すでに承認済み、または一部承認済みの場合は、直接 /write-prd に進みます。/constitution は .memory-bank/analysis/product-brief.md があれば読み込み、各パスで最大 5 件の文脈に応じたガバナンスに関する質問をします。
• ユーザーが /constitution を明示的にスキップする場合は、原則をフレームワークのデフォルト／スキップ済みのままにして続行し、後から承認できることを記録します。
• /write-prd を実行して、Product Brief／PRD のテキストと Constitution から .memory-bank/prd.md を作成します。
• /write-prd は、PRD レベルの曖昧さを解消するため、各パスで最大 5 件の的を絞った質問をします。
• PRD に「スキル／ツール／CLI を使用する」と記載されている場合は、まず /find-skills を実行します（プロジェクトにインストール済み → マーケットプレイス）。

ユーザーが一時的に対応できない場合（「запуск и ушёл」）：

• .protocols/PRD-BOOTSTRAP/decision-log.md に Open questions を記録します。
• 停止して待機します（事実をでっち上げないでください。回答を得る前に EP／FT／タスクの生成へ進まないでください）。

ユーザーが 自律モード を明示的に希望する場合：

• ブロック要因にならない不足情報を Assumptions として記録します。
• ブロック要因（セキュリティ／コンプライアンス／外部契約／データ損失のリスク）がある場合にのみ停止します。
• /write-prd が完了したら /autonomous で続行します。

3A.2 PRD を L1–L3 に振り分ける

/spec-init を実行し、PRD／brief／既存の仕様書の根拠に基づく軽量な SDD ルートマップとして .memory-bank/spec-index.md を更新します。アーキテクチャの聞き取りや、権威ある仕様の捏造は行いません。 次に /prd を実行して、.memory-bank/prd.md をプロダクト、要件、エピック、機能、テストに分解し、インデックスを更新します。 /prd の後は、必ず /spec-design を実行します。独立性の高い小規模な T0／T1 機能では、関連しない領域を not_applicable とした最小限のバックボーンを記録できます。共有範囲に関わる T2／T3 の懸念事項では、必要なバックボーン SDD 仕様と spec-index を作成または更新します。これは、必須の重いフェーズを追加するものではありません。タスクや、機能ごとの実装設計は作成しません。/spec-improve FT-<NNN> は、バックボーンの後に引き続き機能レベルのゲートとして実行します。

/prd が管理するもの：

• .memory-bank/product.md
• REQ-ID
• REQ → Epic → Feature → Test の対応関係を示す RTM テーブル
• .memory-bank/epics/EP-*.md
• .memory-bank/features/FT-*.md

生成する各機能には、必ず次の内容を含めます。

• ユースケース
• 受け入れ基準
• 失敗モード／エッジケース
• テスト戦略の指針

ステータスポリシー：

• Open questions が解決するまでは、EP／FT のフロントマターの status はデフォルトで draft にします。
• 受け入れ基準と検証計画が安定した場合に限り、status: active に変更します。
• /prd／mb-from-prd はタスクを作成しません。標準的な計画経路は /write-prd → /spec-init → /prd → /spec-design → /spec-improve FT-<NNN> → /prd-to-tasks FT-<NNN> です。
• 機能レベルのブロック要因が明示されている場合に限り、機能に clarification_status: pending|blocked を追加します。

3A.3 タスク計画（機能ごとに実施し、「一度にすべて」は行わない）

すべての機能のタスクキューを一度に生成しないでください。

代わりに、次の手順に従います。

1. .memory-bank/schemas/task.schema.json と .memory-bank/tasks/index.json が存在することを確認します。
2. 選択した機能ごとに、明示的に保留中またはブロック中の場合に限り、/clarify-feature FT-<NNN> を使用します。
3. /prd の後に /spec-design を実行します。単純な T0/T1 の範囲には最小限のバックボーンを使用し、共有の懸念事項や T2/T3 の懸念事項には、より充実したバックボーン仕様を使用します。
4. /spec-improve FT-<NNN> を実行してから、/prd-to-tasks FT-<NNN> を実行し、次のものを生成します。
   • .memory-bank/tasks/plans/IMPL-FT-<NNN>.md
   • wave ごとにグループ化されたアトミックな .memory-bank/tasks/TASK-*.task.json レコード。それぞれに必須の tier: T0|T1|T2|T3 を含めます。

タスクの振り分けは task.tier のみに基づきます。従来の risk / risk.level モデルは無効です。

3A.4 主要な概念を特定し、補助ドキュメントを作成する

重要な概念ごとに、後から簡単に読み直せるよう、補助ドキュメントを作成します。

• デフォルト／互換性パス：
  • .memory-bank/architecture/<concept>.md（WHAT/WHY）
  • .memory-bank/guides/<concept>.md（HOW）
• 信頼できる情報源を明確にする場合は、仕様主導の補助ドキュメントを追加します。
  • .memory-bank/tech-specs/...
  • .memory-bank/contracts/...
  • .memory-bank/domains/...
  • .memory-bank/states/...
  • .memory-bank/adrs/...
  • .memory-bank/runbooks/...
  • .memory-bank/testing/...

ルール：

• 従来の二部構成のドキュメントも引き続き有効で、役に立ちます
• 仕様主導のドキュメントは追加するものであり、デフォルトでは置き換えるものではありません
• 新しい仕様を作成する前に、.memory-bank/spec-index.md で既存の仕様を確認してください
• より詳細なドキュメントがある場合は、.memory-bank/spec-index.md と関連する概念ドキュメントから参照できるようにします

3A.5 インデックスを更新する

作成したすべてのドキュメントへの注釈付きリンクを .memory-bank/index.md に追加します。

---

ステップ 3B — ブラウンフィールドのワークフロー（リポジトリ → Memory Bank）

3B.1 リポジトリをスキャンするサブエージェントを並列で起動する

新しいタスクフォルダーを作成します。

• .tasks/TASK-MB-MAP/

スコープが重複しないように、最大 5 つのサブエージェントを並列で起動します。

1. S-01：ビルド／ツール（パッケージマネージャー、スクリプト、CI）
2. S-02：バックエンド／サービス
3. S-03：フロントエンド／UI
4. S-04：データレイヤー（DB、マイグレーション、スキーマ）
5. S-05：テスト＋品質ゲート

各サブエージェントは必ず次を行います。

• 対象のファイル glob が存在することを確認します（「スマートコーリング」）
• 次の命名規則で、詳細なレポートを .tasks/TASK-MB-MAP/ に書き込みます。 TASK-MB-MAP-S-0X-final-report-<code|docs>-YY.md
• 5～10 行の要約とファイル一覧を返します

ベースラインのプロンプトとして ./agents/shared-repo-scanner.md を使用し、スコープを絞ってください。

3B.2 レポートから Memory Bank を統合する

.tasks/TASK-MB-MAP/ のレポートを使用して、次を作成します。

• .memory-bank/product.md — 現在のシステムの内容
• .memory-bank/architecture/ — C4 L1～L3 の概要＋主要な不変条件
• .memory-bank/spec-index.md / .memory-bank/invariants.md / .memory-bank/glossary.md — 明示的な規範的ルーティングを裏付ける証拠がある場合
• .memory-bank/runbooks/ — セットアップ、開発、テスト、デプロイ
• .memory-bank/contracts/ — API／イベントの契約
• .memory-bank/states/ — コードやワークフローから明らかなライフサイクル／状態のルール
• .memory-bank/testing/index.md — 標準のゲート＋検証メモ
• .memory-bank/index.md — 注釈付きリンク

PRD がない場合のルール（必須）：prd.md が存在しない場合、次のものを作成または記入してはなりません。

• .memory-bank/epics/*
• .memory-bank/features/*
• ロードマップ上の実タスクを含む .memory-bank/tasks/*.task.json

ブートストラップによって作成された空のスケルトンファイル／フォルダーは許可されます。

リポジトリのマッピングは、ロードマップの計画ではなく、現状のドキュメント化です。コード／ログ／テストから導き出せない内容は、仮説または未解決の質問として記録してください。

3B.3 PRDの差分をユーザーに依頼する

ベースライン MB の作成後：

• 変更・追加する内容を記述した prd.md をユーザーに依頼します
• プロジェクトの原則が未承認または一部のみ承認されている場合に限り、まず /constitution を実行します。その後、既存のベースラインを対象に、/write-prd、/spec-init、/prd、/spec-design、/spec-improve FT-<NNN>、/prd-to-tasks FT-<NNN> の形式で分解を行います

---

Step 3C — スケルトンのみのワークフロー（PRD なし、コードなし）

リポジトリが新規または空で、prd.md がない場合：

3C.1 スケルトンのみを作成する

通常どおり Step 1 を実行します。すべてのディレクトリ、テンプレートからのコアファイル、AGENTS.md、CLAUDE.md シンボリックリンクを作成します。

スケルトンは、すぐに内容を追加できる構成を提供します。product.md、requirements.md、tasks/index.json などは、ドラフトのひな形／プレースホルダーのままです。 PRD がないモードでは、tasks/index.json は { "version": 1, "tasks": [] } にし、TASK-001.task.json やその他の実行可能なタスクレコードは生成しません。

3C.2 PRDを依頼する

スケルトンの作成後、PRD の提供をユーザーに依頼します：

"Memory Bank のスケルトンを作成しました。プロダクトの詳細、エピック、機能、SDD 設計、タスクレコードを追加するには、prd.md ファイルを提供してください（または要件テキストを貼り付けてください）。今すぐでも後からでも実行できます。プロジェクトの原則がすでに ratified|partial でない場合に限り、まず /constitution を実行し、その後 /write-prd、/spec-init、/prd、/spec-design、/spec-improve FT-<NNN>、/prd-to-tasks FT-<NNN> を実行してください。"

3C.3 待機または続行する

• ユーザーが今すぐ PRD を提供する場合 → Step 3A（グリーンフィールドワークフロー）に進みます。
• ユーザーが後回しにする場合 → ここで停止します。スケルトンは有効で、そのまま使用できます。後で $mb-from-prd または /prd を呼び出すと、Memory Bank に内容を追加できます。
• ユーザーが部分的な情報を提供する場合 → /brief に渡し、プロジェクトの原則がすでに ratified|partial でない場合に限り /constitution を実行してから、/write-prd を実行します。PRD レベルのブロッカーが残っている場合は停止します。

注：スケルトンのみの状態は、有効な停止地点です。AGENTS.md + .memory-bank/index.md + MBB ルールがあれば、エージェントはリポジトリの調査を開始できます。

---

Step 4 — ハイブリッドモード（Claude ↔ Codex）

Claude Code を使用していて、Codex の品質または長期的な自律性が必要な場合：

1. Claude のサブエージェントを使って、スキャンレポートを .tasks/TASK-MB-MAP/ に生成します。
2. シェル経由で Codex を呼び出し、Memory Bank を統合します：

codex exec --ephemeral --full-auto -m gpt-5.2-high \
  'Read .tasks/TASK-MB-MAP and build/refresh .memory-bank per MBB. Keep AGENTS.md short. Produce a summary and run a self-review.'

3. 次に、5人の専門家によるレビューを行うため、Codex の詳細レビュープロファイル（または新しい Claude セッション）を実行します。

---

Step 5 — 複数の専門家によるレビューループ（新しいコンテキスト）

新しいコンテキストでレビュー担当者を実行します（ライターのコンテキストを再利用しないでください）。

• アーキテクト（C4 + 依存関係）
• スコープアナリスト（REQ → Epic → Feature → Task の網羅性）
• MBB コンプライアンスレビュアー（フロントマター、リンク、アトミック性、デュオ）
• 計画レビュアー（タスクレコードの品質、ウェーブ、ゲート）
• セキュリティレビュアー（認証、機密データ、OWASP リスク）
• コード品質レビュアー（条件付き：コードがある場合 — 品質ゲート、規約、ホットスポット）

./agents/shared-review-*.md と ./agents/shared-mb-reviewer.md のプロンプトを使用します。

ルール：

• いずれかのレビュアーが REJECT を返した場合 → MB を修正し、レビューを繰り返します。
• レビュアーのレポートを .tasks/TASK-MB-REVIEW/ に保存します。

---

ステップ 6 — タスクの実行を開始する

レビューゲートに合格した後（APPROVE）：

1. .memory-bank/tasks/index.json と、そこにインデックスされている .task.json レコードから、優先度が最も高い実行可能なタスクを選びます。インデックスが空の場合は、停止して /spec-design を実行し、選択した機能に対して /spec-improve FT-<NNN> と /prd-to-tasks FT-<NNN> を実行します。 その機能が明示的に保留中またはブロックされている場合に限り、先に /clarify-feature FT-<NNN> を実行します。
2. タスクに対して mb-execute を実行します（計画 → 実装 → 品質ゲート → MB-SYNC）。
3. task.tier に応じて振り分けます。T0／T1 では run.md の簡易検証を使用できます。T2／T3 では mb-verify と mb-red-verify が必要です。
4. T3 では、終了前に人間が関与するチェックポイントと、ロールバック／復旧に関する注記が必要です。
5. ウェーブが完了するまで、またはユーザーが停止するまで繰り返します。

意図したモードが無人のエンドツーエンド実行の場合：

• ここで手動ループを続けないでください
• 生成されたプロジェクトコマンド /autonomous に切り替えてください

mb-execute、mb-verify、または mb-red-verify がインストールされていない場合は、それぞれの SKILL.md に従って手動で実行してください。

---

完了の定義

以下を満たしたら完了です。

• AGENTS.md が存在し、簡潔で、.memory-bank/index.md を参照している。
• CLAUDE.md が AGENTS.md のシンボリックリンクまたはコピーである。
• .memory-bank/ に最低限、index + MBB + product + testing が含まれている（PRD ができるまで requirements はスタブのままでもかまいません）。
• .memory-bank/constitution.md が存在し、統治原則の更新に /constitution を利用できる。
• .tasks/ に、命名規則とステージ ID を含むスキャン／レビュー成果物がある。
• Greenfield：PRD からエピック／機能／タスクのレコードが作成されている。
• Brownfield：リポジトリが現状のまま MB にマッピングされ、PRD にないロードマップ項目を創作せずに、PRD の差分をユーザーに確認している。
• Skeleton-only：スケルトンが作成され、ユーザーに PRD を依頼している（有効な停止地点です）。
• 複数の専門家によるレビューに合格している（APPROVE）— Greenfield／Brownfield の場合。Skeleton-only では省略します。
• 実行ループを利用できる（mb-execute + mb-verify が利用可能または文書化されており、T2／T3 タスクでは mb-red-verify も利用可能）。
• 自律ループを利用できる（/autonomous + /autopilot が文書化されている）。

---

このスキルの参考資料

• ./references/shared-structure-template.md
• ./agents/shared-repo-scanner.md
• ./agents/shared-mb-reviewer.md
• ./agents/shared-review-architect.md
• ./agents/shared-review-scope.md
• ./agents/shared-review-code.md
• ./agents/shared-review-plan.md
• ./agents/shared-review-security.md
• ./scripts/shared-init-mb.js（任意のヘルパー）