Panel Brainstorm → Tableau de décision interactif

Que fait Panel Brainstorm → Tableau de décision interactif ?

Si un fichier LOCAL.md se trouve à côté de ce SKILL.md, lisez-le d'abord — il contient les spécificités de cet espace de travail (chemins, outils, exemples) et remplace les valeurs par défaut génériques ci-dessous.

Exécutez un panel de personas sur les pools de crédits Codex / Antigravity / Claude pour générer des idées produit ancrées, les stress-tester via une passe CPO antagoniste, synthétiser une liste dédupliquée d'environ 30 idées avec un top 5 wireframé, et publier un tableau de décision interactif (Implémenter / En attente / Rejeter par idée) dont le résumé copié revient dans le chat comme décision de référence.

Sortie de référence (un panel réel, anonymisé) : assets/decision-board-reference.html.

Quand NE PAS utiliser

• Une demande de fonctionnalité unique et bien cadrée → construisez/planifiez simplement (ou superpowers:brainstorming en ligne).
• Revue de code ou décisions de promotion sur une branche existante → dev-to-prod-promotion-review.
• Questions de pure recherche → deep-research.

Procédure

1. Ancrez-vous d'abord (thread principal)

Lisez le code / la fonctionnalité réelle qui fait l'objet du brainstorming. Rédigez un résumé de l'état actuel (3–6 lignes) : ce qu'il fait aujourd'hui, fichiers clés, limites connues. Chaque prompt de persona intègre ce résumé ainsi que les chemins de fichiers concrets à lire — c'est ce qui ancre les idées plutôt que de les rendre génériques.

2. Concevez le panel

5–7 personas, chacun avec un nom, un titre de poste et un angle qui produit des idées différentes — pas des formulations différentes du même angle. La composition éprouvée :

Archétype de persona	Angle	Backend recommandé
Ingénieur staff ("Dex")	Pas cher et à fort effet de levier vu le code existant	codex
PM Croissance ("Priya")	Activation, boucles d'habitude, mesure	codex
Designer UX ("Wren")	Utilisateurs perdus, wayfinding, accessibilité	antigravity (≤1 leg)
Opérateur avancé ("Marisol")	La journée type de l'opérateur	claude
Nouveau venu nerveux ("Jomar")	Confusion au jour 3, réassurance, langage	claude
Stratège IA ("Kade")	Frontière agentique, appliquée aux mécanismes existants, risques	claude

Adaptez les archétypes au sujet (ex : persona client, persona comptable). Gardez au moins un persona utilisateur (pas un constructeur) et un angle sceptique-adjacent.

Tâche de chaque persona : "TÂCHE DE BRAINSTORMING (rédigez un document markdown, ne modifiez PAS le code de l'application)… proposez exactement 8 idées… pour chacune : nom court, pitch en une ligne, pourquoi/moment qu'elle sert, comment elle fonctionnerait (ancrée dans les fichiers lus), effort P/M/G. Écrivez dans docs/<sujet>-idées/<persona>.md. Ce fichier est votre UNIQUE livrable."

3. Exécutez-le en éventail parallèle

Utilisez l'outil d'exécution parallèle dont vous disposez : un outil de fan-out multi-backend qui exécute chaque persona comme un job d'arrière-plan indépendant dans son propre worktree git (Codex / Antigravity / Claude), ou des sous-agents d'arrière-plan natifs (max 3 simultanés, vagues si plus). Ajouts propres aux panels :

• Une passe de revue antagoniste (un job final qui lit chaque document persona) avec un focus panel produit, pas une revue de code : "Vous êtes un Chief Product Officer sceptique présidant un panel produit… critiquez les idées de chaque panéliste pour leur réalisme et leur impact, signalez les chevauchements, terminez par votre top 8 classé." Les verdicts du CPO deviendront des annotations par idée plus tard.
• Exécutez en arrière-plan ; surveillez la complétion.

4. Vérifiez les livrables — les backends peuvent mentir

Après l'exécution, vérifiez que chaque fichier de sortie du persona existe réellement (ls les worktrees). Antigravity peut signaler status: done sans rien écrire. Réexécutez tout persona manquant comme sous-agent d'arrière-plan natif (même prompt, "retournez les idées comme votre message final, n'écrivez pas de fichiers") — prend ~1 minute.

Aussi : la liste classée finale de la revue peut être tronquée dans les fichiers de rapport de l'exécuteur. Les critiques par idée survivent généralement ; faites le classement final vous-même.

5. Synthétisez

• Dédupliquez ~48 idées brutes → ~30 idées regroupées en 5–6 thèmes ; conservez l'attribution par persona (la convergence = plusieurs personas proposant la même chose est le signal de classement le plus fort).
• Choisissez un top 5 selon : convergence → verdict CPO → adéquation au code existant.
• Notez ce que le panel a écarté et pourquoi (une ligne) — l'utilisateur veut voir les kills.
• Les documents persona vivent dans les worktrees de l'exécuteur qui seront nettoyés ; si vous souhaitez les conserver, copiez-les avant de lancer le nettoyage.

6. Construisez le tableau de décision interactif (Artifact)

Adaptez assets/decision-board-reference.html — conservez sa trousse CSS et l'intégralité de la balise <script> à l'exception de STORE_KEY (doit être unique par tableau, sinon deux tableaux écrasent les décisions de l'autre). Chargez la compétence artifact-design avant d'écrire.

Éléments requis (le motif dev-to-prod-promotion-review) :

• Comptage collant en direct — comptes implémenter / en attente / rejeter / non décidé.
• Cartes du top 5 avec un wireframe en CSS uniquement du changement (la référence contient une trousse de wireframe réutilisable : .wf, .frame, .side, .bub, .rankrow, .spot, .note) + attribution par persona + un encart Vérification CPO :.
• Bascule 3 états (✓ Implémenter / ◦ En attente / ✕ Rejeter) sur chaque carte du top 5 ET chaque ligne du tableau des 30 idées. Les décisions vivent à la granularité de l'idée feuille : une carte de groupe définit data-key plus data-also="iX,iY" de sorte que décider la carte décide ses idées constitutives, et les lignes du tableau restent ajustables individuellement. Cliquer sur le choix actif à nouveau l'efface.
• Persistance localStorage indexée par le STORE_KEY unique.
• Zone de texte de résumé des décisions + bouton Copier — les Artifacts n'ont pas de pont sendPrompt ; le texte copié collé dans le chat EST le canal de retour. Incluez un bouton Réinitialiser.

Vérifiez avant de publier : servez le fichier via un python3 -m http.server local (l'aperçu file:// du navigateur est capricieux) et testez au clic avec javascript_tool : le clic sur un groupe définit les constitutifs, le comptage se met à jour, localStorage persiste, la réinitialisation efface. Les caractères brouillés dans l'aperçu local ne sont que l'absence d'en-tête charset — l'Artifact publié en définit un.

Publiez avec l'outil Artifact ; republicz le même chemin de fichier pour conserver l'URL.

7. Rapportez et collectez les décisions

Message final du chat : top 5 en une ligne chacun + lien vers l'Artifact + note que les décisions se recopient dans le chat. Quand l'utilisateur recolle le résumé, traitez-le comme la décision de référence : réconciliez-le honnêtement avec votre propre classement (un rejet surprise est un signal, pas un bruit), puis planifiez/exécutez la liste IMPLÉMENTEZ et mettez de côté les éléments ATTENTE là où ils sont indiqués.

Erreurs courantes

Erreur	Correctif
Personas sans chemins de fichiers à lire	Idées génériques — toujours intégrer le résumé de l'état actuel + chemins
Faire confiance au statut done d'Antigravity	Vérifier que le fichier de sortie existe ; réexécuter la leg comme sous-agent natif
Décisions uniquement à la granularité du groupe	Les idées feuilles décident ; les groupes propagent via data-also
Réutilisation d'un STORE_KEY	Deux tableaux écrasent les décisions localStorage de l'autre
Nettoyage des worktrees avant la copie des documents persona	Les documents sont sur les branches du worktree — copiez d'abord si vous les conservez
Ignorer la passe CPO	Liste de souhaits non classée ; les critiques sont la moitié de la valeur
Attendre la liste classée du CPO	Elle est tronquée ; classez vous-même à partir de la convergence + verdicts