用途
assemble-panel 用于集中管理评审者的选择与循环治理。当另一个技能或智能体需要组建、保留或收敛一个评审小组时调用它，通常由 /review、/plan-review 和 code-reviewer 触发，而不是直接使用。它向调用方返回一个评审小组（panel）加策略（policy），由调用方负责派发。该技能只产出数据——它从不派发智能体，也不修改文件。
集成契约
调用方需提供：
- scope：一个计划文件路径，或一个 git diff（即被评审的产物）
- overrides（可选）：{ include: [], exclude: [] }
返回内容（供调用方解析的结构化文本）：
- panel：有序的评审者智能体名称列表
- policy：gate、cap 以及下述策略代数
不可用时的回退： [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, skills | codex-specialist |
| *.pem, *.key, secrets 模式 | 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 小组。
- 调用方请求 cap > 5：钳制为 5。这是不可协商的上限。
- 小组超过 5 名成员：警告调用方——这很可能意味着变更范围过宽。
- 派发时评审者不可用：调用方跳过该评审者并记录此缺口。
编排者权限
小组只提供建议；编排者（派发小组的智能体）做决定。上述 gate 和 cap 是该决定的输入，而非对其的覆盖。
可以（MAY）：
- 若处理某个 P1/P2 发现会使范围膨胀到超出单一关注点，可将其降级范围——另开一个后续 issue。
- 当小组发现使范围超出合理的单次落地时，拆分为分阶段的 PR。核心先发布；加固与文档随后。派发前：在交给实现者之前，检查计划的范围——若 Files-to-Modify > 5 或计划测试总数 > 8，预先拆分为顺序阶段。上述反应式触发在小组反馈之后触发；此触发在实现开始前触发，防止单智能体上下文溢出（例如 PR #241：3 个新脚本 + 聚合器变更 + ADR + 11 个测试 → 78 次工具使用 → 溢出）。
- 以明确理由反驳误报。若同一发现在评审者或轮次间反复出现，检查原因——要么评审者是对的，要么代码看起来像他们所标记的模式有结构性原因。反驳时，指明该发现（评审者 + 严重级别 + 引用文本），给出理由，并引用证据（代码路径、现有模式、先前的 ADR）。
- 接受并记录偏差——处理部分 P1，在计划的 Risks 部分为其余部分提供理由后推迟。
不得（MUST NOT）：
- 静默丢弃 P0 发现。P0 必须被处理、升级，或计划被拒绝。
- 不向人类升级就覆盖 security-auditor 的发现。
升级到人类的情形：
- 某个 P0 存在争议，且反驳理由不清晰。
- 多个评审者就某个关注点达成一致，而编排者不同意。
- 某个安全发现的缓解权衡影响信任模型。
反驳示例：
Security-auditor P1："Include severity inside HMAC payload." Orchestrator：Pushing back. Severity is computed by a separate classifier (classify-findings.sh), not emitted by the CLI wrapper, so it's not available at sign-time. Binding it into HMAC would require restructuring the entire review pipeline. Alternative: include tier in fingerprint — this closes the cross-tier collision vector without HMAC restructure. Will address P0-2 with tier-in-fingerprint; defer severity-in-HMAC as a separate ADR if needed.
输出格式
PANEL: technical-editor, code-reviewer, security-auditor
GATE: P2
CAP: 3
ALWAYS: technical-editor
NOTE: codex-specialist included — scope touches sync.sh
每个非显而易见的选取决定对应一行 NOTE。调用方在评审摘要中呈现这些内容。