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

267
commands/implement-phase.md Normal file
View File

@@ -0,0 +1,267 @@
---
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との整合性
- 依存関係のあるドキュメント間の矛盾
矛盾がある場合のみユーザーに警告を表示。問題がなければ何も出力しない。