• Demande de « lancer une réunion » ou « simuler une réunion » sur un sujet
• Veut analyser un problème sous plusieurs angles avant de décider
• Dit « discutons-en avec des personas » ou « qu'en penseraient des experts ? »
• A besoin d'un débat structuré avant une décision d'architecture, produit ou technique
• Souhaite explorer les compromis sur une fonctionnalité, une migration, un refactoring ou un choix de design
• Référence une issue GitLab ou GitHub et souhaite y poster l'analyse de la réunion

• Each persona brings a genuinely different viewpoint
• Personas may disagree — conflict is valuable
• No persona dominates the discussion

• The meeting follows a clear agenda
• Arguments are grounded in facts, trade-offs, and experience
• Every position includes both benefits and risks

• The meeting converges on a recommendation
• The recommendation includes a clear rationale
• Alternative options remain documented for context

• The meeting produces a proposal, not a decision
• The user reviews and validates before any implementation
• The user can ask for a follow-up meeting to dig deeper

1. Read the user's prompt carefully — extract the topic, constraints, and goals
2. If an issue is referenced (GitLab

   #123

   or GitHub

   #123

   ):
   • Fetch the issue details to understand the full context
   • Read the issue description, labels, comments, and linked MRs
3. If code is involved, read the relevant files to understand the current state
4. Identify the decision to make — frame it as a clear question

• A name and role
• A perspective (what they care about most)
• A bias (their natural tendency)

1. The decision question from Step 1
2. All context gathered (issue details, code snippets, constraints)
3. The persona's identity prompt (see template below)

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.

subagent_type: "general-purpose"

"Persona: {name} opening"

SOLID Alex (Senior Backend Engineer): "I think we should..."

1. The decision question
2. The full set of opening statements from Round 1 (all personas)
3. The persona's identity prompt

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.

1. Weight positions by domain relevance:
   • For each persona, assess how central the decision question is to their expertise
   • A database migration question: EXPLAIN PLAN Isabelle's position carries more weight than Pixel-Perfect Hugo's
   • A UI redesign question: Pixel-Perfect Hugo's position carries more weight than EXPLAIN PLAN Isabelle's
   • Whiteboard Damien (Architecte) et Sprint Zero Sarah (PO) jouent le rôle de voix équilibrantes sur tous les sujets
2. Identify consensus and disagreements:
   • Points of agreement across all personas
   • Unresolved disagreements — list them explicitly as open items, do NOT silently pick a side
   • Key trade-offs that emerged from the debate
3. Assess confidence level:
   • High confidence: Strong consensus among domain-relevant personas, risks are well-mitigated
   • Medium confidence: Majority agrees but 1-2 meaningful dissenting points remain
   • Low confidence: Deep disagreement among domain-relevant personas, or critical unknowns remain
   • Include the confidence level in the analysis output
4. If confidence is low:
   • Do NOT force a weak recommendation
   • Instead, clearly state the unresolved points and recommend a follow-up meeting (Step 7) focused on the specific disagreement
   • Present the competing options as equals with their trade-offs
5. Extract each persona's final position in one sentence

• [Reason 1]
• [Reason 2]
• [Reason 3]

• [Risk 1 + mitigation]
• [Risk 2 + mitigation]

1. [Step 1]
2. [Step 2]
3. [Step 3]

undefined

"Voici l'analyse de la réunion. Souhaitez-vous :

1. Valider cette recommandation et passer à l'implémentation (→ Step 8)
2. Approfondir un point spécifique avec une réunion de suivi (→ Step 7)
3. Poster cette analyse sur l'issue [#ID] (→ Step 6, si applicable)
4. Modifier la recommandation"

• [Bénéfice utilisateur / métier 1]
• [Bénéfice utilisateur / métier 2]
• [Alignement avec les objectifs produit]

• [Risque 1 formulé en impact métier → Mitigation]
• [Risque 2 formulé en impact métier → Mitigation]

• Utilisateurs concernés : [Qui est impacté et comment]
• Dépendances : [Autres équipes ou fonctionnalités impactées]

1. [Step 1]
2. [Step 2]
3. [Step 3]

Post the comment using the appropriate tool:
- **GitLab:** Use `glab issue note <iid> --message "<comment>"`
- **GitHub:** Use `gh issue comment <number> --body "<comment>"`

1. Carry forward context:
   • Include the full previous meeting analysis as context for all sub-agents
   • Explicitly reference the original decision question and the specific point to explore deeper
2. Narrow the scope:
   • Frame a new, focused decision question around the unresolved point
   • Format: "Suite de réunion : [Sujet original] → Focus : [Point approfondi]"
3. Adjust the persona panel:
   • Keep personas whose expertise is directly relevant to the focused point
   • Add new personas if the focused topic requires expertise not present in the original meeting (e.g., if a security concern emerged, add Paranoid Shug if not already present)
   • Remove personas whose expertise is not relevant to the narrowed topic
   • Maximum 3-4 personas for the follow-up (keep it focused)
4. Run a 2-round follow-up (Round 1 + Round 2 only, skip Round 3's full synthesis):
   • Sub-agents receive the previous meeting analysis as additional context
   • Their prompts should reference: "In the previous meeting, [summary]. We are now focusing on [specific point]."
5. Produce a delta analysis:
   • Do NOT repeat the full original analysis
   • Write a focused section:

     ## Suite de réunion : Focus sur [point]

   • Include: what changed, what was confirmed, updated recommendation and confidence level
   • If the original recommendation changed, clearly state: "La recommandation initiale est modifiée suite à l'approfondissement"
   • If confirmed, state: "La recommandation initiale est confirmée après approfondissement"
6. Present the updated analysis and return to Step 5 (validate again)

1. Ask the user which implementation mode they prefer:

   "Recommandation validée. Comment souhaitez-vous procéder ?

   1. Implémentation rapide — Je lance un

      /fast-meeting

      avec la recommandation déjà validée (pas de nouvelle réunion, implémentation directe + MR/PR)
   2. Implémentation guidée — J'implémente pas à pas, vous validez chaque étape"

2. If option 1 (fast implementation):
   • Create a branch

     meeting/<short-kebab-case-topic>

   • Implement the validated recommendation directly (skip the meeting phase — it's already done)
   • Run tests, commit, push, create MR/PR following the same protocol as fast-meeting Steps 5-6
   • The MR/PR description must be developer / technically oriented (see template below) — focus on code changes, technical rationale, and review points, not the business analysis
   MR/PR Description Template (French — Developer / Technically Oriented):
   markdown

   ## 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. If option 2 (guided implementation):
   • Present the implementation plan step by step
   • Wait for user confirmation at each significant step
   • The user controls the pace and can adjust the plan

• Each persona speaks consistently with their role and bias
• Personas use concrete examples, not abstract platitudes
• A security engineer talks about attack vectors, not vague "security concerns"
• A product owner talks about user stories and metrics, not code patterns

• At least one persona must disagree with the majority
• Arguments must reference specific trade-offs (performance vs. maintainability, speed vs. safety)
• Avoid false consensus — if everyone agrees too quickly, introduce a devil's advocate position
• Personas can change their mind during the debate if convinced

• The recommendation must be actionable, not vague
• Risks must include mitigation strategies
• Next steps must be concrete and ordered
• The analysis is written in French (natural, professional, using "nous")

• Never create new labels on GitLab or GitHub. When adding labels to issues or merge requests, only use labels that already exist in the project. If unsure which labels exist, list them first (

  gh label list

  for GitHub, or check existing issue labels for GitLab) and pick from the available ones. If no suitable label exists, skip labeling rather than creating a new one.
• Never implement before the user validates the recommendation (option 1 in Step 5)
• The meeting is a thinking tool, not a decision-making authority
• Keep meetings focused — one decision per meeting
• If the subject is too broad, suggest splitting into multiple focused meetings
• The analysis includes a confidence level (high/medium/low) — low confidence triggers a follow-up meeting suggestion instead of forcing a weak recommendation
• Follow-up meetings produce a delta analysis, not a full re-analysis
• When the user validates, they choose between fast implementation (automatic MR/PR) or guided implementation (step by step)
• The analysis is always written in French
• Personas speak in English during the meeting for readability, the final analysis is in French
• If the user provides additional context during the meeting, adapt the discussion accordingly
• Persona selection uses heuristics as suggestions; the user confirms or adjusts before the meeting starts