mb-from-prd

mb-from-prd — PRD → Memory Bank（グリーンフィールド）

• 概要： PRD を、構造化されたプロジェクト知識と追跡可能な計画成果物に変換します。
• 使用するタイミング： プロジェクトがグリーンフィールドで、prd.md または同等の要件がすでに存在する場合です。
• 入力： prd.md またはユーザーが提供する PRD テキストと、初期化済みの .memory-bank/。
• 出力： /spec-design の実行、および /prd-to-tasks の前に各機能に対して /spec-improve を実行するための準備が整った、プロダクト、RTM、エピック、機能、SDD 設計のルーティングです。

前提条件

• リポジトリのルートにいること。
• .memory-bank/prd.md に type: prd、clarification_status: complete、constitution_checked: true が設定されていること。そうでない場合は、先に /write-prd を実行します。
• PRD の分解に必要な軽量 SDD ルートマップとして、.memory-bank/spec-index.md が /spec-init の実行後に存在すること。/prd の後、必須の /spec-design がこのマップを使用し、最小限または完全なバックボーンゲートを記録します。また、機能間でドメイン／モデル／契約／状態／セキュリティ／ランタイム設計が共有されている場合は、バックボーン SDD 仕様と spec-index を更新することがあります。
• プロダクトブリーフなどの任意の分析成果物が存在する場合があります。上流の PRD 入力として使用しますが、必須ではありません。
• .memory-bank/ が存在すること。存在しない場合は、先に mb-init を実行するか、手動でスケルトンを作成します。

プロセス

1) 明確化済みの PRD を読み込む

1. .memory-bank/prd.md を読みます。
2. フロントマターに type: prd、clarification_status: complete、constitution_checked: true が設定されていることを確認します。
3. 分解に影響する未解決の NEEDS CLARIFICATION マーカーが PRD に含まれている場合は、停止します。
4. 軽量 SDD ルートマップとして .memory-bank/spec-index.md を読みます。インデックスが存在しない、古い、プレースホルダーのみである、リンク切れがある、曖昧である、または関連する既存の仕様と、計画中／候補／不明／非該当の領域を安全に特定できない場合は、停止して /spec-init を実行します。
5. PRD のセクション、影響を受けるプロダクト領域、要件、アクター、データ／ドメインモデル、契約／API、状態／ライフサイクル、セキュリティ／コンプライアンス、ランタイム／運用、検証戦略から、関連する権威ある仕様を特定します。
6. .memory-bank/spec-index.md でルーティングされた、関連する権威ある仕様ファイルのみを解決して読み込みます。既定ではすべての SDD 仕様を読み込まないでください。
7. 関連する権威ある仕様が PRD と矛盾する場合は、停止し、仕様または PRD の修正による明示的な解決を求めます。
8. タスクプロトコルフォルダーを開始します。
   • .protocols/PRD-BOOTSTRAP/
   • plan.md（手順）
   • decision-log.md（Q/A と選択肢）

2) スキル／ツールの発見（任意ですが推奨）

PRD で「スキル／ツール／CLI の使用」に言及している場合：

• /find-skills を実行します（プロジェクトにインストール済みのものを先に確認し、次にマーケットプレイスを確認します）。
• 使用する関連スキルの最小セットを提案します（確認なしにインストールしないでください）。

3) ここでは詳細な質問をしない

PRD レベルの曖昧さは /write-prd で解決します。このスキルでは、詳細な質問を繰り返さないでください。 任意の分析（/analysis、/brainstorm、/brief）により、/write-prd への入力を改善できます。

ターゲットモードが完全自律型の場合：

• 実行を妨げない不足事項は、明示的な Assumptions として記録できます。
• 実行を妨げる不足事項（セキュリティ／コンプライアンス／外部契約／データ損失リスク）がある場合は、実行を停止する必要があります。

4) L1 プロダクトブリーフを作成する

.memory-bank/product.md を更新します（ユーザーの表現を使用します）。

5) 要件と RTM

.memory-bank/requirements.md を更新します。

• REQ-ID を列挙します。
• 「対象外」を定義します。
• RTM を記入します：REQ → Epic → Feature → Test。

6) エピックを作成する（L2、ドラフト優先）

各エピックについて：

• .memory-bank/epics/EP-<NNN>-<slug>.md を作成します。
• references/epic-template.md を使用します。
• ビジネス価値と成功指標を必ず含めます。
• Source artifacts、Normative inputs、Constraints / invariants などの任意セクションは、根拠がある場合にのみ記入します。
• 未解決の質問が解消されるまでは、既定で status: draft とします。

7) 機能の作成（L3、ドラフト優先）

機能ごとに、以下を行います。

• .memory-bank/features/FT-<NNN>-<slug>.md を作成します。
• references/feature-template.md を使用します。
• 自律性と明示的な受け入れ基準を確保します。
• デフォルトでは、明確化に関するメタデータを追加しません。PRDで、タスク分解に影響する機能レベルの阻害要因が明示されている場合に限り、clarification_status: pending|blocked を追加します。
• Source artifacts、Normative inputs、Constraints / invariants、Verification targets などの任意セクションは、根拠となる証拠がある場合に限り記入します。
• すべての機能に ## SDD Design Gate セクションを含めます。このセクションは、/prd-to-tasks FT-<NNN> の前に /spec-improve FT-<NNN> を実行するよう案内しますが、プレースホルダーの spec_design_status や新たなブロック状態は導入しません。
• 受け入れ基準と検証計画が確かなものになるまでは、デフォルトで status: draft とします。

8) タスク計画（機能ごとに実施し、一括で行わない）

すべての機能について、タスクキュー全体を一度にまとめて「в лоб」で生成しないでください。

代わりに、以下の手順を実施します。

1. .memory-bank/schemas/task.schema.json と .memory-bank/tasks/index.json が存在することを確認します。新規の骨組みでは { "version": 1, "tasks": [] } となっている場合があります。
2. /prd の後に /spec-design を実行します。小規模で独立した T0/T1 機能では、無関係な領域を not_applicable として、最小限の骨格を記録できます。共有または T2/T3 の懸念事項については、必要な骨格となる SDD 仕様と spec-index を作成または更新します。これは、必須の重い工程がもう一つ追加されるということではありません。タスクも、機能固有の実装設計も作成しません。
3. 選択した機能ごとに、まず /spec-improve FT-<NNN> を実行し、その後 /prd-to-tasks FT-<NNN> を実行して、以下を作成します。
   • .memory-bank/tasks/plans/IMPL-FT-<NNN>.md
   • wave ごとにグループ化され、それぞれに必須の tier: T0|T1|T2|T3 を含む、アトミックな .memory-bank/tasks/TASK-*.task.json レコード

十分な構造化された証拠がある場合は、機能レベルの計画とタスクレコードに、source_artifacts、normative_inputs、constraints、invariants、verification_targets などのより詳細な任意フィールドを含めることができます。 タスクの振り分けを決めるのは task.tier のみです。従来の risk / risk.level モデルは無効です。 標準的な SDD 計画の流れは /write-prd → /spec-init → /prd → /spec-design → /spec-improve FT-<NNN> → /prd-to-tasks FT-<NNN> です。必須の骨格ゲートの後に設ける機能レベルのゲートは、引き続き /spec-improve が担います。/clarify-feature FT-<NNN> は、機能が明示的に pending/blocked となっている場合に限り実行します。シンプルな T0/T1 相当の機能では、/spec-improve により、簡潔な根拠とともに spec_design_status: not_required を設定できます。

これにより、計画の正確性を保ち、推測に基づくタスクの過剰な増加を防げます。

9) 重要な概念のサポートドキュメント

後から理解するために「多くのファイルを読む」必要が生じる概念については、サポートドキュメントを作成します。

互換性を重視した標準の構成：

• .memory-bank/architecture/<concept>.md（WHAT/WHY）
• .memory-bank/guides/<concept>.md（HOW）

より詳細なサポートドキュメント（任意）：

• .memory-bank/contracts/...
• .memory-bank/states/...
• .memory-bank/runbooks/...
• .memory-bank/testing/...

ルール：

• 従来の2文書構成も、引き続き有効で役立ちます。
• より詳細なドキュメントは追加のものであり、証拠に基づいて作成します。
• より詳細なドキュメントがある場合は、.memory-bank/spec-index.md と関連する機能・概念のドキュメントから参照できるようにします。
• 新しい仕様を作成する前に、.memory-bank/spec-index.md で既存の仕様を確認します。

10) インデックスの更新

.memory-bank/index.md を更新し、新しく追加したすべての項目への注釈付きリンクを記載します。

11) レビューゲート

新しいコンテキストでレビューを実施します（できれば mb-review を使用します）。

12) 自律的な引き継ぎ（任意）

目標が「ユーザーとの追加のやり取りなしに、PRD から完了まで進める」ことである場合：

• ここからタスクを手動で実行しないでください。
• 生成されたプロジェクトコマンド /autonomous に引き継ぎます。

完了の定義

• product.md と requirements.md に一貫性があります。
• すべての REQ が RTM のエピック／機能に対応しています。
• エピックと機能が受け入れ基準とともに存在します。
• .memory-bank/spec-index.md で、既存／計画済み／候補／不明／非該当の SDD 設計領域を振り分けています。
• mb-from-prd 自体からスキーマに基づくタスクレコードを作成する必要はありません。
• /spec-improve FT-<NNN> と /prd-to-tasks FT-<NNN> を使ってタスク計画を明示的に続行する場合、スキーマに基づくタスクレコードが .memory-bank/tasks/index.json に索引付けされ、すべてのタスクに tier があります。
• index.md が更新されています。