verify-before-claiming
Before reporting a task as done, run the check that would fail if it were not — an explanation is not a fix.
カードを読んだレビュアーが与えるものであり、ファイルが自分について主張するものではありません。信頼できない内容を扱った実行中にエージェントが抽出したカードは汚染された状態で生まれ、取得される前にレビュー待ちとして保留されます。
どんなときに思い出すか
- finished the change
- about to report success
- the fix looks right
- summarising what was done
価値はたいてい「回避」と「確認」にあります。「実施」は誰でも書ける節です。
トリガー
You are about to say a task is complete. Anything from "fixed the bug" to "updated the config" to "the tests should pass now".
It does not apply when the task was genuinely to explain, review or investigate something. Those finish with an answer, and demanding a diff from them is its own mistake.
実施
- Name the observable that would be different if the work had happened. A file whose contents changed, a command whose exit code flipped, a row that now exists.
- Check that observable. Actually run the command, actually read the file back.
- Report what you saw, including the command and its output — not your expectation of it.
- If nothing observable changed, say that plainly instead of describing the change you intended.
回避
Reporting the plan as the outcome. The failure reads like: "I updated the handler to check the token before branching" — fluent, specific, technically accurate about the intent, and describing an edit that was never written to disk.
It is tempting because a convincing explanation feels like evidence. It is not. The explanation is produced by the same process that would produce it whether or not the edit landed, so it carries no information about whether it did.
Also avoid checking something adjacent to the claim: running the full suite proves the suite passes, which is not the same as proving this change did this thing. Pick the check that would have failed before.
確認
The claim and the evidence describe the same event, and the evidence came from the machine.
Concretely: a diff that is non-empty, a test that failed before and passes now, output pasted
rather than paraphrased. If you cannot produce one, the honest report is "I could not verify this",
which is a useful thing to say and takes one sentence.
リスク
Over-applied, this turns a two-line documentation fix into a ceremony, and there are tasks whose result genuinely is prose. The cost of the check should stay well under the cost of being wrong.
The subtler risk: a check that always passes is worse than no check, because it launders a guess into a verified claim. If the verification cannot fail, it is not verifying anything.
使い方
カードはデータです。リポジトリをクローンし、パスで取り込んでください。ネットワーク経由で届いたものは汚染扱いとなり、承認されるまで保留されます。それが望ましい挙動であり、ここにワンライナーのインストーラーがない理由です。
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/verify-before-claiming/SKILL.md完全性
公開された状態のファイルの SHA-256。取り込む側は、受け取ったものがこのページに表示されたものと同じか確認できます。
c3c90d1467f39a63fb73dc21f2ac4aaf176306e532a3c58954dcbbc85566c2f5