agentleFS
B16B1RDB16B1RD/bb-writ/skills/playbook-parallel/SKILL.md

playbook-parallel

Skill0 starsChanged 6 days agoMITView on GitHub

入口 bb-writ の手順 5 で、feature・bug・docs-skill の手引きを読んだ後、Git の作業場所の確保・再開・統合・片付けに使う。依頼を最初に受ける手引きではなく、読むだけの調査にも使わない。

The file

We split this skill 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
  1. Very specific:

    commit 済み・未保存変更なしの状態で、その組み合わせを対象の検査と利用経路で検証する。検証した HEAD の完全な commit ID を verified として記録する。

    line 39

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill 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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

タスクごとの作業場所と統合

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

依頼に合う feature・bug・docs-skill の手引きを先に読み、実際に書く段階でこの手引きを使う。

Claude Code 同士・Codex 同士・混在を区別しない。作業の単位はタスクで、担当の名前はホストと session ID。1 タスクに 1 worktree・1 ブランチを割り当てる。担当が違うタスク同士は並行し、同じリポジトリへのローカル統合は直列にする。工程の判断はエージェントが行い、補助コードは作業場所の確保・排他・保存先と commit の照合だけを担う。

work.py はプラグインの scripts/work.py。Claude Code は ${CLAUDE_PLUGIN_ROOT}/scripts/work.py、Codex・Grok Build はこの SKILL.md から 2 つ上の scripts/work.py を使う。以下の <work.py> はその実物に置き換える。Python 3.9 以上、Linux・macOS・WSL2 が前提。

始める

  1. 元の checkout の規則、ローカルの指示、現在のブランチ・差分を読む。規則が worktree やタスクブランチを許さなければ勝手に書き換えない。元の checkout の未 commit 変更を stash・コピー・commit しない。依頼がその変更を対象とするなら、分離して見えなくなる変更を示して扱いを確認する。
  2. 新規なら python3 <work.py> task start --dir <元の checkout> --holder "<ホスト> <session>"。基点は統合先の commit、統合先は呼び出し場所のブランチ(既存タスク内ならそのタスクの統合先)。依頼に別の基点・統合先があれば --base <commit等> --target <ローカルブランチ> を付ける。状態ディレクトリの worktrees/ に作業場所が作られる。呼び出し場所に変更を書かず、返された dir で以後の読み書き・検査・commit を行う。出力に unclosed があれば、片付けを呼ばれなかったタスクが残っている(「片付ける」の最後)。
  3. task・branch・base・target・token を記録し、note.path に目的・制約・検証条件・session ID を追記する。task start は担当も取るので、同じ場所で重ねて claim しない。単位ごとに renew --dir <dir> --token <token>。拒否されたら書くのをやめる。
  4. worktree では gitignore した設定や依存が存在しないことがある。対象の通常の準備手順を使い、認証情報や利用者の設定を複製しない。DB・ポート・生成先なども共有するなら、対象の仕組みで分ける。commit 前に元の checkout と作業場所の実効 author・committer と Git 設定の適用元を確認する。違いを --author や一時の環境変数で隠さない。

子に書かせるときは、ここまでを親が行って release し、子はその dir で claim する。再開・統合・片付けも親が行う(delegate)。

Git 以外の書く仕事は従来どおり作業場所の claim を使う。読むだけの調査は作業場所を作らない。新規タスクか再開かをホスト名だけで推定しない。同じ依頼が再送された可能性があれば、一覧と記録から既存タスクを探す。

再開する

python3 <work.py> task list --dir <元の checkout> でタスク・担当・作業場所・未完了の統合を確認する。目的とブランチ、記録を照合し、同じ仕事なら task resume --dir <元の checkout> --task <task> --holder "<ホスト> <session>"。担当が生きていれば拒否される。期限切れ後の担当には新しい token が返る。ホストや session が変わっても同じ作業場所と未 commit 変更を保持する。worktree_branch が記録したブランチと違う場合(detached HEAD なら null)は、その HEAD と差分を保存しながら中断処理を解決する。再開だけで自動的に checkout し直さない。片付けの途中で停止していた場合は、保存先を再照合して completed: true が返ることがある。その場合は新しい担当 token を取らず、完了として報告する。再開の実作業は playbook-session-pickup に従う。

作成途中の停止で作業場所も登録もまだ無い場合は、同じ task resume が記録したブランチ(未作成なら基点)から作成を再開する。一部のファイルや不完全な worktree 登録が残る場合は、task list、git worktree list --porcelain、ブランチと差分を照合する。残っているものを自動で作り直したり削除したりしない。元の担当が動作中なら、期限切れだけを理由にそのプロセスと同時に編集しない。統合の補助操作中はファイルロックがあるため、担当の取り直しは Git の終了まで待つ。

ローカルに統合する

対象の規則と依頼がローカル統合を許すときに使う。元の checkout を統合先ブランチに置き、その checkout の通常の担当は解放しておく。そこで別の担当が書いている場合は統合しない。

  1. 統合先の完全な commit ID を取得し、expected として記録する。
  2. 自分の作業場所でその commit を取り込む(例: git merge --no-edit <expected>)。競合は自分の作業場所で解消する。仕様の矛盾だけ利用者に確認する。
  3. commit 済み・未保存変更なしの状態で、その組み合わせを対象の検査と利用経路で検証する。検証した HEAD の完全な commit ID を verified として記録する。
  4. python3 <work.py> integrate --dir <作業場所> --token <token> --expected <expected> --verified <verified>。リポジトリ共通の排他中に、担当・ブランチ・両方の差分・統合先・検証した HEAD を照合して fast-forward する。統合先が進んでいれば終了コード 6。最新の統合先を取り込み、影響する検証を取り直す。元の checkout に書きかけの変更や別の担当がある場合も、変更せず拒否する。

統合の途中で止まると、共通の統合記録が残る。統合先に書きかけの差分が無ければ、補助コードが実物で閉じる。反映されていなかった記録と、作業場所が消えたタスクの記録は取り消して先へ進む。反映済みで作業場所が残る記録は、そのタスクを再開して、記録にある expected・verified で同じ integrate を呼ぶと完了を復元する(別タスクはそれまで進まない)。統合先の書きかけの差分がある場合は、その HEAD・index・差分を照合し、変更を保存してから再開する。reset --hard や統合記録の手動削除で通さない。

GitHub の PR・保護ブランチ・マージキューなどの経路を、ローカル統合で迂回しない。外部操作の許可・アカウント確認・記録・--match-head-commit は playbook-deliver に従う。この integrate の排他はローカル統合用で、別 PC や GitHub 上の更新を排他しない。外部の統合先との組み合わせの検証は、対象の CI・必須の最新化・マージキュー等で満たす。

片付ける

中断時は作業場所を残して release する。記録と証拠を消さない。依頼で成果ブランチを残す場合も同じ。

完了して片付けるときは、変更を含む別のブランチかタグを確認し、python3 <work.py> task cleanup --dir <作業場所> --token <token> --saved <保存先のブランチかタグ>。タスクのブランチがそのまま・gitignore したファイルも含めて未 commit 変更なし・未完了操作なし・タスクの変更が保存先に入っていることを検査して、worktree とタスクブランチだけを削除する。初期化したサブモジュールのある作業場所は、Git が削除を拒むので片付けない(--force はサブモジュールの中のものも消す)。中身を確かめて、利用者に報告する。変更が入っているかは、HEAD が保存先の祖先か、HEAD を保存先へマージしても保存先のツリーが変わらないかで確かめるので、squash・rebase で統合した後(統合先が進んだ後も)は統合先のブランチをそのまま渡す。タグを作って渡す回避はしない。生成物が残る場合は自分が作ったものだけを片付け、秘密や由来不明のファイルは削除しない。拒否の理由が「未保存の変更・未完了の操作がある」で、何が残っているか分からないときは、git -C <作業場所> status --porcelain --untracked-files=all --ignored=matching で見る(task cleanup と同じ見方。無視されるディレクトリは、空でも中身があっても !! <名前>/ の 1 行で出る)。自分の仕事で立てた子の CLI が、下の階層に空の .claude/.cc-writes/ を残すことがある。空であることを確かめて、rmdir で外す(空でなければ消さず、返答に書く)。対象のリポジトリが .claude/ を丸ごと無視していると、!! <下の階層>/.claude/ と親が出る。中が空の .cc-writes/ だけなら、それを外した後、空になった親の .claude/ も rmdir で外す(親に別のものがあれば、どちらも消さず、返答に書く)。何も出なければ、終わっていない操作がある(python3 <work.py> op pending --dir <作業場所> で見る)。統合していない commit が残る・統合先で取り消された・衝突する場合は拒否されるので、変更を失っていないと自己判断して強制削除せず、作業場所を残して報告する。記録と証拠は削除しない。

タスクの変更を捨てるよう頼まれたときも、worktree とブランチを手で消さない(タスクの記録だけが残り、task list に出続ける)。未 commit の変更は commit し、捨てる commit を別のブランチに退避して(git branch <退避の名前> <タスクのブランチ>)、そのブランチを保存先にして task cleanup する。task cleanup は、gitignore したファイルも含めて作業場所に何も残っていないことを求めるので、生成物は上のとおり自分が作ったものだけを先に片付ける。退避のブランチを消すかは、依頼に従う。作業場所もブランチも既に消えているタスクの記録は、task resume で基点から作業場所を作り直し、統合先を保存先にして task cleanup する(基点が統合先に入っていれば通る。入っていなければ拒否されるので、記録を照合して報告する。前の担当の期限が残っていれば task resume は拒否されるので、切れるのを待つ)。作業場所のディレクトリだけが消えて Git の登録が残っているとき(git worktree list --porcelain に prunable と出る)は、task resume もブランチの削除も拒否される。一覧と照らしてから git worktree prune し、同じ手順で閉じる。このときブランチは残っているので、統合先に入っていない commit があれば、統合先を保存先にした task cleanup は拒否される。捨てるなら、上の退避の手順で閉じる。

task start・task list の出力の unclosed は、担当のいない(解放済みか期限切れ)か、担当の記録を読めない(lease が unreadable)タスクで、作業場所が残っているもの。作業場所は task cleanup だけが消すので、呼ばれなかったタスクは残り続ける(PR を出して終えたタスクなど)。自分の仕事を片付けるときに、task list で取り直して(担当の記録の壊れ方によっては、task list は並べずに止まる。そのときは、自分のタスクを始めたときの task start の出力にあったものを使う。一覧のために task start を呼び直さない。新しいタスクができる)、1 つずつ決める。利用者に要るかどうかを聞かない。lease が released か expired で、landed が真で、commits が 1 以上のものは、変更が統合先に入っているので、task resume で担当を取り(閉じるためだけに取る。その仕事は続けない)、そのタスクの統合先(target)を保存先にして task cleanup で閉じる。拒否されたら、その作業場所のものは何も消さない(前の担当が残した生成物も消さない。無視されるファイルが作り直せるものか、手で置いたものかは、作った担当にしか分からない)。取った担当を python3 <work.py> release --dir <その作業場所> --token <取った token> で返して、作業場所を残す。理由が「未保存の変更・未完了の操作がある」のときは、何が残っているかは出ないので、上と同じ git -C <その作業場所> status --porcelain --untracked-files=all --ignored=matching で見て、返答に書く(何も出なければ、終わっていない操作がある)。landed が偽のもの(統合先に入っていない commit がある)、landed や commits が空のもの・lease が unreadable のもの(記録が壊れていて確かめられない)、commits が 0 のもの(まだ何も commit していない。止めたままの仕事かもしれない)は閉じない。返答には、閉じたものと、閉じなかったものを理由(残っているもの)とともに、1 行ずつ書く。

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.