loop-readiness

ループの準備状況レビュー

これは準備状況のレビューであり、ゲートではありません。合格／不合格の判定や、単一の総合スコアを出すことはありません。各観点で何が整っていて、何が不足しているか、何を検討すべきかを報告することで、ループを開始するかどうかを判断する人に全体像を示します。

ここでいう「ループ」とは、すべてのステップを人間が確認することなく複数回のイテレーションを実行するエージェントやプロセスを指します。オートパイロット、スケジュールされたジョブ、長時間実行されるエージェントのワークフローなどが該当します。このレビューでは、ループ自体ではなく、そのループの計画を確認します。このレビュー中に実行されるものはありません。

ステップ 1：計画を確認する

• 計画がテキストまたはファイルパスとして提示されている場合は、それを使用します。
• 提示されていない場合、利用可能であれば grill-design スキルを使用します。そうでなければ、計画の理解を深めるために、ユーザーに一度に一つずつ質問します。計画で何を実現しようとしているのか、また、どうすれば正常に動作していると判断できるのかを確認します。1 ターンにつき質問は 1 つだけとし、複数の内容をまとめた質問はしません。

ステップ 2：各観点をレビューする

4 つすべてを確認します。それぞれについて、何が整っているか、何が不足しているか、カバー範囲がどの程度深いかを記録します。機械的に埋める固定チェックリストはありません。そのループに実際に必要な深さを判断してください。

2.1 準備完了の定義（DoR）

このループの目的と範囲を定義した文書はありますか？ループによっては、目標の記述、明示的な非目標／範囲外の項目、コントラクト（データの形式、API の境界）、UI のモックや図などが該当します。関係するリスクに応じて、妥当な深さまで確認してください。小規模なループであれば一行の目標で十分な場合もありますが、本番データを扱うループには、さらに詳細な記述が必要でしょう。

2.2 フィードフォワード

フィードフォワードとは、ループが最初から適切に動作する可能性を高めるために、各イテレーションの前または実行中に与えるガイダンスです。規約に関するドキュメント、スキル、コントラクト、ブートストラップスクリプト、コード変換ツールなど、ループが動作中に読み込むもの、または制約として従うものが該当します。このガイダンスが次のどれに当たるかを記録します。

• 計算的 — 必ず通す決定論的なツール／スクリプト／ジェネレーター
• 推論的 — 読み込んで判断を適用するドキュメント／スキル
• 両方、またはいずれでもない

2.3 フィードバック

フィードバックとは、不適切な結果を検出するために、イテレーション／アクションの後に行う検証です。健全なループには通常、少なくとも 1 種類のフィードバックが必要ですが、どの種類をいくつ使うかは、そのループが実際に引き起こし得る問題に基づいて判断します。次の点を確認します。

• 計算的／モック／ドライラン — 単体テスト、リンター、型チェック、構造チェックなど。低コストかつ高速で、各イテレーションで実行できますが、現実の環境で起きる障害を見逃したまま成功することがあります。これだけが存在するフィードバック手段である場合は、このトレードオフを記録してください。
• 実環境 — ループが動作する実際のシステムに対する検証です。実施されているか、また、人の立ち会いなしで安全に実行できるように見えるかを記録します（ステップ 3 の具体的なチェックを参照してください。ここにも適用されます）。
• 推論的 — 決定論的なチェックではなく、LLM を審査役とする評価やレビューのステップによって、結果について意味的な判断を行うものです。

2.4 完了の定義（DoD）

計画には、ループが実際にどう終了するかが記載されていますか？必須の用語や固定された終端状態のセットはありません。作成者が定義した方法でループを終了できます。計画が正常終了の経路以外も考慮しているかを記録してください。失敗した場合はどうなるのか、また、ループが成功したかどうかを判断できない場合（結果が曖昧、前提条件が欠けているなど）はどうなるのかを確認します。こうした項目がなければ、特定の修正を求めずに、不足事項として明らかにする価値があります。

ステップ 3：報告

上記の4つの各観点について、以下を作成します。

• 存在するもの／不足しているもの／一部のみ存在するものをまとめた短いチェックリスト
• その観点に限った定性的な所見を1行で記載します（例：「十分」「限定的」「欠落」）

これらを1つの総合スコアや評価にまとめてはいけません。4つの所見はそれぞれ独立したものとして扱い、判断は読者に委ねます。

続いて、見つかった具体的なギャップに結び付けた実行可能な推奨事項を追加します。「これが不足しています」と述べるだけでなく、具体的な次のステップを提示してください。2.3で実環境に関するフィードバックが見つかった場合は、次の項目を直接確認してください（ここは静的レビュー向きです。通常、説明された計画から明確に「はい」か「いいえ」で判断できます）。不足している項目があれば、それぞれ修正を推奨してください。

• ループが実作業を始める前に、認証情報や権限が実際に機能することを確認する事前チェックの手順がありますか（機能すると想定しているだけではありません）？ なければ、追加を推奨してください。ループを無人で実行する前に、実システムに対して1回テストします。
• 計画が既存のものとして扱うフィードバックの仕組み（ゲートスクリプト、テストスイート、以前の作業から引き継いだチェックなど。ループが新たに構築するものではないもの）は、計画作成後にスモークテストされていますか？ 静的レビューでゲートの説明が正確だと確認できても、計画と実行の間に無関係な変更が入り、ゲートが気付かれないまま壊れている可能性があります（たとえば、ハードコードされたパスが別の場所で変更された場合など）。実際にゲートを実行しなければ、この問題は明らかになりません。静的レビューでは、設計上これを検出できません。まだであれば、フィードバックとして利用できると信頼する前に、loop-preflight スキルを実行するよう推奨してください。このスキルは実際にゲートを実行するため、このレビュー自体が、後述の「計画を絶対に実行しない」というルールに違反することはありません。
• アクセス範囲は最小権限に限定されていますか。つまり、タスクに必要な範囲を超えていませんか？ そうでなければ、範囲を狭めるよう推奨してください。
• デフォルトで読み取り専用ですか？ ループに必要なのが観察だけなのに書き込み権限も付与されている場合は、その権限を外すよう推奨してください。
• ループが実際に書き込む必要がある場合、その書き込み先は、読み取り中心のチェックに書き込み機能を追加しただけの環境ではなく、実際に書き込みが安全な環境（サンドボックス、本番以外の対象など）に限定されていますか？ そうでなければ、ループを無人で実行する前に範囲を見直すよう推奨してください。

その他の推奨事項の例：

• ループの目標や範囲（DoR）が何も記されていない → 開始前に、範囲が途中で逸脱しないよう、少なくとも1行の目標と明示的な対象外事項を記載するよう推奨します
• ループが従うべきガイダンスや規約（Feedforward）がない → 既存のドキュメント／スキル／契約を参照するよう案内するか、存在しない場合は短いものを作成するよう推奨します
• モック／ドライランのフィードバックしかなく、実際の対象に対するものがない → 実環境のチェックを少なくとも1つ追加するか、ループのリスクが低い場合はリスクを明示的に許容するよう推奨します
• DoDにエスカレーションやブロック時の結果が定義されていない → 成功したか判断できない場合に、ループが停止して人間に引き継ぐ方法を定めるよう推奨します

推奨事項は検討すべき提案であり、実行前に必ず満たさなければならない要件ではありません。

ルール

• レビュー対象の計画に含まれるものを絶対に実行しないでください。これは記述内容を対象とする静的レビューであり、実際に動作するかをテストするものではありません。
• 合否判定や、単一の総合スコア／評価を絶対に出さないでください。観点ごとの所見のみを示してください。
• DoDの終端状態に特定の用語を必須としたり、DoRに固定チェックリストを求めたりしてはいけません。そのループ固有のリスクに照らして、記載内容を評価してください。
• 明示的に保存を依頼されない限り、グリルセッションなどの他のファイルに絶対に書き込まないでください。このレビューは会話内に置くか、応答として返してください。