bmad

BMad：意図からデリバリーまでの制御プレーンプロトコル

BMad は、ソフトウェアデリバリーの手法です。その根底にある考え方は、人間の意図を段階的に明確化し、記録し、レビューしたうえで、チャットで即興的に扱うのではなく、永続的なコンテキストとしてエージェントに引き継ぐことです。このスキルはその手法を、どのエージェントハーネスでも実行できるプロトコルにします。公式の BMad インストーラーは必要ありません。

一連の流れ：リクエストを分類 → 意図を圧縮して契約にまとめる → 最小限で安全な経路にルーティング → 範囲を限定した単位を実装 → トリアージとしてレビュー → 失敗を曖昧さが入り込んだレイヤーにルーティング → 観測可能な受け入れ条件に基づいて自律性を制御 → 完了した作業から学習します。

このスキルを使う場面

変更リクエスト、機能追加、バグ報告、委任されたビルド、または複数エージェントによる大規模な取り組みで、次のことが必要な場合に読み込みます。

• 実装前に意図を把握すること。雰囲気ではなく、契約として明確にします。
• 作業にどの程度の手続きを適用するか判断すること。
• セッションやエージェントをまたいで作業を再開できるよう、永続的な成果物を用意すること。
• ノイズを列挙するのではなく、指摘事項をトリアージするレビューを行うこと。
• 境界が安全でない場合に自律性を安全に停止すること。

作業の分類（最小限で安全な経路）

分類	特徴	プロセス
直接対応	目標が明確、変更範囲が局所的、確立されたパターンがあり、影響範囲が小さい	最小限の確認後、すぐに実装
範囲限定	簡潔な契約と計画が必要な、一貫性のある変更	意図の契約 → 計画 → 実装 → レビュー
イニシアチブ	コンポーネント横断、複数ストーリー、高リスク、または戦略上の不確実性がある	分析 → 計画 → ソリューション設計 → 実装 → 学習

判断表、質問を一つに絞るルール、停止条件については、references/classification.md を読み込みます。

意図の契約（5つの項目）

範囲限定またはイニシアチブの作業では、実装前に契約を定めます。

1. 理由 — 目指す成果と、それが重要な理由。
2. 能力 — システムが何を実行できる必要があるか。
3. 制約 — 技術、運用、法務、セキュリティ、プライバシー、時間、コスト、組織上の境界。
4. 対象外 — 明確に対象範囲外とする事項。
5. 成功の指標 — 結果が機能し、受け入れ可能であることをどう確認するか。

項目に重大な曖昧さがある場合は、影響の大きい質問を一つだけ行い、推奨する回答を提示して、判断を待ちます。些細な変更では、契約を会話内の箇条書き5項目で示せます。より大規模な作業では、バージョン管理された仕様ファイルにします。

SPEC の作成方法とステータスの用語については、references/spec.md を読み込みます。テンプレート：templates/SPEC.md と templates/INTENT.md。

標準の流れ

1. 質問する前に、リポジトリと利用可能なコンテキストを調べます。
2. 作業を分類し、提案する進め方を伝えます。
3. 意図の契約を作成または再開し、重大な質問は最大一つに絞ります。
4. 重要な作業では計画を提示し、承認チェックポイントで待機します。
5. 一貫性のある最小限の変更を実装します。まず対象を絞ったテストを実行し、その後、より広範なチェックを行います。
6. 正確性、範囲、セキュリティ、リグレッション、保守性の観点からレビューします。
7. この変更に該当する指摘事項を修正します。先送りする指摘事項には、安定した ID、オーケストレーターによる処置、引き継ぎ先タスクまたはクローズを示す証拠を付与します。フォローアップチケットを作成しただけでは、指摘事項は解決されません。
8. レビューを、対象候補／コンテンツと受け入れ契約、実行したチェック／環境／結果／証拠に紐付けます。関連する変更が行われた場合は、影響を受ける承認を無効にします。意図、動作、リスク、指摘事項の解消状況、および「受け入れ／手直し／調査」の選択肢を報告します。references/review-and-failure-routing.md を参照してください。

仕様のステータス語彙

再開可能な作業のための機械可読なステータスです。

ステータス	意味
draft	仕様は存在しますが、まだ準備ができていません
ready-for-dev	準備状況の確認に合格し、実装可能です
in-progress	実装中です
in-review	レビューまたはトリアージ中です
done	ワークフローが正常に完了しました
blocked	安全に無人で続行できません

blocked は失敗ではなく、引き継ぎを示すシグナルです。上位のオーケストレーター、別の ワークフロー、または人間が引き継ぎます。scripts/check-spec.py を使って、仕様を決定論的に検証してください。

失敗時のルーティング

問題が発生したときは、失敗が入り込んだレイヤーを診断してください。

失敗	ルート
成果が異なる、または問題の捉え方が異なる	意図／分析
要件の欠落または矛盾	契約／計画
技術的なアプローチの競合	アーキテクチャ
ローカルコードの誤り	実装
テストまたは評価が不十分	検証
既存の無関係な問題	明示的に先送り
安全性に関わる曖昧さ	ブロックして確認

仕様が本当の問題である場合、コードの修正を続けないでください。

自律実行ゲート

自律実行は、次のすべてを満たす場合にのみ許可されます。意図の契約に一貫性があること、 受け入れ基準を観測できること、境界が明確であること、リポジトリを安全に変更できること、テストまたは 評価を実行できること、永続的なステータスを書き込めること、エスカレーション方法が定義されていること。自律作業中は、次のルールに従ってください。一度に一つの一貫した変更を行うこと。無関係な改善のためにスコープを広げないこと。許可なくマージ、デプロイ、または外部システムを変更しないこと。意図の不明点、必要な機能の欠如、破壊的な曖昧さ、検証の失敗、または収束しない修正があれば停止すること。

参考ファイル

参考資料	読み込むタイミング
references/protocol.md	エージェント向けの、貼り付けてすぐ使える完全な運用プロトコルが必要なとき
references/classification.md	リクエストを分類するとき、または儀式性の深さを選ぶとき
references/spec.md	SPEC／意図の契約を作成または再開するとき
references/lifecycle.md	イニシアチブを4つのフェーズすべてにわたって実行するとき
references/project-context.md	リポジトリのルール（AGENTS.md）を設定または監査するとき
references/review-and-failure-routing.md	レビューを実施するとき、または失敗を診断するとき
references/autonomy.md	自律型（Build Auto）作業を設定または実行するとき
references/party-mode.md	熟議、トレードオフ、設計に関する議論、事後検証
references/release-intent-acceptance.md	統合されたリリースを意図と照合してレビューし、ステージングからのフィードバックを振り分けるとき
references/adoption.md	プロトコルを段階的に導入するとき、またはダークファクトリーに対応付けるとき

テンプレート

テンプレート	用途
templates/SPEC.md	範囲を限定した作業／イニシアチブ向けの、バージョン管理された機械可読な契約
templates/INTENT.md	範囲を限定した作業向けの、5項目からなる軽量な契約
templates/STORY.md	ディスパッチ可能な、範囲を限定した1つの作業単位
templates/RELEASE-ACCEPTANCE.md	リリースのチェックポイント、統合された成果、欠陥／意図／新規スコープの処置
templates/REVIEW.md	最終的な人間によるチェックポイント：意図 → 挙動 → リスク → 検証

スクリプト

スクリプト	実行するタイミング
scripts/check-spec.py	仕様の作成または編集後：5項目とステータス語彙を検証します（標準ライブラリのみ、--json 出力）

隣接するスキルへのルーティング

• 上流（BMad の前）: product-discovery は問題が実在するかを検証します。 product-shaping はアペタイトを設定してピッチを作成します。product-strategy と product-roadmapping-and-portfolio は戦略的な背景を整理します。
• 下流（BMad の実行中）: 正式な仕様／ゲートのパイプラインには spec-driven-development、依存関係を考慮したデリバリープランには implementation-planning、アーキテクチャ上の意思決定には adr-authoring、 既存のコードベースのリバースエンジニアリングには software-architecture-analysis を使います。
• 実行とゲート: イシューから PR までのデリバリーフローには neckbeard、 受け入れを裏付ける証拠には verification-methodology、テスト戦略には qa-methodology、独立した評価者には agent-evals-and-observability、 Party-Mode 形式のマルチエージェントによる熟議には agent-council、 デプロイゲートには release-engineering、バックログとディスパッチのポリシーには kanban-guru を使います。

使用しない場合

• 問題自体が未検証の場合 → product-discovery。BMad は意図を凝縮しますが、 問題が実在するかどうかは確立しません。
• 作業の価値をどの程度とするか、まだ決まっていない場合 → まず product-shaping（アペタイト、ピッチ、賭け）を使います。BMad は 意図が定まった状態から始まります。
• ファクトリーパイプラインとして、正式な仕様形式とフェーズゲートが必要な場合 → SPEC 形式とゲートの仕組みは spec-driven-development が担います。BMad は その周囲にあるコントロールプレーンのプロトコルを提供します。
• 独自のゲートを備えた、イシューから PR までのデリバリーフローを実行する場合 → neckbeard。BMad はそれを補完するものであり、競合する 2 つのデリバリーライフサイクルを 実行しないでください。
• 独立したレビューが必要な場合 → ロールプレイは独立性を意味しません。 agent-council、別個の評価者、または agent-evals-and-observability を使います。 ペルソナを分けただけで独立したレビューだと決して主張しないでください。
• 公式の BMad インストーラー／ツールを操作する場合 → このスキルは手法を模倣するものであり、 bmad-method npm パッケージのインストールや操作は行いません。

バージョンの差異と帰属

BMad は現在も活発に進化しています（公式リポジトリ：bmadcode/bmad-method。 BMAD™ および BMAD-METHOD™ は BMad Code, LLC の商標です）。古い記事では、名称の 展開形、エージェント、ファイル名、コマンドが異なる場合があります。公式ツールを インストールする際は、公式ドキュメントとインストール済みのソースを正式な情報として 扱ってください。このスキルは、ハーネスに依存しないプロトコルとして手法を独自に 抽出したものであり、公式インストーラーの内容を再現するものではありません。