meeting

用途：在做出架构、产品或技术决策前，模拟一场由多位专家角色参与的会议，从不同视角分析议题、辩论并收敛出建议方案。会议产出的是提案而非最终决定，需用户确认后才能实施。

主要能力：

1. 理解议题：解析用户问题，若引用 GitLab/GitHub issue 则读取其描述、标签、评论与关联 MR，必要时阅读相关代码，并把待决问题表述为一句清晰的决策问题。
2. 选择角色：根据主题从角色池中选 3-5 个相关角色（如后端、架构、DBA、安全、DPO、DevOps、QA、PO 等），宣布角色并请用户确认或调整。技术决策通常包含架构师，产品决策包含 PO。
3. 运行会议：用 Agent 工具并行启动各角色子代理。第一轮为开场陈述（推荐方案、理由、风险、提问）；第二轮为辩论与质询（认同、质疑、遗漏的权衡、立场更新）；第三轮由主持人按领域相关性加权综合，区分共识与未决分歧，并评估置信度（高/中/低）。低置信度时不强行给弱建议，而是列出未决点并建议后续会议。
4. 产出决策分析：以法语结构化输出，含问题、参与者及最终立场、讨论综述、推荐方案与理由、风险及缓解、未决点、备选方案对比、后续步骤。
5. 展示并确认：向用户提供选项——验证并实施、就某点开后续会议、发布到 issue、修改建议；用户未明确选择前不得实施。
6. 发布到 issue（可选）：主题关联 GitLab/GitHub issue 时，可发布面向 PO 与干系人的评论，聚焦业务价值与用户影响。发布命令：GitLab 使用 glab issue note <iid> --message "<comment>"；GitHub 使用 gh issue comment <number> --body "<comment>"。
7. 后续会议：针对未决点缩小范围，保留相关角色并最多 3-4 人，仅进行两轮，产出增量分析，说明建议是变更还是被确认。
8. 验证后实施：可选择快速实施（用 /fast-meeting 直接实现并创建 MR/PR，分支名 meeting/<short-kebab-case-topic>）或引导式逐步实施；MR/PR 描述面向开发者，聚焦代码变更与技术理由。

使用方式：当用户要求“发起会议”“模拟会议”、希望多角度分析问题、需要结构化辩论后再做决策、或引用 issue 并希望发布分析时启用。

限制与前提：依赖 gh 或 glab 发布到 issue（gh 见 https://cli.github.com ，glab 见 https://gitlab.com/gitlab-org/cli ）；角色池、视角与偏见详见 reference/personas.md。资料未提供具体角色定义全文、模型要求、定价或支持平台信息。