bmad-architecture-design

アーキテクチャ設計スキル

呼び出すタイミング

ユーザーが次のような場合に自動的に有効化します：

• 「これをどう構築すればよいですか？」「アーキテクチャはどうなりますか？」と言う
• 「技術スタックは？」「システム設計は？」「どう設計すればよいですか？」と尋ねる
• 「アーキテクチャ」「技術的な決定」「スタック」に言及する
• PRD とエピックが承認されている（フェーズ 3）
• 次のような言葉を使う：アーキテクチャ、技術スタック、設計、システム、構築、技術

具体的なトリガーフレーズ：

• 「これをどう構築すればよいですか？」
• 「アーキテクチャはどうなりますか？」
• 「技術スタックを選択」
• 「[project] のシステム設計」
• 「技術アーキテクチャ」
• 「[feature] をどう設計すればよいですか？」

前提条件：

• PRD が存在し、承認されている
• エピックが定義されている

次の場合は呼び出さないでください：

• PRD の準備ができていない（先に bmad-product-planning を使用）
• すでにアーキテクチャがある（ストーリーに進む）
• 単純なレベル 0～1 のプロジェクト（正式なアーキテクチャは不要な場合があります）

ミッション

承認済みの製品要件を、コンポーネント構成、技術の選択、実装チーム向けの根拠を伝える意思決定アーキテクチャに変換します。

必要な入力

• prd：product-requirements スキルによる最新の PRD とエピックのロードマップ
• constraints：非機能要件、コンプライアンスルール、統合
• existing_assets：リポジトリ、既存のアーキテクチャ図、または技術標準
• project_level：設計の深さを導く BMAD レベルの規模設定

不足している入力がある場合は、作業を進める前にオーケストレーターまたは元のスキルにエスカレーションする必要があります。

出力

• assets/decision-architecture-template.md.template を使用して作成した ARCHITECTURE.md
• ステークホルダー向けに要約した、更新済みのリスクおよび意思決定ログの項目

成果物では、意思決定、却下した選択肢、実装上のガードレールを明確にしてください。

プロセス

1. CHECKLIST.md で前提条件を検証し、計画成果物が承認済みであることを確認します。
2. アーキテクチャを左右する要因（品質属性、制約、統合）を特定します。
3. 要件とのトレーサビリティを確保しながら、コンポーネントのトポロジー、データフロー、技術選定を設計します。
4. 主要な意思決定、代替案、緩和策を記録します。
5. 構造化データが利用可能な場合は、scripts/generate_architecture.py を使用してアーキテクチャ成果物を生成または更新します。
6. 品質チェックリストを確認し、概要と、デリバリー計画および開発実行スキル向けのフォローアップアクションを公開します。

品質ゲート

完全性、実現可能性、ステークホルダーとの整合性を確保するため、CHECKLIST.md に従ってください。ガードレールを満たさない場合は中止してください。

エラー処理

矛盾や不足がある場合：

• 競合の原因となっている具体的な要件または前提を示します。
• product-requirements、UX、または discovery-analysis スキルに確認を依頼します。
• 解決策が記録されるまで、実装を保留することを推奨します。