/gen-l1

L1 生成コマンド

<tri_ssd_context> Tri-SSD（Tri-Layer Slice Spec Driven）はAI/LLMコードエージェントを前提とした仕様駆動開発。

レイヤー構造:

• L0: アイディア・ラフメモ（docs/l0_ideas/）- 任意
• L1: 要件（docs/l1_requirements/vision.md）
• L2: システム構成（docs/l2_foundation/foundation.md）
• L3: フェーズ（docs/l3_phases/PH-xxx.md）- 機能+受け入れ条件

ID形式: PREFIX-nnnn（REQ, PH, F） </tri_ssd_context>

概要

L1（要件・意思決定）ドキュメントを生成する。対話モードまたは既存ドキュメント変換モードで動作。 コードからは読み取れない「なぜその要求が必要か」「なぜそのアプローチを選んだか」を記録する意思決定書を作成する。

引数

• $1 (省略可): 変換元ドキュメントパス
  • 指定あり → 変換モード（既存ドキュメントをL1形式に変換）
  • 省略 → 対話モード（ヒアリングでL1を作成）

使用例

/gen-l1                           # 対話モード
/gen-l1 docs/existing-spec.md     # 既存ドキュメントを変換
/gen-l1 README.md                 # READMEから要件を抽出

原則

<avoid_over_engineering>

• 必要以上に詳細を聞き出さない（技術詳細はL2で決める）
• 「わからない」→ TODOマークして先に進む
• 機能要求は概要レベルで十分（詳細はL3フェーズ）
• 元ドキュメントにない情報を推測・捏造しない
• 「背景・動機」は要点が伝われば十分。ただし1文で済ませず、背景・理由・期待する効果を含めて3-5文程度を目安にする
• 「なぜ必要か」は必ず聞く。機能名だけのリストにしない </avoid_over_engineering>

前提処理

1. $1 があれば変換元ファイルを読み込む
2. docs/l0_ideas/ にファイルがあれば読み込む（→ L0参照フローへ）
3. docs/l1_requirements/vision.md が存在するか確認（再生成モード判定）

---

出力フォーマット（必須）

必須構造

# [プロダクト名] 要件・意思決定ドキュメント

## 1. プロダクトの意思と背景
### 1.1 解決したい課題・ペイン
### 1.2 想定ユーザー／ペルソナ
### 1.3 ビジネス上のゴール
### 1.4 このプロダクトで大事にすること（省略可）

## 2. 制約条件・前提（省略可）
### 2.1 動作環境
### 2.2 法規制・コンプライアンス
### 2.3 外部システム連携

## 3. 要求と意思決定
### [要求名]
- **ID**: REQ-nnnn
- **優先度**: 高/中/低
- **背景・動機**: なぜこの要求が必要か。どんな課題を解決し、どんな効果を期待するか。（3-5文）

[概要説明]

**却下した代替案**（省略可）:
- [代替案] → [採用しなかった理由]

## 4. 非機能要求（高レベル・省略可）

## 5. 参考・類似サービス（省略可）

省略可能: セクション1.4, 2, 4, 5, 各REQの「却下した代替案」 必須: セクション1 (1.1-1.3), 3（各REQに「背景・動機」を含む）

---

変換モード（$1 指定時）

変換手順

1. 元ドキュメント分析: 構造把握、要件抽出、技術詳細とL1相当を分離
2. 情報マッピング:

   L1 セクション	抽出対象
   プロダクトの意思と背景	概要、背景、目的、設計方針
   制約条件	動作環境、前提条件
   要求と意思決定	機能一覧、ユースケース、設計理由・方針の記述
   非機能要求	性能、セキュリティ等

3. 意図の確認: 元ドキュメントから「背景・動機」が読み取れない要求をリストアップし、ユーザーに「なぜこの機能が必要ですか？」と確認。回答をREQの「背景・動機」に反映
4. REQ ID付与: 連番
5. 不足情報: <!-- TODO: 要確認 --> でマーク

既存L1がある場合

• 上書き: 既存を破棄して新規作成
• マージ: 既存と変換元を統合（REQ ID継続）
• キャンセル: 変換を中止

---

L0参照（docs/l0_ideas/ にファイルがある場合）

1. L0ファイルをすべて読み込む
2. アイディアの概要をユーザーに提示して確認
3. 各アイディアについて以下を聞き取る:
   • これはどんな課題を解決するものですか？
   • なぜこのアプローチを考えましたか？
   • 優先度は高いですか？
4. 聞き取った意図をREQエントリの「背景・動機」に反映

---

対話モード（$1 省略時）

対話フロー

Step 1: プロダクトの意思

1. 何を作りたいですか？（プロダクト名・概要）
2. なぜ作りたいのですか？（きっかけ・課題・不満）
3. 誰のためのものですか？（ペルソナ・利用シーン）
4. このプロダクトで最も大事にしたいことは？（省略可）

Step 2: 要求と意思決定

1. ユーザーにどんな体験・価値を届けたいですか？
2. その体験を実現するために、何が必要だと考えていますか？
   • 各要求について「なぜそれが必要か」も教えてください
3. 優先度が高いのはどれですか？その理由は？
4. 検討したが「やらない」と決めたことはありますか？（省略可）

Step 3: 制約・非機能（簡潔に）

1. 動作環境（Web/モバイル等）は？
2. 特別なセキュリティ・性能要件は？
3. 参考にしたい類似サービスは？（省略可）

---

再生成モード（既存L1がある場合・対話モード時）

1. 既存ファイル読み込み、内容把握
2. ユーザーに確認：
   • 追記: 新しい要件を追加（REQ ID継続）
   • 修正: 既存要件を変更（影響範囲を報告）
   • 深掘り: TODO箇所を詳細化
   • 最初から: 既存を破棄して新規作成

保持するもの

セクション	理由
既存のREQ ID	トレーサビリティ維持

---

出力仕様

• ファイルパス: docs/l1_requirements/vision.md
• 曖昧箇所: <!-- TODO: 要確認 --> でマーク
• REQ ID: 連番（REQ-nnnn）

ID採番ロジック

1. 既存REQ IDを検索（Grepで docs/**/*.md から）
2. 最大番号 + 1 で新ID生成（4桁ゼロ埋め）

完了後の案内

• 作成ファイルのパスを報告
• 変換モード時: 抽出できなかった情報を一覧表示
• /gen-l2 で L2 生成できることを案内

---

エラーケース

ケース	対応
変換元ファイルが存在しない	エラー: 「指定されたファイルが見つかりません」
変換元が空ファイル	エラー: 「ファイルが空です」
docs/ が存在しない	警告: 「/init-tri-ssd を先に実行することを推奨します」