sdd-init（Specドラフト作成）

目的

• ユーザーの意図と、sdd-slice-wishで合意した推奨スライスを「契約」として文書化する。
• 以後のTDD（RED）に進めるだけの明瞭さを確保する（最低限の例：ハッピー1＋失敗1）。
• ただし、テストケースの網羅や設計の深掘りはしない（それは sdd-test-cases）。

このスキルの責務 / 非責務（強制）

やること

• docs/specs/YYYYMMDD-{name}.md をテンプレに従って作成する。
• Scope/Non-scope、用語、前提、要件（機能/非機能）、ディレクトリ差分、未決事項を埋める。
• TDDに必要な最低限として、ハッピーケース1つ＋代表的失敗ケース1つを Given/When/Then で記述する（詳細な網羅はしない）。

やらないこと

• 実装、コード変更、テストコードの追加。
• テスト観点の網羅・境界条件列挙・不変条件定義（sdd-test-casesの領域）。
• PR分割の再議論（それは原則 sdd-slice-wish で確定済み）。

入力

• sdd-slice-wish の「次（sdd-initへの入力）」セクション（Goal / Non-Goals / Constraints / 例 / Risks / Open Questions）
• 会話で得られた追加要件（あれば）
• 既存の docs/specs/TEMPLATE.md（存在する場合は参照）

ストップ条件（曖昧なら勝手に進めない）

次のいずれかに該当する場合、Specドラフトの作成はできるが、必ず「未決事項 / オープンクエッション」をブロッカーとして明示し、ユーザーに質問する。
（ブロッカーを解消するまでTDDへ進ませない。）

• 成功条件（Goal）が測定不能（曖昧語のみ）
• 期待するI/F（入力・出力・エラー）が不明で例が書けない
• 互換性/セキュリティ/運用などの制約が不明で、仕様が破綻する可能性がある

作業手順（厳守）

1. Specファイル名を決める
   • YYYYMMDD は実行日（ローカル日付）を使用。
   • {name} は推奨スライスを表すslug（kebab-case推奨）。
2. テンプレ構造どおりに章立てする
   • 見出しを追加しすぎない（必要なら各章の中で小見出しを使う）。
3. 曖昧語を排除する
   • 「適切に」「いい感じに」「なるべく」は禁止。数値・条件・例に置換できないなら未決事項へ。
4. ディレクトリ構造は差分のみ
   • 追加/変更が想定されるパスのみ列挙し、既存構造の全文は書かない。
5. 未決事項を“決めるべき問い”にする
   • 単なる「不明」ではなく、判断に必要な選択肢や影響を添えて問いにする。

生成するSpecの記述ルール（TDDにつなげるための最低限）

• 要件IDを付ける（例：FR-001、NFR-001）。
  ただし、この時点では過剰に細分化しない（多くても数個）。
• エラー仕様は「種類」「観測可能な振る舞い（メッセージ/コード/状態）」を最低限書く。内部実装の都合は書かない。

出力フォーマット（このスキルの成果物）

• docs/specs/YYYYMMDD-{name}.md を作成し、最後にパスを報告する。
  • ユーザーから書き込むファイルを指定されている場合は、それに従う。
• 併せて、ブロッカー（未決事項）がある場合は箇条書きで提示する（ここで解消しない）。

Specテンプレ（このまま書き出す）

以下のフォーマットで docs/specs/YYYYMMDD-{name}.md を作成すること。

# {Title}

## 概要
// 2~3行で
// 何を誰のために、何ができるようになるのか（最小価値）
// sdd-slice-wish の Goal をそのまま短く要約する

## スコープ / 非スコープ
// スコープ: このSpec(=このPR)で確実にやること
// 非スコープ: “やらないこと” を明文化（逸脱防止）
// NOTE: “将来やる” は書いてよいが、このSpecの約束に含めない

## 用語
// ドメイン用語・略語の定義
// 仕様の誤読が起きる単語を優先

## 前提
// Constraints（互換性/権限/依存/運用/既存仕様）
// Assumptions（仮定。仮定は少なく）
// 重要: 仮定が後で覆ると破綻するものは未決事項に回す

## 機能要件
// 要件は “観測可能な振る舞い” として書く（内部実装ではない）
// 要件ID: FR-001, FR-002...
//
// 推奨フォーマット:
// ### FR-001: {要件を1文で}
// - 概要 
/
// NOTE: 境界条件・異常系の網羅は sdd-test-cases でやるため、ここでは増やさない。

## 非機能要件
// 推奨フォーマット:
// ### NFR-001: {要件を1文で}
// - 概要
// 
// 例: 性能、セキュリティ、可用性、監査/ログ、互換性、移行、運用（アラート/ロールバック）
// “目標値があるなら数値で”、なければ制約として明記

## ディレクトリ構造
// 既存のディレクトリ構造との差分のみ記述
// 追加/変更が想定されるパスを箇条書きで

## 未決事項 / オープンクエッション
// ブロッカーは「TDDに進めない理由」として明示
// 各項目は “問い” の形で、判断に必要な情報や選択肢を添える