• Demande un « fast meeting » ou « réunion rapide » sur un sujet
• Veut une décision ET une implémentation automatique sans interruption
• Dit « fast-meeting » ou « lance un fast meeting sur... »
• Veut qu'un sujet soit analysé, décidé et implémenté en une seule commande

• The entire pipeline runs without asking any user questions
• Persona selection is automatic based on context analysis
• The best course of action is implemented immediately after the meeting
• A MR/PR is created automatically on the detected remote (GitLab or GitHub)

• The meeting is compressed: 2 rounds instead of 3 (opening + convergence)
• Personas are limited to 3-4 maximum
• The analysis is concise and action-oriented
• Implementation starts as soon as the meeting concludes

• Personas are auto-selected based on the subject matter
• Each persona brings a genuinely different viewpoint
• The meeting converges quickly toward an actionable recommendation

• Code changes are committed on a dedicated branch
• A MR/PR is created automatically
• The MR/PR description in French summarizes the meeting analysis and implementation

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

   #123

   or GitHub

   #123

   ):
   • Fetch the issue details (description, labels, comments)
3. If code is involved, read relevant files to understand the current state
4. Detect the remote repository type:
   • Run

     git remote -v

     to determine if the remote is GitLab or GitHub
   • Store this for Step 6 (MR/PR creation)
5. Identify the decision to make — frame it as a clear one-line question

"Question: Should we migrate the authentication system from session-based to JWT tokens?"

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

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 (Senior Backend Engineer): "I recommend..."

1. Check if all personas converged on the same approach (same recommendation, no meaningful disagreement)
2. If consensus is too high (all personas agree on the approach with no pushback):
   • Launch one additional sub-agent as a devil's advocate, prompted to find the strongest argument against the consensus position
   • Use this prompt:

     You are a devil's advocate in a fast meeting.
     
     All participants agreed on this approach: {consensus_summary}
     
     Your job: find the strongest possible argument AGAINST this consensus.
     - What could go wrong that nobody mentioned?
     - What assumption are they all making that might be false?
     - What alternative did they dismiss too quickly?
     
     Be specific and concrete. Reference real failure scenarios.
     This is a research task — do NOT write or edit any files.

   • Include the dissenting view in the analysis even if the recommendation doesn't change
3. If there is already meaningful disagreement: proceed directly to Round 2

• Points of agreement across personas
• Key trade-offs that emerged
• The winning recommendation with rationale
• Concrete implementation plan (files to change, approach, order of operations)

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

• [Risk 1 → Mitigation]
• [Risk 2 → Mitigation]

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

undefined

1. Assess the scope: count the estimated number of files to change, lines of code to add/modify, and whether new dependencies or infrastructure are needed
2. Apply thresholds:
   • Small scope (≤10 files, ≤500 lines, no new infrastructure): proceed to Step 5 normally
   • Medium scope (>10 files OR >500 lines): proceed but scope down to the most critical first step only. Add the remaining steps as a checklist in the MR/PR description under a

     ### Étapes restantes

     section
   • Large scope (multi-service changes, architectural migration, new infrastructure required): abort implementation. Output the meeting analysis from Step 4, and suggest the user run the full

     /meeting

     skill for proper planning with validation before implementation
3. If scoping down: clearly state in the analysis what is being implemented now vs. deferred

1. Run

   git status

   to check for uncommitted changes (staged, unstaged, or untracked)
2. If the working tree is dirty:
   • Run

     git stash push -m "fast-meeting: auto-stash before <topic>"

     to save the user's in-progress work
   • Remember the original branch name for later restoration
3. If the working tree is clean: proceed normally

1. Create a new branch from the current branch:
   • Branch name:

     fast-meeting/<short-kebab-case-topic>

     (e.g.,

     fast-meeting/jwt-auth-migration

     )
   • Run:

     git checkout -b fast-meeting/<topic>

2. Implement the changes as described in the implementation plan from Step 4
   • Write code, modify files, add tests as needed
   • Follow the project's existing conventions and patterns
3. Stage and commit all changes:
   • Use a conventional commit message:

     feat(<scope>): <description>

   • Include

     Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

     in the commit message

1. Auto-detect the test runner:
   • Check

     package.json

     for

     test

     ,

     test:unit

     ,

     test:e2e

     scripts
   • Check for

     Makefile

     ,

     pytest.ini

     ,

     phpunit.xml

     , or other test config files
   • If no test runner is found, skip this step and note "No test suite detected" in the MR/PR description
2. Run the tests (scoped to affected files/modules if the test runner supports it, otherwise run the full suite)
3. If tests pass: proceed to push
4. If tests fail:
   • Analyze the failures and attempt one fix cycle (fix the code, re-run tests)
   • If tests pass after the fix: amend the commit with the fix and proceed
   • If tests still fail after one fix attempt:
     • Mark the MR/PR as Draft (prefix title with

       Draft:

       )
     • Add a

       ### Tests en échec

       section in the MR/PR description listing the failing tests and error messages
     • Push anyway so the team can review
5. Include test results summary in the MR/PR description: number of tests run, passed, failed

1. Push the branch to the remote:
   • Run:

     git push -u origin fast-meeting/<topic>

2. Restore the user's working state:
   • Run

     git checkout <original-branch>

     to return to the branch the user was on
   • If a stash was created in Step 5a, run

     git stash pop

     to restore the user's uncommitted work

gitlab-mcp(create_merge_request)

• Title: Short description (under 70 chars, in English)
• Description: The French meeting analysis and implementation summary (see template below)

gh pr create

• Title: Short description (under 70 chars, in English)
• Body: The French meeting analysis and implementation summary (see template below)

• [Raison 1]
• [Raison 2]
• [Raison 3]

• [Risque 1 → Mitigation]
• [Risque 2 → Mitigation]

• [Description des modifications fichier par fichier]

• Revue de code par l'équipe
• Validation des tests
• Merge après approbation

undefined

1. Post a comment on the issue linking to the MR/PR
2. Format:

   Réunion rapide terminée. MR/PR créée : [link]. Voir la description de la MR/PR pour l'analyse complète.

3. Use the appropriate tool:
   • GitLab:

     gitlab-mcp(create_issue_note)

   • GitHub:

     gh issue comment

• 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 impact and delivery timelines, not code patterns

• Maximum 3-4 personas per meeting
• Single round of parallel sub-agents + facilitator synthesis (no Round 2 debate)
• Optional devil's advocate sub-agent only when consensus is too high (adds ~10 seconds)
• No user confirmation before implementation
• Commit message and MR/PR are created automatically

• Follow existing project conventions and patterns
• Write clean, tested code
• Run the project's test suite after implementation; attempt one fix cycle on failures
• Keep changes focused on the recommendation — do not over-engineer
• Scope guard: if changes exceed 10 files / 500 lines, scope down to the critical first step; if the scope is architectural, abort implementation and suggest

  /meeting

• Protect the user's working tree: stash uncommitted changes before branching, restore after push

• This skill does NOT ask for user confirmation — it runs the full pipeline autonomously
• If tests fail after one fix attempt, mark the MR/PR as Draft and document the failures
• If the implementation scope is too large (architectural, multi-service), abort and suggest

  /meeting

  instead
• The user's working tree is always protected: uncommitted changes are stashed before branching and restored after push
• The MR/PR description is always in French
• Branch names use the pattern

  fast-meeting/<topic>

• If the remote type cannot be determined, default to

  gh pr create

  (GitHub)
• Never force-push or modify existing branches — always create a new branch