bb-writ
AGENTS.md0 starsChanged 6 days agoMITView on GitHub
bb-writ は、CLI ハーネス(Claude Code・Codex。Grok Build も同じ SKILL.md を読む)向けのスキルのプラグイン。概要・入れ方・生い立ち・ライセンスは README.md。オーナー専用の取り決め(手元の環境・試験用のリポジトリ・push の方法)は、gitignore した CLAUDE.local.md にある(無ければ、この文書だけに従う)。
- Reads credentials
- Commits and pushes
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,439 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository39 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- verify-parallelSkill
- bb-writSkill
- correctSkill
- create-formal-verification-skillSkill
- create-property-test-skillSkill
- create-verification-skillSkill
- delegateSkill
- interrogateSkill
- playbook-bugSkill
- playbook-deliverSkill
- playbook-docs-skillSkill
- playbook-evalSkill
- playbook-featureSkill
- playbook-investigationSkill
- playbook-parallelSkill
- playbook-pause-safelySkill
- playbook-session-pickupSkill
- playbook-verifySkill
- principle-attack-the-premiseSkill
- principle-encode-lessons-in-structureSkill
- principle-experience-firstSkill
- principle-fail-loudSkill
- principle-fix-root-causesSkill
- principle-foundational-thinkingSkill
- principle-laziness-protocolSkill
- principle-model-the-domainSkill
- principle-never-block-on-the-humanSkill
- principle-no-budget-cap-on-qualitySkill
- principle-no-speculative-structureSkill
- principle-prove-it-worksSkill
- principle-route-lessonsSkill
- principle-sequence-verifiable-unitsSkill
- principle-single-user-machineSkill
- principle-subtract-before-you-addSkill
- principle-test-behavior-not-implementationSkill
- principle-two-human-rolesSkill
- reflectSkill
- unknownsSkill
The file
We split this AGENTS.md into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 70
commit のメッセージは、件名も本文も日本語で書く(feat・docs などの type は英語のまま)。
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
bb-writ の開発の取り決め
bb-writ は、CLI ハーネス(Claude Code・Codex。Grok Build も同じ SKILL.md を読む)向けのスキルのプラグイン。概要・入れ方・生い立ち・ライセンスは README.md。オーナー専用の取り決め(手元の環境・試験用のリポジトリ・push の方法)は、gitignore した CLAUDE.local.md にある(無ければ、この文書だけに従う)。
話し方と名前
- 日本語で話す。
- 旧い作業名(runner・ランナー)を名前に使わない。
公開リポジトリとして
- このリポジトリは公開している。個人名・所属先や他人のリポジトリ名・非公開のリポジトリ名・手元の絶対パス・メールアドレスを、ファイルにも commit のメッセージにも書かない。
- 計画の記録と実測の結果は、このリポジトリに置かない(オーナーの非公開の置き場に置く)。ルールの根拠は、別の文書を指さずに、この文書とスキルの本文に書く。
形
- 入口は
skills/bb-writ、手引きはskills/playbook-*、委任とホストごとの接続点はskills/delegate、審査はskills/interrogate、検証スキルの生成はskills/create-verification-skill、形式検証の検査の生成はskills/create-formal-verification-skill、性質の試験の生成はskills/create-property-test-skill、学びはskills/reflect・skills/correct、原則はskills/principle-*(1 本 1 スキル)。スキルは目的ごとに分ける(1 つに詰め込まない)。bb-writ 自身を確かめる検証スキル(verify-parallel)は配らず、create-verification-skillの決めどおり.agents/skills/に置く(Claude Code には.claude/skills/からの symlink で見せる。置き場と symlink を確かめる検査は無い。配布の検査はskills/だけを見る)。 - すべて SKILL.md の本文で届く形にする。Claude Code はプラグイン内の別ファイルの Read に承認を求め、
disable-model-invocationのスキルは Skill ツールから呼べない(2026-10-17 の実測。tests/test_distribution.pyが検査する)。 - 補助スクリプトは
scripts/launch.py(別系統の CLI を専用ログインで起動し報告を検査)とscripts/work.py(作業場所の確保・担当の貸し出し・統合の排他と照合・外部操作の照合と実行の記録)。標準ライブラリだけ。補助コードに入れるのは、プロセス終了の検出・結果形式の検査・同じ作業への二重書き込みの防止・公開対象と検証対象の一致(work.py op run --verified)のような、実際に壊れた場合を試せる機械的な約束だけ。「次は設計」「次はレビュー」という工程の順序を持たせない。例外は push・PR の前の関門 1 つで、届ける前の審査か要らない理由と変更の危険度の宣言、HEAD の監査役の記録、作業の記録の欄を求める。何を求め何を見ないかと、その理由は「規則と強制するもの」の表の push・PR の 4 行に書く。 - 必須の機能を bb-writ の hook やカスタム subagent 定義に置かない。hook はホストごとに違い、ハーネス間の互換性を保てないため。入口・原則・手引き・検証スキルの生成・学びは、それらが無くても成り立たせる。hook を使うのは任意の案内や通知だけ。
置き場
- 設定
~/.config/bb-writ/(dotenvx の.env・.env.keys、専用ログインのclaude-home・codex-home・grok-auth、比較用のcmp/)。状態~/.local/state/bb-writ/(work/作業場所ごとの担当・記録・証拠、delegations/とdelegations.jsonl委任の記録、grok-homes/起動ごとの Grok の home、resuming/続きの排他、notes/、worktrees/)。状態の置き場に置くものには、消す者と時を決める(消さないと決めるものは、そう書く)。担当・ロック・統合の記録は、work.pyが操作の終わりに消す。worktrees/のタスクの作業場所はtask cleanupが消し、呼ばれなかったものはtask start・task listのunclosedに出る。読み取り専用の Codex の子の一時ディレクトリ(delegations/<名前>/tmp)とgrok-homes/の home は、launcher が起動のたびに、7 日使われていないものと、もう無いタスクの作業場所だけを見ていた子のものを消す(使っている置き場は、そのディレクトリに掛けた排他で守る)。記録・証拠・報告(work/、delegations/の中の報告、delegations.jsonl、notes/)は、消さないと決めてある(消す者を置かない。増え方は守らない)。resuming/は空のファイルで、消さない。delegations/・grok-homes/の下は launcher だけが書く(読み取り専用の Codex の子と Grok の子は、自分の置き場の中にだけ書けた)。手やほかのプロセスで消さない・名前を付け替えない(launcher は、片付けや起動と同時の付け替えを守らない)。状態の置き場を、子の sandbox が書ける場所(/tmpなど)の下に置かない。 - 専用ログイン: Claude Code は
~/.config/bb-writ/.envのCLAUDE_CODE_OAUTH_TOKEN(dotenvx)とCLAUDE_CONFIG_DIR=~/.config/bb-writ/claude-home、Codex はCODEX_HOME=~/.config/bb-writ/codex-home、Grok Build はGROK_HOME=~/.config/bb-writ/grok-auth。呼び出し方はskills/delegate/SKILL.md。 - プラグインとして配る(大前提)。出すときは
.claude-plugin/plugin.json・plugin.json・.claude-plugin/marketplace.jsonの版を一緒に上げる。Codex も同じ 2 つ(marketplace と root のplugin.json)を読む(0.163.0 で確認)。ホスト専用のマニフェストは、必要が実物で出るまで足さない。Codex の専用ログインは版ごとの写しなので、版を上げたとき、または版を上げる前の変更を Codex の子で使うときはcodex plugin remove bb-writ@bb-writ→add(中身が違うと launcher が Codex の子を起動しない)。 - 変更履歴は利用者向けの
CHANGELOG.md1 つ。版を上げる commit で、先頭に## <版> - <日付>の節を足し、前のタグからの変更(版を上げなかった commit の分も)を利用者に何が変わるかで書く。開発者向けの履歴は別に書かず、タグの間の git log を使う。push の後、その commit にclaude plugin tag --pushでタグ(bb-writ--v<版>)を付け、Release はgh release create <タグ> --title "bb-writ <版>" --notes-file <その節を抜き出したファイル>で作る。Release の本文は手で書かない(同じ文面を 2 か所で持たないため。commit を経ない文は、公開前の検査も通らない)。
試験
- 単体:
python3 -B -m unittest discover -s tests -t .(偽の CLI で launcher と work.py、配布の形)。tests/test_properties.pyは Hypothesis(tests/requirements.txt、試験だけの依存)で入力の形の性質を見て、無ければ飛ばす。CI は入れて回す。 - スキルの変更は、新しい CLI セッションで実物を確かめる(最初のツール呼び出しで使われるか、成果物)。比べるときは
skills/playbook-eval。 - GitHub に触れる確かめは、自分が管理する試験用のリポジトリで行う。子の CLI の起動に、普段渡さない設定(
GH_CONFIG_DIR・GH_TOKEN)を足さない。
規則と強制するもの
訂正を受けたら、誤りを直してここに規則を足す。強制するものが無い規則で同じ誤りが起きたら、同じ変更で検査に上げる。起こりえなくなった規則は消す。
| 規則 | 強制するもの |
子の起動の後、ホームに空のファイル・ディレクトリを残さない(子の CLI の sandbox が作る。空の .bash_profile でログインシェルが .bashrc を読まなくなった) | scripts/launch.py が子の前後のホームを home_entries で比べて failed にする(読めない場所が増えたときも)。Claude Code 2.1.309 の sandbox が設定を組むときに作る空のディレクトリ ~/.claude/ssh(サーバー側の機能フラグが有効なとき。CLI が ~/.claude の下に作り、CLI の中にもほかに使う所が見つからない)だけは数えず、消さない。tests/test_launch.py の test_child_leaving_empty_files_in_home_fails・test_only_the_empty_ssh_dir_claude_code_makes_in_home_is_not_residue・test_a_child_hiding_part_of_home_fails、tests/verify_sandbox_live.py の no_home_residue |
書く子の起動の後、対象の直下に、中身の空の場所を残さない(時間切れで止めた Claude Code 2.1.310 の書く子が、0 バイトの .bashrc などと空のディレクトリだけの .claude/ を作業場所に残した) | scripts/launch.py が書く子の前後で対象の直下を比べ、新しくでき、中身が空のままで index に無いものを cwd_residue に並べて failed にする(消さない)。tests/test_launch.py の test_empty_places_the_child_leaves_in_the_target_fail |
| 子の CLI が終わった後(時間切れを含む)、子が起こしたプロセスを残さない(Claude Code の Bash は新しいセッションで動き、プロセスグループを止めても、審査役の試験が子の終了から 49 分以上動いた) | Linux は scripts/launch.py が subreaper になって子孫を止め(照合の前に止める順序は試験で見ない)、止めきれなければ failed。tests/test_launch.py の test_processes_the_child_detached_do_not_outlive_it。test_a_child_the_launcher_cannot_stop_or_check_fails。Linux の外はプロセスグループを止めるだけ(確かめていない) |
| 時間切れで止めた子を、最初から起動し直さない(審査役 2 人が 30 分で止まり、報告の無いまま 90 分で立て直した。それまでの作業は子の会話記録に残っていたが、記録に session が無く続けられなかった) | scripts/launch.py が session を起動の前に決め(Codex は最初の thread.started)、時間切れを timeout と session つきで記録し、--resume が同じ session・同じ権限で続きを起動する。続きの head は前の起動と同じ commit のときだけ書く(審査の続きを、間に進めた commit の審査に数えない)。権限の照合に当たった起動は続けさせない(記録の resumable)。tests/test_launch.py の test_a_timed_out_child_continues_from_where_it_stopped・test_a_timeout_does_not_hide_other_failures・test_a_codex_resume_judges_the_earlier_turns_by_their_own_launch・test_a_resumed_review_counts_only_for_the_commit_it_started_on・test_a_resume_checks_what_it_takes_over_from_the_last_launch・test_resume_takes_the_launch_only_from_the_record |
子を途中で止めるときは launcher に TERM を送り、launcher と子を木ごと KILL しない(中断で木ごと止め、Claude Code 2.1.310 の子が対象に空の .claude/.cc-writes を残し、記録も残らず、task cleanup が止まった) | scripts/launch.py が、子を待つ間に受けた TERM・HUP・INT を直下の子に TERM として伝え、子が終わるのを待ってから記録を書く(Linux では猶予の後は KILL)。tests/test_launch.py の test_a_signal_to_the_launcher_stops_the_child_cleanly_and_keeps_the_record。木ごと KILL しないことは delegate・playbook-pause-safely の文だけ(強制するものは無い) |
| 続きの判定は、1 つ前の記録だけでなく session の履歴で行う(続けさせないと決めた session が 1 つ前の記録から ok になり、見た commit も忘れた。同じ記録から同時に 2 つ起動でき、片付けていない空の残りが続きの ok で隠れた。形式検証で初めて見つかった) | scripts/launch.py の session_history・hold_session。tests/test_launch.py の test_a_session_found_unsafe_cannot_be_continued_from_an_earlier_record・test_a_session_runs_in_one_resume_at_a_time・test_a_resume_from_an_older_record_keeps_the_commits_the_session_saw・test_a_resume_refuses_while_the_last_launch_left_empty_places・test_every_reason_that_bans_a_session_applies_from_an_earlier_record・test_a_resume_from_an_older_record_still_sees_later_empty_places・test_a_reason_of_having_nothing_to_check_keeps_the_earlier_record |
| 時間切れでも、いきなり KILL せず、TERM を送って子の片付けを待つ(KILL で止めた Claude Code の書く子が、作業場所に空の置き場を残した) | scripts/launch.py の wait_for_exit。tests/test_launch.py の test_a_timed_out_child_gets_a_term_and_time_to_clean_up |
| 統合の記録を、作業場所やブランチが消えたまま残して、リポジトリ全体の統合を止めない(統合していないのに記録が残り、別タスクが止まった。形式検証で見つかった) | scripts/work.py の settle_integration。tests/test_parallel.py の test_a_stale_integration_record_of_a_gone_task_does_not_stop_others・test_a_failed_fast_forward_leaves_no_record |
launcher の終わりを、コマンド行の文字列で探す待ち(pgrep -f など)で待たない(審査役の launcher が 3〜4 分で終わった後も、待つループが自分のコマンド行に一致し続け、子が 6 時間止まった) | 無い(delegate の文だけ。待つループは親のホストの shell で動き、補助コードからは見えない) |
launcher はプラグインの置き場に __pycache__ を作らない | tests/test_launch.py の test_launch_leaves_no_bytecode_in_the_plugin |
| Codex の子を、launcher と中身の違う bb-writ の写しで動かさない(Codex の子は専用ログインの写しのスキルを読み、入れ直すまでの間に古い写しで 88 回中 8 回動いた。版を上げる前の変更は届かなかった。読み取り専用の子は、写しの一覧だけが見え、本文は読めなかった(2026-11-11)) | scripts/launch.py の codex_stale_copy(skills/・scripts/ を中身で比べ、違えば unavailable)。tests/test_launch.py の test_a_codex_child_does_not_start_on_a_stale_copy_of_bb_writ |
Claude Code の子に CLAUDE_CODE_SUBPROCESS_ENV_SCRUB を使わない(許可の方針を既定に戻し、空のファイルを残した) | 読み取り専用の子は tests/test_launch.py の test_claude_read_only_in_worktree_denies_the_common_git_dir。書く子は試験が無く、残った空のファイルを上の home_entries が捕まえる |
Claude Code の子には背景の処理を使わせない(CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1。審査役が試験を背景で回し、終わりの知らせが次のターンを起こして、--output-format json が最後のターンの結果だけを返し、報告が 2 回消えた) | tests/test_launch.py の test_claude_child_gets_no_parent_claude_env(書く子と読み取り専用の子の両方) |
Claude Code の子に、親の CLAUDE*・ANTHROPIC_* の環境変数を渡さない | tests/test_launch.py の test_claude_child_gets_no_parent_claude_env |
| 入口の聞く範囲・呼び直しの文・返答の形・検証の条件 (1)〜(6) の文を、要約の後に戻る先頭 5,000 トークン(字数で近似して 5,600 字)に置く。入口が合計の枠から丸ごと落ちたときのため、手引き 8 本(feature・bug・docs-skill・investigation・parallel・session-pickup・verify・deliver)・delegate・interrogate の 10 本だけ、本文の先頭 4,000 字以内に呼び直しの文を置く(単独でも呼ばれる delegate・interrogate は入口から始めた仕事に限る。pause-safely・eval・reflect・correct・unknowns・原則・検証スキルには置いていない) | tests/test_distribution.py の test_entry_keeps_what_to_ask_and_review_rules_within_the_compaction_head(目印の語の位置だけ。順と意味は確かめず、意味は読者役で確かめる)と test_skills_invoked_after_the_entry_say_to_reinvoke_it_after_compaction |
push・PR は、届ける前の審査を通した commit(HEAD と同じで、その commit を対象に launcher で起動して ok で返った読み取り専用の子(審査役・確かめ役など。監査役は除く)の記録(delegations.jsonl の head)がある)か、要らない理由と、変更の危険度を宣言してから出す(危険度も理由も書かずに interrogate を省いて push した。レビュー対応で試験を足した commit を、新しい子の再審査なしに push した。宣言にした後も、子を立てず、自分で入れた退行の注入を審査の代わりにして HEAD を書いた。危険度を中と書いても、後退の一覧を攻める子の記録だけで push し、interrogate の観点の審査が無かった) | scripts/work.py の op run・op begin の --reviewed・--risk(中・高は none: と並べられず、その記録のうち --interrogate を付けて立てた審査役のものが要る。付けたという記録(行と record.json の両方で真)だけを見て、子の役や依頼文は見ない)と、scripts/launch.py が書く委任の記録の head・interrogate。tests/test_work.py の TestReviewedCommit、tests/test_launch.py の test_the_record_names_the_commit_the_child_saw_only_when_the_tree_matches_it・test_an_interrogate_reviewer_is_recorded_and_its_resume_stays_one。人数・審査の中身・手で書き足した記録(BB_WRIT_STATE_DIR の付け替えを含む)と、none: の理由の真偽は確かめない |
push・PR は、宣言(--reviewed none: を含む)にかかわらず、HEAD を対象にした遵守の監査役(返す前の判定)を launcher で立て、ok で返ってから出す(規則の文書の変更で、確かめ方を「合意を含むか」にし、スキルが求める読者役を PR 本文の読み手で、意味の判断を役割の違う repo 独自の agent で代え、none:文書だけ で push して、行どうしの食い違いを人のレビューまで見逃した。中立な再現で、遵守を監査する子は 2 人とも代えたことを挙げた) | scripts/launch.py の --audit(記録の audit、依頼文の prompt.md)と、scripts/work.py の reviews_of・op_step(監査役は審査の記録と周に数えない)。tests/test_work.py の test_every_push_and_pr_needs_an_audit_of_the_head_even_when_no_review_is_declared・test_an_audit_does_not_count_as_a_review・test_audits_do_not_count_as_rounds・test_the_triage_is_needed_even_when_no_review_is_declared、tests/test_launch.py の test_an_auditor_is_recorded_and_its_resume_stays_one。監査の中身(代用を挙げたか、届けてよいと書いたか)と、監査役を立てた場所は見ない。監査役の記録も、手で書き足したものを見分けない。審査(上の行)と監査役の関門は鍵の種類(push・pr)と HEAD で決まり、実行するコマンドとその push 先は見ない(merge・release などほかの鍵には、審査・監査役・作業の記録の欄の関門は掛からない。--verified は push・pr・merge・release のどれにも要る) |
| push・PR は、作業の記録の目的・制約・確かめ方・指摘の扱いを書いてから出す(長いセッションで、言い直し・記録・22 件の指摘の扱いの一覧を飛ばしたまま直し始めた。入口の文は 1 週間で約 2 倍の約 15,500 字に膨らんでいた) | scripts/work.py の note_gaps と op_step。tests/test_work.py の TestNoteBeforePublish、tests/test_properties.py の TestFixedExamples(Hypothesis なしでも回る)と TestInputShapes(揺れの組み合わせ)。欄が空かどうかだけを見て、中身・書いた順は見ない。雛形の行を書き換えた欄の行(「* 目的:」「- 目的:」)は欄と見なさないので、その前の空の欄が埋まって見えることは守らない(手元の記録 202 件で、記号や「:」を書き換えた欄の行は 0 行。別の文言の括弧の行 14 行は多くが欄の中の項目で、中身に数えるのが正しい) |
| task start の作業場所で審査が 3 周に達したら(その作業場所を --cwd にして launcher で読み取り専用の子(審査役・確かめ役など。監査役は除く)を立てて ok で返った commit が 3 つ)、審査を通した commit の push・PR は、作業の記録の「仕組みの要否」(直している仕組みが目的の値に要るかを、仕組みあり・なし・別の形で比べたもの)を書いてから出す(審査の周ごとに仕組みへ直しを足し、仕組みが目的に要るかを誰も問わないまま約 25 周回した。同じ場面を再現した長い作業で、原則の文だけの版は直しを足し続け、雛形の欄と入口の文を足した版は引き継いだ直後に仕組みを外した。関門そのものが働く場面は確かめていない) | scripts/work.py の review_rounds・note_gaps・op_step。tests/test_work.py の TestPremiseAfterRounds。委任の記録の行だけを見るので、手で書き足した行も周に数える |
| CI の結果を見ずに完了と報告しない。Release は CI が通った commit にだけ出し、CI の上限は最も遅い OS の実測の 3 倍以上にする(macOS の job が上限 10 分で 3 回続けて打ち切られ、push 直後に Release を出して見なかった。ほかのリポジトリでも macOS の時間切れを繰り返した) | scripts/work.py の ci_not_passed(op run の release)。tests/test_work.py の test_a_release_waits_for_the_ci_of_the_commit_to_pass、tests/test_distribution.py の test_ci_jobs_have_room_for_the_slow_macos_runners。push の後に CI を待つことと、ほかのリポジトリの上限の決め方は playbook-verify の文だけ |
版はマニフェストの間で揃え、CHANGELOG.md の先頭は今の版。スキルは SKILL.md の本文だけで届き、名前はフォルダと同じ | tests/test_distribution.py |
| 試験が PATH に置く偽のコマンドの中から本物を呼ぶときは、PATH を変える前に引いた絶対パスで呼ぶ。偽物が呼ばれたことを記録で確かめる(偽の git が PATH で自分を呼び続け、利用者のプロセスの上限を埋めて、同時に動いていた Claude Code を落とした) | tests/process_limit.py(包みと各試験のモジュールの先頭から読む)が、試験のプロセスとその子に、利用者の今のスレッド数と元の上限の中ほどの上限を掛ける(Linux。同じ誤りでも増えるのは試験の分だけ)。tests/test_launch.py の test_tests_run_under_a_process_limit |
| bb-writ が状態の置き場に置いたものの要否を、利用者に聞かない。置くものには、消す者と時を決める(消す者のいない子の一時ディレクトリが 3 週間で約 4G たまり、片付けを呼ばれなかったタスクの作業場所が 22 個残った。片付けるかを利用者に返し、「要否をわたしが決めるのは無理」と言われた) | scripts/launch.py の sweep_leftovers(起動のたびに、自分の作った一時の置き場のうち、もう続きから起動されないものを消す)・hold_place(使っている置き場のディレクトリそのものの排他。記録の値にも、ほかのファイルにも頼らない)・remove_tree(fd から降り、symlink をたどらずに消す)・片付けの対象の置き場を指す記録からの --resume の拒否。tests/test_launch.py の test_the_launcher_removes_its_leftovers_after_the_retention・test_places_used_recently_or_without_a_date_stay・test_places_of_a_cleaned_up_task_go_without_waiting・test_a_place_without_a_record_is_judged_by_the_date_in_its_name・test_a_place_in_use_is_kept_whatever_the_records_say・test_a_place_used_again_while_the_sweep_was_deciding_is_kept・test_only_real_places_inside_the_state_are_removed・test_a_linked_delegations_or_homes_directory_is_not_followed・test_a_directory_swapped_for_a_link_during_the_sweep_is_not_followed・test_nothing_is_removed_where_a_directory_cannot_be_locked・test_a_resume_is_refused_once_its_place_is_gone・test_a_place_due_for_removal_cannot_be_continued_even_before_it_is_removed。scripts/work.py の unclosed_tasks(片付けを呼ばれなかったタスクを見せる。見るだけで、何も書かない。tests/test_parallel.py の test_a_new_task_reports_the_tasks_nobody_closed・test_looking_for_unclosed_tasks_writes_nothing・test_a_broken_record_of_another_task_does_not_stop_a_new_task)。片付け・最初の起動・続きの起動の順序と途中の kill -9 は、tests/test_sweep_model.py のモデルが、写した範囲(置き場 1 つ、続き 2・片付け 2)で全部たどる(test_the_modeled_code_keeps_the_promises_in_every_interleaving・test_each_reverted_guard_gives_a_counterexample。scripts/launch.py のこれらの関数を変えたら、モデルが今の本文を写しているかを読み直す。機械では検出しない。名前の付け替えは写さない)。見せたタスクを閉じるのは playbook-parallel の文だけ(統合していない変更と、無視される生成物の扱いは判断が要るので、補助コードは消さない)。記録・証拠・報告の増え方は守らない。使える時刻が 1 つも無い置き場(名前にも記録にも日時が無い・未来の日時だけ)は残る。委任の記録の行を書き換えると、使っていない置き場を期限より早く消させることはできる(使っている置き場は消させられない)。ディレクトリの排他を取れない環境では、片付けは何も消さず、理由を記録に出す。片付けや起動と同時に、sandbox の外の同じ利用者のプロセスが、状態の置き場の中の名前を付け替える場合は守らない(読み取り専用の Codex の子と Grok の子は、置き場の改名と、親・親の親の中への作成に失敗した。親そのものの改名は確かめていない)。片付けが途中で止まって半分になった置き場から続きが始まらないのは、記録の行が launcher の書いたものだけで、時計が戻らず、無くなったタスクの作業場所が同じ道筋に作り直されない間だけ(その外では、続きの子が写しの一部を失ったまま始まることがある)。macOS は、CI の試験(偽の CLI で launcher を動かす)のほかは確かめていない(ディレクトリの flock は、XNU の flock が vnode の種類を見ず、FIFO だけを断ることをソースで読んだ) |
担当の期限が切れても、誰も取り直していなければ(lease.json の token が自分のもの)、持ち主の renew・release・op begin・op done・op run・integrate・task cleanup を拒否しない(監査役を待つ間に期限が切れ、誰も取っていないのに、持ち主の op run・renew・release と integrate が終了コード 3 で拒否された。2026-10-26 に 1 回、2026-11-15 に 2 回) | scripts/work.py の held_lease(期限を読まず、記録が dict か、渡された token が空でない文字列かを見る。記録の token と比べるのは続けて呼ぶ check_token)。tests/test_work.py の test_an_expired_lease_nobody_took_stays_with_its_holder(切れた担当の renew が延ばし、op begin は延ばさず、手放した本人の token は 3)・test_an_expired_lease_nobody_took_still_runs_and_is_extended・test_expired_lease_can_be_taken_over_and_old_holder_is_stopped・test_every_refusal_of_begin_refuses_run_the_same_way(取り直された後は 3)・test_a_broken_lease_record_of_the_holder_is_answered_without_a_crash・test_an_op_without_a_token_is_refused_even_when_the_lease_has_none・test_a_broken_expiry_does_not_crash_op_run_or_leave_its_lock・test_op_run_does_not_shorten_a_longer_lease、tests/test_parallel.py の test_an_expired_lease_nobody_took_still_integrates_and_cleans_up・test_an_expired_lease_taken_by_another_stops_the_old_token・test_a_broken_lease_record_stops_integrate_and_cleanup_without_a_crash、tests/test_oprun_model.py の不変条件 HolderKeepsAccess(戻した版 holder_by_token が反例を出す)。期限を延ばすのは renew と op run(コマンドの間は監督役の keep_lease)だけで、期限の切れたまま通った op begin・op done・integrate・task cleanup の後も、ほかの者は担当を取れる(延ばさないことを試験が見るのは op begin だけ)。期限の切れた担当をほかの者が取ること(待っている持ち主のタスクを、別のセッションが unclosed として閉じることを含む)は止めない。誰も取り直さない限り、切れた担当の token には時間の上限が無い。取り直された後に、担当の記録の token を元の値へ書き戻されると、元の token は通る(check_token は記録との一致だけを見る。変更の前から同じで、書く子は記録から token を読める)。holder の欠けた記録では、前からのとおり持ち主の op begin・op done・op run が落ち、担当が生きている間は status・claim(task resume を含む)・token の違う renew・release も落ちる(守らない) |
scripts/work.py の op run・監督役・操作ごとのロック・担当の約束を変えたら、tests/test_oprun_model.py のモデルを直して全探索を通し、照合した commit とハッシュを進める(審査が 1 周に 1 つずつ交互実行と途中の kill -9 を見つけ、そのたびに直していた) | tests/test_oprun_model.py の test_the_modeled_code_keeps_the_invariants_in_every_interleaving(担当 2・鍵 2・token 3 の範囲の交互実行を全部たどる)・test_each_reverted_fix_gives_a_counterexample(過去の修正を戻した版が反例を出す)・test_the_model_is_the_one_checked_against_tlc(モデルを変えると落ちる。TLC で照らし直したかは確かめない)・test_the_model_was_checked_against_the_current_code(モデルが写す経路の関数の本文と、それが読む定数のハッシュ。変わったことを知らせるだけで、ハッシュを進めたときにモデルと照らしたかは確かめない。コメント・先頭の docstring だけの変更は見ない。写さない経路(task start・resume・cleanup、integrate、pending、main など)の変更は見ない) |
commit
- 通常は main に直接 commit する。並行開発ではタスク専用の worktree・ブランチで commit し、最新の main を取り込んで検証した版を、排他の下で main に統合する。Conventional Commits。
- commit のメッセージは、件名も本文も日本語で書く(
feat・docsなどの type は英語のまま)。
守ること
- トークン・認証情報を画面・ログ・会話に出さない。利用者のログイン(
~/.claude・~/.codex・~/.grok)の写しを作らない。ワーカーは bb-writ 専用のログインを使う。 .envを使うコードは dotenvx(@dotenvx/dotenvx。Python も dotenvx の形)。- トランスクリプトの解析はメタデータだけで、本文を引用しない。push・PR をしてよいかは、対象のリポジトリの規則と依頼で決まる(bb-writ の配布物にこの種の取り決めを書かない)。
- 将来に備えた鍵・構造を足さない(実需が出たら作る)。黙って補うより、理由を出して止める。
- 対象のリポジトリを増やすたびに bb-writ 自身(スキル・コード)を直さない。対象に固有のことは対象のリポジトリの中で解く。
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

