orch

全体像

orchとは、orchタグの付いた未完了のアクティビティで、説明の先頭に「担い手」欄を持つもの。担い手欄に名前とsessionIdで書かれた窓口が、今のorchの担当（今の担い手）である。担い手欄が「空席」、または書かれた窓口が生きていない状態は異常ではない。子として振ったbgは動き続け、報告はログに溜まる。

一生のサイクルは次の順で回る。

1. なる: 仕事を受けた窓口が、自分1体で抱えきれないと判断したら、orchになる（同じ範囲のorchが既にあれば、それに合流するか担い手に頼む）
2. 振る: 子をbgに切り出し、束縛してから起動する
3. 追う: 子とbgの状態を見る
4. 一覧: すべてのorchの担い手・bg・子を一望する（朝はこれに加える形で使う）
5. 空ける／代わる: 窓口を閉じるとき、次に触った窓口が引き継ぐとき
6. 終える: 子が済んだ、またはユーザーの了承を得て閉じる

orchの担い手は、子になる作業をサブエージェントやWorkflowでも自分でせず、必ずbgに振る。orchが自分でやるのはまとめ役の仕事（振り分け・状態の確認・他セッションとの調整・ユーザーへの取り次ぎ）と、自分の判断のための協議（相談役との協議）だけである。

orchは束ねるだけでなく、担当範囲の成果に責任を負う。判断が要る場面では、ユーザーに聞く前に、相談役との協議と実データの収集（調査・実測はbgに振る）で自分で詰める。相談役とは、判断の材料と案を返すだけの相談専用のサブエージェント（その環境で呼べる設計・推論向けのロール。無ければ、判断の論点と材料を渡して案を求めるサブエージェント）を指す。協議は結論を出すための相談で、調査・実測・実装の作業は含まない。結論と責任はorchが持つ。ユーザーに上げるのはユーザーに上げるものの列挙に当たるものだけで、それ以外は在席でも自分で決め、決めた内容と根拠を報告する。

発動の範囲

「orchとして進める」「bgに振って」「orchの状況見せて」「○○のorch続けて」「○○のorch終えて」などのユーザー発話のほか、窓口のClaudeが自分1体で抱えきれないと判断した場面でも自発的に発動してよい。orchタグの付いたアクティビティにcheck-inしたとき（check-in skill経由か、check_inツールの直接呼び出しかを問わない）は、ユーザーの発話がただの「続きやる」「チェックイン」でも必ず発動し、代わる節から入る。

窓口が自分1体で抱えきれないと判断する目安は、判断の要る子の目標が2つ以上ある・長く待つ、に加えて、次のどれかに当たるとき。

• スコープが広くなりすぎた
• 複雑すぎて、やるべきことに自信が持てない
• 情報が足りなすぎる
• 文脈のコントロールが1体ではしんどい

bgに振らずその場で完結する単発の作業やレビューには発動しない。

なる

同じ範囲のorchがあるか確認する

一覧節の手順でsearchし、同じ範囲のorchが既にあるか確認する。

• 空席なら引き受ける（代わる節の手順）
• 担い手がいればその窓口に頼む（peer-nudge skill経由）

orchは無いが、同じ範囲を束ねる未完了のまとめ役（orchタグも担い手欄も無い「[統合]」など）があるとき、またはユーザーが既存のアクティビティを名指ししてorchにするよう頼んだときは、新しく起票せず、それをorchにする（既存のまとめ役をorchにする）。新しく起票すると、同じ範囲に親が2本並ぶ。

無ければ起票する

• activity-startを経由せず、add_activityを直接呼ぶ（check_in=True）。intentはintent:discuss
• タグにorchを含める。domainや内容を表す素タグも付ける
• 説明の先頭に状態節の雛形を置く（状態節とgoalの雛形節を参照）。担い手欄には自分を書く（claude agents --jsonでpidが$CLAUDE_PIDの行のnameとsessionIdを使う）
• 起票と同じ手番で、goalを付ける。形は起点で選ぶ（状態節とgoalの雛形節）
• 最初に振る子が既に分かっているなら、起票のあとすぐに振るへ進み、子を束縛してから開始の宣言を返す

担い手空席の常設orchとして起票する

recompose-context skillで、束ね役の親の提案にユーザーが了承したときの起票。bgに振る話ではなく、同じテーマの子を束ねるために立てる。

1. 無ければ起票すると同じにadd_activityで起票する。担い手欄は「空席」とする。この時点ではgoalを書かない
2. 了承された子を束縛する。根拠はユーザーの了承で、条件の書き方だけ既存のまとめ役をorchにするの手順4の末尾の段落に合わせる（子にgoalが無ければ後付けする）
3. 束縛した条件を持つ常設のgoalを書く（状態節とgoalの雛形節。束縛してから書く）
4. 開始の宣言は返さず、立てたorchと結んだ子の題を一言で伝える。担い手が要るときは「○○のorch続けて」で引き受けられる

既存のまとめ役をorchにする

1. get_by_idsで今のタグと説明を読み、get_goalでgoalのlabelを読む。labelがclosed（判定済み）なら、そのアクティビティはorchにせず無ければ起票するへ進む
2. update_activityを1回だけ呼び、説明とタグを同時に書き換える。分けて書くと「タグはあるが担い手欄が無い」途中の状態ができ、一覧の付け替えがタグを外してしまう
   • 説明: 先頭に状態節を置く（状態節とgoalの雛形節）。担い手欄には自分を書く（名前とsessionIdの取り方は無ければ起票すると同じ）。bg表には、報告先がこのアクティビティで生きているbgがあればその行を書き、無ければ「（無し）」とする。約束・預かり・反映待ちは「（無し）」から始める。元の説明は、役割と範囲として状態節の下に残す
   • 元の説明のうち「orchではない」など、orchでないことを前提にした記述は消し、代わりに経緯へ「{日付}にorchにした（それまではorchでないまとめ役）」の1行を残す。雛形の「書かないもの」に当たる記述（他のorchの担当セッション名、運用規約の写し）も消す
   • タグ: 読んだタグを全部含め、orchを足し、intentをintent:discussに替える。update_activityのtagsは全置換なので、読んだタグを落とさない
3. 同じ手番で、goalを形に合わせる。形は起点で選ぶ（領域を束ねてきたまとめ役なら常設になるのが普通）
   • undefined: 雛形どおりset_goalで作る
   • not_needed（常駐の不要印）: set_goal(..., replace=True)で雛形のgoalに置き換える。不要印のまま残さない
   • active: goalは作り直さない。常設にするなら、update_goalのop=addで錠の条件（担い手human、「ユーザーがこのorchを終えることを了承した」）を足す。期限付きならそのままにする
4. 範囲の中で、まだ束縛していない既存のアクティビティを、下の基準で子にする
5. 開始の宣言を返す。新しく作らず「[統合] ○○」をorchにしたことを含める

既にある未完了のアクティビティを子にするのは、記録から、このorch（またはorchにする前のまとめ役）の仕事として切り出されたと推せるものに限る（recompose-context skillの「親への結びつけ」と同じ基準・同じ条件の書き方）。別のorchの子として束縛済みのもの（各orchのget_goalの条件のboundに出るもの）は子にしない。別の窓口が作業中のものも、基準に合えば束縛してよい。束縛しても作業する窓口は変わらない。子にgoalが無ければ、束縛するときに後付けする（書き方はrecompose-context skillの「goalが未定義」と同じ）。goalが無いままだと、束縛した条件「子のgoalがachievedで閉じた」を満たせない。

開始の宣言

起票（または既存のまとめ役をorchにする手順）が済んだら、次を含む一言をユーザーに返す。

• orchとして回すこと
• 形（期限付き／常設）
• 戻ってくるもの（PRのマージ、判断が要るときのask、止められた操作の許可）

見本:「これは子が3本に分かれて判断も要るので、bgに振って私がorchとして回すね。『[統合] ○○』を作った。形は期限付きで、子が全部済んだら閉じる（ずっと持つ常設にしたければ言って）。あなたに戻ってくるのは、PRのマージと、判断が要るときのask。止められた操作の許可が要るときは、まとめて頼む」

振る

数える

振る前に、claude agents --jsonで全セッションの生きたbg（kind=backgroundかつpidあり）を数える。ユーザーとの取り決めの上限を超えるなら、超えない範囲まで待つ。

束縛して起動する

子1本につき、次の3段を同じ手番で続けて行う。

1. add_activityをcheck_in=Falseで呼び、子を作る（orchタグは付けない。このタグはorchアクティビティ自体にだけ付ける）
2. 子にset_goalでgoalを作る
3. orchのgoalにupdate_goal（op=add）で、子のアクティビティへ束縛した条件を足す

続けて依頼文ラッパー（${CLAUDE_PLUGIN_ROOT}/scripts/bg_dispatch.py。必須引数は--activity-id・--activity-title・--worktree・--parent-goal-handle・--parent-condition-id）で起動する。親goalの指定を必須にする（orchの子は依頼文ラッパーで親goalを指定して振る）。起動後、waitingForを1回見て、起動の入口で止まっていないか確かめる。起動できたら状態節のbg表に1行足す。

期限付きのorchにも、最初の子と範囲の違う子を後から足してよい。2本目のbgのために2本目のorchを作らない。

起動後のbgに、起動時の範囲の外の仕事を送らない。範囲外の残件は新しい子として振る。

起動形

信頼済みのディレクトリで、作業ツリーの中から起動する。止まったらwaitingForを見る。zshのクォート・特殊文字のエスケープに注意する。リポジトリ別の起動場所の具体は、環境ごとの私的な取り決めに従う。

依頼文の書き方

依頼文ラッパーが生成する依頼文に、次を含める。

• 報告先: 親のorchアクティビティ。bgは報告を常にそのアクティビティへadd_logsで書く
• 越えない線: 外向きの操作（他人のブランチ・外部サービスへの書き込み）、~/.claude配下の変更、既決を見直すことになる判断、auto modeや権限に止められた操作は、進めずに報告先へ返す。止められたら迂回しない
• 待たずに進む範囲: 上の線の内側の実装上の判断は、確認が要る場面でも待たずに最も妥当な方針で進め、判断をPR本文と報告に書く
• 人間宛てのaskを起票しない: 人の判断が要るときは報告先へ返す
• EnterWorktreeは使わない
• マイグレーション番号: 必要になったら、origin/mainとopen PRの番号の最大値+1を取り、報告先へ宣言する。返事は待たずに進む。兄弟のbgが同じ番号を取ることはありうるが、yoyoは番号が同じでもファイル名が違えば別のmigrationとして扱い、適用順は-- depends:で決まるので、衝突しても壊れはしない。番号を直すのは後からマージするPR（後発側はマージ順で決める）で、マージする者（orch）がマージ前にorigin/mainと突き合わせ、重なっていれば次の空き番号に振り直させる
• 兄弟との連携: 兄弟（同じ親goalに束縛された他の子）の担当に関わる事実（共有ファイル・マイグレーション番号・mainの破損・前提の変化）を見つけたら、報告先に加えて、その兄弟へもSendMessageで知らせる義務。兄弟の一覧は依頼文に埋め込まず、受けたbgが親goalのconditionsとget_sessionsから引く（orchは子を順に振るので、起動時点では後から振る兄弟が決まっていない）。送るのはこの周知だけで、作業の依頼・質問・進捗は送らせない
• 止める前のsync-memory --minimal: 最後の報告の前に実行する
• 禁止は狭く書き、方針でなく「説明と決定事項に従う」ことを書く。依頼文に"ultracode"やWorkflowの実行指示を書かない（やってはいけないこと節）

追う

生死の規則は2本ある。

• bgの生死: claude agents --jsonでkind=backgroundかつpidあり。stateは生死を表さない
• 窓口（担い手）の生死: claude agents --jsonで、担い手欄のsessionIdが一致しpidがある行がある（kindは問わない）。名前は判定に使わない。Remote Controlの窓口やbgは起動後に名前が自動で変わるため、名前の一致を求めると生きている担い手を死んでいると読んでしまう。そのような行が複数あれば（/resume後に並ぶことがある）startedAtが最も新しい行を担い手とする（/resumeすると同じsessionIdの行が増え、新しく開いた側が今使われている窓口になるため。両方にpidがあっても新しい側に送る）
• 担い手への知らせの宛先: 上で選んだ行の今のname。担い手欄に書かれた名前は人が読むための表示で、宛先には使わない

許可待ちはwaitingForがpermission promptのときと見分ける。attentionの「止まっている」は見に行く候補で、CI待ち・許可待ち・単純に止まった・まだ振っていない、を上の規則で見分ける。

goalのchildrenの「達成」は外した子（waived）を含む。内訳はget_goalの条件で読む。次の一手の規則11が束縛した子について「進める」と返したら、orchでは「振る、または振った子の様子を見る」と読む。

報告済みで次の指示を待っているbgは、要らなければsync-memory --minimalを済ませていることを確かめて止める。

一覧

1. search(keyword="orch", tags=["orch"], entity_type="activity")で引き、get_by_idsで状態と説明を読んで未完了だけを残す
2. 説明の先頭に担い手欄が無いものはorchとして扱わない。orchはorchの目印専用のタグなので、その場で外し、内容に合う素タグに付け替える。CALMのorchの運用を話題にしているものはorchestration、別の意味（プロダクトの部品名など）なら、その意味が分かる別の語（例: プロダクト名を前に付けた語）にする。別の語は、先にsearch_tagsで近い既存のタグを探し、あればそれを使う。update_activityのtagsは全置換なので、今のタグを読んでから渡す。付け替えはユーザーに確かめず、他の窓口のアクティビティでも行い、付け替えたことを一覧に1行添える。orchにしたいまとめ役だったなら、既存のまとめ役をorchにするの手順で付け直す
3. claude agents --jsonで、担い手欄のsessionIdが一致しpidがある行があるかを見る（生死の見方は追う節の窓口の生死の規則による）
4. 各orchのget_goalのchildrenと状態節のbg表を添える

「各orchに○○して」と頼まれたら、この一覧の生きた担い手（その行の今のname）を宛先にし（担当確認・作業依頼はpeer-nudge skill経由）、空席のorchにはログを書く。

朝の一覧

「おはよう、どうなった？」のような呼びかけに対し、上の一覧に次を添える。

• マージできるPR（CI・bot指摘の状態、順序の制約つき）
• 止まっているbg（いつから）
• askの件数（get_overviewのawaiting_humanから）
• 空席のorchの後始末（担い手欄の更新後に溜まったログの件数、Claudeの条件が出揃ったorch、マージ済みで判定待ちの子）
• 期限付きで閉じたorch
• マージ後にユーザーがやること（状態節の反映待ちから作る）

空ける

ユーザーが窓口を閉じると言ったとき（「閉じるから」「終わるから残して」など）に行う。

• 状態節を最新にし、担い手欄を「空席」にする。後任は決めない
• 生きているbgは止めずに残してよい（bg側が最後の報告の前にsync-memory --minimalを済ませている）
• ユーザーに「このorchは空席にした。続けるときはどの窓口でも『○○のorch続けて』」と一言伝える

sync-memoryを実行する窓口が、このorchの担い手で、ユーザーが窓口を閉じると言っているときは、sync-memoryの前に先に「空ける」を行う。閉じないsync-memory（途中の記録）では空けない。

代わる

次にこのorchに触った窓口が行う。

1. check_inする
2. 担い手欄を自分に書き換える。claude agents --jsonでpidが$CLAUDE_PIDの行のnameとsessionIdを書く。担い手欄は、以前の値にかかわらず無条件で今の自分の値に書き直す（/resumeではsessionIdが同じまま名前とpidだけが変わるので、sessionIdが一致していても書き直しを省かない）
3. 状態節の更新時刻以降のログ（空席中のbgの報告を含む）を読む
4. claude agents --jsonでbgの生死を見直し、報告済みで次の指示を待つbgのうち要らないものを止める

bgへ報告先の変更を伝える手順は要らない（bgは報告のたびに担い手欄を読んで宛先を引くため）。

orch同士の約束・待ちは、宛先を相手のorchアクティビティの題で書き、送る時点で相手の担い手を引く。相手が生きていれば（追う節の窓口の生死の規則）、担当確認や作業依頼はpeer-nudge skillを通して、その行の今のnameへSendMessageする。空席なら相手のアクティビティにログを書く。

終える

常設・期限付きの終わり方

• 常設: Claudeの条件（子の条件）が全部終端したら、担い手が1回だけ「このorchを終えてよいか」を聞く
  • 在席ならその場で聞き、答えで錠をsatisfiedにするか、続ける範囲を子にする
  • 不在・空席ならaskを起票し、update_goalのop editで錠の条件のboundをaskにする。問い文に答え方を書く（「終えてよければ『終えてよい』。続けるなら追加の範囲を書く」）
  • 答えが「続ける」なら、同じupdate_goalの呼び出しで、op editで錠のboundをnullに戻し、op set（state=open、noteに日付）を送る。追加の範囲を子にして束縛する
  • 束縛先askが回答済みで規則10（束縛先は済んでいる）が出たら、satisfiedにする前に回答の中身を読む。「続ける」ならsatisfiedにせず束縛を外す（orchタグのnotesにも同じ読み方がある）
  • ユーザーの「終わったってことだよね？」のような疑問の形の発話も終える確認の合図として受け取り、1ターンで「終えてよいか」を確かめる
• 期限付き: 子が全部済めば判定待ちになる。ユーザーの確認を経ずに閉じる前の始末へ進み、閉じたことを一言伝える

閉じる前の始末

1. openの子ごとに行き先を決める。別のorchに渡すなら渡す先のgoalに束縛を足してから、こちらの条件を理由付きでwaivedにする。やめるなら理由付きでwaivedにし、子を閉じる
2. 生きているbgはsync-memory --minimalを指示してから止める
3. 預かりは別のorchの預かりに移すか、アクティビティかaskにする
4. 反映待ちが残っていれば、朝の一覧の「あなたがやること」に出すか済んだことを確かめる
5. judge_goalで閉じる。ユーザーが終えてよいと明言したときは判定の主体を人間（judged_by="human"）にする。閉じたことを、在席ならその場で、不在なら朝の一覧で一言伝える

子を閉じる最後の一手（マージを確かめて人間の条件を満たし、子のgoalを判定する）は、その子を束縛するorchの担い手が持つ。マージした窓口が担い手でなければ、担い手へ知らせる。担い手が空席なら、マージした窓口がその一手だけを済ませ、orchのログに書く（代わらない）。

作業ツリーは子の持ち物とし、子を閉じるときにその子を束縛するorchの担い手が消す。auto modeに止められたらまとめてユーザーに頼む。

activity-finishでこのアクティビティを閉じようとしたら、ここ（「終える」）へ進む。

隣のorchへの検査

orch自身が設計の決定事項をadd_decisionsで記録する前に、隣のorchへ1回だけ検査を頼む。自分の文脈では見えない既決との衝突・前提の抜けを、別の文脈から指摘してもらうため。

1. 一覧節の手順で、担当範囲が近い別のorch（domainと素タグが重なるもの）を1つ選ぶ。生きているかは追う節の窓口の生死の規則で見る
2. 生きていれば、決定事項の案とその根拠を添え、「既決との衝突や前提の抜けがないか見てほしい」とpeer-nudge skill経由でSendMessageする。検査は1回だけで、返事への再検査は頼まない
3. 返事が来るまで、そのdecisionの記録は保留する。他の作業は続け、次の手番までに返らなければ、検査なしで記録し、記録の本文に「検査を頼んだが返答なし」と書く
4. 返事の指摘を判断して、案を直すか、そのまま記録する。指摘を採らないときは理由を記録に書く
5. 空席、または宛先に送れないときは、検査を省いて記録する

ユーザーとの合意で決まる決定事項や、実装上の判断には使わない。

ユーザーに上げるもの

次はユーザーに上げる。それ以外は、在席でもorchの中で相談役との協議と実データの収集で判断して進め、決めた内容と根拠を報告する。

• PRのマージ（1本ずつ名指し。マージの前にclaude botの指摘を確かめ、マイグレーションを足すPRはorigin/mainと番号を突き合わせて、重なっていれば振り直させる）
• auto modeに止められる外向きの操作
• 大きな手間や費用（取り決めたbgの本数の上限を超えることを含む）
• ユーザー設定の変更
• ブランチの削除
• 既決のreasonがユーザーの意図に基づくものの見直し

skill・docsだけのPRを自分でマージしてよいという私的な許可がある場合は、それに従う。許可が無いか止められたら、名指しでユーザーに頼む。

上の列挙に当たる判断待ちは、在席ならその場で聞いて決定事項にし、不在・夜間・空席ならaskにする。askは、待たせている人間の条件の束縛に張り（無ければ人間の条件を足して張る。子に束縛した条件には張らない）、待たせるアクティビティをblocksに入れる。orchの説明とログには、判断待ちの中身を書かない。

マージの承認はPRを名指しした形で頼む（見本:「PR AとPR Bをこの順でマージしてよい、と言ってくれれば続けてやる」）。ユーザー自身の文に両方のPR番号が入っていることを確かめる。短い返事で2本目が止められたら、そのPRを名指しして聞き直す。1本ごとにmainへの到達を確かめてから次へ進む。スタックPR（子のbaseが親のブランチ）なら、親をマージした後に子のbaseがmainに切り替わったことを確かめてから子をマージする。

askの回答をマージの承認として別セッションで使うことはしない。マージはorchの窓口で名指しの承認を得てから行う。askの回答後の実行は、そのaskが結びつくorchの担い手が持つ。結びつくorchが空席のときと、orchに結びつかないaskは、トリアージした窓口が実行まで持つ（代わらない）。実行できないなら、ログで手放さず、結びつくorchの預かりに書くか、新しいaskにする。

やってはいけないこと

• orchの担い手の窓口では、子になる作業をサブエージェントやWorkflowでも回さない。子はbgに振り、bgの中ではサブエージェントを使う（orch自身の判断のための相談役との協議は子の作業ではないので許す。許すのは相談だけで、調査・実測・実装はbgに振る）
• ユーザーに上げるものの列挙に当たらない判断を、協議と情報収集を経ずにユーザーへ投げない
• bgの中のWorkflowは、ユーザー本人がそのbgにattachして自分の言葉で頼んだときだけ使う。依頼文に"ultracode"やWorkflowの実行指示を書かない
• ユーザーが子をWorkflowで回したいと言ったときは、その場でどちらの道にするか聞く（子を起票して束縛し、条件のnoteに「orchの窓口で実行中（ユーザー指定）」と書いて自分で実行するか、bgを振ってそこへattachしてもらうか）
• EnterWorktreeは使わない
• マイグレーション番号は、報告先へ宣言してから取る（返事は待たない）
• 人間宛てのaskを、bgに起票させない
• CALM内部の運用裁定の範囲を超えて、既決を見直すことになる判断を自分だけで決めない

状態節とgoalの雛形

orchアクティビティの説明の先頭に、次の状態節を置く。上書きで保ち、書くのは記録に無いものだけである。書かないもの: 子の状況（goalにある）、PRの番号と状態（子のgoal・bgの報告・PR本体から引く）、ユーザーの判断待ち（askにする）、他のorchの担当セッション名、運用規約の写し。

## 状態
担い手: {名前}（sessionId {sessionId}）／{更新時刻}
（または 担い手: 空席／{更新時刻}）

bg表:
- {子の題} / {bgの短いid} / {作業ツリー} / {起動時刻}

約束:
- {相手のorchアクティビティの題}へ{内容}

預かり:
- {内容}（1件ずつ）

反映待ち:
- {内容}

goalは起点で常設か期限付きかを選ぶ。

• 常設: 束ねた子の条件と、担い手humanの錠「ユーザーがこのorchを終えることを了承した」を持つ
• 期限付き: 束ねた子の条件だけを持つ。子が全部済めば判定待ちになる

どちらの形も、最初に振る子を束縛してから書く（束縛条件が無いと空の条件になる）。期限付きでは、振ると分かっている子を振り出す前に全部束縛する。範囲の違う子を後から足してもよい。