Initial commit

This commit is contained in:
Zhongwei Li
2025-11-30 08:39:29 +08:00
commit f2613ae15b
26 changed files with 5240 additions and 0 deletions

View File

@@ -0,0 +1,210 @@
---
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 Nplan-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の機能定義の整合性
- データ要件と機能要件の整合性
矛盾がある場合のみユーザーに警告を表示。問題がなければ何も出力しない。