---
argument-hint: <タスク名>
description: 機能要件と非機能要件の詳細仕様を作成
allowed-tools: ["Read", "Write", "Task", "AskUserQuestion"]
---

# 詳細要件仕様書を作成します

タスクの機能要件と非機能要件を詳細化し、`specification.md` を生成します。

【対象タスク名】
$ARGUMENTS

## 実行手順

### 0. ステアリングドキュメントの読み込み

以下のステアリングドキュメントを読み込み、プロジェクトのコンテキストを把握：

- `specs/_steering/product.md` - プロダクト方針、ビジネス目標
- `specs/_steering/tech.md` - 技術標準
- `specs/_steering/structure.md` - プロジェクト構造

**ステアリングドキュメントが存在しない場合**:
- 警告メッセージを表示: 「⚠️ ステアリングドキュメントが見つかりません。先に `/sdd:steering` を実行することを推奨します。」

### 1. タスクディレクトリの確認

タスク名が指定されている場合:
- `specs/[taskname]/` ディレクトリの存在を確認
- `specs/[taskname]/overview.md` が存在するか確認

タスク名が指定されていない場合:
- `specs/` ディレクトリ内の利用可能なタスクをリスト表示
- **AskUserQuestionツールを使用**してどのタスクについて作業するかユーザーに選択を求める

### 2. 既存ドキュメントの読み込み

以下のドキュメントを読み込み、要件定義に必要な情報を抽出：

- `specs/[taskname]/overview.md` - プロジェクト概要、主要機能
- `specs/_steering/product.md` - プロダクトの Non-Goals、Business Objectives
- `specs/_steering/tech.md` - 技術的制約

### 3. 非機能要件の確認

以下の非機能要件について、ユーザーに必要かどうかを確認してください：

**AskUserQuestionツールを使用**して、以下を確認：

```
以下の非機能要件について、このタスクで必要なものを選択してください（複数選択可）：

□ パフォーマンス要件（レスポンスタイム、同時接続数、データ処理量など）
□ 可用性要件（稼働率目標、ダウンタイム許容範囲、障害復旧時間など）
□ 保守性要件（コード品質基準、ドキュメント要件、技術的負債の管理など）
□ ユーザビリティ要件（UI/UX要件、アクセシビリティ、多言語対応など）
□ 制約条件（技術的制約、ビジネス的制約、法的・規制上の制約など）
□ テスト戦略（テストの種類、カバレッジ目標など）
□ 開発環境（必要なツール、セットアップ手順など）

注: セキュリティ要件は常に含まれます
```

### 4. specification.mdの生成

`specs/[taskname]/specification.md` を生成：

```markdown
# 詳細仕様書

## 機能要件

[overview.mdの主要機能を詳細化]

### 機能1: [機能名]
- **概要**: [1-2行で機能を説明]
- **優先度**: High/Medium/Low
- **実装Phase**: Phase N（plan-phasesで決定後に追加）
- **入出力定義**:
  - **入力**:
    - パラメータ名: 型、説明
    - パラメータ名: 型、説明
  - **出力**:
    - レスポンス形式
    - 成功時の戻り値
    - エラー時の戻り値
- **制約・注意事項**（必要な場合のみ）:
  - [制約事項や注意点]

### 機能2: [機能名]
...

## 非機能要件

### セキュリティ（必須）
- **認証・認可要件**: [steering/tech.mdから関連する標準を参照]
- **データ暗号化**: [要件]
- **監査ログ**: [要件]
- **セキュリティ標準**: [steering/tech.mdのセキュリティ要件を参照]

[ユーザーが選択した非機能要件のみ以下に含める]

### パフォーマンス（選択時のみ）
- **レスポンスタイム要件**: [具体的な数値]
- **同時接続数**: [具体的な数値]
- **データ処理量**: [具体的な数値]
- **スループット目標**: [具体的な数値]

### 可用性（選択時のみ）
- **稼働率目標**: [例: 99.9%]
- **ダウンタイム許容範囲**: [例: 月間43分以内]
- **障害復旧時間**: [RTO/RPO]
- **監視要件**: [監視項目]

### 保守性（選択時のみ）
- **コード品質基準**: [steering/tech.mdの品質標準を参照]
- **ドキュメント要件**: [要求されるドキュメント]
- **技術的負債の管理**: [方針]
- **リファクタリング方針**: [方針]

### ユーザビリティ（選択時のみ）
- **UI/UX要件**: [要件]
- **アクセシビリティ**: [WCAG準拠レベルなど]
- **多言語対応**: [対応言語]
- **レスポンシブデザイン**: [対応デバイス]

## データ要件

### データモデル概要
[主要なデータエンティティとその関係]

### データ保持期間
[データ種別ごとの保持期間]

### データ移行要件
[既存データからの移行が必要な場合]

## インターフェース要件

### 外部システム連携
[連携する外部システム]

### API仕様概要
[APIの概要、詳細はtechnical-details.mdで定義]

### データフォーマット
[JSON, XML, CSVなど]

## 制約条件（選択時のみ）

### 技術的制約
[steering/tech.mdから関連する制約を参照]

### ビジネス的制約
[steering/product.mdから関連する制約を参照]

### 法的・規制上の制約
[GDPR, 個人情報保護法など]
```

**生成時の注意点**:
- **⚠️ 重要**: 詳細であれば詳細であるほど良いわけではない。必要な部分だけを必要なだけ書くこと
- **⚠️ 重要**: 推測される開発期間、工数、見積もり時間などは一切記載しないこと
- **⚠️ 重要**: 「将来的に必要になる」「今後〜が必要」といった適当な推測に基づいた記述は禁止
- 不明なところは勝手に決めずに「**不明**」と明記し、複数の案（案A、案B、案Cなど）を記述すること
- ステアリングドキュメントの情報を積極的に参照・活用すること
- 実装Phase番号は空欄にする（plan-phasesで決定後に追加）

### 5. 完了報告

```
✅ 詳細要件仕様書を作成しました
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 作成先: specs/[taskname]/specification.md
📝 機能要件: [N]件

💡 次のアクション:
   - 技術詳細化: `/sdd:define-technical [taskname]`
   - 不明点の明確化: `/sdd:clarify-spec [taskname]`
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

## 注意事項

- **⚠️ 重要**: ステアリングドキュメントを必ず参照し、プロジェクトの方針や標準に準拠すること
- 不明なところは勝手に決めずに「**不明**」と明記すること
- ユーザーが選択しなかった非機能要件セクションは含めないこと
- specification.mdは機能要件の詳細を記述する場所（技術実装の詳細はtechnical-details.mdで記述）

## 内部品質チェック

**重要**: 以下のチェックはコマンド内部で実施し、**生成されるspecファイルには結果を記載しません**。

### ステアリングドキュメントレビュー（内部処理）

ドキュメント生成後、内部的にステアリングドキュメントとの整合性を確認：
- product.mdのビジネス目標・ターゲットユーザーとの整合性
- tech.mdのセキュリティ要件との整合性
- structure.mdのプロジェクト構造との整合性

問題がある場合のみユーザーに修正を促す。準拠している場合は何も出力しない。

### 矛盾チェック（内部処理）

ドキュメント生成後、内部的に仕様書間の矛盾を確認：
- overview.mdとspecification.mdの機能定義の整合性
- データ要件と機能要件の整合性

矛盾がある場合のみユーザーに警告を表示。問題がなければ何も出力しない。