assemble-panel について
assemble-panelは、計画ファイルやgit diffに基づいてレビュー担当者を選び、レビュー反復のポリシーを定めるエージェントスキルです。エージェントの起動やファイル編集は行わず、呼び出し元に構造化された担当者リストとポリシーを返します。
主な機能
- 01ファイル種別とキーワードで担当者を選択
- 02担当者の追加・除外指定を適用
- 03指摘の基準とラウンド上限を設定
- 04空または読み込み不能な範囲に対応
- 05構造化された担当者リストとポリシーを返却
活用シーン
- 01計画やdiffのレビュー担当者を選定
- 02複数の呼び出し元でレビュー基準を統一
- 03レビュー範囲の分割要否を判断
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/assemble-panelを入力して読み込まれたか確認します。
詳細
パネルの編成
レビュアーの選定とループのガバナンスを一元管理します。パネルとポリシーを呼び出し元に返し、呼び出し元がディスパッチします。このスキルはデータを生成するものであり、エージェントのディスパッチやファイルの変更は行いません。
統合契約
呼び出し元が指定するもの：
scope：計画ファイルのパス、または git diff（レビュー対象の成果物）overrides（任意）：{ include: [], exclude: [] }
返されるもの（呼び出し元が解析する構造化テキスト）：
panel：レビュアーエージェント名の順序付きリストpolicy：ゲート、上限、および以下の代数
利用できない場合のフォールバック：[technical-editor, code-reviewer]、gate=P2、cap=3。
ツール間の注意事項： Codex/Cursor は Skill ツール経由でスキルを呼び出せません。このファイルを直接読み込み、ポリシー代数をその場で適用してください。
ポリシー代数（凍結済み — 変更禁止、バージョン：1）
DEFAULTS:
gate = P2 # fix P0-P2, record P3+
cap = 3 # max rounds before escalate
always = [technical-editor] # expandable, never reducible
ASSEMBLE(scope: plan_file | diff):
panel = always
+ select_by_scope(file_types(scope))
+ select_by_keywords(body(scope))
+ overrides.include
- overrides.exclude # cannot remove `always` members
RETAIN(reviewer, round_findings):
keep(reviewer) while round_findings.any_above(gate)
EXPAND(panel, prior_scope, current_scope):
new_coverage = file_types(current_scope) - file_types(prior_scope)
panel += select_by_scope(new_coverage) when new_coverage
CONVERGE(round, panel, cap):
APPROVE when all(reviewer.done for reviewer in panel)
ESCALATE when round >= cap
EXIT when any(reviewer.verdict == DROP)
continue otherwise
ESCALATE_RECURRING(finding, rounds_present):
finding.severity += 1 when rounds_present >= 2
スコープからレビュアーへの対応表
select_by_scope(file_types) で使用します：
| ファイルパターン | レビュアー |
|---|---|
.ts、.js、src/、tests/ | code-reviewer |
.yml、.github/workflows/ | code-reviewer、security-auditor |
.sh、scripts/、hooks/ | code-reviewer、security-auditor |
.md（計画、ADR、ドキュメント） | architect-reviewer |
*.css、*.tsx、UI コンポーネント | design-reviewer、accessibility-tester |
sync.sh、AGENTS.md、config.toml、スキル | codex-specialist |
*.pem、*.key、シークレットのパターン | security-auditor |
複数のパターンに該当する場合は、すべてのレビュアーを統合します。重複は取り除きます。
キーワードからレビュアーへの対応表
select_by_keywords(body) で使用します：
| キーワード／フレーズ | レビュアー |
|---|---|
| "architecture"、"ADR"、"system design"、"plan" | architect-reviewer |
| "security"、"auth"、"token"、"PAT"、"OIDC" | security-auditor |
| "WCAG"、"accessibility"、"a11y"、"aria" | accessibility-tester |
| "UI"、"component"、"layout"、"design system" | design-reviewer |
| "docs"、"research"、"ecosystem"、"reference"、"educational" | fact-checker |
| "Codex"、"cross-tool"、"sync.sh" | codex-specialist |
キーワードは大文字と小文字を区別せず、スコープ本文に対する部分文字列一致で判定します。
オーバーライドルール
overrides.includeはレビュアーを無条件に追加します。overrides.excludeはalwaysに含まれるレビュアーを除き、レビュアーを削除します。alwaysのメンバーを除外しようとしても、通知なしで無視されます。- 無効なレビュアー名は、有効な名前の一覧を示すエラーとともに拒否されます。
障害モード
- スコープが空、または読み取れない場合：
alwaysパネルのみを返し、呼び出し元に警告します。 - ファイルタイプが検出されない場合：キーワードマッチングのみを使用します。どちらにも一致しない場合は、
alwaysパネルを返します。 - 呼び出し元が上限に 5 を超える値を指定した場合：5 に制限します。これは交渉不可の上限です。
- パネルのメンバーが 5 人を超える場合：呼び出し元に警告します。変更範囲が広すぎる可能性があります。
- ディスパッチ時にレビュアーが利用できない場合：呼び出し元はそのレビュアーをスキップし、その不足を記録します。
オーケストレーターの権限
パネルは推奨を行いますが、オーケストレーター（パネルにエージェントを割り当てるエージェント）が決定します。上記のゲートと上限は、その決定への入力であり、決定を覆すものではありません。
してもよいこと：
- 対応によって範囲が単一の懸念事項を超えて膨らむ場合、P1/P2 の指摘を対象外とする — フォローアップのイシューを登録します。
- パネルの指摘によって範囲が妥当な単一のリリースを超えて広がる場合、段階的な PR に分割する。まずコアをリリースし、強化とドキュメントは後続にします。**ディスパッチ前：**実装担当者に引き渡す前に、計画の範囲を確認してください — 変更対象ファイル数が 5 を超える、または予定されているテストの合計数が 8 を超える場合は、あらかじめ順次実施するフェーズに分割します。上記の事後的なトリガーはパネルからのフィードバック後に発動しますが、こちらは実装開始前に発動し、単一エージェントのコンテキストがあふれるのを防ぎます（例：PR #241：新規スクリプト 3 件 + アグリゲーターの変更 + ADR + テスト 11 件 → ツール使用 78 回 → あふれ）。
- 明確な根拠を示して誤検知に異議を唱える。同じ指摘が複数のレビュアーまたはラウンドで再発する場合は、その理由を検討してください — レビュアーの指摘が正しいのか、あるいはコードが指摘対象のパターンに見える構造上の理由があるのかを確認します。異議を唱える際は、指摘（レビュアー + 重大度 + 引用文）を明示し、根拠を示して、証拠（コードパス、既存のパターン、過去の ADR）を引用してください。
- 根拠を記録したうえで逸脱を受け入れる — 一部の P1 には対応し、ほかは計画の「リスク」セクションで理由を示して延期します。
してはならないこと：
- P0 の指摘を黙って取り下げること。P0 には対応するか、エスカレーションするか、計画を却下する必要があります。
security-auditorの指摘を、人間にエスカレーションせずに覆すこと。
人間にエスカレーションする場合：
- P0 に異議が唱えられ、異議を唱える根拠が明確でない場合。
- オーケストレーターが同意しない懸念に、複数のレビュアーの意見が一致した場合。
- セキュリティ上の指摘に対する緩和策のトレードオフが、信頼モデルに影響する場合。
異議を唱える例：
Security-auditor P1：「HMAC ペイロードに重大度を含めること。」 オーケストレーター：異議を唱えます。重大度は、CLI ラッパーが出力するものではなく、別の分類器（classify-findings.sh）によって計算されるため、署名時には利用できません。HMAC に含めるには、レビューのパイプライン全体を再構成する必要があります。代替案：フィンガープリントに
tierを含める — これにより、HMAC を再構成せずにティア間の衝突の可能性をなくせます。P0-2 にはフィンガープリントへの tier 追加で対応し、必要であれば重大度の HMAC への組み込みは別の ADR として延期します。
出力形式
PANEL: technical-editor, code-reviewer, security-auditor
GATE: P2
CAP: 3
ALWAYS: technical-editor
NOTE: codex-specialist included — scope touches sync.sh
一見して明らかでない選択の判断ごとに、NOTE 行を 1 行出力します。呼び出し元はこれらをレビューの要約に表示します。