majiayu000 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（入力・出力・エラー）が不明で例が書けない
- 互換性/セキュリティ/運用などの制約が不明で、仕様が破綻する可能性がある
作業手順（厳守）
- Specファイル名を決める
YYYYMMDDは実行日（ローカル日付）を使用。{name}は推奨スライスを表すslug（kebab-case推奨）。
- テンプレ構造どおりに章立てする
- 見出しを追加しすぎない（必要なら各章の中で小見出しを使う）。
- 曖昧語を排除する
- 「適切に」「いい感じに」「なるべく」は禁止。数値・条件・例に置換できないなら未決事項へ。
- ディレクトリ構造は差分のみ
- 追加/変更が想定されるパスのみ列挙し、既存構造の全文は書かない。
- 未決事項を“決めるべき問い”にする
- 単なる「不明」ではなく、判断に必要な選択肢や影響を添えて問いにする。
生成する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に進めない理由」として明示
// 各項目は “問い” の形で、判断に必要な情報や選択肢を添える