name	sdd-documentation
description	ソフトウェア設計ドキュメント（SDD）を作成・管理・実装します。requirements.md、design.md、tasks.mdの作成から、タスク実行・逆順レビューまでの全工程を統括します。SDDワークフロー全体の管理が必要な場合に使用してください。

SDD ドキュメンテーションスキル

ソフトウェア設計ドキュメント（SDD）の作成・管理・実装を統括するオーケストレータースキルです。

概要

このスキルは、以下の4つのサブスキルを連携させて、要件定義から実装までの全工程を管理します：

サブスキル	役割	成果物
requirements-defining	EARS記法による要件定義	docs/requirements.md
software-designing	技術アーキテクチャ設計	docs/design.md
task-planning	AIエージェント向けタスク分解	docs/tasks.md
task-executing	タスク実行・逆順レビュー	実装コード

このスキルを使用する場面

一括初期化

新規プロジェクトでSDDドキュメント一式が必要な場合
docsディレクトリと3つのテンプレートファイルを作成したい場合

全体管理

3つのドキュメント間の整合性を確認したい場合
逆順レビュー（タスク → 設計 → 要件）を実施したい場合
ドキュメント全体の品質をチェックしたい場合

実装フェーズ

tasks.mdに沿って実装を行う場合
実装後の逆順レビュー（実装→タスク→設計→要件）が必要な場合
タスクのステータス管理とGitコミットを統一したい場合

個別作業が必要な場合

特定の工程のみ実施する場合は、各サブスキルを直接使用してください：

要件定義のみ → requirements-defining
設計のみ → software-designing
タスク計画のみ → task-planning
実装のみ → task-executing

ワークフロー

標準フロー（推奨）

┌─────────────────────────────────────────────────────────────┐
│                   sdd-documentation                          │
│                    （このスキル）                             │
│                                                              │
│  1. 初期化                                                   │
│     └─ docsディレクトリと3つのテンプレートを作成             │
│                          ↓                                   │
│  2. requirements-defining                                    │
│     └─ EARS記法で要件定義 → requirements.md                  │
│                          ↓                                   │
│  3. software-designing                                       │
│     └─ 技術設計を文書化 → design.md                          │
│                          ↓                                   │
│  4. task-planning                                            │
│     └─ タスク分解 → tasks.md                                 │
│                          ↓                                   │
│  5. ドキュメント逆順レビュー                                 │
│     └─ tasks → design → requirements の整合性確認           │
│                          ↓                                   │
│  6. task-executing                                           │
│     └─ タスク実行 → 実装コード                               │
│     └─ ステータス更新 → tasks.md                             │
│     └─ コミットテンプレート → Git                            │
│                          ↓                                   │
│  7. 実装逆順レビュー                                         │
│     └─ 実装 → tasks → design → requirements の整合性確認    │
│                          ↓                                   │
│  8. 完了                                                     │
└─────────────────────────────────────────────────────────────┘

各ステップでのユーザー確認

requirements.md作成完了
  ↓
ユーザー確認・承認
  ↓
design.md作成完了
  ↓
ユーザー確認・承認
  ↓
tasks.md作成完了
  ↓
ユーザー確認・承認
  ↓
ドキュメント逆順レビュー
  ↓
タスク実行開始
  ↓
各タスク完了ごとにコミット・ステータス更新
  ↓
実装逆順レビュー
  ↓
完了

ドキュメント初期化

「docsディレクトリを初期化してください」「SDDドキュメントを作成してください」と依頼されたら：

docsディレクトリの作成
requirements.md（要件定義書）の作成
- テンプレート: requirements-defining/assets/templates/requirements_template_ja.md
design.md（設計書）の作成
- テンプレート: software-designing/assets/templates/design_template_ja.md
tasks.md（タスク管理書）の作成
- テンプレート: task-planning/assets/templates/tasks_template_ja.md

逆順レビュープロセス

レビューの流れ

tasks.md → design.md → requirements.md

ステップ1: タスク → 設計の整合性チェック

チェック項目	確認内容
コンポーネント対応	タスクが参照するコンポーネントはdesign.mdに定義されているか
API対応	タスクで実装するAPIはdesign.mdのAPI設計と一致しているか
データモデル対応	タスクで使用するデータ構造はdesign.mdのスキーマと一致しているか
技術スタック	タスクで使用する技術はdesign.mdの技術的決定事項と一致しているか

ステップ2: 設計 → 要件の整合性チェック

チェック項目	確認内容
機能カバレッジ	すべての要件（REQ-XXX）に対応する設計要素があるか
非機能要件対応	NFR-XXXの要件が設計に反映されているか
過剰設計チェック	requirements.mdにない機能が設計に含まれていないか

不整合発見時の報告

ドキュメントの整合性チェックで以下の不整合を発見しました：

【タスク → 設計の不整合】
1. タスク2.1で「PaymentService」を実装するとありますが、
   design.mdにPaymentServiceの定義がありません。

【設計 → 要件の不整合】
2. design.mdに「通知機能」がありますが、
   requirements.mdに対応する要件がありません。

【過不足】
3. REQ-005（レポート出力機能）に対応するタスクがありません。

これらについて確認させてください：
1. PaymentServiceの設計を追加しますか？
2. 通知機能は必要ですか？
3. REQ-005のタスクを追加しますか？

検証チェックリスト

全体チェック

docsディレクトリが存在する
requirements.md、design.md、tasks.mdの3ファイルが存在する
3ドキュメント間の整合性が取れている
逆順レビューが完了している

要件定義書

ユーザーストーリーが明確に定義されている
すべての要件がEARS記法に従っている
要件IDが一意である（REQ-XXX、NFR-XXX）
各要件がテスト可能である

設計書

アーキテクチャ概要が記載されている
主要コンポーネントが定義されている
技術的決定事項と根拠が記載されている
情報の明確性チェックが完了している

タスク管理書

タスクが適切な粒度に分解されている（20-40分程度）
各タスクに受入基準がある
TDD手順が含まれている
推測に基づく実装指示が含まれていない

EARS記法クイックリファレンス

パターン	形式	使用場面
基本	`システムは〜しなければならない`	常時適用される要件
イベント	`〜の時、システムは〜しなければならない`	イベント駆動要件
条件	`もし〜ならば、システムは〜しなければならない`	状態依存要件
継続	`〜の間、システムは〜しなければならない`	継続的要件
場所	`〜において、システムは〜しなければならない`	コンテキスト固有要件

ユーザーとの対話ガイドライン

情報分類プロセス

すべてのドキュメント作成において：

明示された情報: ユーザーが明確に述べた要件、仕様、制約
不明な情報: 推測が必要な項目（「おそらく〜」は不明として扱う）

確認の形式

ドキュメント作成の前に、以下の点を確認させてください：

【明示された情報】
- [ユーザーから明示的に指定された内容]

【不明/要確認の情報】
1. [項目1]: [選択肢A] / [選択肢B] / その他
2. [項目2]: [具体的な質問]

上記の不明点について教えていただけますか？

サブスキルへのリンク

要件定義: requirements-defining/SKILL.md
設計: software-designing/SKILL.md
タスク計画: task-planning/SKILL.md
タスク実行: task-executing/SKILL.md

Gitコミットテンプレート

task-executingスキルで使用するコミットテンプレート：

実装コミット

[タスクID] タスクタイトル

## 実装内容
- 実装した機能の説明

## 受入基準の達成状況
- [x] 基準1
- [x] 基準2

## 関連ドキュメント
- docs/tasks.md: タスクID
- docs/design.md: 関連コンポーネント
- docs/requirements.md: 関連要件ID

## テスト
- テスト実行結果

ステータス更新コミット

Update tasks.md: タスクID completed

タスクタイトルを完了としてマーク。
完了サマリー: [1行の要約]

リソース

ワークフローガイド: references/workflow_guide_ja.md
各サブスキルのテンプレート・リファレンスは各スキルディレクトリを参照

Install Skill

SKILL.md