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に進む
プロセスステップ
ステップ1:現在の計画を読んで理解する
既存の計画ファイルを完全に読み込む:
- 現在の構造、フェーズ、スコープを理解する
- 成功基準と実装アプローチを記録する
要求された変更を理解する:
- ユーザーが追加/変更/削除したい内容を解析する
- 変更にコードベースの調査が必要かどうかを特定する
- 更新のスコープを決定する
ステップ2:必要に応じて調査する
変更に新しい技術的理解が必要な場合のみ調査タスクを生成する。
ユーザーのフィードバックが新しいコードパターンの理解や仮定の検証を必要とする場合:
調査のToDoリストを作成する -
update_todoを使用する包括的な調査のために並行サブタスクを生成する:
taskツールでexploreエージェントタイプを使用する:- 関連ファイルの検索
- 実装の詳細の理解
- 類似パターンの発見
調査で特定された新しいファイルを読み込む:
- メインコンテキストに完全に読み込む
- 計画の要件と照合する
すべてのサブタスクが完了するまで待つ - 先に進む前に
ステップ3:理解とアプローチを提示する
変更を加える前に、理解を確認する:
フィードバックに基づいて、以下を希望されていると理解しています:
- [具体的な詳細付きの変更1]
- [具体的な詳細付きの変更2]
私の調査で発見したこと:
- [関連するコードパターンまたは制約]
- [変更に影響する重要な発見]
以下のように計画を更新する予定です:
1. [行う具体的な変更]
2. [別の変更]
これはあなたの意図に合致していますか?
先に進む前にユーザーの確認を得る。
ステップ4:計画を更新する
既存の計画に焦点を絞った正確な編集を行う:
- 外科的な変更には
editツールを使用する - 明示的に変更しない限り既存の構造を維持する
- すべてのfile:line参照を正確に保つ
- 必要に応じて成功基準を更新する
- 外科的な変更には
一貫性を確保する:
- 新しいフェーズを追加する場合、既存のパターンに従う
- スコープを変更する場合、「やらないこと」セクションを更新する
- アプローチを変更する場合、「実装アプローチ」セクションを更新する
- 自動vs手動の成功基準の区別を維持する
品質基準を維持する:
- 新しいコンテンツに具体的なファイルパスと行番号を含める
- 測定可能な成功基準を記述する
- 言語を明確でアクション可能に保つ
ステップ5:レビュー
行った変更を提示する:
[パス]の計画を更新しました 行った変更: - [具体的な変更1] - [具体的な変更2] 更新された計画は以下のようになりました: - [主要な改善点] - [別の改善点] さらに調整が必要ですか?フィードバックに基づいてさらに反復する準備をする
重要なガイドライン
- 懐疑的であること:問題があるように見える変更リクエストを無条件に受け入れない
- まず調査する:計画を更新する前に常に技術的な詳細を検証する
- コンテキストを保持する:更新時に既存の良いコンテンツを保持する
- 全体的に考える:変更が他のフェーズにどう影響するかを考慮する
- 素早く反復する:小さな焦点を絞った更新は大規模な書き直しよりも良い