heithmurray/agent-skills

bcp-finish

実際の作業の完了ステップ。あるモデルがそれを構築し、別のモデルがそれを攻撃し、オペレーターが決定を下します。Builder-Challenger Protocol v1.7 (https://github.com/heithmurray/builder-challenger-protocol、CC BY 4.0、Heith Murray) に基づきます。

使用時

• 実行する：簡単な変更を超える作業の完了承認を求める前に実行します。依頼を待たないでください。
• スキップする：簡単な作業（明白で小さく、元に戻しやすいもの）にはスキップします。集中した検証で十分です。
• 1回の実行につき1つのトピック：提出しようとしている変更に限定します。

役割

• ビルダー：作業を行ったエージェントであるあなた。すべての異議を修正または回答します。
• チャレンジャー：異なるモデルで、読み取り専用で実行します。問題を発見するのみで、ファイルを編集したり納品物のテキストを書いたりすることはありません。
• オペレーター：作業を所有する人間。オペレーターのみが承認、リスクの受け入れ、ラウンド制限の延長、真実の上書きまたはリフレームの発行、またはスコープに関する判断を行います。あなたはビルダーとチャレンジャーの間を中継し、フォーマット違反に対してのみ標準の RESET — [指示] を発行できます。

誰が誰に挑戦するか

• チャレンジャーは常にビルダーとは異なるモデルファミリーであり、ヘッドレスで読み取り専用モードで起動されます。ペアリングと正確なコマンドは references/tools.md にあります。
• 各ツールの設定されたデフォルトモデルを使用し、自分で選択しないでください。
• 各呼び出しは新しいセッションであり、共有履歴はありません。毎回完全なラウンド入力を渡します（ハンドオフを参照）。
• 各呼び出しには最大10分を許可します。各ラウンドは通常1〜5分です。

ハンドオフ（チャレンジャーが受け取るもの）

各ラウンドで、以下のパーツを順に含む1つのプロンプトを書きます：

1. references/challenger-prompt.md ファイル全体（役割、ルール、フォーマット）。
2. ROUND [n] — BUILDER OUTPUT — v1.[n-1]。
3. トピック：この変更が達成すべきことを一文で、可能な限りオペレーターの言葉で、さらに受入基準を添えて。
4. 確認場所：リポジトリのパス、ベースコミットとヘッドコミット、差分を確認するためのコマンド（例：git diff <ベース>..<ヘッド>）、および重要なファイル。
5. ビルダーの証拠：実行した検証とその結果。
6. ラウンド2以降：あなたのビルダー応答（以下のビルダー応答フォーマット）とチャレンジャーの最後の異議申立台帳をそのまま。

それ以外は何もなし。コメントなし、以前のラウンドは台帳のみ。

チャレンジャーは、自身の主張を証明するためにファイルを読み、読み取り専用コマンドを実行できます。証拠の階層が重要です：コードや計算を実行することがソースを引用することよりも優れており、それは意見よりも優れています。

ループ

ラウンド制限は、オペレーターがラウンド1の前に別の値を設定しない限り5です。制限に達しても承認されていない場合は、停止してオペレーターに問い合わせます。オペレーターは理由を添えて一度延長できます：EXTEND — [現在のラウンド] から [新しい制限] まで。理由：[まだ未解決の具体的な作業]。2回目の延長はありません。制限に再び達するとデッドロックになります。

1. ラウンド1：ハンドオフを送信します。チャレンジャーの返信をそのままラウンド1として保存します。

2. 評決 REVISE または FAIL：ビルダー応答フォーマットで回答します：

   • 評決への応答。
   • 受け入れた異議（ID別）：変更した内容。各異議について：「異議 [ID] は階層 [X] でした。私の修正は [Y] を変更しました。その割合は [Z] のため適切です。」
   • 却下した異議（ID別）：同等以上の階層の証拠を添えた理由。
   • 弱い異議への挑戦。
   • 前提への応答。
   • 実施した修正。
   • 残っている未解決の質問。

   修正を行い、ブランチにコミットします。その後、次のラウンドのハンドオフを送信します。

3. スコープ、動作、または設計を変更する異議は、黙って修正することはできません。停止して、チャレンジャーのテキストをそのまま添えて、決定事項としてオペレーターに持ち込みます。

   • 自分で書いた仕様や計画ではスコープは確定しません。それを指摘して異議を却下しないでください。オペレーターの言葉、またはオペレーターが承認した仕様のみが有効です。却下の唯一の理由がスコープである場合は、「オペレーターのスコープ判断が必要」と報告します。

4. 評決 PASS は、完了した署名チェックリストの未解決数がゼロで、最終評決が承認済みである場合にのみ有効です。それ以外の場合はREVISEとして扱います。

5. ラウンド制限に達しても承認されていない場合：停止して、未解決の台帳をオペレーターに持ち込みます。オペレーターが延長した場合（一度だけ）、続行します。それ以外の場合、または延長された制限に達した場合は、デッドロックとなります：チャレンジャーに1段落の最終見解表明を求め、自分自身のものを書き、両方をオペレーターに持ち込みます。

6. 自己失敗：アプローチ自体が壊れている場合は、必要な3つのパーツを添えてそう述べます：(a) 何が壊れているか、(b) なぜチャレンジによって明らかになったのか、(c) 異なるアプローチが機能するには何が必要か。それをオペレーターに持ち込みます。

チャレンジャーの返信を編集、短縮、または和らげることは決してしないでください。異議が解決されたと主張しないでください。チャレンジャーの台帳のみがそれを解決済みとマークできます。

記録の保存場所

• 作業に変更フォルダまたはタスク記録がある場合は、ラウンドをそこに BCP-LEDGER.md として保存します：各チャレンジャーの返信と各ビルダー応答を順に保存します。
• それ以外の場合は、リポジトリの外の一時フォルダに保存し、最終的な台帳をレポートに含めます。
• そのための新しいトップレベルフォルダは作成しないでください。

オペレーターへのレポート（完了承認）

• ビルダーとチャレンジャーに使用されたモデル、およびラウンド数。
• 最終バージョンとチャレンジャーの最終評決。
• 最終的な異議申立台帳をそのまま。
• チャレンジャーの譲歩と、未提起リスクの自己監査をそのまま。
• あなたの検証証拠。
• リクエストがあいまいだった場合のあなたの解釈（例：「6〜29日目は無料」）をすべて、オペレーターが確認または修正できるように。
• オペレーターの判断が必要なもの：デッドロック、自己失敗、スコープ判断、スコープを変更する異議、受け入れるリスク。
• その後、GoまたはNo-Goを求めます。プッシュ、マージ、公開はオペレーターのGoを待ちます。

チャレンジャーが実行できない場合

1. 一度再試行します。モデルエラーがサポートされていないモデルを示している場合は、報告します。静かにモデルを切り替えないでください。
2. それでも他のツールが利用できない場合は、自分のツールのヘッドレス読み取り専用コマンドをチャレンジャーとして同じループを実行します（references/tools.md を参照）。共有コンテキストのない新しいセッションです。
3. 結果全体をレポートで 自己チャレンジ とラベル付けし、2番目のモデルが利用できなかった理由を説明します。自己チャレンジはビルダーの盲点を共有するため、オペレーターはその重みを低く評価する必要があります。
4. このステップを黙ってスキップしないでください。