@see2et/sdd-slice-wish

---
name: sdd-slice-wish
description: 大きな「やりたいこと」を、1Spec=1PRとしてレビュー可能・検証可能・安全にマージ可能なサイズへスライスする。ここでは具体的な仕様書（受入条件の詳細化・テスト観点の網羅・docs/specs/* の作成）は行わない（それは sdd-init / sdd-test-cases の責務）。出力は「スライス案（S/M/L）」「推奨スライス」「前提・制約・リスク・未決事項」「次フェーズへの入力（sdd-init に渡す要点）」に限定する。
---

# 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
- 理由:（レビュー容易性 / 安全性 / 検証可能性 / 不確実性解消）