chorus-brainstorm

Par chorus-aidlc · chorus

Dialogue optionnel divergent-puis-convergent pour les idées floues. Invoqué depuis le skill chorus-idea en prélude à l'élaboration structurée ; produit un ElaborationRound de Q&A autour des points de décision et rend le contrôle. N'écrit jamais de fichiers, ne poste jamais de commentaires, ne résout jamais l'élaboration.

npx skills add https://github.com/chorus-aidlc/chorus --skill chorus-brainstorm

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

  1. Une question à la fois. Chaque question interactive que tu poses DOIT être une seule question. Attends la réponse avant de poser la suivante.
  2. 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.
  3. 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.
  4. 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.
  5. Aucune écriture de fichier. NE ÉCRIS PAS de markdown, design doc, scratch file ou tout autre fichier sur disque. La conversation produit un ElaborationRound et rien d'autre sur disque.
  6. Aucun commentaire posté. NE APPELLE PAS chorus_add_comment depuis cette skill. Les commentaires appartiennent à la skill /chorus-idea ou à l'utilisateur, pas à l'étape brainstorm.
  7. 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é.
  8. Aucun appel validate_elaboration. NE APPELLE PAS chorus_pm_validate_elaboration depuis 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-idea appelante, 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 customText plus long que ~3 phrases est un signe que tu résumes le transcript au lieu de capturer la rationale. Réduis.
  • Un tableau options de 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 dans customText. 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.

Skills similaires