loop について
loopは、実装とレビュー、修正を繰り返すエージェント向けスキルです。メインエージェントが作業を主導し、レビューが問題なしとなるか、具体的な障害が生じるまで続けます。
主な機能
- 01実装とレビューの反復
- 02対応可能な指摘の修正
- 03無関係なユーザー変更の保持
- 04ToDoリストによる作業管理
- 05修正後の変更検証
活用シーン
- 01複数回のレビューを伴う変更の実装
- 02完了宣言前の不具合確認と修正
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/loopを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
ループ
概要
要求されたタスクを、反復的な実装パイプラインとして実行します。変更を実装し、結果をレビューし、対応可能な問題をすべて修正して、レビューで問題がなくなるか、実際のブロッカーによってこれ以上進められなくなるまで繰り返します。
運用ルール
- オーケストレーターエージェントが責任を持ち続けます。独立した精査にはレビュアーを活用しますが、修正する内容の決定、修正の実施、最終状態の検証はメインエージェントが行います。
- レビューで問題を見つけただけで止めないでください。修正したら、もう一度レビューを実施します。
- レビューでの指摘は、明らかに誤り、重複、利用可能なコンテキストでは対応不可能、またはユーザーの依頼範囲外でない限り、対応可能なものとして扱います。
- 既知の正確性、セキュリティ、データ損失、リグレッション、ビルド、テスト、またはユーザーに見える不具合が残っている状態で、ループが完了したと主張しないでください。
- 関係のないユーザー変更は維持してください。レビューで関係のない未コミットの作業が指摘された場合は、書き換えずにその旨を明示します。
- ハーネスが ToDo リスト、計画、タスクリストに対応している場合は、実装前に明確で詳細な ToDo リストを作成し、レビューと修正の各サイクルを通じて項目の状態を最新に保ちます。
- 長いループでは、特に大幅な編集の前と各レビューサイクルの後に、ユーザーへ進捗を知らせます。
ワークフロー
- タスクを理解し、関連するリポジトリのコンテキストを確認します。
- ハーネスが対応している場合は、実装、検証、レビュー、追加修正を追跡できる、実用的な ToDo リストを作成します。
- リポジトリの既存のパターンに沿って、要求された変更を実装します。
- 変更に最も関連する検証を実施します。
- 実装をレビューします。
- レビューで対応可能な問題が見つかった場合は、修正します。
- 影響を受ける検証を再実施します。
- 再度レビューします。
- 対応可能な指摘がなくなるまで、手順 6〜8 を繰り返します。
- 最終状態、実施した検証、残っているブロッカーや明示的に対応しない問題を報告します。
レビューモード
信頼できる確認ができる範囲で、最小限のレビュー方法を選びます。
- 範囲が狭くリスクの低い単一領域の変更では、セルフレビューを行います。
- 変更範囲が広い場合、セキュリティに関わる場合、複数領域にまたがる場合、コードに不慣れな場合、またはユーザーが独立したレビューを求めている場合は、利用可能であれば並行してレビュアーエージェントを使用します。
- 正確性、テスト、UX、パフォーマンス、セキュリティ、ドキュメントなど、観点ごとに分けることで有用な指摘が増える場合は、レビュアーエージェントを分担させます。
- レビュアーには、タスク、変更したファイルまたは差分、検証結果を共有します。望ましい結論を示したり、追認だけを求めたりしてはいけません。
レビュー基準
各レビューでは、次の点を確認します。
- ユーザーの依頼をすべて満たしているか。
- 変更が既存のアーキテクチャ、命名規則、スタイル、責任範囲に合っているか。
- エラー処理、エッジケース、ロールバックや失敗時の動作が妥当か。
- 変更対象となるリスクの高い動作について、テストや検証で十分に確認できているか。
- 無関係な編集、シークレット、生成物によるノイズ、またはローカル環境だけを前提とした変更がないか。
- 動作を変更した場合、ドキュメントやユーザー向けテキストも更新されているか。
レビュー指摘の修正
対応可能な指摘ごとに、次のことを行います。
- 問題の内容を把握できる程度に再現または調査します。
- 症状だけでなく、根本原因を修正します。
- 動作上のバグで、リポジトリに適切なテストの仕組みがある場合は、テストを追加または更新します。
- まず最も対象を絞った有用な検証を再実施し、リスクやリポジトリの慣例に応じて、より広範なチェックも実施します。
- 指摘と対応状況を簡潔に記録し、レビューサイクルを繰り返しても追跡できるようにします。
修正しない指摘がある場合は、具体的な理由を示す必要があります。その理由は、誤検知、重複、範囲外、前提条件が不足しており対応できない、またはユーザーによるプロダクト上の判断が必要、のいずれかでなければなりません。最終回答では、その理由を明確に報告します。
停止条件
次のいずれかに該当する場合にのみ停止してください。
- レビューで対応が必要な問題が見つからず、関連する検証に合格したか、検証できなかったことを正直に報告している。
- 深刻な解決の試みを行っても同じブロッカーにより進行できない。たとえば、認証情報の不足、サービスの利用不可、外部依存関係の失敗、安全に推測できない曖昧な製品上の判断など。
- ユーザーが明示的に一時停止、停止、または方向転換を求めている。
レビューと修正のサイクルが一度完了しただけで停止しないでください。最初のレビューへの対応が済んだ時点ではなく、作業が問題のない状態になった時点でループを終了してください。
最終回答
次の内容を要約してください。
- 変更内容。
- 実施したレビューサイクルの回数と、最後のレビューの結論。
- 検証コマンドと結果。
- 未修正の指摘事項、ブロッカー、または意図的に保留した内容。
コメント
Markdown 対応