mcpField
B
bmad-tech-spec

bmad-tech-spec

github.com/aj-geddes開発493106 回インストール19 週間前に更新
リポジトリ

bmad-tech-spec について

bmad-tech-specは、BMAD Planning & OrchestratorプラグインのQuick Flow向け計画スキルで、小規模かつ範囲が明確な変更のtech-spec.mdを作成・検証します。要件が明確でストーリー数の少ない作業を対象とし、製品上の背景、技術方針、ストーリー一覧を一つの文書にまとめます。

主な機能

  1. 01tech-spec.mdの作成・更新・検証
  2. 02課題、解決策、プロジェクト範囲の整理
  3. 03MoSCoWタグ付き機能要件の作成
  4. 04技術方針、依存関係、リスクの記録
  5. 05テスト内容を計画方針に限定
  6. 06決定事項を記録し次のストーリー作成を案内

活用シーン

  1. 01小規模機能のQuick Flow仕様を作成
  2. 02既存の技術仕様を改訂して変更を記録
  3. 03ストーリー作成前に仕様の完全性を確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/aj-geddes/claude-code-bmad-skills --skill bmad-tech-spec

インストール後、Claude Code で/bmad-tech-specを入力して読み込まれたか確認します。

同梱ファイルtemplates/tech-spec.template.md

詳細

BMAD 技術仕様書 — Quick Flow

このスキルは、1〜15件のストーリー規模に収まる、小規模で範囲の明確な機能や変更といった Quick Flow の作業向けに、要点を絞った tech-spec.md を作成します。大規模なトラックで必要となる個別の PRD とアーキテクチャ成果物を省き、プロダクトの根拠、技術的なアプローチ、ストーリーバックログを、軽量な1つのドキュメントにまとめます。

トラックの指針

  • 1〜15件のストーリー、単一チーム、要件が明確 → Quick Flow（このスキル）
  • 10〜50件以上のストーリー、複数の懸念事項、または範囲が不確定 → bmad-prd の後に bmad-architecture を使用
  • 30件以上のストーリー、組織横断、セキュリティ／コンプライアンス／DevOps の観点を含む → Enterprise トラック

ワークフロー

ステップ 1 — 意図を確認する

次の3つの意図のどれに当てはまるか、ユーザーに尋ねるか、コンテキストから判断します。

意図該当する場合
作成tech-spec.md がまだ存在しない
更新既存の仕様書の範囲、要件、またはアプローチを見直す
検証ストーリー作成に進む前に、ドラフト仕様書が BMAD の要件を満たしているか確認する
ステップ 2 — コンテキストを収集する

作成の場合は、対話または既存のプロジェクトファイルから、次の情報を収集します。

  1. 問題と解決策 — 何を解決し、どのように解決するのか？
  2. 範囲 — 対象範囲は何か？ 明確に対象外とするものは何か？
  3. 機能要件 — 番号付きで、MoSCoW タグ（MUST / SHOULD / COULD）を付ける
  4. 非機能要件 — 該当するパフォーマンス、セキュリティ、アクセシビリティの目標。適用されない定型項目は省く
  5. 技術的なアプローチ — スタック、主要コンポーネント、データモデルの概要、API サーフェス（該当する場合）
  6. ストーリーリスト — バックログ項目の概要。スクラムマスタースキルが、これらを完全なストーリーファイルにまとめる
  7. 依存関係とリスク — サードパーティライブラリ、外部サービス、既知の不確定要素
  8. 決定ログの記録 — この会話中に行われ、bmad-output/decision-log.md に記録すべき選択

bmad-output/project-context.md が存在する場合は読み込みます。これはプロジェクトの基本規定であり、記録された決定なしにこれと矛盾してはなりません。

更新の場合は、まず既存の bmad-output/tech-spec.md を読み、対象を絞って編集したうえで、変更内容を決定ログに記録します。

検証の場合は、既存の仕様書を読み、以下の検証チェックリストに照らして報告します。

ステップ 3 — 草案を作成または改訂する

テンプレートを次の場所で表示します。

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

すべてのセクションを記入します。本当に該当しないセクション（例：純粋な CLI ツールで API 設計が不要な場合）は省略し、省略したことを本文中に記載します。置き換えられていない {{placeholders}} を残さないでください。

仕様書のテスト戦略は計画のみです。何を、なぜテストすべきかを説明します。テストコードは作成しないでください。カバレッジの数値を必須目標として設定せず、開発チームへの指針として示してください。

ステップ 4 — 出力を書き込む

bmad-output/tech-spec.md に書き込みます（ユーザー設定に outputFolder が設定されている場合は、それに従います）。

決定ログへの記録がある場合は、bmad-output/decision-log.md に追記します（ファイルが存在しない場合は、次の形式で作成します：## [YYYY-MM-DD] <title> ／ **Decision:** ... ／ **Rationale:** ...）。

ステップ 5 — 次のステップを確認する

書き込み後、ユーザーに次のことを伝えます。

  • 仕様書は Quick Flow の計画成果物です。次のステップはストーリーの作成です。
  • 仕様書のストーリーリストからストーリーをまとめるには、bmad-epics-and-stories を使用します。
  • この会話中に範囲が約15件を超えるストーリーに拡大した場合は、先に BMad Method トラック（bmad-prd + bmad-architecture）へ切り替えてから進めることを推奨します。

検証チェックリスト

意図が Validate の場合、各項目について合格／不合格を報告します。

  • 課題の説明が明確かつ具体的である
  • 解決策が実装コードを使わずに説明されている
  • すべての機能要件に番号が振られ、MoSCoW タグが付いている
  • 非機能要件に、該当する場合はパフォーマンスまたはセキュリティに関する項目が少なくとも 1 つ含まれている
  • 技術的アプローチで、技術スタックが示され、主要なコンポーネントが説明されている
  • ストーリーの一覧があり、各ストーリーのタイトルが 1 行で、行動を示す内容になっている
  • ストーリー数が 1～15 である（超過している場合は指摘する）
  • 置換されていない {{placeholders}} が残っていない
  • テストセクションでは戦略のみが説明されている（実行可能なテストコードは含まれていない）
  • 依存関係の表に、バージョンまたはバージョン制約が記載されている
  • リスクの表に、緩和策とともに少なくとも 1 つのリスクが記載されている
  • 重要な選択について、意思決定ログの項目が記載されている
  • テスト、リンティング、ビルド、デプロイの実行を開発エージェントに指示する内容が含まれていない

サブエージェント戦略

このスキルは、主に単一スレッド（1 つの会話、1 つのドキュメント）で実行します。並列処理は任意で、情報収集に限られます。

  • ユーザーが並行調査（例：2 つの技術選択肢の比較）を希望する場合は、WebSearch／WebFetch エージェントを 2 つ並行して起動し、仕様書を作成する前に結果をまとめます。
  • 仕様書は一貫性のある単一のドキュメントであり、マージの競合を避けるため一括で作成する必要があるため、作成作業に並列エージェントを起動しないでください。

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

コメント

Markdown 対応