关于 assemble-panel
assemble-panel 是根据计划文件或 git diff 选择审查者并设定审查循环策略的 Agent 技能。它向调用方返回结构化的审查名单和策略，不会启动 Agent 或修改文件。
主要功能
- 01按文件类型和关键词选择审查者
- 02应用审查者包含与排除覆盖项
- 03设置问题门槛和轮次上限
- 04处理为空或无法读取的范围
- 05返回结构化名单与策略
适用场景
- 01为计划或 diff 选择审查者
- 02在不同调用方间统一审查门槛
- 03判断审查范围是否需要拆分
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/assemble-panel确认已加载。
详细介绍
组装评审面板
集中管理评审者选择和循环治理。向调用方返回评审面板和策略；由调用方负责分派。此技能仅生成数据，不会分派 Agent 或修改文件。
集成契约
调用方提供：
scope：计划文件路径或 git diff（待评审的产物）overrides（可选）：{ include: [], exclude: [] }
返回（供调用方解析的结构化文本）：
panel：有序的评审 Agent 名称列表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 名成员：提醒调用方——这可能表明改动范围过大。
- 分派时评审者不可用：调用方跳过该评审者并注明此缺口。
编排器权限
评审面板负责提出建议；编排器（负责调度评审面板的 Agent）负责决策。上述门槛和上限是决策的输入，而不是对决策的覆盖。
可以：
- 如果处理某个 P1/P2 发现会使范围膨胀到超出单一关注点，可以缩小范围；为此创建后续 issue。
- 当评审面板的发现使范围超出合理的单次合并范围时，可以拆分为分阶段的 PR。先交付核心内容；随后再完善加固和文档。**调度前：**将工作交给实现者之前，检查计划范围——如果待修改文件数 > 5，或计划测试总数 > 8，应预先拆分为连续阶段。上述响应式触发条件在收到评审面板反馈后生效；此条件在开始实现前生效，可避免单个 Agent 的上下文溢出（例如，PR #241：新增 3 个脚本 + 聚合器变更 + ADR + 11 个测试 → 使用 78 次工具 → 溢出）。
- 可以用明确的理由驳回误报。如果同一发现反复出现在不同评审者或轮次中，应查明原因——要么评审者是对的，要么代码存在某种结构性原因，让它看起来符合对方指出的模式。驳回时，需注明该发现（评审者 + 严重程度 + 引述原文），给出理由并引用证据（代码路径、现有模式、先前的 ADR）。
- 可以接受并记录偏离——处理部分 P1，其他问题则在计划的 Risks 部分说明理由后延期处理。
不得：
- 悄然搁置 P0 发现。必须处理 P0、升级处理或否决计划。
- 未经人工升级处理就推翻
security-auditor的发现。
以下情况应升级给人工处理：
- 对 P0 存在异议，且驳回理由不明确。
- 多位评审者对某项关注点达成一致，但编排器持不同意见。
- 安全发现的缓解方案权衡会影响信任模型。
驳回示例：
Security-auditor P1：“将严重程度纳入 HMAC 载荷。” 编排器：驳回。严重程度由单独的分类器（classify-findings.sh）计算，而非由 CLI 包装器生成，因此签名时无法获取。将其绑定到 HMAC 需要重构整个评审流水线。替代方案：将
tier纳入指纹——无需重构 HMAC 即可消除跨层级碰撞攻击路径。将通过在指纹中加入 tier 来处理 P0-2；如有需要，将严重程度纳入 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。调用方会在评审摘要中展示这些内容。