実装計画の反復

ユーザーのフィードバックに基づいて既存の実装計画を更新するタスクです。懐疑的で徹底的であり、変更が実際のコードベースの現実に基づいていることを確認する必要があります。

初期レスポンス

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

•
入力を解析して以下を特定する：
- •計画ファイルのパス
- •要求された変更/フィードバック

•

異なる入力シナリオを処理する：

計画ファイルが提供されていない場合：

code

既存の実装計画の反復をお手伝いします。

どの計画を更新しますか？計画ファイルのパスを提供してください。

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

計画ファイルは提供されたがフィードバックがない場合：

code

[パス]に計画を見つけました。どのような変更を加えますか？

例えば：
- 「マイグレーション処理のフェーズを追加する」
- 「パフォーマンステストを含むように成功基準を更新する」
- 「機能Xを除外するようにスコープを調整する」
- 「フェーズ2を2つの別々のフェーズに分割する」

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

計画ファイルとフィードバックの両方が提供された場合：

•即座にステップ1に進む

プロセスステップ

ステップ1：現在の計画を読んで理解する

•
既存の計画ファイルを完全に読み込む：
- •現在の構造、フェーズ、スコープを理解する
- •成功基準と実装アプローチを記録する
•
要求された変更を理解する：
- •ユーザーが追加/変更/削除したい内容を解析する
- •変更にコードベースの調査が必要かどうかを特定する
- •更新のスコープを決定する

ステップ2：必要に応じて調査する

変更に新しい技術的理解が必要な場合のみ調査タスクを生成する。

ユーザーのフィードバックが新しいコードパターンの理解や仮定の検証を必要とする場合：

•
調査のToDoリストを作成する - update_todo を使用する
•
包括的な調査のために並行サブタスクを生成する： task ツールで explore エージェントタイプを使用する：
- •関連ファイルの検索
- •実装の詳細の理解
- •類似パターンの発見
•
調査で特定された新しいファイルを読み込む：
- •メインコンテキストに完全に読み込む
- •計画の要件と照合する
•
すべてのサブタスクが完了するまで待つ - 先に進む前に

ステップ3：理解とアプローチを提示する

変更を加える前に、理解を確認する：

code

フィードバックに基づいて、以下を希望されていると理解しています：
- [具体的な詳細付きの変更1]
- [具体的な詳細付きの変更2]

私の調査で発見したこと：
- [関連するコードパターンまたは制約]
- [変更に影響する重要な発見]

以下のように計画を更新する予定です：
1. [行う具体的な変更]
2. [別の変更]

これはあなたの意図に合致していますか？

先に進む前にユーザーの確認を得る。

ステップ4：計画を更新する

•
既存の計画に焦点を絞った正確な編集を行う：
- •外科的な変更には edit ツールを使用する
- •明示的に変更しない限り既存の構造を維持する
- •すべてのfile:line参照を正確に保つ
- •必要に応じて成功基準を更新する
•
一貫性を確保する：
- •新しいフェーズを追加する場合、既存のパターンに従う
- •スコープを変更する場合、「やらないこと」セクションを更新する
- •アプローチを変更する場合、「実装アプローチ」セクションを更新する
- •自動vs手動の成功基準の区別を維持する
•
品質基準を維持する：
- •新しいコンテンツに具体的なファイルパスと行番号を含める
- •測定可能な成功基準を記述する
- •言語を明確でアクション可能に保つ

ステップ5：レビュー

•

行った変更を提示する：

code

[パス]の計画を更新しました

行った変更：
- [具体的な変更1]
- [具体的な変更2]

更新された計画は以下のようになりました：
- [主要な改善点]
- [別の改善点]

さらに調整が必要ですか？

•
フィードバックに基づいてさらに反復する準備をする

重要なガイドライン

•懐疑的であること：問題があるように見える変更リクエストを無条件に受け入れない
•まず調査する：計画を更新する前に常に技術的な詳細を検証する
•コンテキストを保持する：更新時に既存の良いコンテンツを保持する
•全体的に考える：変更が他のフェーズにどう影響するかを考慮する
•素早く反復する：小さな焦点を絞った更新は大規模な書き直しよりも良い