bmad-spec

BMAD Spec — Five-Field Kernel Distiller

機能： 整理されていない、構造化されていない、または冗長な入力を受け取り、すべての後続の計画ワークフローの基盤となる、簡潔な SPEC.md カーネル（最大5項目）を作成します。これは計画スキルです。アプリケーションコードの作成、テストの実行、ビルドは行いません。

生成されるもの

設定済みの出力フォルダー（デフォルトは bmad-output/）にある単一のファイル：

bmad-output/
└── SPEC.md    # the five-field kernel

カーネルは意図的に小さくしています。SPEC は PRD でも、概要書でも、アーキテクチャ文書でもありません。何を、なぜ構築するのかを共有するための定義です。後続の各スキル（PRD、tech-spec、architecture）は、スコープの信頼できる基準としてこれを読み込みます。

5つの項目

項目	目的
Problem（課題）	現在、最も困っていることと、それが重要な理由
Capabilities（機能）	ソリューションが実現できなければならないこと（成果を中心に記述）
Constraints（制約）	交渉の余地がない厳格な制限（予算、技術、期間、コンプライアンス）
Non-Goals（対象外）	明確にスコープ外とする内容 — スコープの肥大化や混乱を防ぎます
Success Metrics（成功指標）	課題が解決したことを確認できる、観測可能なシグナル

指針と例を含む正確なテンプレートについては、templates/spec.template.md を参照してください。

ワークフロー

1. 入力の受け取り

ユーザーが渡すものは何でも受け付けます。

• 生の文章、メモ、文字起こしの貼り付け
• 既存ファイルへのパス（Read で読み取ります）
• チャットでの口頭説明

入力が数百語を超える場合は、先に受け取った内容を簡潔に伝えてから進めます。ユーザーに書式を整え直すよう求めないでください。それがこのスキルの役割です。

2. 抽出（内部分析）

入力を読み、各項目に当てはまる情報を見つけます。

• Problem（課題）： どのような苦痛、ギャップ、または障害状態が説明されていますか？誰がそれを経験しますか？
• Capabilities（機能）： どのような成果や能力が求められていますか？機能を能力として言い換えます（「ユーザーが……できる」「システムが……をサポートする」）。
• Constraints（制約）： 何が固定されていますか？予算額、技術上の必須事項、期限、規制への言及、チーム規模の上限を探します。
• Non-Goals（対象外）： 読者が想定する可能性があるのに、入力で触れられていないことは何ですか？明確に除外されていることは何ですか？先送りされていることは何ですか？
• Success Metrics（成功指標）： 「完了」または「動作している」とは、どのような状態ですか？数値、観測可能な動作、しきい値を確認します。

3. 下書きの作成と提示

5つの項目すべての簡潔な下書きを作成し、ディスクに書き込む前にチャットでユーザーに提示します。各項目は簡潔にまとめます。

• Problem（課題）：最大2～5文。
• Capabilities（機能）：成果を中心に記述した箇条書き3～7項目。
• Constraints（制約）：厳格な制限のみを記した箇条書き2～6項目。
• Non-Goals（対象外）：明確で曖昧さのない箇条書き2～6項目。
• Success Metrics（成功指標）：測定可能なシグナルを含む箇条書き2～5項目。

提示した後、焦点を絞った質問を1つします。「SPEC.md を書き込む前に、ここで変更が必要な点はありますか？」

4. 書き込み

ユーザーが確認（または修正）したら、テンプレートを使って SPEC.md を作成します。

${CLAUDE_PLUGIN_ROOT}/skills/bmad-spec/templates/spec.template.md

出力先：<outputFolder>/SPEC.md（bmad-output/config.yaml が存在する場合は読み込み、設定済みの出力フォルダーを確認します。なければ bmad-output/ を使用します）。

bmad-output/decision-log.md に新しいエントリーを追加します（存在しない場合は作成します）。

## SPEC created — <ISO date>
- Source: <one-line description of the input, e.g. "stakeholder brain dump">
- Key scope decision: <the single most important Non-Goal or Constraint>

5. 次のステップへの引き継ぎ

書き込み後、SPEC によって可能になる次の作業をユーザーに伝えます。

• Quick Flow トラック → カーネルをデプロイ可能な仕様にするため、bmad-tech-spec に引き継ぎます。
• BMad Method / Enterprise トラック → 完全な PRD を作成するため、bmad-product-brief または PM ロール（bmad-prfaq）に引き継ぎます。
• ワークスペースがまだない場合は、まず /bmad-planning-orchestrator:bmad-init を実行してトラックを選ぶよう提案します。

3 つのインテント

• 作成 — 新しい SPEC.md に新たな入力を要約します（一般的なケースです）。
• 更新 — ユーザーに新しい情報がある、またはスコープが変更されています。既存の SPEC.md を読み、変更を適用して、差分形式の概要を提示し、確認を得てから 上書きします。変更を decision-log.md に記録します。
• 検証 — 5 つのフィールドからなる契約に照らして SPEC.md をレビューします。すべてのフィールドが 存在し、空でないでしょうか。Problem は一貫した 1 つの記述でしょうか。Capabilities は 機能の一覧ではなく、成果として記述されているでしょうか。Non-Goals は明確でしょうか。不足があれば指摘し、 修正を提案します。

要約のヒューリスティクス

ノイズの多い入力を 5 つのフィールドに割り当てる際は、次のルールに従います。

入力パターン	割り当て先
「修正が必要だ／ユーザーから不満が出ている／壊れている」	Problem
「〜すべき／ユーザーが〜できる／システムが〜をサポートする」	Capabilities
「〜できない／予算がない／〜を使う必要がある／期限までに」	Constraints
「対象外／後で対応／v1 には含めない／対応しない」	Non-Goals
「X% なら／〜が機能しているとわかるのは／目標」	Success Metrics

制約が願望のように聞こえる場合（例：「第 3 四半期に完了できればと思います」）は、 Non-Goals に移すか、ソフト制約として指摘し、曖昧さを記録します。

Capabilities が成果ではなく機能のように聞こえる場合は、言い換えます。「検索バーを 追加する」→「ユーザーが 3 回のキー入力以内に任意のレコードを見つけられる」。

入力に成功指標がない場合は、Problem の記述から代理指標を導き出します。問題が「ユーザーが X を 見つけられない」であれば、「X を見つけるまでの時間を Y% 短縮する」が指標になります。

ガードレール

• 意図的に簡潔に保ちます。 6 つ目のフィールドを追加しないでください。重要な情報が 5 つのフィールドに収まらない場合は、ファイルヘッダーにコンテキストとして記載し、PRD または技術仕様の段階で 拡張するようユーザーに案内します。
• 解決策を設計しません。 Capabilities フィールドでは、実装方法ではなく成果を示します。アーキテクチャ、技術スタック、 アプローチは後続の工程で扱います。
• SPEC 内のどこにも、ストーリーポイント、ベロシティ、バーンダウンを記載しません。
• スコープの原則。 このスキルの最終成果物は SPEC.md です。ストーリーの作成、 コードの記述、受け入れ基準の作成は行いません。これらは後続のスキルに引き継ぎます。

要約パターンの詳細や例外については REFERENCE.md を参照してください。

---

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