sdd-slice-wish（1Spec=1PRへのスライス）

このスキルの責務（重要）

• やること：ユーザーの「やりたいこと」を、1Spec=1PRに収まるように分割し、最初に着手すべきスライスを決める。
• やらないこと：具体的な仕様書（Spec）を起こさない。受入条件の詳細化・網羅・Given/When/Then化・テストケース設計は sdd-init / sdd-test-cases の責務。

1Spec=1PR の定義（このスキルの判断基準）

1Spec=1PRとは「単一目的の変更」を「レビュー可能なサイズ」で「自己完結」させた最小の契約単位。 満たせない場合は、必ず分割し直す。

必須条件（満たさないなら分割）

1. 単一目的（Single Purpose）
   • 目的は1文で言える。PRタイトルに “and” が入るなら原則アウト。
2. 自己完結（Self-contained）
   • PR単体で意図・影響範囲・検証方法が追える。
   • 「未使用APIだけ追加」など、利用例のない変更は原則しない（必要なら別スライス化して理由を明示）。
3. レビュー可能（Reviewable）
   • 差分は小さく焦点化。機能変更と大規模整形/移動/リネームを混ぜない。
   • 目安：変更行数 200〜400 を超えるなら分割を検討（超える理由を明記）。1,500行未満を目指す。
4. 検証可能（Verifiable）
   • 受入条件はテストや手順に落とせる形で定義可能であること（詳細化は次フェーズ）。
5. 安全にマージ可能（Safe to merge）
   • マージ後もシステムが壊れない。段階移行が必要なら小バッチ化（必要に応じてフラグ等）。

入力（会話から取得する情報）

• ユーザーの「やりたいこと」（目的、背景、困りごと）
• 期待する成果（何ができれば成功か）
• 制約（期限、互換性、性能、セキュリティ、運用、既存I/F）
• 既知のリスク・不確実点（わからないこと）
• 可能なら：影響範囲の手がかり（関連モジュール名、画面、API名、ログ等）

作業手順（厳守）

1. 意図の要約（1〜3行）
   • ユーザーの意図を短く再記述し、ズレが出やすい言葉（「いい感じに」「適切に」等）は具体化が必要だと明示する。
2. 現状の把握
   • 意思決定に充分な、プロジェクトの現状についての情報を取得
3. 分割の軸を決める（縦スライス優先）
   • レイヤ別（DBだけ/HTTPだけ/UIだけ）で切るのではなく、ユーザー価値が最短で検証できる縦スライスを優先する。
4. 分割案を3つ出す（Small/Medium/Large）
   • 各案に必ず含める：
     • Goal（このSpec=PRで達成すること：1文）
     • Non-Goals（やらないこと：逸脱防止）
     • 想定する変更の粒度（小さめの目安で良い：例「1〜2モジュール」「新規I/Fなし」など）
     • 主なリスク（壊れやすい場所、検証の難所）
     • Open Questions（この段階で未決のまま残すべき点）
5. 推奨分割案を1つ選ぶ（デフォルト）
   • 選定理由を「レビュー容易性」「安全性」「検証可能性」「学習価値（不確実性の解消）」で説明する。
6. 次フェーズ（sdd-init）への入力を整形する
   • sdd-init がSpecドラフトを書けるだけの材料に限定して渡す：
     • 推奨分割案の Goal / Non-Goals / Constraints / Risks / Open Questions
     • 最低限の “例” ：ハッピーケース1つ、代表的失敗ケース1つ（※詳細化や網羅はしない）
     • スコープ境界（触る/触らない領域の宣言）

ストップ条件（ここで止まり、質問 or 追加情報要求）

• 目的が1文に落ちない（複数目的が混ざっている）
• 成功条件が曖昧で、縦スライスが切れない
• 重大な制約（互換性/セキュリティ/運用）が不明で、分割判断ができない
• Open Questions が多く、推奨分割案の成立に直結する

典型的な分割パターン（指針）

• 準備スライス：テスト足場、最小のリファクタ、計測/ログ、依存整備（振る舞い変更は最小）
• 機能スライス：最小価値（ハッピーケース中心）を縦に通す
• 堅牢化スライス：境界条件・異常系・互換性・性能の強化

やってはいけない（アンチパターン）

• 「全部入り」の分割案（受入条件が増え続ける）
• 機能追加と大規模リファクタを同一分割案に混ぜる
• “ついでに” を許す（YAGNI原則違反を誘発）
• 詳細な仕様・テスト設計に踏み込む（sdd-init / sdd-test-cases の領域侵犯）

出力フォーマット（このスキルの返答は必ずこの形）

1) 意図の要約

• （1〜3行）

2) 制約・前提（わかっていること）

• Constraints（制約）:
• Assumptions（仮定）:

3) スライス案（Small / Medium / Large）

• Small:
  • Goal:
  • Non-Goals:
  • 変更の粒度（目安）:
  • Risks:
  • Open Questions:
• Medium:
  • （同上）
• Large:
  • （同上）

4) 推奨スライス（デフォルト）

• 推奨: Small or Medium or Large
• 理由:（レビュー容易性 / 安全性 / 検証可能性 / 不確実性解消）