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