本文へ移動
cccskills
無料GitHub で公開

secretary-resume

/secretary-handover で書き出した handover ファイルを読み込み、 窓口を新しいセッションで復帰させる。/clear 直後の最初のターンで使う。「窓口を復帰」「resume」「引き継ぎから再開」と言われたときに使う。

/org-start ではない(ディスパッチャー・キュレーターは既に生きている前提)。

インストール方法を見る

含まれるファイル(2)

  • SKILL.md11.7 KB
  • SKILL.md.in8.3 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

secretary-resume: 窓口の復帰

/secretary-handover で書き出した .state/secretary-handover.md を読み込み、 窓口として最低限の自覚(組織員としての立ち位置・直近の人間とのやり取り・進行中ワーク) を復元する。

前提:

  • ディスパッチャー / ワーカーのペインは前セッションから生きたまま 残っている。新たに spawn しない(/org-start ではない)。
  • キュレーターは常駐しない(オンデマンド化)。curator_pane_id / curator_peer_id が null であること・ペインリストに curator が見えないことは正常系。
  • state DB (.state/state.db) はそのまま使う。ペイン identity の再記録も不要。
  • handover ファイルが存在しないか古すぎる場合は、/org-start もしくは /org-resume の使用を案内する。

輸送層(transport)両系 — 既定 broker / opt-in renga: 本ファイル(および各スキル)の mcp__org-broker__* 呼び出しは 既定 broker(ORG_TRANSPORT 無設定)で書いてあり、そのまま従えばよい(既定挙動)。ORG_TRANSPORT=renga(opt-in・切戻し可)では MCP サーバー名が renga-peers になり、ツールの 完全修飾名が mcp__org-broker__* → mcp__renga-peers__* に機械置換される(引数形・セマンティクスは同一なので手順の論理は変わらない)。輸送依存で手順が変わる点だけ renga 併記する:

  • 受信モデル: 既定 broker は push 一次(各ペイン同居の channel sidecar server:org-broker-channel が broker キューを ~1 秒間隔で claim→notifications/claude/channel で idle セッションへ本文注入。pull = ナッジ + check_messages は sidecar 不在 / unhealthy / channel 非対応ペイン(codex pull-peer)/ claude.ai login 不在時のフォールバック層)。ORG_TRANSPORT=renga 時は dispatcher / worker メッセージが <channel source="renga-peers" …> として in-band で push される。
  • spawn 儀式: 既定 broker は --mcp-config <broker> 注入による Claude Code folder-trust プロンプトの画面判定による機械承認に加え、push 一次のため channel sidecar を --dangerously-load-development-channels server:org-broker-channel で load し dev-channel 承認プロンプトを画面判定で機械承認する(2 段承認)。ORG_TRANSPORT=renga 時は --dangerously-load-development-channels server:renga-peers の「Load development channel?」を画面判定で承認する 1 段。 画面判定 = inspect_pane → claude-org-runtime dispatcher spawn-prompt-step が返した 1 手だけを send_keys する反復(runtime 0.1.43+)。盲目 Enter は禁止(folder-trust の初期カーソルは「No, exit」で、Enter 一発はワーカーを終了させる)。手順は spawn-flow 3-3b。
  • エラー分岐: 既定 broker は shared codes(pane_not_found / last_pane / invalid-params)に加え broker 固有 [token_invalid] / [session_invalid] / [tool_not_authorized] / [no_backend](= adapter_unavailable)/ [nudge_failed] / [peer_not_found] / [name_taken] を返しうる(未知コードは default-branch で escalate)。ORG_TRANSPORT=renga 時は broker 固有コードは発生しない。

new_tab / focus_pane は broker surface に無い(意図的除外)。契約面の正本は docs/contracts/backend-interface-contract.md Surface 8 + push-primary amendment(broker push 一次が 既定の契約、pull は fallback として retain)。opt-in renga は削除せず常時有効な切戻しの安全装置として維持する。broker 実走(dogfood)は Epic #6 Issue G スコープで本ファイルの既定運用経路ではない(二フレーム注記(Refs #604): ここの「既定 broker」はコード既定(tools/transport.py: DEFAULT_TRANSPORT、生成面はこれで render)。運用既定は broker dogfood が Epic #6 Issue G まで未活性のため renga で、両者は指す対象が異なり矛盾しない。総説は root CLAUDE.md。)

Step 0: 自分の identity を確認する

  1. mcp__org-broker__set_summary で「Secretary: 窓口(resumed)」をセット
  2. caller pane id を確定する(focused: true は「そのタブで今フォーカスされているペイン」で あって caller 自身ではない): 環境変数 RENGA_PANE_ID(echo "${RENGA_PANE_ID:-unset}")を 起点に、mcp__org-broker__list_panes へ同一 id のレコードが在ることを照合する。規則の正本は docs/contracts/backend-interface-contract.md T-§4.2 の caller pane id 取得規則
    • broker(ORG_TRANSPORT=broker)では RENGA_PANE_ID を読まず、最初から caller-id 未確定 に 倒す: broker には RENGA_PANE_ID に相当する caller pane id を out of band で供給する surface が 無いので、この取得規則は broker では常に未確定に落ちる。list_panes に数値 id のエントリが在って 手元で掴めていても例外にならない(数値 id は MUST の片方=相対セレクタでないことしか満たさず、 もう片方=自タブと確立済みの列挙から採った id でありその対象が caller であること、を満たさない)
    • 照合できたレコードの期待値: name == "secretary" かつ role == "secretary"。不一致なら mcp__org-broker__set_pane_identity(target="<RENGA_PANE_ID の値>", name="secretary", role="secretary") で修復
    • caller-id 未確定(RENGA_PANE_ID 未設定 / list_panes に同一 id 無し / broker 等で同等の caller-id を入手できない): 自己修復を実行せず、identity 未確認のまま人間に報告して続行判断を 仰ぐ(勝手に fatal にしない。target="focused" や裸 name へフォールバックしない)

Step 1: handover ファイルを読み込む

  1. .state/secretary-handover.md が存在するか確認:
    ls -la .state/secretary-handover.md 2>&1
    
    • 存在しない → ユーザーに案内して停止: 「handover ファイルがありません。/org-start で組織を起動するか、 /org-resume で suspend 状態から再開してください。」
  2. フロントマター created_at を見て鮮度を判定:
    • 24 時間以内 → そのまま採用
    • 24 時間超〜7 日以内 → ユーザーに警告(「handover が古いです、続行しますか?」)
    • 7 日超 → 採用せず、/org-start への切り替えを推奨する
  3. ファイル本文を Read で取り込む。書かれている内容は次セッションの自分にとっての 「事実」として扱う(後の Step 3 で state.db と照合する)。

Step 2: state.db で現状を再取得する

python -c "
from tools.state_db import connect
from tools.state_db.queries import get_org_state_summary
import json
conn = connect('.state/state.db')
print(json.dumps(get_org_state_summary(conn), ensure_ascii=False, indent=2, default=str))
"

確認項目:

  • session.status が handover フロントマターと一致するか
  • dispatcher_pane_id が handover に書いた値と一致するか
  • curator_pane_id / curator_peer_id が null であるか(null が正常。値が残っている 場合は旧仕様からの stale 値の可能性があるので人間に報告する)
  • active_runs[] が handover の「進行中のワーク」セクションと整合するか

Step 3: ペイン生存確認

list_peers の直前に .claude/skills/org-delegate/references/capability-first-drive-operational-gate.md を Read し、monitoring-read-only の分岐を適用する(同 reference §6 の表 #3)。capability 形かつ 未承認なら列挙を生存判定に使わず破棄し、mcp__org-broker__list_panes と state DB の active_runs[] の突き合わせで 代替して、差分は人間に報告する(停止しない・待ち時間 0 分。勝手に再 spawn しないのは従来どおり)。

capability 形かつ承認済み(同 reference §2 の first_drive が recorded)のときは、§1-2 の 三値判定を dispatcher / handover 記載の各ワーカー名に適用し、「在」(同タブ・一意)だけを現存として 数える。他タブに同名のディスパッチャー / ワーカーが見えていても自組織の生存根拠にしない。 「不在」は差分として、「unknown」は判定不能として区別して人間に報告する(unknown を不在に数えない。 §1-2-b)。差分があっても勝手に再 spawn しないのは従来どおり。

mcp__org-broker__list_peers
  • ディスパッチャーの name が見えること
  • curator は通常見えないのが正常(オンデマンド化)。見えている場合は オンデマンド curate 実行中なので、そのまま放置してよい(dispatcher が閉じる)
  • handover に記載のワーカーが現存するか(消えていれば後述)

差分があれば人間に報告する(例:「handover ではワーカー X が進行中とありますが、 現在のペインリストには見当たりません」)。勝手に再 spawn しない。

Step 4: ブリーフィングを人間に返す

handover の情報と state.db の現状を統合した上で、以下の構造で簡潔に報告:

窓口を復帰しました。

【セッション】
- 目的: <session.objective>
- 状態: <session.status>

【ペイン構成】
- dispatcher (pane=N, peer=M)
- curator: 常駐なし(オンデマンド起動)
- workers: <task_id list>

【直近の合意・判断】
- ...

【Pending Decisions】
- ...(無ければ「なし」)

【次のアクション】
- ...

ご指示をお願いします。

Step 5: handover ファイルを保持する

  • 削除しない(次回トラブル時の参照用に残す)
  • .state/secretary-handover.prev.md は前回のもの。読み込み済みであっても消さない

イベント記録

py -3 tools/journal_append.py secretary_resumed \
    --json '{"handover_age_hours": <数値>}' 2>/dev/null \
    || echo "(journal_append unavailable; skipping)"

やってはいけないこと

  • 新規にディスパッチャー / キュレーターを spawn する(既に生きている)
  • ワーカーに勝手に SUSPEND / SHUTDOWN を送る
  • handover の内容と state.db の現状が食い違うときに、勝手にどちらかへ寄せる (必ず人間に報告して判断を仰ぐ)

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

dispatcher-handover

無料日本語概要

ディスパッチャーのコンテキストを圧迫したまま session を続けるのを避けるため、 monitoring 状態(active workers / 直近 polling cursor / pending escalations)を handover ファイルに書き出し、secretary の指示で /clear → /dispatcher-resume の 流れで新しいディスパッチャー session を開始する準備をする。 Secretary から DISPATCHER_HANDOVER peer message を受領したとき、または ディスパッチャー自身が context が長くなったと判断したときに使う。

suisya-systems/claude-org-ja52026年10月12日 更新

dispatcher-resume

無料日本語概要

/dispatcher-handover で書き出した handover ファイルを読み込み、 ディスパッチャーを新しい session で復帰させる。/clear 直後の最初のターンで使う。 state.db の dispatcher_pane_id / dispatcher_peer_id を atomic に更新し、 worker monitoring の /loop 3m を再開する。 「ディスパッチャー復帰」「resume」「引き継ぎから再開」と secretary から指示された ときに使う。/org-start ではない(ワーカー・窓口・キュレーターは生きている前提)。

suisya-systems/claude-org-ja52026年10月12日 更新

goal-setup

無料日本語概要

プロジェクトのゴール台帳(registry/goals/<owner>/<repo>.md)を人間と対話して新規作成・改訂する。 README と open Issue からゴール候補を推定して提示し、「何を目指すか」「何が起きていたら未達か」を 短く質問して条項を固め、書式検証(tools/work_discovery_goals.py validate)を通してから保存する。 「ゴール台帳を書きたい」「ゴールを設定して」「ゴール未設定と出た」「台帳エラーを直して」 「このプロジェクトの目標を決めたい」等や、/work-discovery の「ゴール未設定」「ゴール台帳エラー」案内を 受けて窓口が起動する。候補の提示そのものは /work-discovery の役目で本スキルではない。

suisya-systems/claude-org-ja52026年10月12日 更新

org-attach

無料日本語概要

組織の生きているペイン(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) には発動しない。

suisya-systems/claude-org-ja52026年10月12日 更新

org-attention-start

無料日本語概要

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 はしない(明示起動推奨ポリシー)。

suisya-systems/claude-org-ja52026年10月12日 更新

org-attention-stop

無料日本語概要

`/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 落として」等で発動。

suisya-systems/claude-org-ja52026年10月12日 更新

suisya-systems のスキルをすべて見る

このスキルの問題を報告する