# sdd-init

> sdd-slice-wishで決めた「推奨スライス」を入力として、仕様書 docs/specs/YYYYMMDD-{name}.md のドラフトを作成する。ここでは実装もテスト実装も行わない。テストケースの網羅（境界・異常・不変条件の列挙）は sdd-test-cases の責務。

- Author: See2et / しーぜっと
- Repository: See2et/bakopa-vr
- Version: 20251219213927
- Stars: 1
- Forks: 0
- Last Updated: 2026-02-07
- Source: https://github.com/See2et/bakopa-vr
- Web: https://mule.run/skillshub/@@See2et/bakopa-vr~sdd-init:20251219213927

---

---
name: sdd-init
description: sdd-slice-wishで決めた「推奨スライス」を入力として、仕様書 docs/specs/YYYYMMDD-{name}.md のドラフトを作成する。ここでは実装もテスト実装も行わない。テストケースの網羅（境界・異常・不変条件の列挙）は sdd-test-cases の責務。
---

# 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` を作成すること。

```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に進めない理由」として明示
// 各項目は “問い” の形で、判断に必要な情報や選択肢を添える
```