brainstorm

Par chorus-aidlc · chorus

Dialogue optionnel divergent-puis-convergent pour les idées floues sur Hermes. Invoqué depuis la skill d'idée en prélude à l'élaboration structurée ; pose une question à la fois (en chat, ou sous forme de tours d'élaboration à question unique en l'absence d'humain dans le chat), produit un ElaborationRound de Q&R sur les points de décision et rend le contrôle. N'écrit jamais de fichiers, ne publie jamais de commentaires de résumé ou de transcript, ne résout jamais l'élaboration.

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

Skill Brainstorm

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

Ce skill est un producteur d'une elaboration round ; la décision du scheduler (résoudre vs. suivi) appartient au skill idea appelant.


Lors de l'invocation

Uniquement comme sous-étape du skill idea, seulement après que l'utilisateur ait explicitement opté (un oui à l'offre brainstorm, donné en chat ou en réponse au commentaire @mention du skill idea). Ne jamais s'exécuter seul, jamais sans opt-in utilisateur. Le point d'entrée attendu est la « Étape 4.5 : Mode Brainstorm (Prélude Optionnel) » du skill idea — chargez-la avec skill_view("chorus:idea") pour voir le flux environnant.


Comment une question brainstorm atteint l'humain

Chaque question dans ce skill est posée une à la fois, via l'un de deux canaux. Choisissez le canal de votre session :

  • Mode interactif — l'humain est en chat (une session Hermes CLI/TUI où l'humain vous tape) : posez la question directement en chat. Numérotez-la, listez les options avec des lettres (a, b, c…), marquez votre option recommandée, et attendez la réponse. Ne créez pas une elaboration round par question chat — la round synthétisée à l'étape 6 est la piste d'audit pour les brainstorms interactifs.

  • Mode gateway — Chorus vous a réveillé, ou aucun humain n'est en chat (un tour hermes gateway déclenché par une notification Chorus, dans la session clée idea:<ideaUuid>) : chaque question devient une unique elaboration round à question unique :

    1. chorus_pm_start_elaboration({ ideaUuid, depth: "minimal", questions: [ <exactement une question> ] }). Préfixez les ids de questions brainstorm avec bs (bs1, bs2, …) pour que les rounds soient reconnaissables à la reprise.
    2. Postez un seul commentaire pointeur sur l'Idea avec chorus_add_comment qui @mentionne le propriétaire (@[Name](user:<ownerUuid>), propriétaire du ## Checkin injecté par le plugin Chorus Hermes, ou chorus_checkin), p. ex. "@[Owner](user:<uuid>) La question brainstorm <n> attend dans le panneau elaboration : <question en une ligne>." Le commentaire ne pointe que sur la round ; il ne porte jamais de résumé ou de transcript.
    3. TERMINEZ LE TOUR. Ne faites pas de polling. Le gateway vous réveille (même session idea:<ideaUuid>) quand la round est répondue ou le propriétaire répond.
    4. À la réactivation, relisez chorus_get_elaboration({ ideaUuid }) pour récupérer les réponses jusqu'à présent (le contexte peut avoir été compressé), puis continuez avec la question unique suivante.

    Chaque tour gateway compte vers le plafond de 10 rounds de l'Idea, et l'appelant a toujours besoin de place pour une round structurée de suivi. Gardez les brainstorms gateway serrés : peu de questions divergentes, puis la question de convergence.

L'UI Chorus ajoute un "Autre" en texte libre à chaque question de round automatiquement — n'en ajoutez pas vous-même. En chat, l'humain peut toujours répondre en texte libre.


Limite de recherche

Réutilisez les résultats de l'Idea appelante et suivez les règles de recherche partagées (skill_view("chorus:research")); passer en brainstorm ne vous accorde pas une deuxième investigation. Si l'objectif avait besoin d'être affocalisé en premier, après que l'utilisateur sélectionne une direction et avant la synthèse, appliquez la décision de recherche optionnelle de l'appelant une fois avec cette focale. Retournez tout résultat aux côtés de la round synthétisée pour que l'appelant idea la persiste. La recherche ne choisit pas la direction de l'utilisateur, ne supprime pas la porte opt-in/sélection, n'écrit pas de fichiers/commentaires, ou ne résout pas l'elaboration.

Règles strictes

  1. Une question à la fois. Chaque message chat pose exactement une question ; en mode gateway chaque appel chorus_pm_start_elaboration contient exactement une entrée de question. Attendez la réponse avant de poser la suivante.
  2. Multi-choix préféré. Encadrez chaque question comme 2-4 options si possible. Open-ended est acceptable quand les options seraient prématurées, mais penchez vers des choix concrets. (Une question de round a toujours besoin de 2-5 options ; si vous avez vraiment besoin d'une question ouverte en mode gateway, donnez vos meilleures options devinées et laissez l'humain utiliser "Autre".)
  3. Proposez 2-3 directions avant d'arrêter la divergence. Une fois que la direction de requirement est assez claire pour énumérer, présentez 2-3 approches distinctes en une seule question (une question chat, ou une unique round à question unique). Marquez exactement une comme recommandée : en chat ajoutez (Recommandé) à cette option ; dans une round, ajoutez (Recommandé) au label de cette option et expliquez pourquoi dans sa description.
  4. Approbation utilisateur explicite requise pour quitter la divergence. NE PROCÉDEZ PAS à la synthèse tant que l'utilisateur n'a pas sélectionné une des directions proposées.
  5. Aucun fichier écrit. N'ÉCRIVEZ AUCUN markdown, doc de design, fichier scratch ou tout autre fichier sur disque. La conversation produit une ElaborationRound et rien d'autre sur disque.
  6. Aucun commentaire de résumé ou transcript. NE UTILISEZ PAS chorus_add_comment pour rien d'autre que le commentaire pointeur en mode gateway décrit ci-dessus (une courte @mention par round à question unique en attente). Les résumés, confirmations et discussions appartiennent au skill idea ou à l'utilisateur, pas à l'étape brainstorm.
  7. Aucun transfert de doc de design. NE INVOQUEZ AUCUN skill dont le but est de produire un document de design ou un plan d'implémentation. La sortie brainstorm est la round synthétisée — il n'y a pas de doc séparé.
  8. Aucun appel validate_elaboration. NE APPELEZ PAS chorus_pm_validate_elaboration depuis ce skill. Que la elaboration soit résolue ou qu'une round de suivi soit ouverte (chorus_pm_start_elaboration à nouveau) est la décision du skill idea appelant, pas celle de ce skill.
  9. Ne répondez jamais au nom de l'humain. Les questions divergentes et de convergence sont répondues par l'humain (en chat ou dans l'UI Chorus). Les seules réponses que vous soumettez vous-même sont la round synthétisée de l'étape 6, qui enregistre les décisions que l'humain a déjà prises.

Étape par étape

1. Rassembler le contexte

Avant de poser la première question divergente, lisez l'idea et l'état du projet environnant. Miroir la liste gather-context du skill idea :

chorus_get_idea({ ideaUuid })
chorus_get_documents({ projectUuid })
chorus_get_document({ documentUuid })   # pour tout document qui vaut 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 })

Parcouru chaque résultat en cherchant : le contexte énoncé, les requirements énoncées, les contraintes énoncées, et ce qui est conspicuement NON énoncé. Les lacunes sont les questions qui valent la peine d'être posées.

2. Q&R divergent

Posez une question à la fois via le canal choisi ci-dessus. Visez à faire surface :

  • L'objectif que l'idea essaie de servir (souvent plus abstrait que l'énoncé de l'idea).
  • Les contraintes qui excluent des branches entières de l'espace solution (deadlines, compatibilité, scope).
  • Les critères de succès — comment l'utilisateur saura que c'est fait.

Gardez chaque question à un seul but. Si vous avez besoin de poser trois choses, ce sont trois questions (trois tours chat, ou trois unique rounds à question unique), pas une question combinée.

Exemple interactif :

Question 1 — Quel est l'objectif principal derrière cette idea ?
  a) Réduire le temps d'onboarding des nouveaux utilisateurs (Recommandé — l'énoncé de l'idea penche de ce côté)
  b) Réduire la charge de support sur l'équipe
  c) Débloquer une demande client spécifique
Répondez avec une lettre, ou décrivez quelque chose d'autre.

Exemple gateway (une round, puis le commentaire pointeur, puis terminez le tour) :

chorus_pm_start_elaboration({
  ideaUuid,
  depth: "minimal",
  questions: [
    {
      id: "bs1",
      text: "Quel est l'objectif principal derrière cette idea ?",
      category: "business_context",
      options: [
        { id: "a", label: "Réduire le temps d'onboarding (Recommandé)", description: "L'énoncé de l'idea penche de ce côté" },
        { id: "b", label: "Réduire la charge de support" },
        { id: "c", label: "Débloquer une demande client spécifique" }
      ]
    }
  ]
})

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 une seule question de convergence.

Interactif :

Question <n> — <la question de convergence>
  a) Option A (Recommandé) — <quoi + tradeoff>
  b) Option B — <quoi + tradeoff>
  c) Option C — <quoi + tradeoff>
Pourquoi je recommande A : <une phrase sur le tradeoff dominant>.

Gateway (une unique round à question unique, puis le commentaire pointeur, puis terminez le tour) :

chorus_pm_start_elaboration({
  ideaUuid,
  depth: "minimal",
  questions: [
    {
      id: "bs<n>",
      text: "<la question de convergence>",
      category: "<catégorie dérivée>",
      options: [
        { id: "a", label: "Option A (Recommandé)", description: "<quoi + tradeoff>. Recommandé car <tradeoff dominant>." },
        { id: "b", label: "Option B", description: "<quoi + tradeoff>" },
        { id: "c", label: "Option C", description: "<quoi + tradeoff>" }
      ]
    }
  ]
})

La recommandation doit être visiblement marquée pour l'utilisateur. Énoncez pourquoi vous la recommandez — habituellement une phrase sur le tradeoff dominant.

4. Attendre l'approbation explicite

Ne procédez pas à la synthèse si l'utilisateur n'a pas sélectionné l'une des options. Si l'utilisateur choisit « Autre » (ou répond en texte libre), traitez cela comme une nouvelle contrainte — retournez à l'étape 2 ou 3 avec la direction affinée.

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

Pour chaque décision matérielle que l'utilisateur a prise durant la conversation, construisez une ElaborationQuestion. Une « décision matérielle » est un moment où l'utilisateur a choisi entre des alternatives ou a explicitement défini le scope. Mappez chaque décision selon la spécification de synthèse ci-dessous. En mode gateway, lisez les rounds répondues bs* avec chorus_get_elaboration comme votre source.

6. Persister la 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 appel (elles enregistrent les décisions propres de l'humain ; ce ne sont pas des réponses au nom de l'humain) :

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

7. Retourner le contrôle

Arrêtez ici. NE APPELEZ PAS chorus_pm_validate_elaboration. L'appelant du skill idea décide maintenant :

  • Si la round synthétisée répond à tout → l'appelant obtient la confirmation humaine, puis résout avec chorus_pm_validate_elaboration.
  • Si des lacunes restent → l'appelant ouvre une Round 2 structurée en appelant chorus_pm_start_elaboration à nouveau.

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


Spécification de synthèse

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

Champ Source
text La question de décision, énoncé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. Fusionnez les quasi-doublons 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 conduit le choix. Pas un vidage de transcript.

Règles :

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

Anti-motifs

Ne faites pas l'un des éléments suivants. Chacun a un mode d'échec spécifique que ce skill doit prévenir :

  • Blob customText résumé unique. Compresser l'ensemble de la conversation en une ElaborationQuestion avec un long résumé markdown en customText. Le schéma est multi-question pour une raison — préservez la granularité de décision.
  • Transcript-comme-commentaire. Poster le journal de conversation brut comme commentaire sur l'idea (ou n'importe où). La round synthétisée EST l'artefact. Les transcripts bruts polluent la piste d'audit avec du bruit. Le commentaire pointeur gateway est une ligne qui pointe sur une round en attente — rien de plus.
  • Écritures de fichiers. Écrire tout markdown, doc de design, plan ou fichier scratch sur disque. Il n'y a pas de doc de design dans ce flux. La sortie brainstorm est la round synthétisée, pas un document externe.
  • Appels validate_elaboration. Fermer la phase elaboration depuis ce skill. La décision de cycle de vie appartient au skill idea. L'appeler ici dépouille l'appelant de son rôle scheduler.
  • Transfert de doc de design. Invoquer tout skill qui produit un plan d'implémentation ou un document de design. Le pipeline Chorus a déjà Proposal → Document Drafts → Task Drafts pour cela — la sortie brainstorm les alimente via ElaborationRound, pas via des skills doc externes.
  • Encadrements binaires « oui / non » de longueur 2. Réduire chaque décision à « faire cette chose — oui / non ». Presque toujours les véritables alternatives sont 3+ approches avec des tradeoffs significativement différents. Les encadrements de longueur 2 signifient souvent que la phase divergente s'est terminée trop tôt.
  • Poser plusieurs questions à la fois. Le cadence est une question par tour durant la divergence (une question chat, ou une unique round à question unique), puis une question de convergence finale avec 2-3 options. Combiner des questions sans rapport en un message ou une round est un signe que vous vous précipitez.
  • Polling en mode gateway. Boucler sur chorus_get_elaboration attendant l'humain. Postez le commentaire pointeur et terminez le tour ; le gateway vous réveille.

Skills similaires