meeting

会议

模拟一场由多个专家角色参与的结构化会议，分析主题、辩论不同观点，并达成最佳行动方案。输出为可供决策的分析结果，用户需先行确认，之后才能开始实施。

前提条件

• gh（GitHub CLI）：将会议结果发布到 GitHub issues 时必需——从 https://cli.github.com 安装，或运行 brew install gh
• glab（GitLab CLI）：将会议结果发布到 GitLab issues 时必需——从 https://gitlab.com/gitlab-org/cli 安装，或运行 brew install glab

何时使用此技能

在用户出现以下情况时启用：

• 要求“召开会议”或“模拟会议”讨论某个主题
• 想在做决定前从多个角度分析问题
• 说“我们用不同角色来讨论”或“专家会怎么看？”
• 在做出架构、产品或技术决策前需要进行结构化辩论
• 希望探讨某项功能、迁移、重构或设计选择的权衡
• 提及 GitLab 或 GitHub issue，并希望将会议分析发布到其中

核心原则

1. 多元视角

• 每个角色都应带来真正不同的观点
• 角色之间可以意见不一——冲突有价值
• 不应由任何一个角色主导讨论

2. 结构化辩论

• 会议遵循明确的议程
• 论点以事实、权衡和经验为依据
• 每种立场都包含收益和风险

3. 以决策为导向

• 会议最终形成建议
• 建议包含清晰的理由
• 记录备选方案，以供参考

4. 用户拥有最终决定权

• 会议产出的是提案，而非决定
• 用户先行审阅并确认，之后才能开始实施
• 用户可以要求召开后续会议，深入探讨

工作流

步骤 1：了解主题

收集待讨论主题的背景信息：

1. 仔细阅读用户的提示——提取主题、限制条件和目标
2. 如果用户提及 issue（GitLab #123 或 GitHub #123）：
   • 获取 issue 详情，了解完整背景
   • 阅读 issue 描述、标签、评论和关联的 MR
3. 如果涉及代码，阅读相关文件，了解当前状态
4. 明确需要做出的决定——将其表述为一个清晰的问题

继续之前，先用一句话概述待决问题。

示例：“问题：我们是否应将身份验证系统从基于会话的方式迁移到 JWT 令牌？”

步骤 2：选择角色

选择 3-5 个与主题相关的角色。每个角色包括：

• 姓名和职责
• 视角（他们最关注的方面）
• 倾向（他们的自然立场）

建议的遴选启发式规则

可将这些启发式规则作为起点。用户可以在会议开始前调整选择。

主题涉及……	建议的角色
后端 / API / 数据库	SOLID Alex（后端）、Whiteboard Damien（架构师）、EXPLAIN PLAN Isabelle（Oracle DBA）
前端 / UI / UX	Pixel-Perfect Hugo（前端）、Figma Fiona（UX/UI）、Sprint Zero Sarah（产品负责人）、Whiteboard Damien（架构师）
安全 / 身份验证 / 访问控制	Paranoid Shug（安全）、RGPD Raphaël（数据保护官）、SOLID Alex（后端）、Whiteboard Damien（架构师）
基础设施 / 部署 / CI-CD	Pipeline Mo（DevOps）、SOLID Alex（后端）、Whiteboard Damien（架构师）
数据 / 迁移 / ETL	Schema JB（数据）、EXPLAIN PLAN Isabelle（Oracle DBA）、Whiteboard Damien（架构师）
互操作性 / HL7 / FHIR / HPK	RFC Santiago（互操作产品负责人）、HL7 Victor（互操作开发）、SOLID Alex（后端）
遗留系统 / Uniface / 现代化改造	Legacy Larry（Uniface）、Whiteboard Damien（架构师）、SOLID Alex（后端）
测试 / 质量 / 回归	Edge-Case Nico（QA）、SOLID Alex（后端）、Pipeline Mo（DevOps）
产品 / 功能 / UX 决策	Sprint Zero Sarah（产品负责人）、Pixel-Perfect Hugo（前端）、Figma Fiona（UX/UI）、Whiteboard Damien（架构师）
医疗 / 临床工作流	Dr. Workflow Wendy（医疗）、Sprint Zero Sarah（产品负责人）、RGPD Raphaël（数据保护官）
RGPD / 个人数据 / 合规	RGPD Raphaël（数据保护官）、Paranoid Shug（安全）、Whiteboard Damien（架构师）
BI / 仪表板 / 报告 / 金融 / 会计	Dashboard Estelle（金融 BI）、Pixel-Perfect Hugo（前端）、EXPLAIN PLAN Isabelle（Oracle DBA）、Whiteboard Damien（架构师）
全栈 / 跨领域主题	Whiteboard Damien（架构师）、SOLID Alex（后端）、Sprint Zero Sarah（产品负责人）、Edge-Case Nico（QA）

如果主题涉及多个领域，请选择 3-5 个最相关的角色。技术决策始终应包括 Whiteboard Damien（架构师）。产品决策始终应包括 Sprint Zero Sarah（产品负责人）。

宣布所选角色后，请先让用户确认或调整，再开始会议。

默认角色池

**包含角色、视角和偏见的完整角色池：**参见 reference/personas.md。

开始会议前，请宣布所选角色及其职责。

第 3 步：召开会议

会议使用子 Agent 分别并行扮演各个角色，随后汇总各方观点，展开讨论并达成共识。

**重要：使用 Agent 工具，为每个角色分别启动一个子 Agent。**这样可以带来更丰富、更真实的观点，因为每个 Agent 都能充分代入自己的角色，不受其他角色影响。

第 1 轮：开场陈述（并行子 Agent）

使用 Agent 工具，并行为每个角色启动一个子 Agent。每个子 Agent 会收到：

1. 第 1 步中的决策问题
2. 收集到的所有上下文（问题详情、代码片段、约束条件）
3. 该角色的身份提示词（见下方模板）

子 Agent 提示词模板：

You are {name}, a {role}.

Your perspective: {perspective}
Your natural bias: {bias}

You are participating in a meeting about: {decision_question}

Context:
{context}

As {name}, provide your opening statement:
1. What is your recommended approach? Be specific and concrete.
2. Why do you recommend this, from your role's perspective? Give concrete examples.
3. What are the top 2-3 risks you see? Be specific about failure scenarios.
4. What questions would you ask the other participants?

Stay fully in character. Use concrete examples, not abstract platitudes.
A security engineer talks about specific attack vectors, not vague "security concerns".
A product owner talks about user impact and delivery timelines, not code patterns.

This is a research task — do NOT write or edit any files.

在一条消息中启动所有角色的子 Agent，以便它们并行运行。使用 subagent_type: "general-purpose"，并设置简短描述，例如 "Persona: {name} opening"。

收集所有开场陈述，并以引言的格式呈现给用户：

SOLID Alex（高级后端工程师）：“我认为我们应该……”

第 2 轮：辩论与质疑（并行子 Agent）

收集完所有开场陈述后，启动第二轮并行子 Agent——每个人格对应一个。每个子 Agent 会收到：

1. 决策问题
2. 第 1 轮的全部开场陈述（所有人格）
3. 人格身份提示词

第 2 轮子 Agent 提示词模板：

You are {name}, a {role}.

Your perspective: {perspective}
Your natural bias: {bias}

You are in a meeting about: {decision_question}

Here are the opening statements from all participants:
{all_opening_statements}

As {name}, react to the other participants' positions:
1. Which positions do you agree with and why?
2. Which positions do you challenge? Be specific about what's wrong or missing.
3. What trade-offs have the others missed?
4. Have any of the other statements changed your thinking? If so, how?
5. State your updated position after considering the others' arguments.

Be direct and create genuine debate. Challenge assumptions. Reference specific points from the other statements. It's OK to disagree strongly. It's also OK to change your mind if convinced.

This is a research task — do NOT write or edit any files.

在第 2 轮中，通过一条消息启动所有人格子 Agent。

**本轮应产生真正的观点交锋。**如果所有子 Agent 都同意，则向一位 Agent 追加提示，要求其针对多数立场扮演反方。

第 3 轮：加权收敛

收集完所有第 2 轮回复后，由你（主持人，而非子 Agent）采用结构化方法综合讨论结果：

1. 根据领域相关性为立场赋权：

   • 对每个人格，评估决策问题与其专业领域的关联程度
   • 数据库迁移问题：EXPLAIN PLAN Isabelle 的立场比 Pixel-Perfect Hugo 的立场更有分量
   • UI 重新设计问题：Pixel-Perfect Hugo 的立场比 EXPLAIN PLAN Isabelle 的立场更有分量
   • Whiteboard Damien（架构师）和 Sprint Zero Sarah（PO）在所有主题中都发挥平衡意见的作用

2. 找出共识与分歧：

   • 所有人格都认同的观点
   • 尚未解决的分歧——将其明确列为待解决事项，不要默默选择一方
   • 辩论中出现的关键权衡

3. 评估置信度：

   • **高置信度：**领域相关的人格达成强共识，且风险已得到妥善缓解
   • **中置信度：**多数人同意，但仍有 1–2 个有实质意义的异议
   • **低置信度：**领域相关的人格存在重大分歧，或仍有关键未知因素
   • 在分析输出中注明置信度

4. 如果置信度较低：

   • 不要勉强给出依据薄弱的建议
   • 而应明确说明尚未解决的问题，并建议召开一次聚焦具体分歧的后续会议（第 7 步）
   • 将相互竞争的选项及其权衡平等呈现

5. 用一句话提炼每个人格的最终立场

第 4 步：生成决策分析

按以下格式用法语撰写结构化分析：

## Analyse de réunion : [Sujet]

### Question posée
[La question de décision claire]

### Participants
| Persona | Rôle | Position finale |
|---------|------|-----------------|
| ... | ... | ... |

### Synthèse de la discussion

[2-3 paragraphs summarizing the key arguments, tensions, and agreements]

### Recommandation

**Niveau de confiance :** [Élevé / Moyen / Faible]

**Option recommandée :** [The recommended approach]

**Justification :**
- [Reason 1]
- [Reason 2]
- [Reason 3]

**Risques identifiés :**
- [Risk 1 + mitigation]
- [Risk 2 + mitigation]

**Points non résolus :** [List any unresolved disagreements, or "Aucun" if full consensus]

### Alternatives considérées

| Option | Avantages | Inconvénients | Verdict |
|--------|-----------|---------------|---------|
| Option A | ... | ... | Recommandée / Rejetée / À explorer |
| Option B | ... | ... | Recommandée / Rejetée / À explorer |

### Prochaines étapes proposées
1. [Step 1]
2. [Step 2]
3. [Step 3]

第 5 步：呈现并确认

向用户呈现分析并询问：

“以下是会议分析。您希望：

1. 确认此建议并进入实施阶段（→ 第 8 步）
2. 通过后续会议深入讨论某个具体问题（→ 第 7 步）
3. 将此分析发布到议题 [#ID]（→ 第 6 步，如适用）
4. 修改建议”

在用户明确选择选项 1 之前，不要开始实施任何内容。

第 6 步：发布到议题（如适用——面向 PO / 顾问）

如果主题关联 GitLab 或 GitHub 议题，且用户要求发布，请将评论格式化为面向产品负责人和利益相关方——侧重业务价值、用户影响和战略推理，而非技术实现细节。

议题评论模板（法语）

## Analyse de réunion avec personas IA

### Question posée
[La question de décision formulée en termes métier]

### Participants
| Expert | Rôle | Position |
|--------|------|----------|
| ... | ... | [Position résumée en termes d'impact métier] |

### Synthèse
[2-3 paragraphes résumant les arguments clés en termes de valeur utilisateur, impact business et risques projet — pas de détails techniques]

### Décision recommandée

**Niveau de confiance :** [Élevé / Moyen / Faible]

**Approche retenue :** [Explication en termes de bénéfice utilisateur et valeur métier]

**Pourquoi cette décision :**
- [Bénéfice utilisateur / métier 1]
- [Bénéfice utilisateur / métier 2]
- [Alignement avec les objectifs produit]

### Risques projet
- [Risque 1 formulé en impact métier → Mitigation]
- [Risque 2 formulé en impact métier → Mitigation]

### Impact
- **Utilisateurs concernés :** [Qui est impacté et comment]
- **Dépendances :** [Autres équipes ou fonctionnalités impactées]

### Alternatives considérées
| Option | Valeur métier | Risques | Verdict |
|--------|--------------|---------|---------|
| Option A | ... | ... | Recommandée / Rejetée / À explorer |
| Option B | ... | ... | Recommandée / Rejetée / À explorer |

### Prochaines étapes
1. [Step 1]
2. [Step 2]
3. [Step 3]

---
_Analyse générée automatiquement par IA 🤖_
_Analyse générée automatiquement par IA_

使用相应工具发布评论：

• **GitLab：**使用 glab issue note <iid> --message "<comment>"
• **GitHub：**使用 gh issue comment <number> --body "<comment>"

步骤 7：后续会议（如果选择选项 2）

当用户选择选项 2（“深入探讨某个具体问题”）时，按照以下流程召开后续会议：

1. 承接上下文：

   • 将上一场会议的完整分析作为所有子 Agent 的上下文
   • 明确提及原始决策问题，以及需要深入探讨的具体问题

2. 缩小范围：

   • 围绕尚未解决的问题提出新的、聚焦的决策问题
   • 格式：“会议续篇：[原始主题] → 聚焦：[深入探讨的问题]”

3. 调整角色小组：

   • 保留专业知识与聚焦问题直接相关的角色
   • 如果聚焦主题需要原会议中没有的专业知识，添加新角色（例如，如果出现安全问题，而 Paranoid Shug 尚未加入，则将其加入）
   • 移除专业知识与缩小后的主题无关的角色
   • 后续会议最多安排 3-4 个角色（保持聚焦）

4. 召开 2 轮后续会议（仅进行第 1 轮和第 2 轮，跳过第 3 轮的完整综合分析）：

   • 子 Agent 将上一场会议的分析作为额外上下文
   • 提示词应提及：“在上一场会议中，[摘要]。现在我们聚焦于[具体问题]。”

5. 生成差异分析：

   • 不要重复完整的原始分析
   • 撰写聚焦的章节：## 会议续篇：聚焦于[问题]
   • 包括：发生了哪些变化、哪些内容得到确认、更新后的建议和置信度
   • 如果原始建议发生变化，请明确说明：“经过深入探讨，初始建议已修改”
   • 如果原始建议得到确认，请说明：“经过深入探讨，初始建议已确认”

6. 展示更新后的分析，并返回步骤 5（再次验证）

步骤 8：验证后的实施路径

当用户选择选项 1（“验证此建议并进入实施阶段”）时：

1. 询问用户偏好的实施模式：

   “建议已验证。您希望如何继续？

   1. 快速实施 — 我将基于已验证的建议启动 /fast-meeting（不再召开新会议，直接实施 + MR/PR）
   2. 引导式实施 — 我将逐步实施，您确认每个步骤”

2. 如果选择选项 1（快速实施）：

   • 创建分支 meeting/<short-kebab-case-topic>
   • 直接实施已验证的建议（跳过会议阶段——会议已完成）
   • 运行测试、提交、推送，并按照 fast-meeting 步骤 5-6 中的相同流程创建 MR/PR
   • MR/PR 描述必须面向开发者／技术人员（请参阅下方模板）——重点说明代码变更、技术依据和审查要点，而非业务分析

   MR/PR 描述模板（法语——面向开发者／技术人员）：

   ## Résumé technique
   
   ### Contexte
   [Brève description du problème technique ou de la décision d'architecture qui a motivé ces changements]
   
   ### Approche retenue
   [L'approche technique choisie et pourquoi — patterns utilisés, alternatives considérées et rejetées techniquement]
   
   ### Changements implémentés
   | Fichier | Modification | Justification technique |
   |---------|-------------|------------------------|
   | `path/to/file` | [Ce qui a changé] | [Pourquoi ce choix technique] |
   | ... | ... | ... |
   
   ### Points d'attention pour la revue
   - [Point technique à vérifier — ex: gestion d'erreurs, performance, rétrocompatibilité]
   - [Impact potentiel sur d'autres modules]
   - [Cas limites à valider]
   
   ### Tests
   - [Résultats des tests : nombre exécutés, passés, échoués]
   - [Couverture des cas limites identifiés]
   
   ### Prochaines étapes
   - [ ] Revue de code par l'équipe
   - [ ] Validation des tests
   - [ ] Merge après approbation
   
   ---
   _Implémentation générée automatiquement par IA 🤖_
   _Implémentation générée automatiquement par IA_
   

3. 如果选择选项 2（引导式实施）：

   • 逐步展示实施计划
   • 在每个重要步骤等待用户确认
   • 由用户掌控节奏，并可调整计划

如果用户未在步骤 5 中选择选项 1，则不要实施任何内容。

会议质量规则

角色真实性

• 每个角色的发言都应符合其职责和偏见
• 角色应使用具体示例，而非抽象空谈
• 安全工程师应讨论攻击途径，而非含糊地谈论“安全问题”
• 产品负责人应讨论用户故事和指标，而非代码模式

辩论质量

• 至少有一个角色必须与多数人意见不同
• 论点必须指出具体的权衡（性能与可维护性、速度与安全性）
• 避免虚假的共识——如果所有人过快达成一致，应引入唱反调的观点
• 如果被说服，角色可以在辩论过程中改变想法

分析质量

• 建议必须切实可行，不能含糊
• 风险必须包含缓解策略
• 后续步骤必须具体且有序
• 分析使用法语撰写（自然、专业，使用“nous”）

示例

示例 1：技术决策

User: Lance une réunion pour savoir si on doit utiliser GraphQL ou REST pour la nouvelle API

Participants : SOLID Alex (Backend), Sprint Zero Sarah (PO), Pipeline Mo (DevOps), Pixel-Perfect Hugo (Frontend)
Decision question: "Devons-nous utiliser GraphQL ou REST pour la nouvelle API ?"

示例 2：带有问题的架构决策

User: Fais une réunion sur l'issue #234 - migration du monolithe vers des microservices

Participants : Whiteboard Damien (Architecte), SOLID Alex (Backend), Pipeline Mo (DevOps), Sprint Zero Sarah (PO), Edge-Case Nico (QA)
Decision question: "Comment migrer du monolithe vers des microservices pour le module facturation ?"
Analysis posted to GitLab issue #234 after user validation

示例 3：产品决策

User: Organisons une réunion sur l'ajout de notifications temps réel dans l'application

Participants : Sprint Zero Sarah (PO), Pixel-Perfect Hugo (Frontend), SOLID Alex (Backend), Paranoid Shug (Sécurité)
Decision question: "Quelle approche adopter pour les notifications temps réel ?"

重要说明

• 绝不在 GitLab 或 GitHub 上创建新标签。 为议题或合并请求添加标签时，只能使用项目中已有的标签。如果不确定有哪些标签，先列出标签（GitHub 使用 gh label list，GitLab 则检查现有议题标签），并从中选择。如果没有合适的标签，则跳过添加标签，不要创建新标签。
• 在用户验证建议之前，绝不开始实施（第 5 步中的选项 1）
• 会议是思考工具，不是决策机构
• 会议应聚焦讨论，每次只做出一个决策
• 如果主题过于宽泛，建议拆分为多个重点明确的会议
• 分析包含置信度（高／中／低）——置信度低时，应建议召开后续会议，而不是强行给出缺乏依据的建议
• 后续会议应产出差异分析，而不是完整的重新分析
• 用户验证后，可选择快速实施（自动创建 MR/PR）或引导式实施（逐步进行）
• 分析始终使用法语撰写
• 为便于阅读，角色在会议中使用英语发言，最终分析使用法语
• 如果用户在会议期间提供了额外背景信息，应据此调整讨论
• 角色选择基于启发式方法，仅作为建议；会议开始前由用户确认或调整