generar-backlog

PRD + Tech Design → バックログ分解

目標

承認済みの PRD.md と TECH-DESIGN.md（ADR を含む）を、実装可能な仕様の順序付きバックログに変換します。「プロダクトとアーキテクチャがある」状態から「最初に何を作ればよいかわかっている」状態への、欠けている橋渡しです。各バックログ項目は、単一の SDD 変更（sdd-new／仕様駆動のサイクルを 1 回）にできる範囲にします。機能領域全体でも、ボタン 1 つだけでもありません。

このスキルは SDD 自体を実行せず、コードも書きません。SDD サイクルで項目ごとに使用するロードマップを作成します。

必須入力

• PRD.md — 必須です。
• TECH-DESIGN.md とその adrs/*.md — 必須です。アーキテクチャなしで分解すると、コンポーネントの境界を考慮しないバックログ項目が作られてしまいます。

いずれかがない場合は、作業を中止して提出を依頼してください。

ワークフロー

1. PRD.md と TECH-DESIGN.md（および ADR）をすべて読みます。
2. 両方の文書ですでに定義されている内容から、自然な実装単位を特定します。PRD のフローと受け入れ基準、TDD のコンポーネントとデータの境界が該当します。これらの文書のどちらにも根拠がない範囲を作り出さないでください。
3. 各単位は、現実的に単一の SDD サイクルで完了できる規模にします。価値あるまとまりとして十分な大きさがあり、独自のミニプロジェクトにならずに仕様化、設計、実装できる程度に小さくします。「el sistema」というタイトルのバックログ項目は大きすぎ、「cambiar el color de un botón」は小さすぎます。どちらの極端な場合も、黙って受け入れずに指摘してください。
4. 推測した優先度ではなく、依存関係に基づいてバックログを並べます。他の項目で必要とされる項目（たとえば、それを使う機能より前に必要なデータモデルや認証）は、どれだけ興味深いかにかかわらず、先に配置します。
5. 各項目について、ドメイン固有のビジネスルールをコンテキストとして必要とする可能性が高いかどうかを示します。判断の目安は、汎用的な PRD／TDD で定義される範囲を超えた、専門的な計算、規制対象のロジック、用語に関わる項目です（例：会計モジュールの勘定科目表のルール）。すべてのプロジェクトに該当すると想定しないでください。ほとんどのプロジェクトでは必要ありません。該当項目には、明示的に次のように記載します。「この項目の仕様を生成する前に、あれば、このドメインのビジネスルールに関するドキュメントをコンテキストとして共有してください」。このスキルがそのドキュメントを作成したり、共有を依頼したりすることはありません。重要となる項目を示すだけです。
6. 最終決定の前に、バックログの草案をユーザーに提示します。順序が妥当か、項目を分割または統合する必要があるか、また、フラグを付けた項目について、ここに記載すべきドメインルールがすでに文書化されているかを明示的に尋ねます。ファイルを書き込む前に回答を待ってください。
7. プロジェクトのルートに BACKLOG.md を書き込みます。

出力形式（BACKLOG.md）

# Backlog: {Nombre del proyecto}

| # | Item | Alcance | Depende de | Contexto extra requerido |
|---|---|---|---|---|
| 1 | {Nombre} | {1 línea} | — | — |
| 2 | {Nombre} | {1 línea} | #1 | Reglas de negocio de {dominio} |

## Cómo usar este backlog

Cada ítem es una spec independiente. Al implementarlo, arrancá un ciclo de Spec-Driven
Development (`sdd-new` o el flujo equivalente de tu harness) usando este ítem como el
"change" — no el proyecto completo. Si la columna "Contexto extra requerido" tiene algo,
compartilo como contexto al generar la spec de ese ítem.

品質ゲート

返答する前に、次の点を確認します。この確認はユーザーには見せません。

• すべてのバックログ項目に PRD または TDD の明確な根拠があり、内容を作り出していない。
• 「プロジェクト全体」や、単純すぎる変更 1 件だけを項目にしていない。
• 依存関係に循環がなく、基盤となる項目が、それに依存する項目より先に配置されている。
• ドメイン知識が重要な項目には追加コンテキストのフラグを付け、必要だと黙って決めつけることも、黙って見落とすこともしていない。