• Demande une « revue d'issue » ou « issue review » sur une issue
• Dit « issue-review #42 » ou « issue-review <URL> »
• Veut analyser une issue sous plusieurs angles avant implémentation
• Veut un avis structuré sur la faisabilité, la complétude et les risques d'une issue

• The entire pipeline runs without asking any user questions (except for closed issues — see Edge Cases)
• Persona selection is automatic based on issue content analysis
• The review comment is posted directly on the issue

• Personas review feasibility, completeness, risks, and architecture
• 3 full rounds ensure genuine debate and richer analysis
• Each persona brings a genuinely different viewpoint

• The skill reads the full issue: description, all comments, labels
• If a branch is linked, the branch diff is analyzed
• The existing codebase is explored automatically to give personas informed context

• This skill does NOT implement anything
• It produces a review with actionable next steps
• The team reads the analysis and decides what to do

1. Parse the user's input to extract the issue reference:
   • Issue number:

     #42

   • Full URL:

     https://gitlab.example.com/group/project/-/issues/42

     or

     https://github.com/owner/repo/issues/42

   • If no valid issue reference is found, ask the user to provide one
2. Detect the remote repository type:
   • Run

     git remote -v

     to determine if the remote is GitLab or GitHub
   • Store this for Step 7 (posting the comment)
3. Fetch the issue details:
   • GitLab:

     glab issue view <iid>

     — title, description, labels, state
   • GitHub:

     gh issue view <number>

     — title, body, labels, state
4. Fetch all issue comments:
   • GitLab:

     glab issue note list <iid>

     or

     glab api /projects/:id/issues/:iid/notes

   • GitHub:

     gh issue view <number> --comments

5. Check issue state:
   • If the issue is closed, warn the user and ask for confirmation before proceeding (see Edge Cases)
   • If the issue is open, proceed normally
6. Check for minimal content (see Edge Cases):
   • If the issue has no description or only a one-line title with no meaningful content, skip the meeting and post a short comment listing what's missing

• Issue title, description, and all comments (collected in Step 1)
• Labels and milestones (for domain detection)

1. Check for linked branches:
   • GitLab: Check the issue for related merge requests via

     glab api /projects/:id/issues/:iid/related_merge_requests

     or look for branch references in the issue/comments
   • GitHub: Check for linked pull requests via

     gh pr list --search "<issue reference>"

2. If a branch exists:
   • Fetch the diff:

     git diff main...<branch>

     (or the appropriate base branch)
   • Include the diff summary and key file changes in the persona context

1. Analyze the issue content to identify which parts of the codebase are relevant:
   • File paths, module names, function names, or components mentioned in the issue or comments
   • Domain keywords that map to specific directories or files
2. Explore the codebase — read relevant files to understand the current state:
   • Use Glob and Grep to find related files
   • Read the most relevant files (prioritize files explicitly mentioned, then files in related modules)
   • Understand existing patterns, architecture, and conventions
3. Build a context summary for the personas including:
   • Issue content (description + comments)
   • Linked branch diff (if any)
   • Relevant codebase snippets and architecture overview

1. The issue title and description
2. All context gathered (comments, branch diff, codebase snippets)
3. The persona's identity prompt

You are {name}, a {role}.

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

You are reviewing an issue before implementation. Here is the issue:

**Title:** {issue_title}
**Description:** {issue_description}
**Comments:** {issue_comments}

Codebase context:
{codebase_context}

{branch_diff_context_if_any}

As {name}, provide your review:
1. **Feasibility:** Is this issue feasible as described? What's missing or unclear?
2. **Risks:** What are the top 2-3 risks? Be specific about failure scenarios from your domain.
3. **Completeness:** Are acceptance criteria clear enough to implement? What questions would you ask the PO?
4. **Architecture/Design:** How should this be approached technically? What patterns or constraints apply?
5. **Pushback:** What would you challenge from other typical perspectives?

Stay fully in character. Be concise and actionable. Use concrete examples, not abstract platitudes.

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

subagent_type: "general-purpose"

"Review persona: {name}"

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

1. Check if all personas converged on the same assessment (same verdict, no meaningful disagreement)
2. If consensus is too high (all personas agree with no pushback):
   • Launch one additional sub-agent as a devil's advocate:

     You are a devil's advocate reviewing an issue.
     
     All reviewers agreed on this assessment: {consensus_summary}
     
     Your job: find the strongest possible argument AGAINST this consensus.
     - What risk did nobody mention?
     - What assumption are they all making that might be false?
     - What edge case or failure mode was dismissed 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
3. If there is already meaningful disagreement: proceed directly to Round 2

1. The issue details
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 review meeting about this issue:

**Title:** {issue_title}

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

As {name}, react to the other reviewers' positions:
1. Which assessments do you agree with and why?
2. Which assessments do you challenge? Be specific about what's wrong or missing.
3. What risks or gaps have the others missed?
4. Have any of the other statements changed your assessment? If so, how?
5. State your updated verdict: is this issue ready for implementation, needs adjustments, or needs a rethink?

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 issue is to their expertise
   • A database migration issue: EXPLAIN PLAN Isabelle's position carries more weight than Pixel-Perfect Hugo's
   • A UI redesign issue: Pixel-Perfect Hugo's position carries more weight than EXPLAIN PLAN Isabelle's
2. Identify consensus and disagreements:
   • Points of agreement across all personas
   • Unresolved disagreements — list them explicitly
   • Key risks and gaps that emerged from the debate
3. Assess the issue readiness:
   • Ready for implementation: Well-defined, feasible, risks are manageable
   • Needs adjustments: Feasible but missing details, unclear acceptance criteria, or risks need mitigation
   • Needs significant rework: Major gaps, unclear scope, architectural concerns unresolved
4. Compile actionable next steps — concrete checklist items the team can act on

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

• [Action 1 — e.g., "Préciser les critères d'acceptation pour le cas X"]
• [Action 2 — e.g., "Valider l'impact sur le module Y avec l'équipe"]
• [Action 3]

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

• [Action 1]
• [Action 2]
• [Action 3]

• Issue : #XX — [titre]
• Remote : GitLab / GitHub
• Personas : [Name (Role)] | [Name (Role)] | [Name (Role)]
• Rounds : 3 (ouverture + débat + convergence)
• Anti-groupthink : déclenché / non nécessaire
• Verdict : ✅ Prête / ⚠️ Ajustements / ❌ Refonte
• Commentaire : publié (#XX) / échec ([raison])
• Durée totale : [durée wall-clock]

undefined

1. Do NOT run the persona meeting — there is not enough content to review
2. Post a short comment in French on the issue listing what's missing:

undefined

• Description détaillée du besoin ou du problème
• Critères d'acceptation
• Contexte métier (qui est impacté, quel workflow)
• [Any other specific gaps detected]

3. Output the same message in the conversation and stop

1. Warn the user: "Cette issue est fermée. Souhaitez-vous quand même lancer la revue ? (utile pour une rétrospective)"
2. If the user confirms: proceed normally
3. If the user declines or does not respond: stop

• Output the full review in the conversation
• Provide a pre-formatted manual command
• Record the failure in the Run Summary

• 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

• 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, the anti-groupthink check triggers a devil's advocate
• Personas can change their mind during the debate if convinced

• The review must be actionable, not vague
• Risks must include mitigation strategies
• Next steps must be concrete and checkboxable
• The verdict must be one of the three defined levels (ready / needs adjustments / needs rework)
• The analysis is written in French (natural, professional, using "nous")

• Never create new labels on GitLab or GitHub. Only use labels that already exist in the project. If no suitable label exists, skip labeling.
• This skill is analytical only — it does NOT implement code, create branches, or create MRs/PRs
• The review comment is always in French, PO/consultant oriented, with technical concerns surfaced when needed
• The codebase is always explored for context, even when no branch is linked
• The meeting runs 3 full rounds (opening + debate + convergence) for review depth
• If the remote type cannot be determined, default to

  gh issue comment

  (GitHub)
• The skill supports both GitLab and GitHub issues