fast-meeting

快速会议

与专家角色开展全自主会议，然后立即实施推荐的解决方案、创建合并请求或拉取请求，并发布法语描述——整个过程无需用户确认。

前置条件

• gh（GitHub CLI）：项目使用 GitHub 时必需——从 https://cli.github.com 安装，或运行 brew install gh
• glab（GitLab CLI）：项目使用 GitLab 时必需——从 https://gitlab.com/gitlab-org/cli 安装，或运行 brew install glab

何时使用此技能

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

• 针对某个主题要求进行“快速会议”或“快速讨论”
• 希望在不中断的情况下获得决策并自动实施
• 说“fast-meeting”或“针对……启动一次 fast meeting”
• 希望通过一条命令分析、决定并实施某个主题

核心原则

1. 完全自主

• 整个流程无需向用户提问
• 根据上下文分析自动选择角色
• 会议结束后立即实施最佳方案
• 自动在检测到的远程仓库（GitLab 或 GitHub）上创建 MR/PR

2. 速度优先于全面性

• 精简会议：进行 2 轮，而非 3 轮（开场 + 收敛）
• 角色最多限制为 3–4 个
• 分析简洁且以行动为导向
• 会议一结束就开始实施

3. 视角多元且聚焦

• 根据主题自动选择角色
• 每个角色都提供真正不同的视角
• 会议迅速收敛到可执行的建议

4. 完整交付

• 在专用分支上提交代码变更
• 自动创建 MR/PR
• MR/PR 的法语描述总结会议分析和实施内容

工作流

步骤 0：Worktree 清理

开始之前，清理先前会议可能因崩溃而遗留的 worktree：

1. 运行 git worktree prune，移除过时的 worktree 引用
2. 检查 git worktree list——如果有条目对应名为 fast-meeting-* 或 fm-* 的同级目录：
   • **并行安全：**移除前，使用 fuser -s <worktree-path> 2>/dev/null 确认该 worktree 目录中没有正在运行的 git 进程。如果目录正在使用，跳过它——它属于另一个正在运行的 fast-meeting
   • 仅移除已确认过时的 worktree：git worktree remove <path> --force
3. 同时清理任何旧版 fast-meeting/* 分支：git branch --list 'fast-meeting/*' | xargs -r git branch -D

这样可以确保从干净的状态开始，同时不影响并行运行的 fast-meeting。

步骤 1：收集上下文

1. 阅读用户的提示——提取主题、约束和目标
2. 如果提到了 issue（GitLab #123 或 GitHub #123）：
   • 获取 issue 详情（描述、标签、评论）
   • 保存 issue 引用（编号、URL、项目），供步骤 8 和 9 使用
3. 如果未提及 issue，请记录这一点——稍后可能会在步骤 4b 中创建 issue
4. 如果涉及代码，阅读相关文件以了解当前状态
5. 检测远程仓库类型：
   • 运行 git remote -v，确定远程仓库使用 GitLab 还是 GitHub
   • 保存此信息，供步骤 8（创建 MR/PR）使用
6. 明确需要作出的决策——将其表述为一个清晰的单行问题

继续之前，先输出决策问题。例如：

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

步骤 2：自动选择角色

根据主题自动选择 3-4 个角色。参考以下启发式规则：

主题涉及……	自动选择的角色
后端 / 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（后端）
Legacy / 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（数据保护官）
GDPR / 个人数据 / 合规	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-4 个角色。技术决策始终包含 Whiteboard Damien（架构师）。产品决策始终包含 Sprint Zero Sarah（产品负责人）。

**角色及其职责、视角和偏见的完整列表：**参见 reference/personas.md。

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

步骤 3：进行快速会议

会议使用子代理，让每个角色独立并行地开展工作。快速会议将流程压缩为 2 轮。

重要：使用 Agent 工具，将每个角色作为独立子代理启动。

第 1 轮：立场与建议（并行子代理）

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

1. 步骤 1 中的决策问题
2. 收集到的所有上下文（问题详情、代码片段、限制条件）
3. 该角色的身份提示词

子代理提示词模板：

You are {name}, a {role}.

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

You are participating in a fast meeting about: {decision_question}

Context:
{context}

As {name}, provide your position:
1. What is your recommended approach? Be specific and concrete.
2. What are the top 2 risks? Be specific about failure scenarios.
3. What is your preferred implementation strategy in concrete steps?
4. What would you push back on from other typical perspectives?

Stay fully in character. Be concise and actionable — this is a fast meeting.

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

在一条消息中启动所有角色子代理，使其并行运行。使用 subagent_type: "general-purpose" 和类似 "Fast persona: {name}" 的简短描述。

收集所有立场，并以引述形式呈现：

SOLID Alex（高级后端工程师）：“我建议……”

反群体思维检查

收集完第 1 轮回复后，评估共识程度：

1. 检查所有角色是否都趋同于同一种方案（推荐相同，且没有实质性分歧）
2. 如果共识程度过高（所有角色都同意该方案，且没有提出异议）：
   • 启动一个额外的子 Agent担任唱反调者，并要求其找出反对共识立场的最有力论据
   • 使用此提示词：

     你是一次快速会议中的唱反调者。
     
     所有参与者都同意采用此方案：{consensus_summary}
     
     你的任务：找出反对该共识的最有力论据。
     - 可能出现哪些没人提到的问题？
     - 他们都在作出什么可能并不成立的假设？
     - 他们过快否决了哪个替代方案？
     
     请具体、明确，并引用真实的失败场景。
     这是一项研究任务——请勿编写或编辑任何文件。
     

   • 即使推荐方案不变，也要在分析中纳入异议观点
3. **如果已经存在实质性分歧：**直接进入第 2 轮

第 2 轮：收敛（单次综合）

收集完所有第 1 轮回复后，由你（主持人，而非子 Agent）进行综合：

• 各角色之间的共识点
• 出现的关键权衡
• 最终推荐方案及其理由
• 具体实施计划（要更改的文件、方法和操作顺序）

**不要启动第二轮子 Agent。**请直接综合，以节省时间。

第 4 步：给出精简决策

编写面向用户展示的精简分析：

## Fast Meeting : [Sujet]

**Question :** [La question de décision]

**Participants :** [Name (Role)] | [Name (Role)] | [Name (Role)]

### Recommandation retenue
[The recommended approach in 2-3 sentences]

### Justification
- [Reason 1]
- [Reason 2]
- [Reason 3]

### Risques et mitigations
- [Risk 1 → Mitigation]
- [Risk 2 → Mitigation]

### Plan d'implémentation
1. [Step 1]
2. [Step 2]
3. [Step 3]

第 4b 步：确保议题存在

如果第 1 步已经引用了议题，则该议题已可用——跳至第 5 步。

如果没有引用议题，则自动创建一个以便追踪——无需询问用户或征求确认。这符合 fast-meeting 的完全自主约定。

1. 根据会议分析创建议题：
   • **标题：**决策问题的简短表述（少于 70 个字符，使用法语）
   • **描述：**面向 PO 的摘要，使用以下模板
2. 立即创建议题：
   • **GitLab：**使用 glab issue create --title "<title>" --description "<description>"
   • **GitHub：**使用 gh issue create --title "<title>" --body "<description>"
   • 保存新建议题的编号和 URL，以供第 8 步和第 9 步使用
   • 不要添加标签，除非已确认这些标签在项目中存在（先列出标签）
3. 如果创建议题失败（API 错误、权限被拒绝、未找到项目）：在运行摘要中记录错误，然后在没有议题的情况下继续——第 8 步和第 9 步会据此调整

自动创建的议题描述模板（法语——面向 PO / 顾问）

## Contexte
[Business context derived from the user's prompt — what problem or opportunity triggered this analysis]

## Question analysée
[The decision question from Step 1, framed in business terms]

## Participants
| Expert | Rôle |
|--------|------|
| [Name] | [Role] |
| ... | ... |

## Recommandation
[The recommended approach in 2-3 sentences, focusing on user/business value rather than technical details]

## Risques identifiés
- [Risk 1 in business impact terms → Mitigation]
- [Risk 2 in business impact terms → Mitigation]

---
_Issue créée automatiquement par un fast-meeting IA_

第 5 步：范围控制

实施前，估算推荐变更的范围：

1. **评估范围：**估算要更改的文件数、要添加或修改的代码行数，以及是否需要新增依赖项或基础设施
2. 应用阈值：
   • 小范围（≤10 个文件、≤500 行、不需要新增基础设施）：正常进入第 6 步
   • 中等范围（>10 个文件或 >500 行）：继续操作，但要缩小范围，仅实施最关键的第一步。将剩余步骤作为清单，添加到 MR/PR 描述中的 ### Étapes restantes 部分
   • 大范围（涉及多个服务的变更、架构迁移、需要新增基础设施）：中止实施。输出第 4 步的会议分析，并建议用户运行完整的 /meeting 技能，在实施前进行充分规划和验证
3. **如果缩小范围：**在分析中明确说明当前实施的内容与延期的内容

步骤 6：创建工作树并实施

立即开始实施，无需询问用户。 这是与会议流程的关键区别。

实施工作在 git 工作树中进行，该工作树会创建一份隔离的仓库副本。用户的工作树绝不会被修改——不执行 stash、不切换分支，也不会有状态损坏的风险。

创建工作树

1. 记录当前分支以供参考（例如，main）
2. 根据会议建议确定分支类型：
   • 修复 Bug → fix/
   • 新功能 → feat/
   • 重构 → refactor/
   • 默认 → feat/
3. 检查冲突前获取远程状态：
   • 运行 git fetch origin，确保分支信息是最新的
4. 创建工作树前检查分支名称是否冲突：
   • 运行 git branch -a，检查 <type>/fm-<topic> 是否已存在（在本地或作为 remotes/origin/<type>/fm-<topic>）
   • 如果分支已存在：追加数字后缀（-2、-3 等），直到找到唯一名称。不要强制删除现有分支——它们可能包含已审查或正在进行的工作
5. 使用专用分支创建工作树：
   • 分支名称：<type>/fm-<short-kebab-case-topic>（例如，feat/fm-jwt-auth-migration、fix/fm-notification-display）——如果检测到冲突，则添加后缀
   • 工作树路径：$(git rev-parse --show-toplevel)/../fm-<topic>
   • 运行：git worktree add ../fm-<topic> -b <type>/fm-<topic>
6. 如果创建工作树失败：
   • 如果错误表明分支已存在：运行 git branch -D <type>/fm-<topic>，然后重试创建工作树
   • 如果仍然失败（磁盘空间、权限、路径长度、子模块或其他任何原因）：中止实施流程。输出步骤 4 中的完整会议分析、确切的错误消息，然后停止。用户可以修复根本问题并重新运行。绝不回退到 stash/checkout——用户的工作树绝不能被修改

在工作树中实施

1. 所有文件修改都必须在工作树路径内进行——所有读写操作都使用工作树的绝对路径
2. 按照步骤 4 中的实施计划实施更改
   • 根据需要编写代码、修改文件、添加测试
   • 遵循项目现有的约定和模式
3. 在工作树中暂存并提交所有更改：
   • 运行 git 命令前先 cd 到工作树路径
   • 使用 Conventional Commits 格式的提交消息：feat(<scope>): <description>
   • 在提交消息中包含 Co-Authored-By: Claude Opus 4.6 <[email protected]>
   • **如果 git commit 因预提交钩子而失败：**分析钩子的输出，修复代码以通过钩子，然后重试提交一次。如果仍然失败，则按测试失败处理——以 Draft 状态推送，并在 MR/PR 描述中记录钩子错误。绝不使用 --no-verify

步骤 7：测试、推送并清理

运行测试

提交后，使用项目的测试套件验证实现：

1. 自动检测测试运行器：
   • 检查 package.json 中是否有 test、test:unit、test:e2e 脚本
   • 检查是否存在 Makefile、pytest.ini、phpunit.xml 或其他测试配置文件
   • 如果未找到测试运行器，则跳过此步骤，并在 MR/PR 描述中注明“未检测到测试套件”
2. 运行测试（如果测试运行器支持，则仅运行受影响文件/模块的测试；否则运行完整测试套件）
3. **如果测试通过：**继续推送
4. 如果测试失败：
   • 分析失败原因，并尝试一轮修复（修复代码，然后重新运行测试）
   • 如果修复后测试通过：将修复补充到提交中，然后继续
   • 如果尝试一次修复后测试仍然失败：
     • 将 MR/PR 标记为草稿（在标题前加上 Draft:）
     • 在 MR/PR 描述中添加 ### 测试失败 部分，列出失败的测试和错误消息
     • 仍然推送，以便团队审查
5. **在 MR/PR 描述中包含测试结果摘要：**运行、通过和失败的测试数量

推送分支

1. 从工作树内推送分支：
   • 运行：git push -u origin <type>/fm-<topic>（在工作树路径下运行）
   • 如果推送失败（身份验证错误、没有远程仓库、权限被拒绝、网络问题）：
     • 不要移除工作树——必须保留已提交的工作
     • 输出工作树路径、分支名称和确切的错误消息
     • 输出手动恢复命令：cd <worktree-path> && git push -u origin <branch>
     • 完全跳过步骤 8 和 9——没有可供关联的内容
     • 直接进入运行摘要（步骤 10），并将推送状态设为“失败”

清理工作树

2. 移除工作树（仅在成功推送后）：
   • 返回原始仓库路径
   • 运行：git worktree remove ../fm-<topic>
   • 如果移除失败（例如，工作树中有未提交的更改），运行：git worktree remove ../fm-<topic> --force
   • **清理后验证：**运行 git worktree list，确认其中不再显示 fast-meeting 工作树。如果仍然显示，向用户输出清理命令：git worktree remove <path> --force
3. **无需恢复：**用户的工作树从未被修改——他们仍处于原始分支，所有未提交的更改也都保持原样

步骤 8：创建 MR/PR

根据步骤 1 中检测到的远程仓库类型：

如果是 GitLab：

使用 glab mr create --title "<title>" --description "<description>" --target-branch main 创建合并请求，其中：

• **标题：**简短描述（少于 70 个字符，使用英文）
• **描述：**法语会议分析和实现摘要（见下方模板）
• **Issue 链接：**如果存在 issue（在步骤 4b 中引用或创建），请在描述中加入 Closes #XX，以便在合并时自动关闭该 issue

如果是 GitHub：

使用 gh pr create 创建拉取请求，其中：

• **标题：**简短描述（少于 70 个字符，使用英文）
• **正文：**法语会议分析和实现摘要（见下方模板）
• **Issue 链接：**如果存在 issue（在步骤 4b 中引用或创建），请在正文中加入 Closes #XX，以便在合并时自动关闭该 issue

如果创建 MR/PR 失败：

如果创建 MR/PR 失败（API 超时、速率限制、身份验证问题、MCP 工具错误）：

• 输出远程仓库 URL 和分支名称
• 输出格式化好的手动命令，供用户复制粘贴：
  • GitLab：提供用于手动创建 MR 的网页 URL
  • GitHub：gh pr create --head <branch> --title "<title>" --body "<body>"
• 在对话输出中包含完整的 MR/PR 描述文本，避免内容丢失
• 如果适用，继续执行步骤 9（issue 评论）——即使没有 MR/PR 链接，issue 评论仍然有价值
• 在运行摘要（步骤 10）中记录失败

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_

关联 Issue： 如果存在 Issue（在步骤 1 中引用或在步骤 4b 中创建），请在 --- 分隔符后、斜体页脚前另起一行追加 Closes #<issue_number>。如果不存在 Issue，则完全省略此行。

步骤 9：在 Issue 中留言（面向 PO／顾问）

在关联的 Issue 中发布一条面向产品负责人／顾问的评论。这条评论是供重新打开工单的 PO／顾问查看的决策书签：必须在 15 行显示文本以内回答“做出了什么决定，为什么？”。便于快速浏览——读者会在 3 秒内决定是否深入了解。

Issue 处理方式：

• 步骤 1 中引用了 Issue： 在该 Issue 中发布评论
• 步骤 4b 中创建了 Issue： 在新创建的 Issue 中发布评论
• 步骤 4b 中创建 Issue 失败： 跳过此步骤，并在运行摘要中记录失败

编写规则

• 只使用一个二级标题——## Décision，置于顶部，用 1–2 句可执行的话说明结论。这是 80% 的读者会阅读的唯一内容。
• 省略问题描述——Issue 标题已经说明问题。不要换一种说法重述。
• 不要使用角色表。 角色是内部制作机制，不属于交付内容。只在页脚中以扁平的内联列表形式提及，供审计使用。
• 每个部分最多 3 个项目符号。 如果需要更多，说明决定还不够明确。
• 不要使用空占位内容。 如果字段没有实际内容（没有期限、没有依赖项），就完全省略，不要写“N/A”或“如适用”。
• 不要写技术细节。 实现细节应放在 MR/PR 描述中。

Issue 评论模板（法语）

## Décision

[1-2 phrases actionnables au présent, en termes métier]

**Pourquoi**
- [Bénéfice utilisateur / métier 1]
- [Bénéfice utilisateur / métier 2]
- [Bénéfice utilisateur / métier 3 ou trade-off assumé]

**Risques**
- [Risque métier → mitigation]
- [Risque métier → mitigation]

**Impact** : [utilisateurs concernés] · [délai si pertinent] · [dépendances si pertinentes]

**MR/PR** : [Lien]

---
_Fast-meeting IA · [Persona1, Persona2, Persona3]_

精简规则：

• 如果会议没有产生有意义的业务风险，则省略Risques部分。
• 如果答案只是泛泛的“所有用户”，则省略Impact行。
• 页脚仅保留一行——角色以逗号分隔的扁平列表呈现，不写职责，也不写职位。

使用适当的工具发布评论：

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

步骤 10：运行摘要

每次快速会议运行结束时，都必须输出结构化运行摘要，无论流程在哪一步成功或失败。这样可以为自主流程提供可观测性。

### Fast Meeting — Run Summary
- **Sujet :** [topic]
- **Branche :** `<type>/fm-<topic>`
- **Worktree :** [path] (nettoyé : oui/non)
- **Push :** succès / échec ([erreur si applicable])
- **MR/PR :** [URL] / non créé ([raison si applicable])
- **Tests :** [N exécutés, N passés, N échoués] / non détectés
- **Issue :** liée (#XX) / créée (#XX) / échec de création ([erreur])
- **Commentaire issue :** publié (#XX) / ignoré (pas d'issue)
- **Durée totale :** [durée wall-clock de l'ensemble du pipeline]

如果任何步骤失败，摘要必须包含失败原因，以及前面步骤中已提供的任何手动恢复命令。

会议质量规则

角色真实性

• 每个角色的发言应符合其职责和倾向
• 角色应使用具体示例，而不是空泛说教
• 安全工程师应讨论攻击向量，而不是含糊的“安全顾虑”
• 产品负责人应讨论用户影响和交付时间线，而不是代码模式

速度规则

• 每次会议最多 3–4 个角色
• 仅进行一轮并行子 Agent 分析，再由主持人综合（不进行第二轮辩论）
• 仅在共识度过高时才可选择启用唱反调的子 Agent（约增加 10 秒）
• 实施前无需用户确认
• 自动创建提交消息和 MR/PR

实施质量

• 遵循项目现有惯例和模式
• 编写整洁且经过测试的代码
• 实施后运行项目测试套件；失败时尝试进行一轮修复
• 专注于建议方案，不要过度设计
• 范围控制：如果改动超过 10 个文件／500 行，则缩减范围，仅保留关键的第一步；如果涉及架构范围，则中止实施并建议使用 /meeting
• 保护用户的工作树：实施在隔离的 git worktree 中运行，不会修改用户的工作目录

示例

示例 1：技术决策

User: fast-meeting : est-ce qu'on doit utiliser GraphQL ou REST pour la nouvelle API

→ Auto-sélection : SOLID Alex (Backend), Pixel-Perfect Hugo (Frontend), Whiteboard Damien (Architecte)
→ Lance le fast meeting (1 tour + synthèse)
→ Implémente l'approche recommandée
→ Crée la branche feat/fm-graphql-vs-rest-api
→ Commit, push, crée la MR/PR avec description en français

示例 2：附带问题的错误修复

User: fast-meeting sur l'issue #42 - les notifications ne s'affichent pas

→ Récupère les détails de l'issue #42
→ Auto-sélection : Pixel-Perfect Hugo (Frontend), SOLID Alex (Backend), Edge-Case Nico (QA)
→ Lance le fast meeting
→ Implémente le correctif
→ Crée la MR/PR, poste le lien sur l'issue #42

示例 3：重构

User: fast-meeting : refactorer le module d'authentification pour supporter OAuth2

→ Auto-sélection : Paranoid Shug (Sécurité), SOLID Alex (Backend), Whiteboard Damien (Architecte), Pipeline Mo (DevOps)
→ Lance le fast meeting
→ Implémente le refactoring
→ Crée la MR/PR avec analyse en français

示例 4：未引用问题 — 自动创建

User: fast-meeting : migrer le cache Redis vers Valkey

→ Pas d'issue référencée
→ Auto-sélection : SOLID Alex (Backend), Pipeline Mo (DevOps), Whiteboard Damien (Architecte)
→ Lance le fast meeting (1 tour + synthèse)
→ Crée automatiquement l'issue #58 avec résumé PO (aucune confirmation requise)
→ Implémente la migration dans un worktree isolé
→ Commit, push, crée la MR/PR (Closes #58) avec description technique
→ Poste le résumé PO sur l'issue #58

重要说明

• 绝不要在 GitLab 或 GitHub 上创建新标签。为问题或合并请求添加标签时，只能使用项目中已有的标签。如不确定有哪些标签，请先列出（GitHub 使用 gh label list，GitLab 则查看现有问题标签），并从中选择。如果没有合适的标签，就跳过添加标签，不要创建新标签。
• 此技能不会要求用户确认——它会自主运行完整流程
• 如果一次修复尝试后测试仍然失败，请将 MR/PR 标记为草稿，并记录失败情况
• 如果实现范围过大（涉及架构或多个服务），请中止并建议改用 /meeting
• 始终保护用户的工作树：实现过程在隔离的 git worktree 中运行——不会暂存更改，不会切换分支，也不会有状态损坏的风险。如果创建 worktree 失败，流程会干净地中止，不会退而使用 stash/checkout
• 可以在不同的 worktree 上并行运行多个 fast-meeting——步骤 0 只会清理没有活动进程的 worktree，因此并行运行是安全的
• 创建 MR/PR 时，使用 git branch -r | grep '/fm-' 检查是否存在其他活动的 fast-meeting 分支。如果存在其他分支，请在 MR/PR 描述中添加警告：“注意：还有其他 fast-meeting 分支处于活动状态。合并前请检查潜在冲突。”
• MR/PR 描述始终使用法语
• 分支名称遵循 Git flow 约定：<type>/fm-<topic>（例如 feat/fm-<topic>、fix/fm-<topic>）——根据会议建议自动确定
• 如果无法确定远程类型，默认使用 gh pr create（GitHub）
• 绝不要强制推送或修改现有分支——始终创建新分支