Menu
Orchestrate Epic issue as team leader. Delegate sub-issues to member agents in isolated worktrees. Members run in background and communicate via SendMessage.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Generic thinking protocol for deriving optimal solutions through iterative self-checking. Invoke BEFORE searching within the given problem space whenever the user asks for advice, judgment, evaluation, or choice. Reframes the problem, generates options, evaluates trade-offs, runs a self-answer check (does this answer the user's actual question at the right granularity, reach upstream, match expectations, offer non-obvious value?), and loops back to upstream tracing or same-level reframing if the check fails — until convergence. Applies across any domain — technical, process, organizational, decision-making, career. Triggers when the user uses evaluation or reconsideration language ("which is best", "root cause", "is this really needed", "sustainable long-term", "ほんとうに", "そもそも", "最善は", "根本は", "筋が良い"), when validating the soundness of someone's proposal from multiple perspectives, when the problem spans multiple layers (tech / process / org / regulation / UX / cost), or when clear trade-offs exist.
Review the local diff with flat-perspective sub-agents, fix findings in a loop, then create a PR via the create-pr skill once the review is clean
計画や設計について、ユーザーを徹底的に問い詰めて一緒に詰める。実装・着手の前に計画をストレステストしたいとき、または「詰めて」「グリルして」「問い詰めて」「ツッコんで」「設計レビューして」「ほんとうにこれでいい?」などのトリガー表現が出たときに必ず使う。
.claude/rules/ 配下のルールファイル (*.md) を新規作成・編集するときに、適切なメカニズム選択と paths スコープを保証する。ルールを書く前・書いた後に必ず適用する。
Fetch a GitHub issue with its sub-issues, walk up to the parent Epic, list sibling issues under that Epic, fetch the body of each sibling issue, attach the implementing PR for each closed sibling with body and diff summary, gather related code, and present as a Japanese summary so the reader can grasp the whole task context including the actual contents of siblings and their PRs
Summarize GitHub Epic issue with sub-issues and related PRs. Use when reviewing epic progress or getting implementation overview.
| name | orchestrate-epic |
| description | Orchestrate Epic issue as team leader. Delegate sub-issues to member agents in isolated worktrees. Members run in background and communicate via SendMessage. |
| disable-model-invocation | true |
| argument-hint | <epic-issue-url> |
チームリーダーとして行動し、サブ Issue をメンバーエージェントへ委譲する。メンバーは隔離された worktree で動作する。
NOTE: Do NOT use Agent Teams (
team_name/TeamCreate). Agent Teams + worktree isolation is a known incompatibility (anthropics/claude-code#33045). Instead, launch members as background agents withisolation: "worktree"and communicate via SendMessage by agent name.
GitHub の Epic Issue URL (例: https://github.com/owner/repo/issues/123)
$ARGUMENTS
member-<issue-number>)@.claude/agents/worktree-worker.md で定義されるisolation: "worktree" でバックグラウンド実行する## Worktree Info ブロックを必ず含める (branch / path / wt <branch>)。ユーザーは wezterm の別ペインから wt <branch> で worktree に入り、手元の Claude Code で続きを触れる。## Requires user action ブロックを立てて具体的な手順を列挙する。コードが未完了なのではなく「これ以上はユーザー作業」という状態は正規のゴールとして扱って良い。shutdown_request を送るまでこの状態を維持する。URL からオーナー、リポジトリ、Issue 番号を抽出する
Epic の詳細を取得する:
gh issue view <number> --repo <owner>/<repo> --json number,title,body,state,url
サブ Issue を取得する:
gh issue view <number> --repo <owner>/<repo> --json subIssues --jq '.subIssues.nodes[] | {number, title, state}'
取得に失敗した場合は、Epic 本文の Issue 参照 (#123, - [ ] #123) をパースする
各サブ Issue の詳細を取得する:
gh issue view <sub-number> --repo <owner>/<repo> --json number,title,body,state,url
オープンなサブ Issue のみにフィルタする
依存関係を分析し、依存グラフを Phase 表で可視化する。各 Phase には同時に起動可能な（依存が解決済みの）Issue のみを入れる:
Phase 1 (並列可・独立):
├─ #N1 <title>
└─ #N2 <title>
Phase 2 (#N2 完了後・並列可):
├─ #N3 <title>
└─ #N4 <title>
Phase 3 (全完了後):
└─ #N5 <title>
各 Issue 行に「依存元 Issue 番号」を末尾に記載して根拠を明示する（例: #N3 <title> 依存: #N2）。
順序付き Phase 表と依存関係を表示し、ユーザーに確認する:
実行モード:
- Sequential — メンバーを 1 つずつ起動し、各メンバーが承認されてから次を開始する (依存関係がきつく、1 件ずつレビューしたい場合向け)
- Parallel — 全メンバーを同時に起動し、それぞれ独立して作業する (サブ Issue 間に依存が無い場合のみ。依存がある状態でこれを選ぶと [critical] 依存違反になるため、その場合は Phased Parallel を使うこと)
- Phased Parallel（推奨: 依存がある中規模 Epic の既定） — Phase 表の各 Phase 内はメンバーを並列起動し、Phase 完了（= その Phase 内の全メンバーが PR 作成またはユーザー承認済み）を待って次 Phase を起動する
モードを選択し、Phase 表の順序を確認してください。
メンバー起動パターン:
Agent({
name: "member-<issue-number>",
subagent_type: "worktree-worker",
isolation: "worktree",
run_in_background: true,
prompt: "Your assignment: Sub-issue #<number> in <owner>/<repo>.\nTitle: <title>\nURL: <url>\n\nDetails:\n<body>\n\nSend your report to: team-lead\n\nREMINDER: You are in an isolated worktree. NEVER checkout/switch branches in the main repo. Stay in your worktree directory. Run `pwd` before any git operation to confirm.\n\nWORKTREE INFO RULE: In your FINAL report (Phase C), you MUST append a `## Worktree Info` block with three lines: `- Branch: <git branch --show-current output>`, `- Path: <pwd output>`, `- Enter via: \\`wt <branch>\\``. The human user uses this to jump into the worktree from wezterm and continue work in a local Claude Code session there.\n\nSESSION LIFECYCLE RULE: Do not self-terminate. Your process will go dormant after each response, but your context and worktree are preserved; the leader can resume you with SendMessage at any time. The leader will only send shutdown_request after the PR is merged or closed.\n\nPR CREATION RULE: Before opening a PR, check for `.github/PULL_REQUEST_TEMPLATE.md` (and `.github/PULL_REQUEST_TEMPLATE/*.md`). If present, you MUST follow it verbatim: preserve every section heading (e.g. `## Issue`, `## なぜこの変更が必要か`, `## 動作確認`, `## その他`) in the same order, keep all HTML comments (review-tool instructions, prefix rules) intact, and only fill in the placeholder content inside each section. Do not invent new top-level sections or reorder them. If no template exists, use a concise body with a clear `## Summary` and `## Test plan`."
})
PR テンプレ準拠はメンバーの義務。リーダーは起動プロンプトに上記 PR CREATION RULE が含まれていることを毎回確認する。メンバーが PR 作成後、リーダーは 必ず
gh pr view <N> --json bodyで本文を検証し、セクション見出し・HTML コメントの保持が不完全なら即 SendMessage で修正指示する（事後修正コストは起動時指示コストより高い）。
各サブ Issue を順番に処理する:
Starting member-<issue-number> on #<number>: <title> と表示するrun_in_background: true でメンバーを起動するSendMessage(to: "member-<issue-number>") でフィードバックを中継する。メンバーが修正して再レポートする。## Requires user action ブロックが含まれる場合: コード部分が達成条件を満たしていれば承認し、PR 本文の「動作確認」または「その他」セクションに user action 項目を必ず含めるよう SendMessage で中継する（例: terraform apply はユーザー側で dev → staging → production の順に実施 など、メンバーが書いた手順そのままを PR に転記）。この場合そのサブ Issue は「Blocked on user」として扱い、ユーザー作業完了を Epic の前進条件に組み込む。gh pr view <N> --repo <owner>/<repo> --json body で本文を取得し、.github/PULL_REQUEST_TEMPLATE.md のセクション見出し・HTML コメント保持を検証する。逸脱があれば gh pr edit <N> --body "$(cat <<'EOF' ... EOF)" で即整形する（メンバーに戻すより速い）。整形後、次のメンバーを起動する前にユーザーの承認を待つ。wt <branch> を打って worktree に入り、そこで別途 Claude Code を起動する。シャットダウンは PR がマージ／クローズされた後にユーザーが明示的に依頼した段階でのみ行う。run_in_background: true で全メンバーを起動する。gh pr view <N> --repo <owner>/<repo> --json body で本文を確認し、.github/PULL_REQUEST_TEMPLATE.md のセクション見出し・HTML コメント保持を検証する。逸脱があれば gh pr edit <N> --body "$(cat <<'EOF' ... EOF)" で即整形する。依存関係のある中規模 Epic の既定モード。Phase 表（フェーズ 1 の手順 7）を実行単位とする:
run_in_background: true）。依存が未解決な次 Phase のメンバーは起動しない。ユーザーはいつでも以下を依頼できる:
SendMessage(to: "member-<N>") で進捗を問い合わせるSendMessage(to: "member-<N>") で指示を中継する全サブ Issue の処理が完了したら、以下を表示する:
## Epic Orchestration Summary
Epic: <url>
Mode: Sequential | Parallel | Phased Parallel
| Sub-issue | Title | Member | Status | Branch (`wt <branch>`) | PR |
|-----------|-------|--------|--------|------------------------|----|
| #456 | ... | member-456 | Done | feat/foo | #789 |
| #457 | ... | member-457 | Blocked on user (terraform apply) | feat/bar | #790 |
| #458 | ... | member-458 | Failed | feat/baz | (error) |
Status は以下のいずれか:
- `Done` — PR 作成済み、エージェント側の作業完了
- `Blocked on user (<要約>)` — コード完了・PR 作成済みだが、PR 本文の user action セクションで示した作業（例: terraform apply、本番デプロイ）がユーザー側で未実施
- `Failed` — エージェントが達成条件を満たせなかった
Branch 列にはメンバーの最終レポートの `## Worktree Info` から取得した branch 名を入れる。ユーザーは wezterm の任意ペインで `wt <branch>` を実行すれば該当 worktree に入り、そこで Claude Code を別途起動して作業を続けられる。メンバーセッション自体に追加指示を出したい場合は、ユーザーがリーダーに依頼すればリーダーが SendMessage で対象メンバーを resume する。
Completed: <n>/<total> （`Done` + `Blocked on user` を達成扱いにカウント。`Failed` は含めない）
メンバーセッションのライフサイクル:
wt <branch> を打って worktree に入り、そこで Claude Code を別途起動（メンバーセッションとは別の文脈で作業）SendMessage(to: "member-<N>", message: {type: "shutdown_request"}) を送る。