268 lines
10 KiB
Markdown
268 lines
10 KiB
Markdown
---
|
||
argument-hint: <taskname> [phase.task]
|
||
allowed-tools: ["Read", "Write", "Edit", "Bash", "Task", "AskUserQuestion", "TodoWrite"]
|
||
---
|
||
|
||
# specs/[taskname]/配下の仕様書ドキュメントを読み込み、それに基づいて実装作業を行います
|
||
|
||
以下の引数で指定されたタスクについて、仕様書に基づいた実装作業を行ってください。
|
||
|
||
【引数】
|
||
$ARGUMENTS
|
||
|
||
## 引数の形式
|
||
- `[taskname]` - タスク名のみ指定した場合、そのタスクの最初から作業開始
|
||
- `[taskname] [phase].[task]` - Phase番号とタスク番号を指定した場合、そのタスクから作業開始
|
||
- 例: `user-authentication 2.3` → user-authenticationのphase2のタスク3から開始
|
||
|
||
## 実行手順
|
||
|
||
### 0. TodoWriteで実装ステップをTodoリストに追加
|
||
|
||
コマンド実行時、最初に以下の4つのステップをTodoWriteツールでTodoリストに追加：
|
||
|
||
```
|
||
TodoWrite([
|
||
{
|
||
content: "タスクとPhaseの特定",
|
||
activeForm: "タスクとPhaseを特定中",
|
||
status: "in_progress"
|
||
},
|
||
{
|
||
content: "ステアリングドキュメントと仕様書の読み込み",
|
||
activeForm: "ステアリングドキュメントと仕様書を読み込み中",
|
||
status: "pending"
|
||
},
|
||
{
|
||
content: "Phase状況の確認",
|
||
activeForm: "Phase状況を確認中",
|
||
status: "pending"
|
||
},
|
||
{
|
||
content: "実装作業の実行",
|
||
activeForm: "実装作業を実行中",
|
||
status: "pending"
|
||
}
|
||
])
|
||
```
|
||
|
||
その後、以下のステップを順番に実行し、各ステップ完了時にTodoの状態を更新：
|
||
|
||
### 1. タスクとPhase/タスクの特定
|
||
上記の引数を解析して作業対象を特定：
|
||
|
||
1. **引数が指定されている場合**
|
||
- `[taskname]`のみ: specs/[taskname]/を対象とし、Phase 1から開始
|
||
- `[taskname] [phase].[task]`: specs/[taskname]/を対象とし、指定されたPhaseとタスクから開始
|
||
|
||
2. **引数が指定されていない場合**
|
||
- `specs/`ディレクトリ内のサブディレクトリを一覧表示
|
||
- 複数のタスクがある場合、ユーザーに選択させる：
|
||
「どのタスクで作業しますか？」
|
||
- [1] specs/user-authentication/
|
||
- [2] specs/payment-integration/
|
||
- [3] specs/admin-dashboard/
|
||
- 単一のタスクのみの場合は自動選択
|
||
|
||
3. **指定されたタスクディレクトリが存在しない場合**
|
||
- エラーメッセージを表示: 「specs/[taskname]/ ディレクトリが見つかりません」
|
||
- specs/配下の利用可能なタスクを一覧表示
|
||
|
||
### 2. ステアリングドキュメントの読み込み
|
||
|
||
プロジェクト全体のコンテキストを把握するため、以下のステアリングドキュメントを読み込みます：
|
||
|
||
**`specs/_steering/product.md`**:
|
||
- プロダクトの目的とビジョン
|
||
- ターゲットユーザー
|
||
- 主要機能とビジネス目標
|
||
|
||
**`specs/_steering/tech.md`**:
|
||
- 技術スタックとアーキテクチャ
|
||
- 開発標準（型安全性、コード品質、テスト戦略）
|
||
- 重要な技術的決定事項
|
||
|
||
**`specs/_steering/structure.md`**:
|
||
- プロジェクト構造と命名規則
|
||
- コード組織原則
|
||
- モジュール境界
|
||
|
||
**`specs/_steering/principles.md`**:
|
||
- 開発原則
|
||
|
||
**ステアリングドキュメントが存在しない場合**:
|
||
- 警告メッセージを表示: 「⚠️ ステアリングドキュメントが見つかりません。プロジェクト固有のコンテキストなしで進めます。」
|
||
- `/sdd:steering` コマンドでステアリングドキュメントを作成することを推奨
|
||
- 処理は続行（ステアリングドキュメントは必須ではない）
|
||
|
||
### 3. 仕様書の確認
|
||
選択されたタスクディレクトリ（specs/[taskname]/）から以下のファイルを読み込んで内容を把握：
|
||
|
||
1. **specs/[taskname]/overview.md** - プロジェクト全体の概要とPhase構成を理解
|
||
2. **specs/[taskname]/specification.md** - 機能要件と非機能要件の詳細を確認
|
||
3. **specs/[taskname]/technical-details.md** - 技術的な実装方針を確認
|
||
4. **specs/[taskname]/tasks/phase{N}-{phaseName}.md** - 該当するPhaseの計画書を確認
|
||
|
||
### 4. 現在の状況確認
|
||
以下を確認してユーザーに報告：
|
||
- 各Phaseの現在の状態（未着手/進行中/完了）
|
||
- 実装可能なPhaseの特定（依存関係を考慮）
|
||
- ブロッカーの有無
|
||
|
||
### 5. 作業開始位置の決定
|
||
|
||
#### 5-1. `[phase].[task]` が指定されている場合
|
||
1. 指定されたPhaseファイル（phase{N}-{phaseName}.md）を読み込む
|
||
2. 指定されたタスク番号のタスクを特定
|
||
3. そのタスクの依存関係を確認：
|
||
- 依存関係が満たされていない場合、警告を表示し、ユーザーに続行するか確認
|
||
- 依存関係が満たされている場合、そのまま続行
|
||
4. 指定されたタスクの詳細を表示し、実装計画に進む
|
||
|
||
#### 5-2. `[phase].[task]` が指定されていない場合
|
||
ユーザーに以下を質問：
|
||
「どのPhaseの作業を進めますか？」
|
||
|
||
選択肢：
|
||
- Phase {N}: {phaseName}（状態: 〇〇、依存関係: 〇〇）
|
||
- または、特定のタスク番号を指定（例: 2.3 でPhase 2のタスク3）
|
||
|
||
### 6. タスクの確認と実行計画
|
||
選択されたPhaseまたはタスクについて：
|
||
|
||
1. **仕様の確認**
|
||
- specification.mdから該当機能の詳細仕様を抽出
|
||
- technical-details.mdから技術的な実装方針を確認
|
||
- Phase計画書から具体的なタスクとその依存関係を確認
|
||
|
||
2. **実行可能性の確認**
|
||
- 依存関係が満たされているか確認
|
||
- ブロッカーがないか確認
|
||
- 必要なライブラリやツールが揃っているか確認
|
||
|
||
3. **TodoWriteで実装タスクを追加**
|
||
|
||
Phase計画書のタスクリストから、以下の形式でTodoWriteに実装用Todoを追加：
|
||
|
||
```
|
||
- content: "{タスク名} の実装"
|
||
activeForm: "{タスク名} を実装中"
|
||
status: "pending"
|
||
```
|
||
|
||
**重要**:
|
||
- Phase計画書のタスク1つにつき、Todoアイテム1つを作成
|
||
- タスクの依存関係順に並べる
|
||
- 各Todoには以下の情報を含める：
|
||
- 実装対象のファイルパス
|
||
- 実装する機能の概要
|
||
- テスト対象
|
||
|
||
4. **ユーザーに確認**
|
||
|
||
追加した実装用Todoリストを表示し、AskUserQuestionで確認：
|
||
「この計画で実装作業を開始してよろしいですか？」
|
||
|
||
承認された場合、次のステップへ進む
|
||
|
||
### 7. 実装作業
|
||
承認後、追加した実装用Todoを1つずつ実行：
|
||
|
||
各Todoについて以下の手順で作業：
|
||
|
||
1. **Todoを`in_progress`に更新**
|
||
|
||
2. **実装**
|
||
- specification.mdの要件を満たすコードを実装
|
||
- technical-details.mdの技術方針に従う
|
||
- 既存のコードベースとの整合性を保つ
|
||
- any型は絶対に使用しない
|
||
|
||
3. **品質チェック**
|
||
- コードレビュー基準に従っているか確認
|
||
- エラーハンドリングが適切か確認
|
||
- 関数型プログラミングのスタイルを意識（map/filterの活用）
|
||
|
||
4. **テスト**
|
||
- Phase計画書のテスト計画に従ってテストを実装
|
||
- ユニットテスト
|
||
- 統合テスト（必要に応じて）
|
||
|
||
5. **Todoを`completed`に更新**
|
||
|
||
6. **次のTodoへ** - すべての実装Todoが完了するまで繰り返し
|
||
|
||
### 8. 完了報告と状態更新
|
||
|
||
作業完了後の報告フォーマット：
|
||
|
||
```
|
||
✅ タスク [Phase.Task] の実装が完了しました
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
📍 対象: specs/{taskname}/ - Phase {N}, Task {M}
|
||
|
||
💡 次のアクション:
|
||
- 次のタスク実施: `/sdd:implement-phase {taskname} {phase}.{task+1}`
|
||
- Phase検証実施: `/sdd:verify-phase {taskname} {phase}` （Phase内の全タスク完了時）
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
```
|
||
|
||
**Phase状態の更新**:
|
||
- specs/[taskname]/overview.mdのPhase状態を更新
|
||
- 該当するspecs/[taskname]/tasks/phase{N}-{phaseName}.mdのタスク状態を更新
|
||
- タスク目次の該当タスクの状態とTDDステップを更新
|
||
|
||
### 9. 品質チェックの実施
|
||
作業完了前に必ず以下を確認：
|
||
|
||
- [ ] 仕様書の要件を満たしているか
|
||
- [ ] 依存関係が適切に処理されているか
|
||
- [ ] エラーハンドリングが実装されているか
|
||
- [ ] テストが実装され、パスしているか
|
||
- [ ] any型を使用していないか
|
||
- [ ] 関数型のスタイルを意識しているか（配列操作など）
|
||
- [ ] 既存の類似実装を確認し、重複を避けているか
|
||
- [ ] 既存ライブラリで実現できないか検討したか
|
||
|
||
## 重要な注意事項
|
||
|
||
- 実装中は仕様書（overview.md、specification.md、technical-details.md）を常に参照し、要件から逸脱しないこと
|
||
- Phase計画書の依存関係を必ず確認し、順序を守ること
|
||
- タスク・Phaseの状態を適切に更新すること
|
||
- 不明点や仕様の矛盾があれば、実装前にユーザーに確認すること
|
||
|
||
## 使用例
|
||
|
||
1. タスク全体を最初から開始:
|
||
`/sdd:implement-phase user-authentication`
|
||
|
||
2. Phase 2のタスク3から開始:
|
||
`/sdd:implement-phase user-authentication 2.3`
|
||
|
||
3. 引数なしで対話的に選択:
|
||
`/sdd:implement-phase`
|
||
|
||
## 内部品質チェック
|
||
|
||
**重要**: 以下のチェックはコマンド内部で実施し、**生成されるspecファイルには結果を記載しません**。
|
||
|
||
### ステアリングドキュメントレビュー（内部処理）
|
||
|
||
実装完了後、内部的にステアリングドキュメントとの整合性を確認：
|
||
- product.mdのビジネス目標との整合性
|
||
- tech.mdのコーディング標準との整合性
|
||
- structure.mdの命名規則・モジュール境界の遵守
|
||
- principles.mdの開発原則との一致
|
||
|
||
問題がある場合のみユーザーに修正を促す。準拠している場合は何も出力しない。
|
||
|
||
### 矛盾チェック（内部処理）
|
||
|
||
実装完了後、内部的に仕様書間の矛盾を確認：
|
||
- 実装内容とPhase計画書の整合性
|
||
- specification.mdとの整合性
|
||
- technical-details.mdとの整合性
|
||
- 依存関係のあるドキュメント間の矛盾
|
||
|
||
矛盾がある場合のみユーザーに警告を表示。問題がなければ何も出力しない。
|