| name | jp-iterate-plan |
| description | 徹底的な調査と更新で既存の実装計画を反復します。新しい情報やフィードバックに基づいて既存の計画を変更、拡張、または改善する必要がある場合に使用します。 |
| compatibility | GitHub Copilot CLI用に設計 |
| metadata | {"author":"humanlayer","version":"1.0","original-source":"https://github.com/humanlayer/humanlayer"} |
実装計画の反復
ユーザーのフィードバックに基づいて既存の実装計画を更新するタスクです。懐疑的で徹底的であり、変更が実際のコードベースの現実に基づいていることを確認する必要があります。
初期レスポンス
このスキルが呼び出された場合：
-
入力を解析して以下を特定する：
- 計画ファイルのパス
- 要求された変更/フィードバック
-
異なる入力シナリオを処理する：
計画ファイルが提供されていない場合：
既存の実装計画の反復をお手伝いします。
どの計画を更新しますか？計画ファイルのパスを提供してください。
ユーザーの入力を待ちます。
計画ファイルは提供されたがフィードバックがない場合：
[パス]に計画を見つけました。どのような変更を加えますか？
例えば：
- 「マイグレーション処理のフェーズを追加する」
- 「パフォーマンステストを含むように成功基準を更新する」
- 「機能Xを除外するようにスコープを調整する」
- 「フェーズ2を2つの別々のフェーズに分割する」
ユーザーの入力を待ちます。
計画ファイルとフィードバックの両方が提供された場合：
プロセスステップ
ステップ1：現在の計画を読んで理解する
-
既存の計画ファイルを完全に読み込む：
- 現在の構造、フェーズ、スコープを理解する
- 成功基準と実装アプローチを記録する
-
要求された変更を理解する：
- ユーザーが追加/変更/削除したい内容を解析する
- 変更にコードベースの調査が必要かどうかを特定する
- 更新のスコープを決定する
ステップ2：必要に応じて調査する
変更に新しい技術的理解が必要な場合のみ調査タスクを生成する。
ユーザーのフィードバックが新しいコードパターンの理解や仮定の検証を必要とする場合：
-
調査のToDoリストを作成する - update_todo を使用する
-
包括的な調査のために並行サブタスクを生成する：
task ツールで explore エージェントタイプを使用する：
- 関連ファイルの検索
- 実装の詳細の理解
- 類似パターンの発見
-
調査で特定された新しいファイルを読み込む：
- メインコンテキストに完全に読み込む
- 計画の要件と照合する
-
すべてのサブタスクが完了するまで待つ - 先に進む前に
ステップ3：理解とアプローチを提示する
変更を加える前に、理解を確認する：
フィードバックに基づいて、以下を希望されていると理解しています：
- [具体的な詳細付きの変更1]
- [具体的な詳細付きの変更2]
私の調査で発見したこと：
- [関連するコードパターンまたは制約]
- [変更に影響する重要な発見]
以下のように計画を更新する予定です：
1. [行う具体的な変更]
2. [別の変更]
これはあなたの意図に合致していますか？
先に進む前にユーザーの確認を得る。
ステップ4：計画を更新する
-
既存の計画に焦点を絞った正確な編集を行う：
- 外科的な変更には
edit ツールを使用する
- 明示的に変更しない限り既存の構造を維持する
- すべてのfile:line参照を正確に保つ
- 必要に応じて成功基準を更新する
-
一貫性を確保する：
- 新しいフェーズを追加する場合、既存のパターンに従う
- スコープを変更する場合、「やらないこと」セクションを更新する
- アプローチを変更する場合、「実装アプローチ」セクションを更新する
- 自動vs手動の成功基準の区別を維持する
-
品質基準を維持する：
- 新しいコンテンツに具体的なファイルパスと行番号を含める
- 測定可能な成功基準を記述する
- 言語を明確でアクション可能に保つ
ステップ5：レビュー
-
行った変更を提示する：
[パス]の計画を更新しました
行った変更：
- [具体的な変更1]
- [具体的な変更2]
更新された計画は以下のようになりました：
- [主要な改善点]
- [別の改善点]
さらに調整が必要ですか？
-
フィードバックに基づいてさらに反復する準備をする
重要なガイドライン
- 懐疑的であること：問題があるように見える変更リクエストを無条件に受け入れない
- まず調査する：計画を更新する前に常に技術的な詳細を検証する
- コンテキストを保持する：更新時に既存の良いコンテンツを保持する
- 全体的に考える：変更が他のフェーズにどう影響するかを考慮する
- 素早く反復する：小さな焦点を絞った更新は大規模な書き直しよりも良い
