AgentSkillsCN

sdd-slice-wish

将大的“想做的事”切分为1Spec=1PR，可评审、可验证、安全合并的尺寸。此处不进行具体规格书（细化验收条件、覆盖测试视角、docs/specs/*的创建）（那是sdd-init / sdd-test-cases的责任）。输出仅限于“切片方案（S/M/L）”、“推荐切片”、“前提、约束、风险、未决事项”、“下一阶段的输入（传递给sdd-init的要点）”。

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