sdd-lite

name	sdd-lite
description	小〜中規模の機能実装向けの軽量な仕様駆動開発ワークフロー。 specファイルから即実装に入る簡易版。 トリガー: /sdd-lite, 軽いspec, 小さい機能の実装、またはsddから「この規模ならliteで十分」と案内された場合。

SDD Lite - 軽量仕様駆動開発

ドキュメントファーストの開発を通じて機能を実装するための構造化されたワークフロー。 小〜中規模のタスクに最適。1セッションで完結することを想定。

ディレクトリのセットアップ

タスク用の仕様ディレクトリを作成します:

mkdir -p ./.specs/{task-name}

タスクに基づいて{task-name}を日本語で命名します（例: 記事コンポーネント作成, ユーザー認証追加）。

フェーズ概要

1. Context Analysis    → 1-context.md
2. Prototyping (opt)   → 2-prototyping-learnings.md
3. Requirements        → 3-requirements.md
4. Design              → 4-design.md
5. Implementation Plan → 5-implementation-plan-{N}.md
6. Implementation      → (PR loop)

各フェーズ: ドキュメント作成 → ユーザーに提示 → 承認を得る → 次のフェーズへ

フェーズ1: コンテキスト分析

既存のコードベースを分析し、パターンと制約を理解します。

.specs/{task-name}/1-context.md を作成します。フォーマットは references/templates.md を参照してください。

内容:

• 技術スタックとフレームワーク
• 関連する既存のコード/コンポーネント
• プロジェクトの規約（命名、構造）
• 制約や制限事項

ユーザーに提示し、次に進む前に承認を得てください。

フェーズ2: プロトタイピング（オプション）

要件定義の前に、使い捨てのプロトタイプを素早く構築してユーザー体験を理解します。

次に進む前に、プロトタイピングを行うかどうかユーザーに確認してください。

実行: /prototype を使用

学びを .specs/{task-name}/2-prototyping-learnings.md に記録します。 学びをユーザーに提示し、次に進む前に承認を得てください。

フェーズ3: 要件定義

タスクが達成すべきことを定義します（方法ではなく何を）。

.specs/{task-name}/3-requirements.md を作成します。フォーマットは references/templates.md を参照してください。

プロトタイピングを実施した場合: 2-prototyping-learnings.md を参照して、発見された知見を取り入れます。

ガイドライン:

• ユーザーストーリー形式を使用する
• 受け入れ基準をチェックボックスとしてリストする
• スコープの境界を定義する（スコープ内/スコープ外）
• 簡潔に保つ: セクションごとに最大5項目
• 技術的な実装の詳細は含めない
• 曖昧な要件には [NEEDS CLARIFICATION] マークを付ける（例: User can authenticate [NEEDS CLARIFICATION: OAuth? Password?]）

すべての [NEEDS CLARIFICATION] マーカーは承認前に解決する必要があります。

ユーザーに提示し、次に進む前に承認を得てください。

フェーズ4: 設計

アーキテクチャレベルでの実装方針を定義します。実装の詳細ではありません。

.specs/{task-name}/4-design.md を作成します。フォーマットは references/templates.md を参照してください。

内容:

• ドメインモデル: コアの型定義のみ（ユーティリティ型や内部の詳細は含まない）
• 機能の境界: どの機能が存在するか、その責務（各1行）、機能間の依存関係
• ディレクトリ構造: 機能レベルのパッケージ構造のみ（各機能内の詳細なファイルは含まない）
• メインフロー: データ変換を伴う主要な処理ステップ（例: validateInput: FormInput → ValidatedInput）
• レイヤー構造: プロジェクトのレイヤー階層における各ロジックの配置場所

設計原則: ロジックをコアに寄せる

フレームワークやインフラストラクチャに依存しないコアロジックを最初に書きます。コアはReact、CLI、サーバーなど、どこで使用されるかを知るべきではありません。

すべてのプロジェクトにはレイヤー階層があります（内側 = より純粋、外側 = より副作用的）。常にロジックをできるだけ内側に寄せます。

例（Reactプロジェクト）:

Core (pure functions) → State (jotai) → Hooks → Components

例（バックエンドプロジェクト）:

Domain Logic → Application Service → Controller → HTTP Handler

プロジェクトのレイヤーを特定し、各ロジックがどこに属するかを文書化します。メリット: テストが容易、再利用性が向上、境界が明確。

ユーザーに提示し、次に進む前に承認を得てください。

フェーズ5: 実装計画

設計をTracer Bullets方式の垂直スライスで分割します。各スライスはすべてのレイヤーをエンドツーエンドで貫通する薄い単位です。

各スライスごとに .specs/{task-name}/5-implementation-plan-{N}.md を作成します。フォーマットは references/templates.md を参照してください。

垂直スライスの原則

• 各スライスは、すべてのレイヤー（スキーマ、API、UI、テスト）を貫通する狭いが完全なパスを提供する
• 完了したスライスは、それ単体でデモまたは検証が可能である
• 少数の厚いスライスよりも、多数の薄いスライスを優先する

ガイドライン

• PRごとに1ファイル
• PRの単位 = レビュー可能なサイズ
• 各PRはレビュー方法を定義する必要がある（テスト、型、動作するUI等）
• 進捗追跡用のチェックボックスタスクを含める
• タスクの依存関係を示す（並列実行可能なもの）
• コミットは提案であり、実装中に調整する

すべての計画をユーザーに提示し、次に進む前に承認を得てください。

フェーズ6: 実装

実装計画をPRごとに実行します。

PRループ

各 5-implementation-plan-{N}.md に対して:

1. タスクを実行する（進行に応じてチェックボックスをチェック）
2. コミットメッセージを提案する（gitコマンドは実行しない）
3. 検証を実行: tsc, lint, test
4. 確認: 学びにより 3-requirements.md または 4-design.md の更新が必要か？
   - はい → ドキュメントを更新し、残りの計画への影響を確認
   - いいえ → 続行
5. ユーザーに提示して承認を得る
6. ユーザーOK → 次のPRへ
   ユーザーNG → フィードバックに対応し、ステップ3から繰り返す

重要なルール

• 3-requirements.md と 4-design.md を厳密に遵守する
• 学びが得られた場合は仕様を直接更新する（別の学びファイルは作成しない）
• コミットメッセージを提案するが、gitコマンドは決して実行しない
• ユーザー確認の前に tsc/lint/test を実行する