CommandMate: Command for Claude Code

並列Issueオーケストレーション

概要

developブランチをオーケストレーターとして、複数Issueの並列開発からUAT合格までの全ライフサイクルを統括します。各Issueはfeatureブランチのworktreeで並列に開発され、commandmatedev CLIで制御します。

原則: オーケストレーターはコードに触れない。制御と判断のみ。

必ず守ること

実測・根拠は docs/orchestrate/ へ。本体には規則を 1 行だけ書く。 根拠は「根拠: docs/orchestrate/.md#<見出し>」の行で指し、 run のたびには読まない手順（exit code ごとの対処・担当の切り替え・monitor）は、本体に「いつ・どの文書を読むか」を書いて docs/orchestrate/ に置く。 本体のバイト数の上限は scripts/check-orchestrate-size.mjs が持つ（CI の orchestrate-size）。超えたら、実測・根拠を docs/orchestrate/ へ移す。 下は、本文に散らばった必須・禁止の規則を 1 行ずつ集めたもの。括弧は元の見出しで、規則は元の場所にも残っている。

• オーケストレーターはコードに触れない。制御と判断のみ（概要）
• develop ブランチ上で実行する。契約系フラグ（--contract / --verify）が使えることを最初に確かめる（前提条件）
• 送り先は --instance で指定し、send / wait / capture / respond で同じ値を渡す（Phase 0）
• ワーカーに /model を送らない。Claude のモデルは起動時に .claude/settings.local.json で決める（Phase 0）
• 迷ったら難（opus）にする。迷ったら Claude に回す（1-2b）
• worktree の npm install では --include=dev を省かない（2-2）
• requireCommit: true を外さない（2-4）
• 同じブランチに契約を積むときは、scope.allow を前の契約の allow との和集合にする（2-4）
• .sh を触る Issue では gates に lint-sh を足す（2-4）
• CHANGELOG.md と docs/module-reference.md を scope.allow に入れない。ワーカーには断片を書かせる（2-4-1）
• 整理と、振る舞いの変更を同じ PR に入れない。整理の契約の scope.allow に tests/** を入れない（2-4-3）
• tmux・セッションに触れる Issue は、2-5 の 4 項目を契約に転記する（2-5）
• 実機でエージェント CLI・サーバーを動かす Issue は、隔離の項目を契約に転記する（2-6）
• 2.5 の分析の依頼は契約を使わない（素の send）（2.5-1）
• assign.tsv / tasks.tsv を stdin で読まない（fd 3 から読む）（3-1）
• send が exit 99 なら、待つ前に画面を見る（3-1）
• send の stdout はパイプで切らずファイルに落とし、送信後に started=1 を確かめる（3-1）
• monitor の COMPLETE 判定をマージ可否の裁定に使わない。裁定は wait --verify の exit code（3-2）
• wait には --instance "$AGENT" と --on-prompt human を付ける（3-3）
• 裁定が作業の終わりのものだと確かめてから Auto-Yes を切る。合格の記録は再利用しない（3-3）
• Antigravity 担当は、完了の合図（IMPL_COMPLETED）を確かめてから裁定する（3-3）
• 不合格は先にワーカー起因かを判定する。再指示は同一 worktree につき最大 2 回（3-4）
• 再指示の後の裁定は wait → verify --task の 2 段で行う（3-4）
• ワーカーに「lint/tsc/test を実行して結果を報告して」と送らない（5-1）
• 未処置の指摘（5-3）が残っている PR はマージしない（5-3）
• 検証の順番待ちの間に、オーケストレーターが worktree にコミットしない（5-3）
• 同時 CI は 3〜4 本。1 本に落とすのも失敗である（6-1）
• MERGEABLE を組み合わせがコンパイルできる証拠にしない。refresh → tsc ＋ 影響テストを通してからマージする（6-2）
• PR の pull_request run を手でキャンセルしない（6-2）
• bucket に fail / cancel が 1 つでもあればマージしない。判定はスクリプトで行う（6-3）
• 断片が無い PR・check が exit 0 にならない PR はマージしない（6-4）
• 起票の前に同じ不具合の開いている Issue を探す。起票はユーザーの了承を得てから行う（8-3）