Skill Brainstorm

Un cadre dialogué divergent-puis-convergent pour les idées dont la direction est encore en formation. Compresse la conversation en un seul ElaborationRound de Q&A points de décision — 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 en amont.

Ce skill est un producteur d'un round d'élaboration ; la décision du scheduler (valider vs. suivi) appartient au skill d'idée appelant.

Namespace Tool: Les outils Chorus sont exposés par le serveur MCP connecté sous un préfixe mcp__chorus__ sur dsh (ex. mcp__chorus__chorus_get_idea). Les noms nus sont utilisés ci-dessous pour la lisibilité — préfixez mcp__chorus__ lors de l'invocation. Voir chorus pour la règle complète.

Modèle d'interaction dsh: en session interactive, utilisez ask_user_question pour le cadre une-question-à-la-fois. Quand CHORUS_DAEMON_HEADLESS=1, persistez les points de décision via un round d'élaboration Chorus et un commentaire @mention, puis terminez le tour.

À l'invocation

Uniquement comme sous-étape du skill d'idée, seulement après que l'utilisateur ait explicitement opté pour (via le prompt en texte brut Brainstorm du skill d'idée). Ne jamais exécuter seul, ne jamais exécuter sans opt-in utilisateur. Le point d'entrée attendu est « Étape 4.5 : Mode Brainstorm (Prélude Optionnel) » du skill d'idée — voir le skill d'idée pour le flux environnant.

Règles strictes

Une question à la fois. Chaque prompt DOIT contenir exactement une question. Attendez la réponse de l'utilisateur avant de poser la suivante.
Multi-choix préféré. Encadrez chaque question comme 2-4 options si possible. En dsh interactif, passez ces options à ask_user_question. L'approche ouverte est acceptable quand les options seraient prématurées, mais privilégiez les choix concrets.
Proposez 2-3 directions avant d'arrêter la divergence. Une fois que la direction du besoin est assez claire pour être énumérée, présentez 2-3 approches distinctes en un seul prompt. Marquez exactement une comme l'option recommandée et dites pourquoi (le compromis dominant).
L'approbation explicite de l'utilisateur est requise pour sortir de la divergence. Ne procédez PAS à la synthèse tant que l'utilisateur n'a pas sélectionné l'une des directions proposées dans sa réponse.
Aucune écriture de fichier. N'écrivez AUCUN markdown, doc de conception, fichier brouillon ou autre fichier sur le disque. La conversation produit un ElaborationRound et rien d'autre sur disque.
Aucun commentaire posté. N'appelez PAS chorus_add_comment depuis ce skill. Les commentaires appartiennent au skill d'idée ou à l'utilisateur, pas à l'étape brainstorm.
Aucun handoff de design-doc. N'invoquez PAS writing-plans, writing-skills ou tout skill dont le but est de produire un document de conception. La sortie brainstorm est le round synthétisé — il n'y a pas de doc séparé.
Aucun appel validate_elaboration. N'appelez PAS chorus_pm_validate_elaboration depuis ce skill. Que résoudre l'élaboration ou ouvrir un follow-up round (chorus_pm_start_elaboration de nouveau) est la décision du skill d'idée appelant, pas celle de ce skill.

Étape par étape

1. Recueillir le contexte

Avant de poser la première question divergente, lisez l'idée et l'état du projet environnant. Répliquez la liste gather-context du skill d'idée :

chorus_get_idea({ ideaUuid })
chorus_get_documents({ projectUuid })
chorus_get_document({ documentUuid })   # pour tout document valant la peine d'être lu intégralement
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 })

Parcourez rapidement chaque résultat pour : les antécédents énoncés, les exigences énoncées, les contraintes énoncées, et ce qui est notablement NON énoncé. Les lacunes sont les questions qui méritent d'être posées.

2. Q&A divergent

En dsh interactif, posez une question à la fois avec ask_user_question. En mode daemon-headless, persistez les points de décision actuels en tant que round d'élaboration, commentez avec un @mention, et terminez le tour. Visez à mettre en lumière :

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-t-il que c'est terminé.

Maintenez chaque question mono-objectif. Si vous devez poser trois choses, ce sont trois prompts, pas un message combiné.

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 question interactive, ou utilisez le handoff élaboration/commentaire headless :

Sur la base de ce que vous m'avez dit, voici trois directions. Laquelle voulez-vous ? (répondez A / B / C, ou décrivez la vôtre)

A) <Option A — RECOMMANDÉE> — <quoi + compromis>
B) <Option B> — <quoi + compromis>
C) <Option C> — <quoi + compromis>

Je recommande A parce que <une phrase sur le compromis dominant>.

Énoncez pourquoi vous recommandez une option — généralement une phrase sur le compromis dominant.

4. Attendez l'approbation explicite

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

5. Synthétiser le Q&A points 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 défini explicitement la portée. 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. N'appelez PAS chorus_pm_validate_elaboration. L'appelant du skill d'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 demeurent → l'appelant ouvre un Round 2 structuré avec chorus_pm_start_elaboration.

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 :

Champ	Source
`text`	La question de décision, formulée de façon neutre. Exemple : « Quel placement du modèle de profondeur ? »
`category`	`functional`, `non_functional`, `business_context`, `technical_context`, `user_scenario`, ou `scope` — dérivé du sujet.
`options`	Toutes les directions considérées, longueur 2-5. Collapser les quasi-doublons en une option.
`selectedOptionId`	L'id de l'option approuvée par l'utilisateur.
`customText`	Une rationale de 1-3 phrases capturant la contrainte ou le compromis qui a conduit le choix. Pas un dump 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 array options de longueur 2 avec cadrage binaire « oui / non » est un signe que vous avez pré-rétrécit les alternatives. Réexaminez — il y a généralement au moins trois chemins significativement différents, même si deux d'entre eux sont rejetés rapidement.
Omettez les « décisions » qui n'ont jamais été genuinely contestées. Si l'utilisateur a accepté instantanément la seule proposition, c'est de l'information pour le contenu de l'idée, pas un Q&A points de décision.

Anti-motifs

Ne faites aucune des choses suivantes. Chacun a un mode d'échec spécifique que ce skill doit prévenir :

Blob customText résumé unique. Compresser la conversation entière 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 log de conversation brut comme un 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 fichier. Écrire tout markdown, doc de conception, plan ou fichier brouillon sur disque. Il n'y a pas de doc de conception dans ce flux. C'est une divergence intentionnelle du cadence superpowers/brainstorming en amont.
Appels validate_elaboration. Fermer la phase d'élaboration depuis ce skill. La décision de cycle de vie appartient au skill d'idée. L'appeler ici prive l'appelant de son rôle de scheduler.
Handoff writing-plans / design-doc. Invoquer tout skill 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 brainstorm les alimente via ElaborationRound, pas via des skills doc externes.
Cadrages binaires « oui / non » de longueur 2. Réduire chaque décision à « faire cette chose — oui / non ». Presque toujours les véritables alternatives sont des approches 3+ avec des compromis significativement différents. Les cadrages de longueur 2 signifient souvent que la phase divergente s'est terminée trop tôt.
Poser plusieurs questions en un seul prompt. Le cadence est une question par tour pendant la divergence, puis un prompt de convergence final avec 2-3 options. Combiner des questions non liées est un signe que vous vous précipitez.

brainstorm-chorus