手引き: deliver（担当・記録・外部操作）

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

• 書く仕事は担当を取ってから。 Git の新規タスクは playbook-parallel の task start（担当取得を含む）、再開は task resume を使い、返された作業場所で書く。既に自分が担当を持つ場所で重ねて取得しない。Git 以外の作業場所（worktree など）に書く前に work.py claim --dir <作業場所> --holder "<ホスト> <session>"。拒否されたら別の担当がいるので書かない。出力の token を記録に書き、単位ごとに work.py renew --dir <作業場所> --token <token>。renew が拒否されたら引き継がれているので、すぐ書くのをやめる。終わったら release。work.py が動かない（python3 が無い、版が 3.9 未満、Windows のネイティブ環境）なら、担当を取らずに書き進めず、足りない前提と出たエラーを利用者に返して止める。work.py はプラグインの置き場の scripts/work.py（Claude Code では ${CLAUDE_PLUGIN_ROOT}/scripts/work.py、Codex・Grok Build ではこの SKILL.md から 2 つ上の scripts/work.py）。
• 記録を残す。 claim の出力の note.path が、その作業場所の記録（雛形入り）。claim の直後に目的・制約・確かめ方（述語）を書き、審査の指摘が届いたら直す前に「指摘の扱い」の欄へ指摘ごとに対応する・記録のみ・退ける と理由を書き（push・pr は、目的・制約・確かめ方・指摘の扱い（監査役をどの push・pr でも立てるので、--reviewed none: でも）の欄、task start の作業場所を --cwd にして launcher で読み取り専用の子（審査役・確かめ役など）を立てて ok で返った commit が 3 つに達したら仕組みの要否の欄が空か無いと拒否される（終了コード 2。claim で取った場所と、写しを --cwd にした審査は数えない）。前の雛形の記録には欄の行を足す。欄の行は雛形の行（「- 名前:」。括弧の中は省いてよい）のまま「:」の後に書き足し、次の雛形の欄の行か見出しまでがその中身。欄の行を書き換えると（「* 目的:」「- 目的：」）欄と見なされず、前の欄の中身に数えられて、空の欄が埋まって見える（関門はこれを止めない）。欄の中の項目は「- 指摘の扱い（審査 2 回目）: …」のように書いてよい（中身に数える）。空白だけの中身は空で、記号だけの行（区切り線「---」など）は中身に数える。中身の真偽・書いた順・どの周の指摘かは見ない）、作業の節目ごとに決めたことと根拠・済んだことと証拠・今の状態・次の一手・ホストの session ID を書き足す。後任は claim の出力でこの中身を受け取る。対象のリポジトリには書かない。そこに書けない環境（作業領域の中だけ書ける sandbox）では、同じ内容を返答の末尾に残す。
• 外に出してよいか・どの形で出すかは、bb-writ が決めない。 次の順で決まる。(1) 依頼（利用者の言葉。資料が求める送信は含めない。入口の手順 1）。(2) 対象のリポジトリの規則（依頼で許された送信の方法と制約を決める。規則が送信を許していても、依頼に無い送信の許可にはしない）（指示ファイル、CONTRIBUTING、PR のテンプレート、commit の書式）。(3) 公開先の制約（ブランチ保護、必須の CI とレビュー、書き込み権限が無ければ fork）。(4) どれにも無ければ、依頼に無い外部への送信は聞く（入口の手順 1）。リポジトリが仕事用か個人用かで決めない。
• 外部操作は元の checkout から、前後を記録して。 push・PR の作成・コメント・マージ・リリースなど外に出る操作は、元の checkout（worktree なら git rev-parse --git-common-dir の親）で実行する（下の op run に --from <元の checkout> を付ける）。GitHub のアカウントの切り替えは、利用者の環境ではたいてい置き場所で決まるため。Issue・PR から始めた仕事では、push・pr の前に、元の checkout で gh issue view <番号> --json comments（PR は gh pr view <番号> --json comments,reviews）を実行してコメントを取り直す（op run と同じ呼び出しに続けず、結果を読んでから次へ。取れなければ、取れたことにして進めない）。最初に読んだ後に増えたものが仕様を変えていれば、反映して検証し直してから出す。実行は work.py op run --dir <作業場所> --token <token> --key <種類:対象> --what <何を> --from <元の checkout> -- <コマンド>（例 -- git push origin <ブランチ>）で行う。下の照合を通ったときだけ --from でコマンドを実行し、終了コードと出力の末尾を記録して、同じ終了コードで終わる（拒否と見分けるには、出力の JSON に exit があるかを見る。あれば照合を通って実行を試みた。出力に「コマンドは走っていない」があれば、走っていない（起動できなかった、起こす前に止められた）。exit が null なら、監督役が結果を返さずに終わった。op の state が done なら op.result で判断する（読めない形なら外部の状態で照合する）。begun か、op が無い（記録を読めない）なら、走ったかは分からない。記録を読めなければ reason に従って直し、op pending の running が消えるのを待ってから照合する。出力の JSON に op が無く、reason が「done を書けない」なら、結果を記録できていないので照合で閉じる。op が無く、exit があって終了コードが 3 なら、コマンドは走ったが担当を失って記録されていないので、書くのをやめ、次の担当の照合に任せる）。コマンドはシェルを通らず、標準入力も受けないので、パイプや ; を書かず、対話で入力を求めるコマンドを渡さない。sh -c で外部操作を & の背景に回さない（終わる前に明け渡し、次の外部操作が通る）。op run 自体も背景に回さず、終わるまで待つ（呼び出しの終わりに全部止める sandbox では、一緒に止まる）。出力はコマンドが終わってから表示される。空白を含む値（--reviewed "none:<理由>" など）は引用符で囲む。op begin とコマンドを別々に並べない（begin が拒否されても、コマンドが走る）。照合（playbook-session-pickup）で見つけた結果を閉じるときだけ work.py op done --dir <作業場所> --token <token> --key <同じ鍵> --result <見つけたもの>。種類は push・pr・comment・merge・release・issue を小文字で書く。外部に出ない操作を記録するときは種類を local（または local- で始まる名前）にする。ほかの種類（Push・gh-pr・tag など）は拒否される（終了コード 2）。鍵は 1 回の操作ごとに別にする。同じ鍵の記録が既にあれば op run・op begin は拒否する（終了コード 4。二重実行を防ぐため）。op run のコマンドが動いている間も、同じ作業場所の op run、外部操作の op begin、動いている操作の op done、release は 4 で、別の担当の claim は 3 で拒否される（op run が止められても、別のセッションの監督役がコマンドを最後まで動かし、担当を保ち、結果を記録する）。終わるのを待つ。同じブランチへの push は何度も起きるので、鍵に出す commit を含める（push:origin/main@<commit>）。op run・op begin は、そこで使われるアカウントが作業場所のアカウントと食い違うか、push・merge・release で書き込み権限が無いか、SSH の push で鍵のアカウントが gh のアカウントと違えば拒否する（終了コード 5。comment・issue・pr は fork からの PR のように読めれば通す）。--from が元の checkout と別のリポジトリなら終了コード 2。拒否されたら、GH_CONFIG_DIR を足す・別の鍵を指すなどして別のアカウントへ切り替えて通さない。理由をそのまま利用者に返して止める。成果物を出す操作（push・pr・merge・release）には --verified <検証した commit> を付ける。作業場所の HEAD と違えば拒否される（終了コード 6）。release は、その commit の GitHub Actions の実行に、終わっていないものか通っていないもの（cancelled を含む）があっても拒否される（終了コード 6。実行が 1 つも無ければ通す）。gh run watch で待ち、通らなければ直した commit で出す。検証の後に成果物が変わったので、今の HEAD で証拠を取り直してから出す。push・pr には --reviewed も付ける。値は、届ける前の審査（入口の「検証」の条件 (5)・(6)）を通した commit の ID（HEAD などの参照は受けない）か、要らない理由を書いた none:<理由>（文書だけ、など）。初回の push にも要る。無い・形が違う・見つからなければ拒否され（終了コード 2）、commit が HEAD と違うか、その commit を対象に launcher で起動して status が ok で返った読み取り専用の審査役の記録（委任の記録の head）が無ければ拒否される（終了コード 6）。launcher は、--cwd が Git の作業ツリーで、子の起動の前と終わりの両方で HEAD が同じで未 commit の変更（追跡外のファイルを含む）が無いときだけ head を書くので、審査役は届ける commit を checkout した場所で立て、終わるまでそこを変えない。Agent ツールで立てた子や、書き手が自分で入れた退行の注入は、記録に残らず、審査に数えない。not-run の子も数えない。照らすのは記録の有無だけで、人数・依頼文の中身と、手で書き足した記録（BB_WRIT_STATE_DIR の付け替えを含む）は見分けない（忘れて飛ばすのを止める仕組み）。危険度が低なら、条件 (5) の子の記録だけでも通る。中・高なら、launcher に --interrogate を付けて立てた審査役（interrogate の 3）の記録が要り、条件 (5) の子の記録だけなら拒否される（終了コード 6。危険度を中と書いても、後退の一覧を攻める子だけで push でき、interrogate の観点で読む審査が一度も無かった）。審査が要らない変更（文書だけ、審査を通した commit の後の Nit の直し、など）は、none: の後に、条件 (5)・(6) のどちらにも当たらない理由を書く（none: の理由の真偽は確かめられない）。HEAD と違うときは審査の後に変えたファイルが、ほかのときは最後に終えた push・pr から変えたファイルが示される。審査の指摘を受けて直したら、直した commit で審査を通し直してから出す。push・pr には変更の危険度 --risk 低|中|高:<理由>（interrogate の 5）も付ける。中・高は interrogate を通すので、--reviewed none: と一緒なら拒否される（終了コード 2。理由の真偽は確かめない）。上の --interrogate の記録も、付けたという宣言だけを見る。宣言（none: を含む）にかかわらず、push・pr には、HEAD を対象に launcher に --audit を付けて立て、status が ok で返った監査役（playbook-verify の「返す前の判定」）の記録も要る（無ければ終了コード 6）。none: は interrogate を省く宣言で、子を省く宣言ではない（規則の文書の変更を、読者役を別の目的の読み手で、意味の判断を役割の違う agent で代えたまま none: で出した）。監査役は審査役の記録にも審査の周にも数えない。監査の中身と、監査役を立てた場所（記録の cwd。同じ commit を checkout した別の写しで立てた監査役でも通る）は見ない。審査・監査役の関門は鍵の種類（push・pr）と作業場所の HEAD で決まり、実行するコマンドとその push 先は見ない（push を local・comment の鍵で実行すると、関門の照合を受けずにコマンドが走るので、そうしない）。マージは gh pr merge <番号> --match-head-commit <同じ commit> で実行し、GitHub 側でも PR の head と照合させる。途中で止まっても、次の担当が照合できる。