bmad

BMAD パケット優先ルーター

bmad を共通レイヤーの BMAD/BMM の入り口として使用します。

目的は、すべてのフェーズコマンドやランタイムのセットアップ規則を列挙することではありません。 目的は次のとおりです。

1. ユーザーがすでに持っているパケットを特定する
2. プロジェクトのレベルと、現在のフェーズとして考えられるものを選ぶ
3. 今の曖昧さを減らせる、次に作成する単一の成果物またはゲートを推奨する
4. ランタイム、レビュー、実行、ゲーム固有の詳細は外部へ振り分ける

最も手早くルーティングするには、まず references/intake-packets-and-route-outs.md を読んでください。さらに詳しい情報が必要な場合は、references/core-routing.md、references/status-and-review.md、references/runtime-and-module-boundaries.md を使用してください。

このスキルを使用する場面

• ユーザーが、複数の状態が混在するプロジェクトから BMAD/BMM スタイルのワークフローを開始、または再開したい場合
• アイデアメモ、PRD、技術仕様書、アーキテクチャ作業、または部分的な実装の後に、次のフェーズを尋ねられた場合
• 既存のリポジトリ、イシュー、レビューのメモ、またはブラウンフィールドの状況があり、次の成果物を実情に即して選ぶ必要がある場合
• Claude、Codex、Gemini 固有のランタイムオーバーレイに移る前に、ベンダーに依存しない BMAD の入り口を求めている場合
• 次の手順が、アイデア出し、計画、アーキテクチャ、承認、実行タスクの分割、ランタイムへの引き継ぎのどれにあたるか判断する必要がある場合

このスキルを使用しない場面

• プロジェクトの枠組みがまだできておらず、主なニーズが自由なコンセプト形成である場合 → bmad-idea を使用
• 主なニーズがゲーム制作パケット（GDD、プレイテストのメモ、ビルドのイシュー、ローンチ計画）である場合 → bmad-gds を使用
• 主なニーズが成果物の承認、注釈付け、または計画のレビューである場合 → plannotator を使用
• 次の成果物がすでに決まっており、主なニーズが実行可能なバックログへのタスク分割である場合 → task-planning を使用
• 主なニーズが Claude Code 向けのランタイム固有のオーケストレーション設定である場合 → oh-my-claudecode を使用
• 主なニーズが Codex を優先するワークフローのランタイム動作である場合 → oh-my-codex を使用
• 主なニーズが Gemini / Antigravity に対応するポータブルなハーネスの設定である場合 → oh-my-agent を使用

手順

ステップ 1：受付内容を1つの主要パケットに整理する

フェーズについて話す前に、現在の依頼を表す最適な単一のパケットを選びます。

bmad_packet:
  packet_type:
    - concept-packet
    - planning-packet
    - architecture-packet
    - review-gate-packet
    - execution-packet
    - runtime-handoff-packet
    - brownfield-resume-packet
  evidence_in_hand:
    - idea-notes
    - product-brief
    - prd
    - tech-spec
    - architecture-draft
    - review-feedback
    - active-repo
    - issue-or-bug-link
    - sprint-plan
    - milestone-or-launch-pressure
  project_type: web-app | backend-api | mobile-app | game | library | automation | unknown
  project_level: 0 | 1 | 2 | 3 | 4 | unknown
  runtime_context: claude | codex | gemini | opencode | mixed | unknown
  main_constraint: ambiguity | review-blocker | execution-readiness | runtime-setup | brownfield-drift | unknown

ルール：

• ユーザーが複数の成果物に言及していても、まず主要なパケットを1つ選びます。
• パケットが明らかに計画前の段階にある場合は、その旨を伝え、早い段階で bmad-idea に振り分けます。
• パケットの大半がゲーム制作の調整に関する場合は、早い段階で bmad-gds に振り分けます。
• 既存のリポジトリ、イシュー、または部分的な実装から始める依頼では、プロジェクトをグリーンフィールドと見なすのではなく、brownfield-resume-packet を優先します。

ステップ 2：成果物の詳細度より先にプロジェクトのレベルを選ぶ

次の基準を使用します。

• レベル 0 — 単一の不可分な変更、バグ修正、設定の微調整
• レベル 1 — 小規模な機能、対象ファイルが限定的、調整コストが低い
• レベル 2 — 中規模の機能群、複数領域にまたがる動作、計画とアーキテクチャが明確に必要
• レベル 3 — 複雑な統合、複数のサブシステム、API／データ契約、複数スプリントにわたる開発
• レベル 4 — 大規模な刷新、プラットフォーム移行、エンタープライズ規模の調整

目の前のパケットから明らかに必要と判断できる場合を除き、レベル 0～1 の作業にアーキテクチャや大掛かりな計画を無理に適用しないでください。

ステップ 3：パケットから現在のフェーズを推測する

逆ではなく、パケットを使って現在の BMAD フェーズを推測します。

パケットの種類	想定されるフェーズ	デフォルトの次の成果物またはゲート
concept-packet	分析	product-brief、または bmad-idea へのルーティング
planning-packet	計画	prd または tech-spec
architecture-packet	ソリューション設計	architecture または architecture review gate
review-gate-packet	フェーズ間の境界	次へ進む前に plannotator でレビュー
execution-packet	実装	sprint-plan、story packet、または task-planning へのルーティング
runtime-handoff-packet	実装準備完了	oh-my-claudecode、oh-my-codex、または oh-my-agent へのランタイム引き継ぎ
brownfield-resume-packet	混在／不明	workflow-status の更新、リポジトリの状態の要約、その後、事実に即した最小の成果物

指針：

• 事実に即した最小の次の成果物を優先します。
• 成果物がすでに存在していてもレビューされていない場合、次のステップは新たな文書の作成ではなく、レビューゲートであることがよくあります。
• 依頼の実態がランタイム／セットアップに関するものであれば、bmad は簡潔にし、外部へルーティングします。

ステップ 4：並行する成果物群ではなく、次の成果物を 1 つ選ぶ

現在の曖昧さを最も解消できる、次の成果物またはゲートを 1 つだけ選びます。

現在の状態	推奨される次のステップ
漠然としたアイデア、機会、ユーザーの課題	product-brief
要件が固まりつつあるが、実装の形はまだ不明確	prd または tech-spec
計画はあるが、システムの形がまだ曖昧	architecture
アーキテクチャはあるが、承認が得られていない	review gate
承認済みのアーキテクチャがあり、実行単位への分割が不十分	sprint-plan または story packet
実装が進行中だが、状況が不明確	workflow-status の更新と次のストーリーの推奨
承認後、ランタイムが実際のボトルネック	oh-my-claudecode／oh-my-codex／oh-my-agent へのランタイム引き継ぎ

ステップ 5：専門作業を明確にルーティングする

最初の振り分けが決まったら、残りを明確にルーティングします。

• bmad-idea → 正式な BMAD 成果物の作成前に行う、計画前のコンセプト整理
• plannotator → PRD、アーキテクチャ、スプリント計画、計画の差分に対するレビュー／承認ゲート
• task-planning → 次の成果物が承認済み、または明らかな場合に行う、実行可能な単位への分割
• oh-my-claudecode → Claude を優先するランタイムオーケストレーション、フック、チームモード、停止コールバック
• oh-my-codex → Codex を優先するオーケストレーション、AGENTS.md の注入、ワークフロースキル、tmux チームランタイム
• oh-my-agent → Gemini／Antigravity のポータブルハーネス、.agents/ を信頼できる唯一の情報源とする構成、生成されたランタイムビュー
• bmad-gds → ゲーム固有の制作ルーティング

ルートアウトする理由を簡潔に記載します。隣接するスキル名を挙げるだけでは不十分です。

ステップ 6：状態とレビューを可視化する

プロジェクトがすでに BMAD の状態ファイルやヘルパースクリプトを使用している場合は、それらを引き続き活用します。

• フェーズを飛び越える提案をする前に、ステータス／設定の成果物を確認する
• 必須の成果物が存在していて承認されていない場合は、plannotator にルーティングする
• ワークフローを最初から再構築するより、スクリプト／ステータスを把握したうえで判断する
• プロジェクトがまだアイデア段階であるかのように装わず、ブラウンフィールドの証拠を正直に活用する

ステップ 7：簡潔な BMAD ルーティング概要を作成する

必ず次の構成で返します。

# BMAD Routing Brief

## Scope
- Packet type: ...
- Project type: ...
- Project level: 0 | 1 | 2 | 3 | 4
- Runtime context: ...
- Confidence: high | medium | low

## Current phase
- analysis | planning | solutioning | implementation | mixed | unknown
- Why: ...

## Recommended next move
- product-brief | prd | tech-spec | architecture | review gate | sprint-plan | story packet | workflow-status update | runtime handoff

## Why this is next
- 2-4 bullets grounded in the packet

## Route-outs
- Skill / module: ...
- Why: ...
- What to pass forward: ...

## What not to do yet
- 1-3 bullets preventing premature detail or the wrong lane

ステップ 8：詳細はリファレンスに委ねる

ヘルパースクリプト、コマンド群、ランタイムルールをすべて盛り込み、メインの回答を膨らませないでください。必要に応じてリファレンスを使用します。

• インテークパケットとルートアウト
• コアルーティングモデル
• ステータスファイル、スクリプト、レビューゲート
• ランタイムとモジュールの境界

出力形式

短い BMAD ルーティング概要を返します。

必須要件：

• 次の成果物を選ぶ前に、主要なパケットを1つ選びます
• プロジェクトレベルの前提を明示します
• フェーズを進める前に、レビューゲートを明確にします
• ランタイム／セットアップの詳細は、共通 BMAD レイヤーから分離します
• ユーザーが完全なワークフローパケットを求めていない限り、おおむね400～700語未満に収めます

例

例1：ブラウンフィールドのリポジトリで、次のステップが不明

入力

bmad を使ってください。すでにリポジトリと製品メモはありますが、計画がずれてしまい、PRD、アーキテクチャ、またはスプリント計画だけでよいのか分かりません。

出力例

• パケットタイプ：brownfield-resume-packet
• 推定フェーズ：mixed
• 推奨する次のステップ：workflow-status を更新し、次に実際に不足している成果物を特定します
• ルート先への振り分けは、不足している成果物の特定後にのみ行います

例2：アーキテクチャはあるが、実行が不十分

入力

API 移行のアーキテクチャ文書はすでに作成しました。BMAD では次に何をすればよいですか？

出力例

• パケットタイプ：architecture-packet
• 現在のフェーズ：solutioning
• 推奨する次のステップ：アーキテクチャが未レビューならreview gate、レビュー済みならsprint-plan
• ルート先：最初にplannotator、次にtask-planning

例3：ランタイム固有のフォローアップ

入力

Codex CLI で BMAD を使いたいです。実際には何を使えばよいですか？

出力例

• bmad はパケット／フェーズのルーターとして維持します
• パケットタイプ：runtime-handoff-packet
• Codex のランタイム固有の内容はoh-my-codexに振り分けます
• bmadを Codex のセットアップガイドにしないでください

ベストプラクティス

1. パケット優先のルーターとして動作する — ユーザーがすでに持っている成果物や証拠から始めます。
2. 詳細より先にレベルを選ぶ — レベル0～1とレベル2～4で、同じ書類を作成しないようにします。
3. レビューを明確にする — 承認がボトルネックなら、新しい成果物を作り出す前にその点を示します。
4. ランタイムのオーバーレイを分離する — ベンダー／ランタイム固有の内容はoh-my-claudecode、oh-my-codex、oh-my-agentが担当します。
5. 明確な引き継ぎを1つに絞る — 次のステップを1つ、ルート先を1～2個示すほうが、膨大なワークフローを提示するより効果的です。
6. 詳細にはリファレンスを使う — ヘルパースクリプト、ステータスのルール、ランタイムの境界はサポート文書に記載します。

参考資料

• インテークパケットとルート先への振り分け
• コアのルーティングモデル
• ステータスファイル、スクリプト、レビューゲート
• ランタイムとモジュールの境界
• ./scripts/init-project.sh
• ./scripts/check-status.sh
• ./scripts/phase-gate-review.sh
• 上流 BMAD README
• ../bmad-idea/SKILL.md
• ../plannotator/SKILL.md
• ../task-planning/SKILL.md
• ../bmad-gds/SKILL.md