Claude Code の並列エージェント(agent teams・teammate)の後始末と無応答時の打ち切りルール。`name` を付けて Agent を起動するとき、TeamCreate でチームを組むとき、teammate から `idle_notification` が届いたとき、評価ループ等で次のイテレーションのエージェントを起動する前、エージェントの返信が届かないときに参照する。`name` を付けない通常のサブエージェント起動だけなら対象外。
project-session
指定したプロジェクト(ghq 管理下の部分一致キー、または直接パス)のディレクトリでブランチを変えずに claude を detached セッション(herdr 管理下なら workspace か専用 session、それ以外は tmux)として起動する。`/project-session` の明示実行専用。
含まれるファイル(4)
- SKILL.md10.1 KB
- references/behavior.md6.7 KB
- scripts/launch.sh34.6 KB
- scripts/tests/launch.test.sh16.4 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
project-session
指定されたプロジェクトのディレクトリで(ブランチを変えず・worktree も作らず)claude を detached セッションとして起動する。呼び出し=起動意図とみなし、追加の承認ゲートは挟まない。 ただし対象プロジェクトが未指定なら一覧から選ばせる。これは承認ゲートではなく起動対象を 確定させる必須手順で、省くことはできない(後述のフロー exit 4)。
マルチプレクサ backend は実行環境から自動判定する(AI が選ばない。判定は launch.sh の責務):
| backend | 条件 | 起動先 |
|---|---|---|
herdr | HERDR_ENV=1(herdr 管理下の pane から実行) | プロジェクト用の新しい workspace を作成し、その root pane で claude を起動 |
tmux | それ以外 | detached な tmux セッション |
PROJECT_SESSION_BACKEND に herdr / tmux を設定すれば明示的に上書きもできる(通常は不要)。
herdr backend で何を作るか(topology)は起動引数の --session フラグで切り替える:
| topology | 指定方法 | 作るもの | 使いどころ |
|---|---|---|---|
workspace(既定) | フラグ無し | 起動元 pane と同じ session に workspace を足す | 通常。別プロジェクトを開くだけ |
session | --session | プロジェクト専用の herdr session を detached で立て、その中に workspace を作る | 起動した claude を親に、そのプロジェクトの作業を 1 セッション内で完結させたいとき |
環境変数 PROJECT_SESSION_TOPOLOGY でも指定できるが(フラグが優先)、remote-control 越しでは
環境変数を前置できないため通常はフラグを使う。
session を選ぶ理由は隔離ではなく到達性にある。herdr のソケットは session ごとに分かれるため、
起動した claude が他の pane を監視・操縦するには、その claude と対象が同じ session に居る必要がある。
プロジェクト専用 session の中で立てれば、その claude を親とする一連の作業がその session 内で閉じる。
起動引数
/project-session [--session] [プロジェクト名(部分一致可)] [claudeへ渡す引数...]
--session(任意・先頭に置く): プロジェクト専用の herdr session を立てて起動する (topology=session)。省略時は現在の session に workspace を足す。- 次の 1 トークン: プロジェクト指定(省略可)。既定は ghq list への部分一致キーだが、
/...~..../...../...の形なら ghq 解決を飛ばしてそのディレクトリを直接使う (ghq 管理外のリポジトリ用)。裸の名前は常に ghq キー扱いで、 カレント配下に同名ディレクトリがあっても掴まない。 - 残り全部: claude への passthrough 引数(
--model opus/-p '...'/--remote-control等、素通し)。
省略の判定は AI が行わない。ARGUMENTS をそのまま launch.sh launch に渡し、launch.sh が
「--session を除いた先頭トークンが無い、または - 始まり」を省略と判定して exit 4 で一覧を返す。
ARGUMENTS: --remote-control nput のように passthrough 引数だけが渡されたケースは省略であり
(--remote-control は claude のフラグ、nput はその値)、nput をプロジェクト名として拾わない。
例:
/project-session --session <プロジェクト名> --remote-control
そのプロジェクト専用の herdr session を立て、中の claude を --remote-control <セッション名> 付きで起動する
(値なしの --remote-control にはセッション名が自動で入る)。
/project-session ~/<ディレクトリ名> --remote-control
ghq 管理外のディレクトリを直接指定して起動する(セッション名は basename から作る)。
/project-session --remote-control nput # プロジェクト未指定(exit 4 → 一覧提示)
/project-session nput --remote-control # nput を起動(正しい書き順)
決定論ツール(scripts/launch.sh)
ghq 照合・セッション名決定・backend 判定・セッション起動は bash <SKILL>/scripts/launch.sh に委譲する
(<SKILL> はプラグイン実行時 ${CLAUDE_PLUGIN_ROOT}/project-session、個人 skill 配置時は
この SKILL.md があるディレクトリ)。3 サブコマンドと exit code 契約:
-
launch.sh list—ghq listをそのまま 1 行 1 件で出力(「一覧を見せて」と明示されたとき用。 引数省略時の一覧はlaunch自身が exit 4 で返すので、省略判定のために先に叩かない)。 -
launch.sh resolve [query]— 部分一致解決の結果で分岐:- 省略(無し /
-始まり): stdout に全一覧、stderr にno query、exit 4 - 一意: stdout に relpath 1 行、exit 0
- 複数: stdout に候補一覧、stderr に
ambiguous、exit 2 - 0 件: stdout に全一覧、stderr に
not found、exit 3 - パス指定(
/...~..../...../...)は ghq を引かず、存在すれば絶対パス 1 行で exit 0、 存在しなければ stderr にエラーで exit 3
- 省略(無し /
-
launch.sh launch [--session] [query] [claude引数...]— 本体。--sessionは<query>より前に 置いたときだけ topology フラグとして解釈し、それ以降は claude への passthrough として素通しする。<query>省略(フラグを除いた先頭が無い /-始まり)は stdout に全一覧・stderr にno queryで exit 4(passthrough に--remote-control <値>があり、その値が ghq に一意一致するなら stderr に書き順のヒントも 1 行出る)。ツール欠落は exit 1、解決が一意でなければresolveと同じ出力・exit code(2/3)で中断する。成功時は起動して次を stdout へ出力する:SESSION: <セッション名> BACKEND: herdr | tmux TOPOLOGY: workspace | session (herdr backend のときだけ出る) PROJECT: <ghq relpath | 絶対パス> PATH: <起動ディレクトリの絶対パス> BRANCH: <現在ブランチ | (detached)> DIRTY: clean | N files CLAUDE_ARGS: (無し | 実際に渡した引数列) ATTACH: tmux attach -t <名前> | herdr(workspace ラベル: <名前>)に切り替える | herdr session attach <名前>
フロー
- ARGUMENTS をそのまま
launch.sh launch [--session] [query] [claude引数...]に渡す。 省略か指定かを読解しない。ユーザーが--sessionを付けていたらそのまま<query>の前へ引き渡す (claude 引数側へ回さない)。ARGUMENTS が空でもlaunch.sh launchを引数無しで実行する。 - exit code で分岐する:
- exit 0: 起動成功。出力の SESSION/BACKEND/PROJECT/PATH/BRANCH/DIRTY/ATTACH を整形して報告する。
DIRTY: N filesでも止めない(未コミット変更は情報提供のみ)。 - exit 4(プロジェクト未指定): stdout の全一覧を番号付きで提示して選択させる。
AskUserQuestion は選択肢 4 個上限なので、候補が多いときは本文に番号付きで列挙し自由記述で受ける。
stderr に
hint:行があればそのまま添える(書き順の取り違えの可能性をユーザーに知らせる)。 選ばれた relpath(または basename)を query にし、元の--sessionと passthrough 引数を そのまま保ってlaunchを再実行する。ghq 管理外のディレクトリを開きたいと言われたら、一覧から選ばせず そのパスをそのまま query にする。 - exit 2(曖昧): stdout の候補一覧を提示して選択させ、選んだ relpath で
launchを再実行する。 - exit 3(0 件): stdout の全一覧を提示して選び直させる。ユーザーが挙げた名前が ghq 管理外の
ディレクトリを指していそうなら、一覧から選ばせる前にパス指定(
~/<名前>等)を提案する。 - exit 1: backend に必要なコマンド(
herdrまたはtmux/ghq/claude)の欠落など。 stderr のメッセージをそのまま伝える。
- exit 0: 起動成功。出力の SESSION/BACKEND/PROJECT/PATH/BRANCH/DIRTY/ATTACH を整形して報告する。
- query の出所はユーザーのトークンか、一覧からのユーザーの選択だけ。exit 4 / 2 / 3 で候補を
提示する局面では、次を query にして
launchし直すことを禁止する:- カレントディレクトリ(「今いるのが dotfiles だから dotfiles」)
- 会話の文脈(「直前に skills の話をしていたから skills」)
--remote-controlなど passthrough 引数の値(--remote-control nputのnput) 「確認を挟まず起動」は対象が確定しているときだけ許され、未確定なら一覧提示は省けない。
- 起動後は
ATTACH:行を添えて結果を報告する。TOPOLOGY: sessionのときは、合流がherdr session attach <名前>である点と、使い終わったら後始末が要る点も併せて伝える (手順はreferences/behavior.md)。
参照
references/behavior.md: セッション名の決定規則・backend 別の起動手順など、launch.shの挙動解説 (フローの実行には不要。ユーザーから挙動を問われたときだけ読む)。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
spec.md の REQ-# を入力に、機能一覧・モジュール構成・インターフェース・データフローを持つ docs/dev/<対象>/basic-design.md を作成・改訂するスキル。/basic-design <対象名> で明示的に呼び出されたときのみ使用する。
技術的な内容を、技術用語を排したビジネス職向けの平易な説明文に翻訳する。`/biz-translate` と明示的に呼ばれたときのみ実行する。
`git commit` / `git commit --amend` を実行する前、または「commit」「amend」「コミット」「コミットして」の一語・短文だけを渡された時点で必ず発火する git コミット実施ルール。理由や差分の説明が一切無くても、ファイル全文を読んでメッセージを組み立てる前に先に参照する。主目的は論理的に独立した修正を都度・適切な粒度でコミットすること。メッセージは Conventional Commits 形式、素材は同梱の決定論スクリプト commit-context.sh が出す staged diff のみ。「コミット分けて」と依頼される、独立した複数修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase / squash / cherry-pick 後のメッセージを整える、`gh pr create` の PR タイトルをコミット流儀へ揃える場面でも参照する。plan モードでのコミット計画の立案は commit-plan スキルの領分。
実装計画・リファクタリング計画・レビュー対応計画・並列作業のタスク分解など、計画を成果物として書き出すときに必ず参照するコミット計画ルール。plan モードでは ExitPlanMode で plan を提示する前に必須、計画ドキュメントや job-graph のタスク分解・エージェントへの指示文でも同様に適用する。計画成果物にコミット計画セクション(論理的に独立した修正単位での分割と Conventional Commits 形式のメッセージ)が無ければ実装に入らない。「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画を立てて」「コミット計画を立てて」「タスクを分解して」と依頼される、複数の独立した修正をまとめるか分けるか計画段階で判断する等の場面では、ユーザーが「コミット」に一切言及していなくても必ず発火する。コミットの実施(素材収集・メッセージ確定・git commit 実行)は commit-flow スキルが担う。
プロジェクトに 1 つの「完成の定義」docs/dev/definition-of-done.md を対話で構築・改訂し、機械判定節と人判定節の二部構成で書き出すスキル。/def-done で明示的に呼び出されたときのみ使用する。