ディスパッチャーのコンテキストを圧迫したまま session を続けるのを避けるため、 monitoring 状態(active workers / 直近 polling cursor / pending escalations)を handover ファイルに書き出し、secretary の指示で /clear → /dispatcher-resume の 流れで新しいディスパッチャー session を開始する準備をする。 Secretary から DISPATCHER_HANDOVER peer message を受領したとき、または ディスパッチャー自身が context が長くなったと判断したときに使う。
secretary-handover
窓口のコンテキストを圧迫したまま session を続けるのを避けるため、 直近のやり取り・進行中ワーク・組織状態を handover ファイルに書き出し、 /clear → /secretary-resume で新しい窓口セッションを開始する準備をする。
「リフレッシュ」「窓口を引き継ぎたい」「コンテキスト整理」と言われたとき、 または窓口自身が context が長くなったと判断したときに使う。
含まれるファイル(1)
- SKILL.md6.4 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
secretary-handover: 窓口の引き継ぎ
窓口セッションを長期化させずに、組織員としての自覚と直近やり取りを次セッションへ
受け渡すための引き継ぎファイルを作る。書き出した後にユーザーへ /clear →
/secretary-resume の流れを案内する。
重要な前提:
- ディスパッチャー / キュレーター / ワーカーのペインは生かしたまま残す。
/clearは窓口の Claude コンテキストだけをリセットするので、state.db と handover ファイルから復帰できれば組織は途切れない。- state DB (
.state/state.db) は唯一の SoT。ペイン identity やワーク状態は そちらから引ける。handover はあくまで「会話の温度感」「人間との合意」「進行中の判断」など、 構造化データに収まらない部分を残すために使う。
Step 1: handover 対象を整理する
書き出す前に、窓口(自分)の context から以下を抽出する:
- 直近の人間との合意・判断
- 採用した方針、却下した選択肢、保留中の検討事項
- 進行中のワーク
- 派遣中のワーカー、その task_id、最新の進捗ステータス
- Pending Decisions(人間に投げて未回答)
.state/pending_decisions.jsonがあれば併読し、register と context の差分を残す
- 次のアクション(窓口視点)
- 次に自分が何をすべきか、誰の返答を待っているか
- 直近の重要なやり取り抜粋
- ユーザーが言った決定的な一言、自分が提案して合意された案など、3〜6 項目程度
Step 2: state.db から構造化情報を取得する
handover に参考情報として埋め込む。書き出し先は sandbox で write 可能な $TMPDIR
(未設定なら /tmp フォールバック)に置く:
python3 -c "
from tools.state_db import connect
from tools.state_db.queries import get_org_state_summary
import json, os
conn = connect('.state/state.db')
out_path = os.path.join(os.environ.get('TMPDIR', '/tmp'), 'secretary-handover-state.json')
with open(out_path, 'w') as f:
json.dump(get_org_state_summary(conn), f, ensure_ascii=False, indent=2, default=str)
print(out_path)
"
シェルリダイレクトで > /tmp/... を使うと、sandbox 環境では /tmp が read-only で
書き込み失敗する。Python 側で TMPDIR を解決してから open(..., 'w') する形が安全。
ここから以下を取り出す:
session.status/session.objectivesession.dispatcher_pane_id/session.dispatcher_peer_idsession.curator_pane_id/session.curator_peer_id(null が正常系。curator はオンデマンド化済みで常駐せず、org-start がStateWriter.CLEARで明示クリアする。null を「欠損」扱いしない)active_runs[](進行中タスク)active_worker_dirs[](生きているワーカーディレクトリ)- 直近の
recent_events上位 3〜5 件
Step 3: handover ファイルを書き出す
書き出し先: .state/secretary-handover.md
既存ファイルがあれば .state/secretary-handover.prev.md にバックアップしてから上書きする:
[ -f .state/secretary-handover.md ] && cp .state/secretary-handover.md .state/secretary-handover.prev.md
フォーマット(YAML frontmatter + markdown):
---
created_at: <UTC ISO8601>
session_status: <ACTIVE | IDLE | SUSPENDED>
session_objective: <一行サマリー or null>
dispatcher_pane: <pane_id> / peer=<peer_id>
curator_pane: null # 常駐廃止(オンデマンド化)。null が正常
---
# Secretary Handover
## 直近の人間との合意・判断
- ...
## 進行中のワーク
- worker-<task_id> (<worker_dir>): <最新の状態 / 待ち事項>
- ...
## Pending Decisions(人間に投げて未回答)
- ...
(無ければ「なし」と明記する。空にしない)
## 次のアクション(窓口視点)
- ...
## 直近の重要なやり取り抜粋
- user: 「...」
- 窓口: 「...」
- ...
## 参考: state.db スナップショット
(Step 2 で取得した active_runs / recent_events を簡潔に転記。
全文は `.state/state.db` に残っているので最小限でよい)
書き方の注意:
- 「過去ログ」ではなく「次の自分への申し送り」として書く。たとえば 「ユーザーは B 案で進めたい意向」「ワーカーからの retro gate ack 待ち」のような形。
- 機密情報・トークン・パスワードは絶対に書かない。
- ファイルは人間も読むことを想定する。
Step 4: イベントを記録する
py -3 tools/journal_append.py secretary_handover \
--json '{"reason": "context_compaction", "active_workers": [...]}' 2>/dev/null \
|| echo "(journal_append unavailable; skipping)"
Step 5: ユーザーへ案内する
以下のメッセージで完了報告する:
窓口の handover を `.state/secretary-handover.md` に書き出しました。
このまま /clear で context をリセットしてください。
新しい窓口セッションが始まったら /secretary-resume を実行すると、
handover を読み込んで現状把握した状態で再開できます。
ディスパッチャー・キュレーター・ワーカーペインはそのまま稼働を続けるので、
組織は中断されません。
窓口がやってはいけないこと:
/clearを自分で打とうとしない(Claude Code 側のコマンド、ユーザーが入力する)- ディスパッチャーやキュレーターに SHUTDOWN を送らない(/org-suspend ではないので、 ペインは生かしたまま残す)
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
/dispatcher-handover で書き出した handover ファイルを読み込み、 ディスパッチャーを新しい session で復帰させる。/clear 直後の最初のターンで使う。 state.db の dispatcher_pane_id / dispatcher_peer_id を atomic に更新し、 worker monitoring の /loop 3m を再開する。 「ディスパッチャー復帰」「resume」「引き継ぎから再開」と secretary から指示された ときに使う。/org-start ではない(ワーカー・窓口・キュレーターは生きている前提)。
プロジェクトのゴール台帳(registry/goals/<owner>/<repo>.md)を人間と対話して新規作成・改訂する。 README と open Issue からゴール候補を推定して提示し、「何を目指すか」「何が起きていたら未達か」を 短く質問して条項を固め、書式検証(tools/work_discovery_goals.py validate)を通してから保存する。 「ゴール台帳を書きたい」「ゴールを設定して」「ゴール未設定と出た」「台帳エラーを直して」 「このプロジェクトの目標を決めたい」等や、/work-discovery の「ゴール未設定」「ゴール台帳エラー」案内を 受けて窓口が起動する。候補の提示そのものは /work-discovery の役目で本スキルではない。
組織の生きているペイン(secretary / dispatcher / worker)へ tmux で**直接入る** ための **コマンドを出力するだけ** の read-only スキル。`mcp__org-broker__list_panes`(論理ペイン) と `/usr/bin/tmux -L claude-org-broker list-panes -a`(pane_id ↔ session マッピング)を pane_id(%N)で突き合わせ、各ペインに role + name(task_id) ラベル付きの attach コマンドを 生成する(読取専用 `-r` / 書込は `-r` 無し / デタッチは `Ctrl-b d`)。 「ワーカーのペインを見たい」「ワーカーのペインに入りたい」「dispatcher の様子を直接見たい」 「ペインに入りたい」「あのペインを直接覗きたい」「attach コマンド教えて」 「tmux でつなぎたい」「worker の画面に入る」等で発動。 自分で attach はせず・ペインも一切変更しない(コマンド文字列とペイン一覧表を表示するのみ)。 作業委譲(org-delegate)・ダッシュボードで状況一覧(org-dashboard)・watcher 停止(org-attention-stop) には発動しない。
attention notification watcher(承認待ち / 判断待ち / CI 失敗等を OS 通知 + 音で能動通知)を dispatcher ペインの右側に split で常駐起動する。`.state/attention.json` が未配置なら ja 既定テンプレートを `tools/templates/attention.example.json` から自動コピーする。 起動後のペイン id は `.state/attention_pane.json` に記録し、`/org-attention-stop` から参照する。 「attention 起動」「通知監視を始めて」「watcher を立てて」等で発動。 `/org-start` からの auto-start はしない(明示起動推奨ポリシー)。
`/org-attention-start` で起動した attention watcher ペインを停止する。 `.state/attention_pane.json` に記録された pane_id を `list_panes` の name/role で identity 確認し、いまも attention watcher を指している場合だけ `close_pane`(pane 破棄)で 破棄する(pane_id が別ペインへ再割当て済みなら close せず stale sidecar として削除)。 「attention 止めて」「通知監視を停止」「watcher 落として」等で発動。