iterate-until-verified

検証できるまで反復する

タスクはそのまま維持し、タスクを取り巻くプロセスを強化します。

モードを選択する

• 実行： 以下のワークフローに沿って、元のタスクを完了します。デフォルトではこのモードを使用します。
• 作成： ユーザーが完成した成果物ではなく、改善されたプロンプトを求めている場合は、再利用可能なプロンプトのラッパーを返します。ラッパー内でも、元のタスクを変更せず、優先される指示として維持します。

プロンプトの作成から実行へ、黙って切り替えてはいけません。

1. 元のタスクを固定する

次の内容を抽出します。

• 成果と納品物
• 対象者と用途
• 提供された入力と参考資料
• 制約、ツール、形式、除外事項
• 許可された操作と保護すべき境界
• 明示された完了の定義

これらをタスクの契約として扱います。対象を置き換えたり、要件を作り出したり、制約を緩めたり、権限を拡大したり、検証方法を成果物にしたりしてはいけません。

不足している回答によって作業が大きく変わり、かつ安全に確認できない場合にのみ、質問します。それ以外の場合は、妥当な前提を明示して作業を進めます。

2. 目標を合格基準に変換する

完璧、最高、プロフェッショナル、本番環境対応、AAA などの言葉を、観察可能なチェック項目に変換します。タスクに関連する側面のみを選びます。

• 正確性と事実の妥当性
• 依頼内容に対する完全性
• 仕上がり、明瞭さ、対象者への適合性
• 使いやすさとアクセシビリティ
• 堅牢性、エッジケース、回帰に対する安全性
• パフォーマンス、セキュリティ、コンプライアンス
• 提供されたベンチマークに対する視覚的、編集上、技術上の忠実性

簡潔な受け入れ基準マトリックスを作成します。

基準	検証方法	合格条件	証拠
関連する品質の側面	テスト、確認、比較、または読み返し	観察可能な二値条件	コマンド、ソース、スクリーンショット、出力、または成果物

曖昧なスコアより、合否で判断できる条件を優先します。「すごい」といった強い反応は有用な指標になり得ますが、それだけを基準にしてはいけません。

3. 作業を分解し、担当を割り当てる

タスクを、担当者、入力、出力、統合時の境界が明確な、意味のある最小単位の作業に分割します。

• 本当に独立している作業のみ、並行して進めます。
• 変更が密接に関連する場合は、競合を避けるため、1人の担当者にまとめます。
• 各作業者には元のタスク契約を渡し、必要なコンテキストだけを提供します。
• 各作業者には、自信があるという主張ではなく、成果物または証拠を提出させます。
• 作業間の整合性と回帰に対する一貫性には、統合担当者1人が責任を持ちます。

利用可能で、許可されており、有用な場合は、サブエージェントや委任先の作業者を活用します。それ以外の場合は、同じ担当境界を維持しながら、作業を順番に進めます。

4. 作成と評価を分ける

実装担当者に、自分の成果物を唯一の承認者にしてはいけません。

検証担当者には、次の内容を提供します。

• 元のタスク契約
• 受け入れ基準マトリックス
• 評価対象の成果物
• 関連するベンチマークまたはソース資料

検証を再現するために必要な場合を除き、実装担当者の根拠説明や自己評価は伏せます。検証担当者には、まず不備を探し、証拠を示し、裏付けのない主張を退け、基準ごとの判定を返すよう指示します。

ブラインド比較を行う場合：

• 実用上可能であれば、候補を匿名化し、順序をランダム化します。
• 同じ条件で、同じもの同士を比較します。
• 評価者には作成者や候補の識別情報を伏せますが、タスクや評価基準は伏せません。
• 明らかな識別要素が残っている場合、その比較をブラインドとは呼びません。

5. 作業に合った証拠で検証する

利用可能な最も強力な検証手段を使います。

• コード： 対象を絞ったテスト、型チェック、ビルド、リンター、セキュリティチェック、実行時の動作、回帰テスト。
• ビジュアル作業： 関連するサイズでのレンダリング結果、インタラクションチェック、アクセシビリティチェック、アクセス可能な参考資料との並列比較。
• 調査または分析： 一次情報、再現可能な計算、引用チェック、矛盾の検索。
• 文章作成： 事実確認、簡潔な網羅性、読者への適合性、構成、代表的な参考資料に照らした編集チェック。
• 計画または意思決定： 制約の網羅性、依存関係のチェック、失敗シナリオ、実現可能性、明示的なトレードオフ。
• 外部アクション： 対象を正確に特定してから、アクション後に読み戻して確認します。

自己評価を証拠の代わりにしてはいけません。ベンチマーク、情報源、テスト結果、スクリーンショット、ブラインド判定を捏造してはいけません。

6. ループを実行する

次の手順を繰り返します。

1. 候補を作成または改善します。
2. 該当するすべてのゲートを実行します。
3. 証拠とともに、pass、fail、または blocked を記録します。
4. 各失敗を担当する作業ストリームに割り当てます。
5. 証拠に対処する最小限の修正を行います。
6. 失敗したゲートと、影響を受ける回帰ゲートを再実行します。
7. 検証済みの作業のみを統合します。

必須ゲートが失敗しており、安全かつスコープ内のアクションで有意義な進展が見込める間は、続行します。同じアプローチで失敗を繰り返した後は、同じことを続けず、アプローチを変えるか、ブロッカーを報告します。

7. 誠実に終了する

次の条件を満たした場合にのみ完了とします。

• 必須ゲートがすべて合格している
• 統合後の結果が、元のタスクを引き続き満たしている
• 変更した作業に関連する回帰がチェックされている
• 最終的な主張が証拠によって裏付けられている
• 残る不明点が開示されている

必須ゲートが、アクセス不足、利用できない入力、新たな権限、または実現不可能な制約に依存する場合は、ブロックとして終了します。具体的なブロッカーと、次に必要な最小限のアクションを明示します。成功を宣言するためだけに、ゲートの基準を下げてはいけません。

Compose モードのテンプレート

強化したプロンプトを返す場合は、次の形式を使います。

Use an iterative execution-and-verification workflow around the authoritative task below.

AUTHORITATIVE TASK
<preserve the user's original task here without changing its subject, deliverables, or constraints>

PROCESS
1. Extract the task contract and convert subjective quality language into observable acceptance gates.
2. Decompose independent workstreams and fan them out when delegation is useful and permitted.
3. Keep one integrator responsible for consistency.
4. Assign an independent verifier that sees the task, rubric, candidate, and references—but not the implementer's self-assessment.
5. Verify with task-appropriate evidence. Use anonymized side-by-side comparison when a real comparable benchmark exists.
6. Route failed gates back to the responsible workstream, revise, and re-check affected regressions.
7. Do not finish until every required gate passes or a concrete blocker is proven.

FINAL RESPONSE
Return the deliverable, a concise gate-by-gate evidence summary, and anything still unverified. Do not claim checks that were not run.

プロセスはタスクに合わせて調整します。別のプロンプトから、適用できない分野固有のツール、ベンチマーク、品質に関する主張を流用してはいけません。

完了チェック

• 元のタスクが引き続き最優先されている。
• 主観的な目標が、観察可能なゲートになっている。
• 競合する編集を生み出さずに、独立した作業が分離されている。
• 作成と評価が異なる役割に割り当てられている。
• ベンチマークが実際のもので、比較可能であり、誠実に明示されている。
• 失敗したゲートを受けて修正が行われている。
• 最終的な主張が、収集した証拠と一致している。