8.8 KiB
8.8 KiB
argument-hint, description, allowed-tools
| argument-hint | description | allowed-tools | |||
|---|---|---|---|---|---|
| <タスク名> | 実装概要と調査項目を特定してoverview.mdに追加 |
|
実装概要と調査項目を特定します
タスク名をもとに、overview.mdに実装概要と調査項目を追加します。
重要: このコマンドは実装の大枠（どんな機能を作るか）と調査項目を決定します。詳細な調査は /sdd:conduct-research で実施してください。
【タスク名】 $ARGUMENTS
実行手順
0. ステアリングドキュメントの読み込み
以下のステアリングドキュメントを読み込み、プロジェクトのコンテキストを把握：
specs/_steering/product.md- プロダクト方針specs/_steering/tech.md- 技術スタックspecs/_steering/structure.md- プロジェクト構造specs/_steering/principles.md- 開発原則
ステアリングドキュメントが存在しない場合:
- 警告メッセージを表示: 「⚠️ ステアリングドキュメントが見つかりません。先に
/sdd:steeringを実行することを推奨します。」 - AskUserQuestionツールで確認:
- 「ステアリングドキュメントなしで続行しますか？」
- 選択肢: 「はい（続行）」「いいえ（中断して /sdd:steering を実行）」
- 「いいえ」の場合は処理を中断
1. 引数チェックとoverview.mdの読み込み
$ARGUMENTS が空の場合：
- エラーメッセージ: 「タスク名を指定してください。例:
/sdd:plan-implementation user-authentication」
$ARGUMENTS が指定されている場合：
specs/[taskname]/overview.mdの存在を確認- 存在しない場合: エラーメッセージ「overview.mdが見つかりません。先に
/sdd:init-taskを実行してください。」 - 存在する場合: overview.mdを読み込み
2. 実装する機能の特定
overview.mdの「目的」「スコープ」「想定される成果物」から、実装する機能を特定：
機能特定の流れ:
- overview.mdから実装すべき機能の候補を抽出
- 各機能について、AskUserQuestionで確認・選択させる
- 例: 「ユーザー認証機能を実装しますか？」→ 「はい（必須）」「はい（任意）」「いいえ（不要）」
- 例: 「認証方法はどうしますか？」→ 「JWT」「Session」「OAuth2」
- 例: 「この機能の優先度は？」→ 「High（最優先）」「Medium（通常）」「Low（後回し可）」
- ユーザーが選択した機能のみをリストに追加
- 機能ごとに入出力イメージを記載
技術スタックの決定:
- ステアリングドキュメント（tech.md）を確認
- tech.mdに記載がない技術要素について、複数の選択肢がある場合はAskUserQuestionで選択させる
- 例: 「フロントエンドフレームワークは？」→ 「React」「Vue」「Svelte」
- 例: 「状態管理ライブラリは？」→ 「Redux」「Zustand」「Jotai」「不要」
- ユーザーが選択した技術スタックを記録
- 選択できなかった項目（調査が必要）は調査項目として抽出
3. 調査項目の特定
実装概要から、技術的に不明な点を抽出：
調査項目の判定基準（コマンド内部で使用、specには出力しない）:
- これは本当に技術的に不明な点か？
- ドキュメントを読めばわかることではないか？
- 一般的な実装パターンで解決できないか？
- 複数の選択肢があり、検証が必要か？
調査項目として抽出すべきもの:
- プロジェクト固有の技術的課題
- 複数の技術の組み合わせで生じる不明点
- パフォーマンスやセキュリティの具体的な検証が必要な項目
- 技術選定（複数の選択肢から選ぶ必要がある）
調査項目として抽出すべきでないもの:
- 「ライブラリ選定」のような当たり前の項目
- 公式ドキュメントを読めばわかること
- 一般的な実装パターンで解決できること
調査項目の特定フロー:
- 実装概要から調査が必要そうな項目を全て抽出（制限なし）
- 抽出した全ての項目について、1つずつAskUserQuestionで確認
- 例: 「JWT認証のパフォーマンス検証が必要ですか？」→ 「はい」「いいえ」
- 例: 「この技術選定は調査が必要ですか？」→ 「はい」「いいえ」
- ユーザーが「はい」と選択した項目のみを調査項目リストに追加
- 全ての候補について確認が完了するまで繰り返す
4. overview.mdへの追記
overview.mdに以下のセクションを追加：
## 実装概要
### 実装する機能
1. [機能名1]
- 概要: [1-2行で説明]
- 入力: [概要レベル]
- 出力: [概要レベル]
- 優先度: High/Medium/Low
2. [機能名2]
- 概要: [1-2行で説明]
- 入力: [概要レベル]
- 出力: [概要レベル]
- 優先度: High/Medium/Low
### 技術スタック（候補）
- フロントエンド: [候補]
- バックエンド: [候補]
- データベース: [候補]
- その他: [候補]
## 調査項目
| 状態 | 調査項目名 | 理由 | 概要 |
|------|-----------|------|------|
| 未着手 | [調査項目1] | [なぜこれが不明なのか] | - |
| 未着手 | [調査項目2] | [なぜこれが不明なのか] | - |
---
**次のステップ**:
- 調査が必要: `/sdd:conduct-research [taskname]`
- 調査不要: `/sdd:define-requirements [taskname]`
追記時の注意点:
- 既存の「次のステップ」セクションは削除して上書き
- 調査項目がない場合は「調査項目なし。すぐに要件定義に進めます。」と記載
- 不明な点は「不明」と明記
- 「将来的に」「など」の使用を禁止
- ユーザーがAskUserQuestionで選択した内容をそのまま記載（追加の確認は不要）
5. 完了報告
調査項目がある場合:
✅ 実装概要と調査項目を特定しました
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 更新先: specs/[taskname]/overview.md
📝 実装機能数: [N]件
🔍 調査項目数: [N]件
💡 次のアクション:
- 調査実施: `/sdd:conduct-research [taskname]`
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
調査項目がない場合:
✅ 実装概要を特定しました
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 更新先: specs/[taskname]/overview.md
📝 実装機能数: [N]件
🔍 調査項目: なし
💡 次のアクション:
- 要件定義: `/sdd:define-requirements [taskname]`
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
注意事項
- ⚠️ 重要: 調査が必要そうな項目は全て抽出し、各項目についてユーザーに判断を仰ぐこと
- ⚠️ 重要: 調査項目の数に制限はありません。ユーザーが「必要」と判断した項目のみをリストに追加します
- ⚠️ 重要: ステアリングドキュメント（
specs/_steering/）を必ず読み込み、プロジェクトのコンテキストを反映してください - ⚠️ 重要 不明なところは勝手に決めずに「不明」と明記すること
- 「将来的に必要になる」「今後〜が必要」といった適当な推測に基づいた記述は禁止
- 現時点で明確に必要なことのみを記載すること
内部品質チェック
重要: 以下のチェックはコマンド内部で実施し、生成されるspecファイルには結果を記載しません。
ステアリングドキュメントレビュー（内部処理）
ドキュメント更新後、内部的にステアリングドキュメントとの整合性を確認：
- product.mdのビジネス目標と実装機能の整合性
- tech.mdの技術方針と技術スタック候補の適切性
- structure.mdのプロジェクト構造との整合性
- principles.mdの開発原則との一致
問題がある場合のみユーザーに修正を促す。準拠している場合は何も出力しない。
矛盾チェック（内部処理）
ドキュメント更新後、内部的に仕様書間の矛盾を確認：
- overview.md内の目的・スコープと実装機能の整合性
- 調査項目と実装機能の関連性
矛盾がある場合のみユーザーに警告を表示。問題がなければ何も出力しない。