Chorus Brainstorm Skill
Un cadre de dialogue divergent-puis-convergent pour les idées dont la direction se forme encore. Compresse la conversation en un seul ElaborationRound de Q&A décisionnel — même structure qu'un round d'élaboration structuré, mais les questions, options et réponses sont synthétisées à la fin de la conversation plutôt que posées au départ.
Cette skill est un producteur d'un round d'élaboration ; la décision du scheduler (résoudre ou follow-up) appartient à la skill appelante /chorus-idea.
Quand elle est invoquée
Uniquement comme sous-étape de la skill /chorus-idea, uniquement après que l'utilisateur ait explicitement opté pour via une question interactive. Ne jamais s'exécuter seule, ne jamais s'exécuter sans opt-in utilisateur. Le point d'entrée attendu est « Étape 4.5 : Mode Brainstorm (Prélude Optionnel) » de la skill idea — voir /chorus-idea pour le flux environnant.
Règles strictes
- Une question à la fois. Chaque question interactive que tu poses DOIT être une seule question. Attends la réponse avant de poser la suivante.
- Multi-choix préféré. Cadre chaque question avec 2-4 options si possible. Ouvert est acceptable quand les options seraient prématurées, mais privilégie les choix concrets.
- Propose 2-3 directions avant d'arrêter la divergence. Une fois que la direction requise est assez claire pour être énumérée, présente 2-3 approches distinctes dans une seule question. Marque exactement une comme option recommandée, et dis pourquoi.
- Approbation utilisateur explicite requise pour quitter la divergence. NE PROCÈDE PAS à la synthèse tant que l'utilisateur n'a pas sélectionné l'une des directions proposées.
- Aucune écriture de fichier. NE ÉCRIS PAS de markdown, design doc, scratch file ou tout autre fichier sur disque. La conversation produit un
ElaborationRoundet rien d'autre sur disque. - Aucun commentaire posté. NE APPELLE PAS
chorus_add_commentdepuis cette skill. Les commentaires appartiennent à la skill/chorus-ideaou à l'utilisateur, pas à l'étape brainstorm. - Aucun handoff de design-doc. NE INVOQUE PAS de skill dont le but est de produire un design document. La sortie du brainstorm est le round synthétisé — il n'y a pas de doc séparé.
- Aucun appel
validate_elaboration. NE APPELLE PASchorus_pm_validate_elaborationdepuis cette skill. Le choix de résoudre l'élaboration ou d'ouvrir un round de follow-up (chorus_pm_start_elaborationà nouveau) est la décision de la skill/chorus-ideaappelante, pas celle de cette skill.
Étape par étape
1. Rassembler le contexte
Avant de poser la première question divergente, lis l'idée et l'état du projet environnant. Reproduis la liste gather-context de /chorus-idea :
chorus_get_idea({ ideaUuid })
chorus_get_documents({ projectUuid })
chorus_get_document({ documentUuid }) # pour tout document valant la peine d'être lu en entier
chorus_get_proposals({ projectUuid, status: "approved" }) # pour comprendre les motifs
chorus_list_tasks({ projectUuid }) # pour éviter de dupliquer le travail existant
chorus_get_comments({ targetType: "idea", targetUuid: ideaUuid })
Survole chaque résultat pour : contexte déclaré, exigences déclarées, contraintes déclarées, et ce qui conspicuement N'EST PAS déclaré. Les lacunes sont les questions qui méritent d'être posées.
2. Q&A divergent
Pose une question à la fois (interactive, mono-objectif). Vise à mettre en surface :
- Le but que l'idée tente de servir (souvent plus abstrait que l'énoncé d'idée).
- Les contraintes qui excluent des branches entières de l'espace des solutions (délais, compatibilité, périmètre).
- Les critères de succès — comment l'utilisateur saura-t-il que c'est fait.
Garde chaque question mono-objectif. Si tu dois poser trois choses, c'est trois tours, pas une question combinée.
3. Propose 2-3 directions
Quand le but, les contraintes et les critères de succès sont assez clairs pour que tu puisses nommer des approches distinctes, présente-les dans une seule question :
Question : « <la question de convergence> »
Options :
- « Option A (Recommandée) » — <quoi + tradeoff>
- « Option B » — <quoi + tradeoff>
- « Option C » — <quoi + tradeoff>
(simple sélection)
La recommandation doit être visiblement marquée pour l'utilisateur. Énonce pourquoi tu la recommandes — généralement une phrase sur le tradeoff dominant.
4. Attends l'approbation explicite
Ne procède pas à la synthèse si l'utilisateur n'a pas sélectionné l'une des options. Si l'utilisateur répond avec du texte libre (une nouvelle contrainte), traite cela comme un perfectionnement — retourne à l'étape 2 ou 3 avec la direction perfectionnée.
5. Synthétise le Q&A décisionnel
Pour chaque décision matérielle que l'utilisateur a prise lors de la conversation, construis une ElaborationQuestion. Une « décision matérielle » est un moment où l'utilisateur a choisi entre des alternatives ou fixé explicitement le périmètre. Mappe chaque décision selon la spécification de synthèse ci-dessous.
6. Persiste le round
Appelle chorus_pm_start_elaboration avec les questions synthétisées :
chorus_pm_start_elaboration({
ideaUuid,
depth: "standard",
questions: [
{ id: "q1", text: "...", category: "...", options: [...] },
...
]
})
Puis soumets les réponses en un appel :
answer_elaboration({
ideaUuid,
roundUuid,
answers: [
{ questionId: "q1", selectedOptionId: "...", customText: "<rationale>" },
...
]
})
7. Retourne le contrôle
Arrête-toi ici. NE APPELLE PAS chorus_pm_validate_elaboration. L'appelant /chorus-idea décide maintenant :
- Si les réponses du round synthétisé couvrent tout → l'appelant obtient la confirmation humaine, puis résout avec
chorus_pm_validate_elaboration. - Si des lacunes demeurent → l'appelant ouvre un Round 2 structuré en appelant
chorus_pm_start_elaborationà nouveau.
La profondeur de tout round de follow-up est le choix de l'appelant, pas le tien.
Spécification de synthèse
Chaque décision matérielle devient exactement une ElaborationQuestion avec ces champs :
| Champ | Source |
|---|---|
text |
La question décisionnelle, formulée neutralement. Exemple : « Quel placement de modèle de profondeur ? » |
category |
functional, non_functional, business_context, technical_context, user_scenario, ou scope — dérivée du sujet. |
options |
Toutes les directions qui ont été considérées, longueur 2-5. Collapse les quasi-duplicatas en une option. |
selectedOptionId |
L'id de l'option que l'utilisateur a approuvée. |
customText |
Une rationale de 1-3 phrases capturant la contrainte ou le tradeoff qui a mené au choix. Pas un vidage de transcript. |
Règles :
- Un
customTextplus long que ~3 phrases est un signe que tu résumes le transcript au lieu de capturer la rationale. Réduis. - Un tableau
optionsde longueur 2 avec un cadrage binaire « oui / non » est un signe que tu as pré-réduit les alternatives. Réexamine — il y a généralement au moins trois chemins significativement différents, même si deux d'entre eux se font rejeter rapidement. - Saute les « décisions » qui n'ont jamais été genuinely contestées. Si l'utilisateur a accepté instantanément la seule proposition, c'est une information pour le contenu de l'idée, pas un Q&A décisionnel.
Anti-patterns
Ne fais AUCUNE des choses suivantes. Chacun a un mode de défaillance spécifique que cette skill doit prévenir :
- Blob
customTextà résumé unique. Compresser la conversation entière en une ElaborationQuestion avec un long résumé markdown danscustomText. Le schéma est multi-questions pour une raison — préserve la granularité décisionnelle. - Transcript-as-comment. Poster le log de conversation brut comme commentaire sur l'idée (ou n'importe où). Le round synthétisé EST l'artefact. Les transcripts bruts polluent l'audit trail avec du bruit.
- Écritures de fichier. Écrire un markdown, design doc, plan ou scratch file sur disque. Il n'y a pas de design doc dans ce flux.
- Appels
validate_elaboration. Fermer la phase d'élaboration depuis cette skill. La décision du lifecycle appartient à la skill/chorus-idea. L'appeler ici prive l'appelant de son rôle de scheduler. - Handoff de design-doc. Invoquer une skill qui produit un plan d'implémentation ou un design document. Le pipeline Chorus a déjà Proposal → Document Drafts → Task Drafts pour cela — la sortie du brainstorm les alimente via ElaborationRound, pas via des skills de doc externes.
- Cadrages binaires « oui / non » de longueur 2. Réduire chaque décision à « faire cette chose — oui / non ». Presque toujours les alternatives genuines sont 3+ approches avec des tradeoffs significativement différents. Les cadrages de longueur 2 signifient souvent que la phase divergente s'est arrêtée trop tôt.
- Poser plusieurs questions à la fois. Le cadence est une question par tour durant la divergence, puis une seule question de convergence finale avec 2-3 options. Combiner des questions non-liées est un signe que tu te précipites.