Compétence Brainstorm

Un cadence de dialogue divergent-puis-convergent pour les idées dont la direction est encore en formation. Compresse la conversation en un seul ElaborationRound de Q&R au point de décision — même structure qu'un elaboration round structuré, mais les questions, options et réponses sont synthétisées à la fin de la conversation plutôt que posées en amont.

Cette compétence est un producteur d'un elaboration round ; la décision du scheduler (résoudre ou suivi) appartient à la compétence idée appelante.

Lors de l'invocation

Uniquement en tant que sous-étape de la compétence idée, uniquement après que l'utilisateur ait explicitement opté via AskUserQuestion. Ne jamais exécuter en standalone, ne jamais exécuter sans opt-in de l'utilisateur. Le point d'entrée attendu est « Étape 4.5 : Mode Brainstorm (Prélude optionnel) » de la compétence idée — voir la compétence idée pour le flux environnant.

Règles strictes

1. Une question à la fois. Chaque appel AskUserQuestion DOIT contenir exactement une entrée question. Attendez la réponse avant de poser la suivante.
2. Multi-choix préféré. Formulez chaque question sous forme de 2-4 options si possible. Les questions ouvertes sont acceptables quand les options seraient prématurées, mais privilégiez les choix concrets.
3. Proposez 2-3 directions avant d'arrêter la divergence. Une fois que la direction de la requirement est assez claire pour être énumérée, présentez 2-3 approches distinctes dans un seul AskUserQuestion. Marquez exactement une comme option recommandée selon la convention de recommandation AskUserQuestion de l'outil hôte (la spec ne dicte pas un format de marquage spécifique — suivez la documentation de l'outil).
4. Approbation utilisateur explicite requise pour quitter la divergence. NE PAS procéder à la synthèse tant que l'utilisateur n'a pas sélectionné l'une des directions proposées.
5. Aucun fichier écrit. NE PAS écrire de markdown, document de conception, fichier scratch ou tout autre fichier sur disque. La conversation produit un ElaborationRound et rien d'autre sur disque.
6. Aucun commentaire posté. NE PAS appeler chorus_add_comment depuis cette compétence. Les commentaires appartiennent à la compétence idée ou à l'utilisateur, pas à l'étape brainstorm.
7. Aucun transfert de design-doc. NE PAS invoquer writing-plans, writing-skills ou toute compétence dont l'objectif est de produire un document de conception. La sortie du brainstorm est le round synthétisé — il n'y a pas de doc séparé.
8. Aucun appel validate_elaboration. NE PAS appeler chorus_pm_validate_elaboration depuis cette compétence. Le choix de résoudre l'elaboration ou d'ouvrir un round de suivi (chorus_pm_start_elaboration à nouveau) est la décision de la compétence idée appelante, pas celle-ci.

Étape par étape

1. Rassembler le contexte

Avant de poser la première question divergente, lisez l'idée et l'état du projet environnant. Reflétez la liste gather-context de la compétence idée :

chorus_get_idea({ ideaUuid })
chorus_get_documents({ projectUuid })
chorus_get_document({ documentUuid })   # pour tout document qui vaut la peine d'être lu intégralement
chorus_get_proposals({ projectUuid, status: "approved" })   # pour comprendre les patterns
chorus_list_tasks({ projectUuid })   # pour éviter de dupliquer le travail existant
chorus_get_comments({ targetType: "idea", targetUuid: ideaUuid })

Parcourez rapidement chaque résultat pour : contexte énoncé, requirements énoncées, contraintes énoncées, et ce qui n'est conspicuément PAS énoncé. Les lacunes sont les questions qui valent la peine d'être posées.

2. Q&R divergent

Posez une question à la fois via AskUserQuestion. Visez à surfacer :

• L'objectif 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 de solution (délais, compatibilité, portée).
• Les critères de succès — comment l'utilisateur saura que c'est terminé.

Gardez chaque question à un seul objectif. Si vous devez poser trois choses, ce sont trois rounds, pas une seule AskUserQuestion combinée.

3. Proposer 2-3 directions

Quand l'objectif, les contraintes et les critères de succès sont assez clairs pour que vous puissiez nommer des approches distinctes, présentez-les dans un seul AskUserQuestion :

AskUserQuestion({
  questions: [
    {
      question: "<la question de convergence>",
      header: "<en-tête court>",
      options: [
        { label: "Option A (Recommandée)", description: "<quoi + tradeoff>" },
        { label: "Option B", description: "<quoi + tradeoff>" },
        { label: "Option C", description: "<quoi + tradeoff>" }
      ],
      multiSelect: false
    }
  ]
})

La recommandation doit être visiblement marquée à l'utilisateur en utilisant la convention AskUserQuestion de l'outil hôte. Énoncez pourquoi vous la recommandez — généralement une phrase sur le tradeoff dominant.

4. Attendre l'approbation explicite

Ne pas procéder à la synthèse si l'utilisateur n'a pas sélectionné l'une des options. Si l'utilisateur choisit « Autre » avec du texte libre, traitez-le comme une nouvelle contrainte — retournez à l'étape 2 ou 3 avec la direction affinée.

5. Synthétiser la Q&R au point de décision

Pour chaque décision matérielle que l'utilisateur a prise pendant la conversation, construisez une ElaborationQuestion. Une « décision matérielle » est un moment où l'utilisateur a choisi entre des alternatives ou a défini la portée explicitement. Mappez chaque décision selon la spec de synthèse ci-dessous.

6. Persister le round

Appelez chorus_pm_start_elaboration avec les questions synthétisées :

chorus_pm_start_elaboration({
  ideaUuid,
  depth: "standard",
  questions: [
    { id: "q1", text: "...", category: "...", options: [...] },
    ...
  ]
})

Puis soumettez les réponses en un seul appel :

answer_elaboration({
  ideaUuid,
  roundUuid,
  answers: [
    { questionId: "q1", selectedOptionId: "...", customText: "<rationale>" },
    ...
  ]
})

7. Retourner le contrôle

Arrêtez-vous ici. NE PAS appeler chorus_pm_validate_elaboration. L'appelant de la compétence idée 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 restent → l'appelant ouvre un Round 2 structuré en appelant chorus_pm_start_elaboration à nouveau.

La profondeur de tout round de suivi est l'appel de l'appelant, pas le vôtre.

Spec de synthèse

Chaque décision matérielle devient exactement une ElaborationQuestion avec ces champs :

Règles :

• Un customText plus long que ~3 phrases est un signe que vous résumez un transcript au lieu de capturer la rationale. Coupez.
• Un tableau options de longueur 2 avec un cadrage binaire « oui / non » est un signe que vous avez pré-réduit les alternatives. Réexaminez — il y a généralement au moins trois chemins significativement différents, même si deux se font rapidement rejeter.
• Ignorez les « décisions » qui n'ont jamais été véritablement contestées. Si l'utilisateur a accepté instantanément la seule proposition, c'est une information pour le contenu de l'idée, pas une Q&R au point de décision.

Anti-patterns

Ne faites pas ce qui suit. Chacun a un mode d'échec spécifique que cette compétence 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-question pour une raison — préservez la granularité de décision.
• Transcript-comme-commentaire. Poster le log de conversation brut comme commentaire sur l'idée (ou ailleurs). Le round synthétisé EST l'artefact. Les transcripts bruts polluent la piste d'audit avec du bruit.
• Écritures de fichiers. Écrire tout markdown, document de conception, plan ou fichier scratch sur disque. Il n'y a pas de document de conception dans ce flux. C'est une divergence délibérée du cadence upstream superpowers/brainstorming — lisez design.md si vous êtes confus.
• Appels validate_elaboration. Fermer la phase d'elaboration depuis cette compétence. La décision du lifecycle appartient à la compétence idée. L'appeler ici prive l'appelant de son rôle de scheduler.
• writing-plans / transfert de design-doc. Invoquer toute compétence qui produit un plan d'implémentation ou un document de conception. Le pipeline Chorus a déjà Proposal → Document Drafts → Task Drafts pour cela — la sortie du brainstorm les alimente via ElaborationRound, pas via des compétences de doc externes.
• Cadrages binaires « oui / non » de longueur-2. Réduire chaque décision à « faire cette chose — oui / non ». Presque toujours les alternatives véritables sont 3+ approches avec des tradeoffs significativement différents. Les cadrages de longueur-2 signifient souvent que la phase divergente s'est terminée trop tôt.
• Poser plusieurs questions dans un seul AskUserQuestion. Le cadence est une question par tour pendant la divergence, puis une question de convergence finale avec 2-3 options. Combiner des questions non liées est un signe que vous vous précipitez.