用途：在发布高风险内容前，用多个评审视角分析同一份草稿，并汇总为统一结论。
主要能力：读取草稿及其 .status.yaml，获取 piece_type、audience、stage、goals；据此提出 4-6 名评审员并说明理由，同时列出不纳入的评审员及原因；用户确认后并行运行评审子代理；最后运行 panel-synthesizer，输出共识发现、建设性张力、独特见解、建议优先级与一个“难题”。
可用评审员及子代理类型：asshole（compound-writing:review:asshole-reviewer，逻辑严谨与无支撑论断）、mom（可读性、术语、普通读者）、hemingway（精简、词句层面）、sedaris（具体性、幽默、声音）、sorkin（节奏、推进力）、vonnegut（故事基础与结构）、hitchcock（张力、悬念、利害）。
使用方式：调用 /panel；代理读取草稿与状态文件后给出评审团提案，等待确认或调整；确认后并行 spawn 评审代理，收集完整输出，再以草稿、上下文和全部评审输出运行 synthesizer，最后展示综合结果。若评审员启动失败，记录缺失者并用可用输出继续，在综合中说明缺口；若无 .status.yaml，则从草稿推断并说明上下文有限；若无草稿，询问路径、slug 或直接粘贴。
规模建议：最少 3 名，推荐 4-5 名，最多 7 名。
适用场景：高利害发布前、希望免手动运行多评审、怀疑不同方面需不同关注、自己太接近作品而不知需要什么反馈。
限制：张力由 synthesizer 指出但不解决，需作者自行裁决；辩论模式（评审员多轮回应）标注为未来设想，当前未提供；具体安装命令、收费与平台信息暂未提供。