248 lines
10 KiB
Markdown
248 lines
10 KiB
Markdown
---
|
||
argument-hint: <タスク名> [調査項目名]
|
||
allowed-tools: ["Read", "Write", "Edit", "Bash", "WebSearch", "Task"]
|
||
---
|
||
|
||
# overview.mdの調査項目を実施し、個別ファイルとして保存します
|
||
|
||
このコマンドは `specs/[taskname]/overview.md` の調査セクションから調査項目を読み取り、調査を実施して `specs/research/[調査項目名].md` として保存します。
|
||
|
||
## コマンドの役割
|
||
|
||
**`/sdd:conduct-research`（このコマンド）の役割**:
|
||
- **技術的な調査・検証**を実施
|
||
- AIが自律的に調査・実験・ベンチマークなどを行って判断できる項目
|
||
- 例：
|
||
- ライブラリやフレームワークの選定（性能比較、機能比較）
|
||
- 実装方法の検証（PoC作成、パフォーマンス測定）
|
||
- アーキテクチャの実現可能性調査
|
||
- セキュリティ手法の選定と検証
|
||
|
||
**`/sdd:clarify-spec` との違い**:
|
||
- **clarify-spec**: ビジネス要件やユーザーの意思決定が必要な項目をユーザーに質問
|
||
- **conduct-research**: 技術的な調査が必要な項目をAIが調査・検証
|
||
- clarify-specは「ユーザーに聞く」、conduct-researchは「AIが調べる」
|
||
|
||
**使い分けの例**:
|
||
- ✅ research: 「JWT vs セッション認証のパフォーマンス比較」（技術的検証）
|
||
- ✅ clarify: 「ログイン時にメールアドレスとユーザー名のどちらを使うか」（ビジネス要件）
|
||
- ✅ research: 「PostgreSQL vs MySQL のベンチマーク」（技術的検証）
|
||
- ✅ clarify: 「管理者画面の公開範囲（社内のみ or 顧客も使用）」（ビジネス要件）
|
||
|
||
【引数】
|
||
$ARGUMENTS
|
||
|
||
## 引数の形式
|
||
- `[taskname]` - タスク名のみ指定した場合、全ての未完了調査項目を順に実施
|
||
- `[taskname] [調査項目名]` - 特定の調査項目のみ実施
|
||
- 例: `user-authentication JWT認証のパフォーマンス検証` → 指定された調査項目のみ実施
|
||
|
||
## 実行手順
|
||
|
||
### 1. タスクと調査項目の特定
|
||
|
||
1. **引数が指定されている場合**
|
||
- `[taskname]`のみ: specs/[taskname]/overview.mdの調査セクションから未完了の調査項目を抽出
|
||
- `[taskname] [調査項目名]`: 指定された調査項目のみを対象
|
||
|
||
2. **引数が指定されていない場合**
|
||
- `specs/`ディレクトリ内のサブディレクトリを一覧表示
|
||
- 複数のタスクがある場合、AskUserQuestionツールでユーザーに選択させる
|
||
- 単一のタスクのみの場合は自動選択
|
||
|
||
3. **指定されたタスクディレクトリが存在しない場合**
|
||
- エラーメッセージを表示: 「specs/[taskname]/ ディレクトリが見つかりません」
|
||
- specs/配下の利用可能なタスクを一覧表示
|
||
|
||
### 2. overview.mdの確認
|
||
|
||
1. **ファイルの存在確認**
|
||
- `specs/[taskname]/overview.md` の存在を確認
|
||
- 存在しない場合: エラーメッセージを表示し、`/sdd:init-task` コマンドの実行を提案
|
||
|
||
2. **調査項目の抽出**
|
||
- overview.mdの「調査項目」セクション（表形式）から調査項目を抽出
|
||
- 各調査項目の以下の情報を取得:
|
||
- 状態（未着手/完了）
|
||
- 調査項目名
|
||
- 理由
|
||
|
||
3. **未完了調査項目のリスト表示**
|
||
- 状態が「未着手」の項目を表示
|
||
- 調査項目が全て完了している場合: 完了メッセージを表示して終了
|
||
|
||
### 3. ステアリングドキュメントの読み込み
|
||
|
||
プロジェクト全体のコンテキストを把握するため、以下のステアリングドキュメントを読み込みます：
|
||
|
||
**`specs/_steering/product.md`**:
|
||
- プロダクトの目的とビジョン
|
||
- ターゲットユーザー
|
||
- 主要機能とビジネス目標
|
||
|
||
**`specs/_steering/tech.md`**:
|
||
- 技術スタックとアーキテクチャ
|
||
- 開発標準（型安全性、コード品質、テスト戦略）
|
||
- 重要な技術的決定事項
|
||
|
||
**`specs/_steering/structure.md`**:
|
||
- プロジェクト構造と命名規則
|
||
- コード組織原則
|
||
- モジュール境界
|
||
|
||
**ステアリングドキュメントが存在しない場合**:
|
||
- 警告メッセージを表示: 「⚠️ ステアリングドキュメントが見つかりません。プロジェクト固有のコンテキストなしで進めます。」
|
||
- `/sdd:steering` コマンドでステアリングドキュメントを作成することを推奨
|
||
- 処理は続行（ステアリングドキュメントは必須ではない）
|
||
|
||
### 4. 調査項目の選択
|
||
|
||
**調査項目名が指定されている場合**:
|
||
- 指定された名前の調査項目を特定
|
||
- その調査項目の詳細を表示
|
||
- 手順5へ進む
|
||
|
||
**調査項目名が指定されていない場合**:
|
||
- 未完了の調査項目を表示
|
||
- AskUserQuestionツールを使用してユーザーに選択させる
|
||
- 各調査項目を選択肢として提示
|
||
- 「全て順番に実施」オプションも含める
|
||
|
||
### 5. 調査の実施
|
||
|
||
選択された調査項目について、以下の手順で調査を実施:
|
||
|
||
#### 5-1. 調査内容の確認
|
||
1. **調査項目の詳細を確認**
|
||
- overview.mdから調査項目名と理由を取得
|
||
- 何を調査すべきかを明確に理解
|
||
|
||
2. **調査プランの作成（内部処理）**
|
||
- TodoWriteツールを使用して調査ステップを計画
|
||
- 例:
|
||
- コードベースの既存実装を調査
|
||
- ドキュメント・ベストプラクティスを調査（WebSearchツール使用）
|
||
- PoC実装（必要な場合）
|
||
- ベンチマーク実施（必要な場合）
|
||
- 結果の比較と分析
|
||
- **調査プランはspecファイルには書かない**（内部処理のみ）
|
||
|
||
#### 5-2. 調査の実行
|
||
|
||
調査方法に応じて適切なアプローチを選択:
|
||
|
||
**A. コードベース調査**
|
||
- 既存の実装パターンを確認
|
||
- 使用されているライブラリやフレームワークを確認
|
||
- 類似機能の実装方法を分析
|
||
|
||
**B. ドキュメント調査**
|
||
- WebSearchツールを使用して最新のベストプラクティスを調査
|
||
- 公式ドキュメントを参照
|
||
- 技術記事やブログを調査
|
||
|
||
**C. PoC（Proof of Concept）実装**
|
||
- 小規模な実装例を作成
|
||
- 動作確認とパフォーマンス測定
|
||
- 実装の難易度や工数を評価
|
||
|
||
**D. ベンチマーク**
|
||
- 複数の選択肢を比較
|
||
- パフォーマンス測定
|
||
- リソース使用量の確認
|
||
|
||
#### 5-3. 調査結果のまとめと保存
|
||
|
||
調査完了後、以下の情報をまとめて `specs/[taskname]/research/[調査項目名].md` として保存:
|
||
|
||
```markdown
|
||
# [調査項目名]
|
||
|
||
## 結論
|
||
- 選択: [選択した技術/手法]
|
||
- 理由: [選択の理由を1-3行で簡潔に]
|
||
|
||
## 詳細（必要な場合のみ）
|
||
- パフォーマンス測定結果
|
||
- セキュリティ考慮事項
|
||
- 実装の難易度評価
|
||
- 注意点やリスク
|
||
|
||
## 関連タスク
|
||
- specs/[taskname]/
|
||
```
|
||
|
||
**ファイル名の決定**:
|
||
- 調査項目名をそのままファイル名にする
|
||
- 例: 「JWT認証のパフォーマンス検証」→ `JWT認証のパフォーマンス検証.md`
|
||
|
||
### 6. overview.mdの調査セクション更新
|
||
|
||
#### 6-1. 表の更新
|
||
- overview.mdの調査項目表で、該当行の「状態」列を「完了」に更新
|
||
- 「概要」列に調査結果の簡潔なサマリーと結果ファイルへのリンクを追加:
|
||
```markdown
|
||
| 完了 | [調査項目名] | [理由] | [選択した技術/手法](research/[調査項目名].md) |
|
||
```
|
||
|
||
#### 6-2. 全調査項目完了時の処理
|
||
- 全ての調査項目の状態が「完了」になっている場合
|
||
- overview.mdの「次のステップ」を更新:
|
||
```markdown
|
||
**次のステップ**: `/sdd:define-requirements [taskname]` で要件定義を開始してください
|
||
```
|
||
|
||
### 7. 完了報告
|
||
|
||
```
|
||
✅ 調査項目を完了しました
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
📍 対象タスク: [taskname]
|
||
📝 完了した調査項目: [調査項目名]
|
||
🔍 結論: [選択した技術/手法]
|
||
|
||
📄 保存先: specs/[taskname]/research/[調査項目名].md
|
||
📊 調査の進捗: 完了 {完了数} / {総数}
|
||
|
||
💡 次のアクション:
|
||
- 残りの調査項目: `/sdd:conduct-research [taskname]`
|
||
- 全調査完了: `/sdd:define-requirements [taskname]`
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
```
|
||
|
||
**複数の調査項目を順に実施する場合**:
|
||
- 1つの調査項目が完了したら、次の未完了項目を自動的に表示
|
||
- ユーザーに「続けて次の調査項目を実施しますか？」と確認
|
||
- 承認されたら手順4に戻って次の調査項目を実施
|
||
|
||
## 重要な注意事項
|
||
|
||
- **調査は丁寧に**: 調査は実装の品質を左右する重要なステップです。時間をかけて丁寧に調査してください
|
||
- **エビデンスベース**: 推測ではなく、調査結果（ベンチマーク、ドキュメント、PoC）に基づいて判断すること
|
||
- **調査結果は簡潔に**: 結論と理由を明確に。詳細は必要な場合のみ記載
|
||
- **個別ファイルで管理**: 各調査項目は `specs/research/[調査項目名].md` として個別に保存
|
||
- **調査プランはspecに書かない**: 調査プランは内部処理のみ。結果だけをファイルに保存
|
||
|
||
## 使用例
|
||
|
||
1. タスク全体の調査を順に実施:
|
||
`/sdd:conduct-research user-authentication`
|
||
|
||
2. 特定の調査項目のみ実施:
|
||
`/sdd:conduct-research user-authentication JWT認証のパフォーマンス検証`
|
||
|
||
3. 引数なしで対話的に選択:
|
||
`/sdd:conduct-research`
|
||
|
||
## 内部品質チェック
|
||
|
||
**重要**: 以下のチェックはコマンド内部で実施し、**生成されるspecファイルには結果を記載しません**。
|
||
|
||
### ステアリングドキュメントレビュー（内部処理）
|
||
|
||
調査結果ファイル生成後、内部的にステアリングドキュメントとの整合性を確認：
|
||
- tech.mdの技術方針と調査結果の整合性
|
||
- product.mdのビジネス目標との整合性
|
||
|
||
問題がある場合のみユーザーに修正を促す。準拠している場合は何も出力しない。
|