BMad：意図からデリバリーへの制御プレーンプロトコル
BMadは、ソフトウェアデリバリー手法であり、1つの考えに基づいています。人間の意図は、チャットで即興的に処理されるのではなく、段階的に明確化され、記録され、レビューされ、持続可能なコンテキストとしてエージェントに引き渡されるべきである、という考えです。このスキルは、その手法を、どのエージェントハーネスでも従うことができるプロトコルに変換します。公式のBMadインストーラは必要ありません。
ループ：分類リクエスト → 圧縮意図を契約に → ルーティング最小の安全な経路へ → 実装1つの境界単位 → レビュートリアージとして → ルーティング失敗をあいまいさが混入した層へ → ゲート制御自律性を観測可能な受容で → 学習完了した作業から。
このスキルを使用するタイミング
変更要求、機能追加、バグ報告、委任ビルド、またはマルチエージェントエピックに以下が必要な場合にロードします。
- 実装前の意図の捕捉 — 雰囲気ではなく、契約。
- 作業に必要な儀式の量に関する決定。
- セッションやエージェントをまたいで作業を再開可能にするための永続的なアーティファクト。
- ノイズを列挙するのではなく、調査結果をトリアージするレビュー。
- 境界が安全でない場合に安全に停止する自律性。
作業の分類（最小の安全な経路）
| クラス | 形状 | プロセス |
|---|---|---|
| 直接型 | 明確な目標、局所的な変更、確立されたパターン、小さな影響範囲 | 最小限の明確化の後、すぐに実装 |
| 境界型 | 短い契約と計画を必要とする首尾一貫した変更 | 意図契約 → 計画 → 実装 → レビュー |
| 主導型 | コンポーネント横断、複数ストーリー、高リスク、または戦略的に不確実 | 分析 → 計画 → ソリューション化 → 実装 → 学習 |
決定表、1つの質問ルール、停止条件については、references/classification.md をロードしてください。
意図契約（5つのフィールド）
境界型または主導型の作業の場合、実装前に契約を確立します。
- Why（なぜ） — 成果とその重要性。
- Capabilities（能力） — システムが実行できなければならないこと。
- Constraints（制約） — 技術的、運用上、法的、セキュリティ、プライバシー、時間、コスト、組織の境界。
- Non-goals（非目標） — 明示的に範囲外のこと。
- Success signal（成功シグナル） — 結果が機能し、受け入れ可能であることをどのように確認するか。
フィールドに実質的なあいまいさがある場合は、1つの影響度の高い質問をし、推奨回答を提案し、決定を待ちます。些細な変更の場合、契約は会話中の5つの箇条書きで済みます。大規模な作業の場合は、バージョン管理された仕様ファイルになります。
SPECの作成とステータス語彙については、references/spec.md をロードしてください。テンプレート：templates/SPEC.md と templates/INTENT.md。
正規のループ
- 何かを尋ねる前に、リポジトリと利用可能なコンテキストを検査する。
- 作業を分類し、提案された経路を述べる。
- 意図契約を確立または再開し、最大1つの実質的な質問をする。
- 自明でない作業については計画を提示し、承認チェックポイントで待機する。
- 最小の首尾一貫した変更を実装し、最初に焦点を絞ったテストを実行し、次に広範なチェックを実行する。
- 正確性、スコープ、セキュリティ、リグレッション、保守性についてレビューする。
- この変更に属する調査結果を修正し、無関係な調査結果は明示的に延期する。
- 意図、動作、ファイル、リスク、検証、調査結果の処分、および受け入れ/やり直し/調査の選択肢を報告する。
仕様ステータス語彙
再開可能な作業のための機械可読ステータス：
| ステータス | 意味 |
|---|---|
draft | 仕様は存在するが、準備ができていない |
ready-for-dev | 準備完了チェックを通過、実装準備完了 |
in-progress | 実装進行中 |
in-review | レビューまたはトリアージ進行中 |
done | ワークフローが正常に完了 |
blocked | 無人で安全に続行できない |
blocked はルーティングシグナルであり、失敗ではありません。上位のオーケストレーター、別のワークフロー、または人間が引き継ぎます。scripts/check-spec.py で仕様を決定論的に検証します。
失敗ルーティング
何かが間違っている場合、失敗が混入した層を診断します。
| 失敗 | ルート |
|---|---|
| 間違った成果または間違った問題 | 意図 / 分析 |
| 要件の欠落または矛盾 | 契約 / 計画 |
| 競合する技術的アプローチ | アーキテクチャ |
| ローカルコードの誤り | 実装 |
| 不十分なテストまたは評価 | 検証 |
| 無関係な既存の問題 | 明示的に延期 |
| 安全でないあいまいさ | ブロックして質問 |
仕様が本当の問題である場合に、コードにパッチを当て続けてはいけません。
自律性ゲート
自律実行は、以下のすべてが成立する場合にのみ許可されます。意図契約が首尾一貫している、受容が観測可能である、境界が明示的である、リポジトリが安全に変更可能である、テストまたは評価が実行可能である、永続的なステータスが書き込み可能である、エスカレーションが定義されている。自律作業中は、1回に1つの首尾一貫した変更。無関係な改善でスコープを拡大しない。承認なしにマージ、デプロイ、または外部システムを変更しない。意図のギャップ、能力の欠如、破壊的なあいまいさ、検証の失敗、または非収束的な修正で停止する。
参照ファイル
| 参照 | ロードするタイミング |
|---|---|
| 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 | 自律（ビルドオート）作業の設定または実行 |
| references/party-mode.md | 熟考、トレードオフ、設計議論、ポストモーテム |
| references/adoption.md | プロトコルの段階的導入またはダークファクトリへのマッピング |
テンプレート
| テンプレート | 目的 |
|---|---|
| templates/SPEC.md | 境界型/主導型作業のためのバージョン管理されたマシン契約 |
| templates/INTENT.md | 境界型作業のための軽量な5フィールド契約 |
| templates/STORY.md | 1つの境界化された、ディスパッチ可能な作業単位 |
| templates/REVIEW.md | 最終的な人間によるチェックポイント：意図 → 動作 → リスク → 検証 |
スクリプト
| スクリプト | 実行するタイミング |
|---|---|
| scripts/check-spec.py | 仕様の作成または編集後：5つのフィールド＋ステータス語彙を検証（stdlibのみ、--json出力） |
隣接スキルへのルーティング
- 上流（BMadの前）：
product-discoveryは問題が現実かどうかを検証します。product-shapingはアペタイトを設定しピッチを生成します。product-strategyとproduct-roadmapping-and-portfolioは戦略的コンテキストを枠組み化します。 - 下流（BMad中）：
spec-driven-developmentは正式な仕様/ゲートパイプライン用。implementation-planningは依存関係を認識したデリバリープラン用。adr-authoringはアーキテクチャ決定用。software-architecture-analysisは既存コードベースのリバースエンジニアリング用。 - 実行とゲート：
neckbeardはイシューからPRへのデリバリーフロー用。verification-methodologyは受容エビデンス用。qa-methodologyはテスト戦略用。agent-evals-and-observabilityは独立した評価者用。agent-councilはパーティーモードスタイルのマルチエージェント熟考用。release-engineeringはデプロイメントゲート用。kanban-guruはバックログとディスパッチポリシー用。
使用すべきでない場合
- 問題自体が検証されていない →
product-discovery。BMadは意図を圧縮しますが、問題が現実かどうかを確立するわけではありません。 - 作業にどれだけの価値があるかまだ決定していない → 最初に
product-shaping（アペタイト、ピッチ、ベット）。BMadは配置された意図から開始します。 - 工場パイプラインとして正式な仕様形式とフェーズゲートが必要 →
spec-driven-developmentがSPEC形式とゲートメカニズムを所有します。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 の商標です）。古い記事では、名前の拡張、エージェント、ファイル名、コマンドが異なります。公式ツールをインストールする場合は、公式ドキュメントとインストールされたソースを信頼できるものとして扱ってください。このスキルは、メソッドをハーネス非依存のプロトコルとして独自に蒸留したものです。公式インストーラのコンテンツを複製するものではありません。