bmad-readiness-check

BMAD 準備状況チェック

「計画はここまでです。」 このスキルは、ソリューション策定から実装への移行を判断するゲートです。コードを1行も書く前に、計画文書一式に内部的な矛盾がないこと、つまり要件がアーキテクチャで網羅されていること、エピックが要件にさかのぼれること、そして重要な項目が欠落していないことを検証します。

出力は、明確な PASS／CONCERNS／FAIL 判定と、実行可能な具体策を含む readiness-report.md です。

---

ワークフロー

TodoWrite を使用して、成果物の読み込み → 相互参照 → 品質チェック → レポート生成 → 判定の表示を追跡します。

---

ステップ 1 — 計画成果物の場所を特定する

同梱の存在確認を実行します。

bash "${CLAUDE_PLUGIN_ROOT}/skills/bmad-readiness-check/scripts/readiness-check.sh" <output-folder>

スクリプトは必須の成果物ファイルを確認し、事前チェックの判定（PASS／CONCERNS／ FAIL）を出力します。出力を読みます。ステップ 2 で読み込む成果物のパスも表示されます。

既定の検索ルートは bmad-output/（またはユーザーが設定した outputFolder）です。 ユーザーがカスタムパスを指定した場合は、引数として渡します。

---

ステップ 2 — 成果物を読み込んで解析する

スクリプトが特定した各成果物を読みます。

要件ドキュメント（PRD または tech-spec）：

• ラベル付きの機能要件（FR-001、FR-002 …）、またはラベルがない場合は要件の箇条書きを抽出します。
• 非機能要件（NFR-001 …、または名前付きのセクション： パフォーマンス、セキュリティ、スケーラビリティ、信頼性、保守性）を抽出します。
• エピックの数と、概要レベルのスコープ記述を記録します。

アーキテクチャドキュメント：

• システムコンポーネントと、それぞれの責務を抽出します。
• FR のトレーサビリティマトリクス、または FR とコンポーネントの明示的な対応付けを探します。
• NFR の網羅状況に関するセクションを探します。
• 技術スタックの決定事項と、トレードオフに関する注記を記録します。

エピック／ストーリー（存在する場合）：

• エピックとストーリーの数を数えます。
• 各エピックについて、参照している PRD の要件を特定します。

ベースラインを記録します。

Baseline
- FRs found: N
- NFRs found: N
- Epics found: N  (0 if Quick Flow)
- Stories found: N  (0 if not yet decomposed)

---

ステップ 3 — 相互参照チェック

3a. FR → アーキテクチャの網羅状況

各 FR について、アーキテクチャドキュメント内で FR 識別子と要件の主題を検索します。 次のように判定します。

• 網羅済み — FR が明示的に扱われ、担当コンポーネントが割り当てられています。
• 暗黙的 — 主題は扱われていますが、明示的には関連付けられていません。
• 未対応 — 網羅されている証拠がありません。

3b. NFR → アーキテクチャの網羅状況

各 NFR カテゴリについて、専用のアーキテクチャセクションまたは明示的な方針があるか確認します。

• パフォーマンス：キャッシュ、応答時間の目標、非同期パターン。
• セキュリティ：認証／認可モデル、暗号化、シークレット管理。
• スケーラビリティ：水平／垂直スケーリング方針、負荷分散。
• 信頼性：フェイルオーバー、バックアップ、稼働時間の目標。
• その他、該当するもの。

それぞれを「対応済み」／「一部対応」／「未対応」として判定します。

3c. エピック → FR のトレーサビリティ（BMad Method／Enterprise トラック）

各エピックが、少なくとも 1 つの FR または PRD のセクションを参照していることを確認します。 追跡可能な要件がない孤立したエピックにフラグを付けます。

3d. アーキテクチャ品質の抜き取りチェック

アーキテクチャドキュメントに次の内容が含まれていることを確認します。

• アーキテクチャパターンが明記され、正当化されている
• コンポーネントの責務とインターフェースが定義されている
• データモデル／エンティティの関係
• API 設計またはサービス契約
• 技術選択とその根拠
• トレードオフの記録
• 前提条件と制約の一覧

---

ステップ 4 — 判定の算出

以下の基準を適用します（BMAD Method v6 のゲート基準を PASS／CONCERNS／FAIL で表現したものです）。

基準	PASS	CONCERNS	FAIL
FR の網羅率（網羅済み＋暗黙的に網羅）	≥ 90 %	80–89 %	< 80 %
NFR の網羅率（対応済み＋部分的に対応）	≥ 90 %	80–89 %	< 80 %
アーキテクチャ品質チェック	≥ 80 %	70–79 %	< 70 %
ブロッカーとなる問題（重大な不足）	0 件	軽減策あり	未軽減
エピックのトレーサビリティ（該当する場合）	すべてリンク済み	≥ 80 % がリンク済み	< 80 %

総合判定のルール：

• PASS — すべての基準が PASS のしきい値を満たし、ブロッカーがありません。
• CONCERNS — 1 つ以上の基準が CONCERNS の範囲にあり、ブロッカーには軽減計画があります。注意して進め、ストーリーの詳細化時に懸念事項に対処してください。
• FAIL — いずれかの基準が CONCERNS のしきい値を下回る、または未軽減のブロッカーがあります。問題が解決するまで、ストーリーの作成に進まないでください。

---

ステップ 5 — レポートの生成

次のテンプレートを使用して準備状況レポートを作成します。

${CLAUDE_PLUGIN_ROOT}/skills/bmad-readiness-check/templates/readiness-report.template.md

保存先：<outputFolder>/readiness-report-<project-slug>-<date>.md

Write ツールを使用します。分析結果に基づいて、すべての {{placeholder}} フィールドに値を入力してください。

---

ステップ 6 — 判定の表示

ユーザーに簡潔な要約を表示します。

Readiness Check Complete

Artifact Coverage
  FR coverage:          XX %
  NFR coverage:         XX %
  Architecture quality: XX %

Verdict: PASS | CONCERNS | FAIL

<One-sentence rationale>

Report saved: <file path>

続けて、具体的な次のステップを推奨します。

• PASS → エピック／ストーリーの分解に進みます （/bmad-planning-orchestrator:bmad-epics-and-stories）。
• CONCERNS → 注意して進みます。ストーリー作成者が Dev Notes として引き継ぐ必要がある未解決項目を列挙してください。
• FAIL → 必須の修正項目を上位 3～5 件列挙します。対処後に準備状況チェックを再実行してください。

---

対象範囲の境界

このスキルが検証するのは計画ドキュメントのみです。以下は行いません。

• アプリケーションコードの作成。
• テスト、リンター、ビルドツールの実行。
• プルリクエストや差分のレビュー。
• カバレッジやベロシティ指標の算出。

判定が PASS または CONCERNS の場合は、エピック／ストーリースキルで作成されたストーリーファイルを通じて、開発ツールに引き継ぎます。

---

ペルソナに関する注記

このゲートは従来、BMAD Method において Winston（システムアーキテクト）が担当してきました。このスキルはワークフローであり、キャラクターではありませんが、レポートのトーンには Winston の姿勢――徹底的、体系的、品質重視――を反映してください。

---

---

BMAD Planning & Orchestrator プラグインの一部です。BMAD Code Organization による BMAD Method のための Claude Code ハーネスです（https://github.com/bmad-code-org/BMAD-METHOD）。`bmad-check-implementation-readiness` の理念を実装しています。方法論に関する功績はすべて BMAD Code Organization に帰属します。