pr-auto-fix プラグインの監視ループを起動するトリガースキル。Hook で PR 作成が検知された後、Claude が `pr-auto-fix:auto-fix-pr` として呼び出すと Monitor (`pr-auto-fix-watcher`) がバックグラウンドで起動する。Monitor からの通知を受けて pr-auto-fixer エージェントへディスパッチする責務を持つ。ユーザーが手動で起動するスキルではなく、Hook 経由でのみ呼ばれる前提。
multi-agent-orchestration
Agent tool で複数のサブエージェントを並列起動する/エージェントチームを組成する前に、編成パターン(サブエージェント vs エージェントチーム、レビュアー Teammate の要否、各役割のモデル選択)を決定するためのガイドを適用する。
トリガー:3 つ以上の Agent を並列起動する/タスク間に依存関係がある/チームメイト同士の相互通信が必要/設計や計画フェーズで複数視点が欲しい/ある成果物を別の成果物がレビュー・参照する構造になる。単発のサブエージェント呼び出しや、依存のない fire-and-forget な並列調査では発火しない。
含まれるファイル(1)
- SKILL.md6.1 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
マルチエージェント編成パターン
Agent tool で非自明な並列・チーム作業を委譲する前に、以下の 3 つの判断を済ませる。
1. サブエージェント vs エージェントチームの判定
| 状況 | 採用 |
|---|---|
| 各タスクが独立、結果は親が統合するだけ | サブエージェント並列(Agent を fire-and-forget で複数起動) |
| タスク間に依存(A の出力が B の入力になる) | エージェントチーム(TeamCreate → team_name 付き spawn) |
| チームメイト同士で相談・通知が発生する | エージェントチーム |
| 計画/設計フェーズで複数視点を組み合わせたい | エージェントチーム |
サブエージェントの限界: 親 → 子の一方向通信のみ。並列起動はできるが互いに会話できないため、依存があると「古い情報で並列実行 → 後で書き直し」になる。
エージェントチームの利点: SendMessage でチームメイト間の双方向通信が可能。TeammateIdle フックでアイドル時の振る舞いも制御できる。Plan Approval ワークフローで段階的承認も取れる。
2. レビュアー Teammate の組み込み
エージェントチームを組成する場合は、原則としてレビュアー Teammate を 1 人入れる。理由:
- オーケストレーター(Team Lead)が「設計者かつ判定者」になるのを避ける
- 3 冊跨ぎ・複数ファイル跨ぎの整合性は、独立した目で見たほうが取りこぼしが少ない
- メンタリングで自分自身が教えてきた「ガードレール 3 層」「Devil's Advocate」の実践
レビュアーの設計
1 人のレビュアー Teammate に 2 フェーズ で実行させる:
- 整合性チェック: 既存方針(DESIGN.md / CLAUDE.md / その他規約)との齟齬、章番号・誘導リンク・命名の矛盾
- Devil's Advocate: 「本当にその追加が必要か」「読者像/スコープから外れていないか」「既存で代替できないか」を逆張りで問う
レビュアーを 2 人に分けると視点がブレるので、1 人 2 フェーズが推奨。
レビュアーを省略してよい場合
- 出力が小規模(1 ファイルの単純編集など)
- 不可逆的な影響がない(ドラフトレベル)
- ユーザーが明示的に「レビュー不要」と言っている
3. 役割別モデル選択
| 役割 | モデル | 根拠 |
|---|---|---|
| 計画・設計・章立て・判断 | Opus | トレードオフ評価、整合性判断、抽象化が必要 |
| 実装・調査・整理 | Sonnet | 速度重視、決められた手順の実行 |
| 単純な変換・抽出・コピペ | Haiku | コスト最適化 |
| レビュアー Teammate | Opus(原則) | 視点を持って判定するため |
model パラメータは明示する。省略すると agent definition の frontmatter or 親から継承で意図と異なるモデルになる可能性がある。
実行フロー(典型例)
依存ありのチーム作業の場合:
TeamCreateでチームを作る(名前は作業内容を表す、例:book-update-team)- 第 1 段の Teammate を Opus で spawn(
team_name+name付き) - 第 1 段完了 → 結果を見て第 2 段の Teammate に
SendMessageで前提を伝える - 第 2 段の Teammate を並列 spawn(依存がない範囲で)
- 全成果物が出揃ったらレビュアー Teammate を spawn(2 フェーズで実行)
- レビュー結果を踏まえて元 Teammate に修正依頼を
SendMessage - 最終成果物を Team Lead が統合・書き込み
アンチパターン
- 依存があるのにサブエージェント並列で済ませる: 後段が古い情報で動く
- レビュアーなしでオーケストレーターが自己レビュー: 設計者バイアスで甘くなる
- モデル省略で全部 Sonnet になる: 計画フェーズの判定が浅くなる
- チームメイトに
nameを付けない:SendMessageで再開できず、毎回Agent新規起動になる - 作業中にチームを跨いで指示を出す:
team_nameを省略すると現在のチーム context に入る — 意図しないチームに紛れ込ませない
エフォートレベル別の適用範囲
現在のエフォートレベル: !echo ${CLAUDE_EFFORT:-high}
low: 編成パターンの判定のみ(レビュアーの追加は省略)medium: 標準的な編成判定+レビュアーの組み込みhigh/xhigh/max: 全ステップを完全実行(Devil's Advocate フェーズ含む)
注意事項
- このスキルは「編成パターンの決定」だけを担う。実装の詳細(具体的な SendMessage の中身や Agent への prompt)は呼び出し側のロジックに任せる
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1が有効な環境を前提とする。無効な環境ではエージェントチーム機能は使えないため、サブエージェント並列にフォールバックする- 判定に迷ったらユーザーに確認する。特に「レビュアーを入れるか省略するか」はコスト感が出るので相談したほうが良い場面がある
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
Claude Codeマーケットプレイス用のプラグインを作成する。新規プラグイン作成、コマンド・エージェント・フック・MCPサーバーの追加時に使用。
ユーザー本人の声で日本語のプローズを起草・推敲・レビューする際に文体ガイドを適用する。対象は Qiita/Zenn 技術記事、note 記事、Slack メッセージ下書き、ユーザーが書く PR/コードレビューコメント、その他ユーザー名義で外部に出る日本語の長文。基本トーン・句読点ルール・用語表記・禁止表現(em ダッシュ「——」、「刺さる/効く」、「リポ」略称など)・シチュエーション別温度感を読み込んだ上で文章を組み立てる。コード・ログ・コミットメッセージの定型文、および他者が書いた文章のレビュー(他人の PR コメントの校正など)には適用しない。