手引き: verify（確かめて返す）

会話が要約された後は、入口 bb-writ を呼び直して全文を読み直す（要約の後は、先に呼んだ入口が落ちていることがある）。

入口の「検証」の (1)〜(6) は要点だけで、ここが全文。

確かめる

下の「検証」の、その対象の形で確かめる。対象のリポジトリに検証スキル（verify-*）があれば、それに従う。無く、同じ確かめ方を繰り返し使いそうなら create-verification-skill で作る。対象のリポジトリにある検査のうち、変更が影響する範囲のもの（文書なら文書の検査、コードなら該当のテストと lint。CI と同じコマンド）は、変更が小さくても手元で実行する。変えた事実（値・条件・状態・名前）を前提にしている記述は、差分の外まで探して読む。同じリポジトリの別の文書の要約文や、変えたコードを説明するコメント・テスト名・assert のメッセージのこと。変えた語・アンカー・リンク先で検索し、食い違えば同じ変更で直す。レビュー対応の直しでも同じにする。検査は、差分の外の文が古くなったことを捕まえない。同じ変更の途中で範囲を広げた（振る舞い・検査・節を足した）ら、その commit の後に、同じ変更の中で「この変更でしたこと」を並べた文を拾い直す。前の commit で自分が書いた作業記録の表の行・文書の要約・CHANGELOG の節と、その変更の PR の本文のこと。git diff <基点>...HEAD と PR の本文（gh pr view <番号> --json body。git の差分には出ない）を、変更を指す識別子（Issue・PR の番号）と、前の commit で書いた要約の語で探し、足した分を欠けば同じ変更で書き足す。誤りを書いていない要約も、欠けていれば直す対象にする。足したのが新しい振る舞いなら、変えた語で探しても要約は見つからない。外部のサービスの挙動に頼る主張（前の決定・出典から流用した理由を含む）は、主審が実物（実際の実行結果・公式の文書）で確かめる（審査役は確かめられない。interrogate の 5）。足した試験・検査は、流した出力のケースの名前・失敗のメッセージを、人が読む文として読む（書式の指定（%s・{} など）がそのまま残っていないか、どの場合を確かめるかが名前から読めるか）。同じ成果物に対する有効な既存の検証結果は、取り直さずに再利用する。「ビルドが通った」「テストが通った」だけを完成の根拠にしない。

検証

信じてよい条件: (1) 何が観測できれば成功かを、依頼・既存仕様・実物の利用箇所から先に定める。通るように後から弱めたら「同じ条件を満たした」と報告しない。(2) 新しい自動検査は、正しい例に加え、対象の欠陥を入れた例または既知の失敗例で落ちることを確かめる。欠陥の例には、検査が見る語を残したまま意味を後退させる例と、既知の古い形（出典の古い記述・前の版）から作る例を必ず含める。語を消す例だけでは、語の有無と順だけを見る検査も通ってしまう。(3) 意味の判断が残れば、別セッションに目的・実物・反例を渡す（delegate の launcher で読み取り専用に立てる。Agent の子の書き込みは OS で止まらない）。作者の成功報告だけを読ませない。対象のリポジトリにある別の役の agent（設計の文書との整合を見る役など）は、役割が意味の判断でなければ代わりにならない。別モデルが通したことを機械的な証明にしない。(4) 未実行・環境不足・結論の出ない部分は、その範囲を残す（閉じられるものは閉じてから。入口の「返答の形」の 4）。CI が無ければ「CI なし」としてローカルの結果から判断し、対象に必須の CI があればその結果も待つ。小さな訂正では既存の確かな検証を再利用する。ただし、主張を足す・変える訂正は、1 行でも再利用しない。その主張を縛る検査があるかを確かめ、無ければ (2) の形で足す。(5) 新しい自動検査を足す変更と、検査の期待値を変える変更では、push・PR の前に、新しい文脈の子 1 人に、意図・検査・その主張の出典・後退の一覧だけを渡し、次の 3 つを頼む（起動は delegate の launcher）。(a) 意図の主張を、今の出典の、その主張を定める節の全文と照らし合わせ、抜けた限定・例外を挙げる。主張を正しいものとして渡さない。出典を超える主張は、検査を足さずに出典まで狭める。(b) 後退の一覧の行を 1 つずつ注入し、検査が落ちるか。一覧に無い後退の出所が 3 つの中にあれば、行を足す。(c) 主張を保ったまま検査を落とす書き換え（誤検出）。意図には、その検査が守る範囲の主張をすべて書く。依頼（Issue など）に MUST・受入条件が並んでいれば、1 行ずつ写し、行ごとに守る検査（無ければ無い）を添える。後退の一覧は最初の子を立てる前に書き、出所は 3 つだけにする。前の版（変えた hunk を戻す）、出典の古い記述、手で並べた要素（分岐・許す値・比べ方・境界の文字。分岐ごとに書いた同じ条件は、それぞれ別の要素）を 1 つずつ落とす・緩めるもの。一覧の行が通ったら検査を直し、直した commit で新しい子に、一覧の行が落ちることと、直しの差分（前に通した commit から直した commit まで）を interrogate の 3 の観点で読むことだけを頼む（新しい後退は探させない。危険度が中・高なら --interrogate を付けて立てる）。直しで足した試験の名前・メッセージにも誤りが入る（printf の書式をそのまま埋め込んだケース名を、「防ぐか」だけを確かめた 2 周の子も書き手も、出力に写したまま挙げなかった）。一覧の外で子が見つけた書き換えは、検査を足さず、守らない範囲をリポジトリの中の文（試験の名前・コメント・文書）に書いて閉じる。PR の本文はマージの後に読まれない。収束は、一覧の全行に落ちる検査か、守らない範囲の文があること。証拠には、子に攻めさせた commit と一覧を書く。(6) コード（試験・検査のコードを含む）を変える変更では、push・PR の前に、(5) とは別に、変更の危険度に応じて interrogate を通す（低なら省く。危険度と深さ・周回の止め方は interrogate の 5）。(5) の子は主張に書かれていない性質（足したコードの異常系、試験の壊れにくさ、主張の外の MUST、実装より広い条件の文）に向かず、(5) を済ませたことは届けてよい理由にならない。指摘は主審として「対応する」（同じ変更で直す）・「記録のみ」（直さない理由を入口の返答の 2 に書く）・「退ける」に決め、どこまで直すかを利用者に選ばせない。仕様の矛盾か製品上の選択を含む指摘だけを、入口の返答の形の 4(b) で返す。利用者に頼まれた審査の報告は、利用者が決める。次の周とその範囲、前提を疑う時期、主張を破る経路の閉じ方は interrogate の 5・6。

共通にするのは「依頼から成果へ進む体験」で、言語名や検査コマンドではない。その対象の通常の開発方法（package script・devcontainer・CI の定義・既存の検査）をそのまま使う。初めて見る言語や道具でも、bb-writ を直さずに進める。検証は、利用者が成功を観測する場所から決める。

CI を試し場にしない。 入口の手順 3 で仕様を読み、手元で確かめられる部分（BSD と GNU のコマンド、macOS 標準の bash 3.2、一時ディレクトリの symlink などの差を含む）は手元で潰してから CI に出す。調べるための job・step・commit を、push・pull_request で動く workflow に足さない。確かめるための push を重ねない。push のたびに全部の job が動き、private のリポジトリでは macOS の runner の分単価が Linux の約 10 倍になる（2026-01 からの価格表で $0.062 と 2-core の $0.006）。CI は仕上がった変更の確かめに使う。手元に無い環境（対象の開発者が macOS を使うなど）での確認が必須なら、手元で潰した後に、まとめて 1 回にする。その 1 回は、push で動かない起動（workflow_dispatch だけで動く workflow など）か、その環境の利用者の手元での実行で行う。workflow を足す・変えることが依頼に無ければ、聞く（入口の手順 1）。出す前に起動条件を読む。PR のブランチへの 1 回の push で、push と pull_request の両方の起動条件が同じ job を動かすことがある。それで落ちたら、ログと仕様から原因を絞って手元で直す。次の 1 回の前に、落ちた差と読んだ仕様を記録に書く。

CI の結果まで見る。 push・PR の後は、その commit の CI が終わるまで gh run watch --exit-status <id> で待ち、job ごとの結果を返答の 3 に書く。終わる前に「済んだ」と書かない。cancelled（時間切れなどの打ち切り）も失敗と同じに扱う。Release は CI が通った commit にだけ出す（work.py op run の release は、終わっていない・通っていない実行があれば拒否する）。workflow の timeout-minutes を決める・変えるとき、打ち切りが出たときは、gh run list・gh run view で最も遅い OS の成功した実行の時間を見て、その最長の 3 倍以上にする。macOS の runner は Linux より遅く、日によって 1〜2 割揺れる（上限を実行時間ぎりぎりに置くと、全部通る試験が打ち切られる）。打ち切りに、試験を削って合わせない。

完了の証拠は、確認した成果物の版（commit・PR・ファイルのパス）、検証の手順と入力、結果、残った範囲を結び付ける。検証の後に成果物や前提が変わったら、影響する証拠を取り直す。出力はコマンドと観測をそのまま載せる。長いものは、担当を取った仕事では claim の出力の note.evidence_dir、担当を取らない読むだけの仕事では ~/.local/state/bb-writ/notes/<owner>__<repo>/ に置いてパスを示す。/tmp は消えるので証拠に使わない（そこにしか書けない環境なら、そう書く）。要約で置き換えない。変更を届けるとき（PR など）は、本文に「なぜ・何が変わるか・範囲・壊れうる所・どう確かめたか・戻し方」を書く。必須の PR や CI を作るために仕事を変形させない。

返す前の判定（遵守の監査）

push・PR の前と返す前に、入口の返答の 2〜4 の下書き（4 が無ければ「無し」）と作業の記録・差分を、新しい文脈の子に渡す。届ける commit を checkout した未 commit の変更が無い場所を --cwd にし、delegate の launcher に --audit を付けて読み取り専用で立てる（work.py は、--reviewed none: でも、HEAD を対象にしたこの記録が無い push・pr を拒否する。none: は interrogate を省く宣言で、子を省く宣言ではない）。子には次を判定させ、下書きも作業者の報告も正しいとは伝えない。

• 遵守: 使ったスキル（入口・この手引き・課題の手引き。名前を渡し、子が本文を読む）から、この変更に当てはまる確かめ方の要求を全部挙げ、要求ごとに「満たした」「省いた（記録に理由がある）」「別のもので代えた（代えたもので要求を満たすか）」「省いたが記録に理由が無い」に分ける。根拠にしたスキルの文と、記録の行・委任の記録（立てた子の out の prompt.md の依頼文と report.md）を引かせる。記録の要約だけで判定させない（「審査役 2 人が ok」とだけ書いた記録からは、何を頼んだかが分からない）。Claude Code の監査役は、その場所の作業の記録・その場所を --cwd にした子の out・bb-writ のスキルを読める（ほかの場所の記録は読めないので、記録の置き場の外に書いたものは中身を依頼文に写す）。対象の検査（文書の検査・試験）も子に実行させる（読んだだけの報告は not-run で、関門に数えない）。
• 4 の各項目と、2 に書いた「残した点・守らないこと」の各項目が、実行・読み・試作・別の環境・同じ仕事での修正（範囲の外で見つけた穴も）・既定での決定（戻せる選択）のどれで閉じられるか。閉じられないなら、確かめた制約か、目的・規則・仕様から決まらない戻せない選択か。意図して守らない振る舞いは、試験か文に示されていて依頼の目的に反しなければ閉じたものとする。

審査の深さと周回は interrogate の 5 で決まり、判定では変えない。その止め方で回さなかった周は残りに数えず、3 に書く。依頼に無い外部への送信（push・Release）の許可は、4 (b) の仕事の権限として 1 行で聞く。閉じられると判定された項目は閉じてから、もう一度判定させる。子の判定を退けるときは、その理由を返答の 3 に書く。遵守で「代えた」「理由が無い」と挙がった要求は、記録の指摘の扱いの欄に書き（push・pr はこの欄が空なら拒否される）、対応するなら要求どおりにやり直し、直した commit で監査役を立て直す。