実装計画

インタラクティブで反復的なプロセスを通じて詳細な実装計画を作成するタスクです。懐疑的で徹底的であり、ユーザーと協力して高品質な技術仕様を作成する必要があります。

初期レスポンス

このスキルが呼び出された場合：

•
パラメータが提供されたか確認する：
- •ファイルパスまたはチケット参照が提供された場合、デフォルトメッセージをスキップする
- •提供されたファイルを即座に完全に読み込む
- •調査プロセスを開始する
•
パラメータが提供されていない場合、以下のように応答する：

code

詳細な実装計画の作成をお手伝いします。まず、何を構築するか理解させてください。

以下を提供してください：
1. タスク/チケットの説明（またはチケットファイルへの参照）
2. 関連するコンテキスト、制約、または具体的な要件
3. 関連する調査や以前の実装へのリンク

この情報を分析し、包括的な計画を作成するためにあなたと協力します。

その後、ユーザーの入力を待ちます。

プロセスステップ

ステップ1：コンテキスト収集と初期分析

•
言及されたすべてのファイルを即座に完全に読み込む：
- •チケットファイル、調査ドキュメント、関連する実装計画
- •言及されたJSON/データファイル
- •view ツールを使用してファイル全体を読み込む
- •重要：これらのファイルを自分で読む前にサブタスクを生成しない
•
コンテキスト収集のための初期調査タスクを生成する：ユーザーに質問する前に、task ツールで explore エージェントタイプを使用して並行調査する：
- •チケット/タスクに関連するすべてのファイルを見つける
- •現在の実装がどのように動作するかを理解する
- •この機能に関する既存のドキュメントを見つける
•
調査タスクで特定されたすべてのファイルを読み込む：
- •調査タスク完了後、関連として特定されたすべてのファイルを読み込む
- •これにより、先に進む前に完全な理解が得られる
•
理解を分析して検証する：
- •チケットの要件と実際のコードを照合する
- •不一致や誤解を特定する
- •検証が必要な仮定を記録する

•

情報に基づいた理解と焦点を絞った質問を提示する：

code

チケットとコードベースの調査に基づいて、[正確な要約]が必要であると理解しています。

以下を発見しました：
- [file:line参照付きの現在の実装の詳細]
- [発見された関連パターンまたは制約]
- [特定された潜在的な複雑さまたはエッジケース]

調査で解決できなかった質問：
- [人間の判断が必要な具体的な技術的質問]
- [ビジネスロジックの明確化]
- [実装に影響する設計上の好み]

ステップ2：調査と発見

初期の明確化を得た後：

•
ユーザーが誤解を修正した場合：
- •正しい情報を検証するための新しい調査タスクを生成する
- •ユーザーが言及した具体的なファイル/ディレクトリを読み込む
- •自分で事実を検証してからのみ先に進む
•
調査のToDoリストを作成する - update_todo を使用して探索タスクを追跡する
•
包括的な調査のために並行サブタスクを生成する： task ツールで適切なエージェントタイプを使用する：
- •explore - ファイルの検索、実装の理解、パターンの発見
- •codebase-analyzer - 特定コンポーネントのより深い分析（利用可能な場合）

•

調査結果と設計オプションを提示する：

code

調査に基づいて、以下を発見しました：

**現在の状態：**
- [既存コードに関する主要な発見]
- [従うべきパターンまたは規約]

**設計オプション：**
1. [オプションA] - [長所/短所]
2. [オプションB] - [長所/短所]

**未解決の質問：**
- [技術的な不確実性]
- [必要な設計上の決定]

どのアプローチがあなたのビジョンに最も合致しますか？

ステップ3：計画構造の開発

アプローチが合意された後：

•

初期計画のアウトラインを作成する：

code

提案する計画の構造は以下の通りです：

## 概要
[1〜2文の要約]

## 実装フェーズ：
1. [フェーズ名] - [達成すること]
2. [フェーズ名] - [達成すること]
3. [フェーズ名] - [達成すること]

このフェーズ分けは妥当ですか？順序や粒度を調整すべきですか？

•
詳細を書く前に構造についてフィードバックを得る

ステップ4：詳細計画の作成

構造が承認された後、以下のテンプレートを使用して計画を作成する：

markdown

# [機能/タスク名] 実装計画

## 概要
[何を実装するか、なぜ実装するかの簡単な説明]

## 現状分析
[現在何が存在するか、何が不足しているか、発見された主要な制約]

## 望ましい最終状態
[この計画完了後の望ましい最終状態の仕様とその検証方法]

### 主要な発見：
- [file:line参照付きの重要な発見]
- [従うべきパターン]
- [作業すべき制約]

## やらないこと
[スコープクリープを防ぐためにスコープ外の項目を明示的にリストする]

## 実装アプローチ
[高レベルの戦略と理由]

## フェーズ1：[説明的な名前]

### 概要
[このフェーズで達成すること]

### 必要な変更：

#### 1. [コンポーネント/ファイルグループ]
**ファイル**：`path/to/file.ext`
**変更内容**：[変更の概要]

```[言語]
// 追加/変更する具体的なコード
```

### 成功基準：

#### 自動検証：
- [ ] テスト合格：`npm test` または `make test`
- [ ] 型チェック合格：`npm run typecheck`
- [ ] リンティング合格：`npm run lint`

#### 手動検証：
- [ ] UIでテストした際に機能が期待通りに動作する
- [ ] 関連機能にリグレッションがない

**実装に関する注意**：このフェーズを完了し、すべての自動検証が合格した後、次のフェーズに進む前に手動確認のために一時停止してください。

---

## フェーズ2：[説明的な名前]
[同様の構造...]

---

## テスト戦略

### ユニットテスト：
- [テストすべきこと]
- [主要なエッジケース]

### 統合テスト：
- [エンドツーエンドのシナリオ]

## 参照
- [関連ファイルまたはドキュメント]

ステップ5：レビューと反復

•

計画のドラフトを提示する：

code

実装計画を作成しました。

以下をレビューしてお知らせください：
- フェーズのスコープは適切ですか？
- 成功基準は十分に具体的ですか？
- 調整が必要な技術的詳細はありますか？
- 不足しているエッジケースや考慮事項はありますか？

•
フィードバックに基づいて反復する - ユーザーが満足するまで

重要なガイドライン

•懐疑的であること：仮定せず、調査で検証する
•深く考えること：エッジケース、統合ポイント、障害を考慮する
•具体的であること：ファイルパスと行番号を含める
•品質を維持すること：計画は実行可能で検証可能であるべき
•価値に焦点を当てること：ユーザー向けの改善を優先する
•進んで反復すること：計画は協力によって改善される