verify-before-claiming
タスクを完了と報告する前に、完了していなければ失敗するはずの検査を実行してください。説明は修正ではありません。
カードを読んだレビュアーが与えるものであり、ファイルが自分について主張するものではありません。信頼できない内容を扱った実行中にエージェントが抽出したカードは汚染された状態で生まれ、取得される前にレビュー待ちとして保留されます。
どんなときに思い出すか
- 変更が終わった
- 成功を報告しようとしている
- 修正は正しそうに見える
- やったことをまとめる
価値はたいてい「回避」と「確認」にあります。「実施」は誰でも書ける節です。
上のカード本文は翻訳です。CLI が取り込み、エージェントが実行時に読み、下のハッシュが証明するのは英語の原文です。
トリガー
タスクが完了したと述べようとしている場合に当てはまる。「バグを修正した」から「設定を更新した」「これでテストは通るはずだ」まで、あらゆる場合が該当する。
タスクが本当に何かを説明する、レビューする、調査するというものだった場合には当てはまらない。それらは答えをもって完了するものであり、そこに差分を要求すること自体が間違いである。
実施
- その作業が実際に行われていたら異なっているはずの、観測可能な事象を名指しする。内容が変わったファイル、終了コードが変わったコマンド、新たに存在する行、といったものだ。
- その観測可能な事象を確認する。実際にコマンドを実行し、実際にファイルを読み戻す。
- 見たものを、期待ではなく、コマンドとその出力を含めて報告する。
- 観測可能な変化が何もなかったなら、意図していた変更を説明する代わりに、その事実をはっきりと述べる。
回避
計画を結果として報告すること。その失敗はこんな風に読める。「分岐処理の前にトークンをチェックするようハンドラーを更新した」——流暢で具体的、意図については技術的に正確でありながら、ディスクには一度も書き込まれなかった編集を説明している。
説得力のある説明は証拠のように感じられるため、これは魅力的に見える。しかしそうではない。その説明は、編集が実際に反映されたかどうかに関わらず同じプロセスから生成されるものであり、それが実際に反映されたかどうかについての情報を何も持たない。
主張に隣接する何かをチェックすることも避けること。フルスイートを実行することが証明するのは、そのスイートが通るということであり、この変更がこのことを行ったことの証明にはならない。以前は失敗していたはずのチェックを選ぶこと。
確認
主張と証拠が同じ出来事を記述しており、その証拠はマシンから得られたものであること。
具体的には: 空でない diff、以前は失敗し今は通るテスト、言い換えではなく貼り付けられた出力。それを提示できないなら、誠実な報告は「これは検証できなかった」であり、それは有用な一言であり、一文で済む。
リスク
過剰に適用すると、2行だけのドキュメント修正が儀式のようなものになってしまう。結果が本当に文章そのものであるタスクも存在する。チェックのコストは、間違えることのコストより十分小さく保つべきである。
より微妙なリスクは、常に通ってしまうチェックはチェックがないよりも悪いということだ。それは推測を検証済みの主張へとロンダリングしてしまう。その検証が失敗しえないなら、それは何も検証していない。
使い方
カードはデータです。リポジトリをクローンし、パスで取り込んでください。ネットワーク経由で届いたものは汚染扱いとなり、承認されるまで保留されます。それが望ましい挙動であり、ここにワンライナーのインストーラーがない理由です。
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/verify-before-claiming/SKILL.md完全性
公開された状態のファイルの SHA-256。取り込む側は、受け取ったものがこのページに表示されたものと同じか確認できます。
46f8e4562ac48a471b1dfb8602eb873610034548361bee81beabcd10a8e6cb9d