Compétence Brainstorm
Un cadre de dialogue divergent-puis-convergent pour les idées dont la direction est encore en cours de formation. Compresse la conversation en un seul ElaborationRound de Q&A à points 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 d'emblée.
Cette compétence est un producteur d'un elaboration round ; la décision du scheduler (valider vs. suivi) appartient à la compétence idea qui l'appelle.
Espace de noms des outils : Les outils Chorus sont exposés par le serveur MCP connecté sous un préfixe
chorus__sur OpenClaw (ex.chorus__chorus_get_idea). Les noms nus sont utilisés ci-dessous par souci de lisibilité — préfixez avecchorus__lors de l'invocation. Voir/choruspour la règle complète.
Modèle d'interaction OpenClaw : OpenClaw n'a pas de primitive
AskUserQuestion. Chaque étape « demander à l'utilisateur » ci-dessous est un prompt en texte brut — écrivez la question (et les options) dans votre message et attendez la réponse libre de l'utilisateur avant de continuer. Le cadre une-question-à-la-fois tient toujours : envoyez une question, lisez la réponse, puis envoyez la suivante.
Lors de l'invocation
Uniquement comme sous-étape de la compétence idea, uniquement après que l'utilisateur ait explicitement opté (via le prompt Brainstorm en texte brut de la compétence idea). Ne jamais s'exécuter seul, ne jamais s'exécuter sans l'accord de l'utilisateur. Le point d'entrée attendu est l'« Étape 4.5 : Mode Brainstorm (Prélude optionnel) » de la compétence idea — voir la compétence idea 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é. Structurez chaque question comme 2-4 options si possible (présentez-les sous forme de liste lettrée dans votre prompt en texte brut). 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 des exigences est assez claire pour pouvoir énumérer, présentez 2-3 approches distinctes dans un seul prompt. Marquez exactement une comme 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.
- Aucun fichier écrit. NE ÉCRIVEZ AUCUN markdown, doc de conception, fichier de brouillon ou tout autre fichier sur le disque. La conversation produit un
ElaborationRoundet rien d'autre sur le disque. - Aucun commentaire publié. NE APPELEZ PAS
chorus_add_commentdepuis cette compétence. Les commentaires appartiennent à la compétence idea ou à l'utilisateur, pas à l'étape brainstorm. - Aucun transfert de doc de conception. NE INVOQUEZ PAS
writing-plans,writing-skills, ou toute compétence dont le but est de produire un document de conception. La sortie du brainstorm est le round synthétisé — il n'y a pas de document séparé. - Aucun appel
validate_elaboration. NE APPELEZ PASchorus_pm_validate_elaborationdepuis cette compétence. Qu'il faille résoudre l'elaboration ou ouvrir un round de suivi (chorus_pm_start_elaborationà nouveau) est la décision de la compétence idea qui l'appelle, pas celle de cette compétence.
É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. Miroir la liste gather-context de la compétence 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 })
Parcourez rapidement chaque résultat pour : contexte déclaré, exigences déclarées, contraintes déclarées, et ce qui est manifestement NON déclaré. Les lacunes sont les questions qui valent la peine d'être posées.
2. Q&A divergente
Posez une question à la fois sous forme de prompt en texte brut. Visez à mettre en évidence :
- Le but que l'idée essaie de servir (souvent plus abstrait que la déclaration 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 fait.
Gardez chaque question à usage unique. Si vous avez besoin de poser trois choses, c'est trois prompts, pas un message combiné.
3. Proposer 2-3 directions
Quand le but, 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 prompt en texte brut :
Basé sur 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>.
Dites pourquoi vous recommandez une option — habituellement 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 cela comme une nouvelle contrainte — retournez à l'étape 2 ou l'étape 3 avec la direction affinée.
5. Synthétiser la Q&A des points de décision
Pour chaque décision matérielle que l'utilisateur a prise au cours de 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 ici. NE APPELEZ PAS chorus_pm_validate_elaboration. L'appelant de la compétence 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 restent → 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 manière neutre. Exemple : « Quel placement du modèle de profondeur ? » |
category |
functional, non_functional, business_context, technical_context, user_scenario, ou scope — dérivée du sujet. |
options |
Tous les sens qui ont été considérés, longueur 2-5. Regroupez les quasi-doublons en une seule 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 compromis qui a motivé le choix. Pas un vidage de transcription. |
Règles :
- Un
customTextplus long que ~3 phrases est un signe que vous résumez une transcription plutôt que de capturer la rationale. Coupez. - Un tableau
optionsde longueur 2 avec un cadrage binaire « oui / non » est un signe que vous avez pré-réduit les alternatives. Réexaminez — il y a habituellement au moins trois chemins significativement différents, même si deux d'entre eux sont rapidement rejetés. - Ignorez les « décisions » qui n'ont jamais été genuinement 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 une Q&A à point de décision.
Anti-motifs
Ne faites aucune des choses suivantes. Chacune a un mode d'échec spécifique que cette compétence doit prévenir :
- Blob
customTextrésumé unique. Compresser la conversation entière en une ElaborationQuestion avec un long résumé markdown danscustomText. Le schéma est multi-question pour une raison — préservez la granularité de la décision. - Transcription comme commentaire. Publier le journal de conversation brut comme commentaire sur l'idée (ou n'importe où). Le round synthétisé EST l'artefact. Les transcriptions brutes polluent l'audit trail avec du bruit.
- Écritures de fichiers. Écrire tout markdown, doc de conception, plan ou fichier de brouillon sur le disque. Il n'y a pas de doc de conception dans ce flux. C'est une divergence délibérée du cadre
superpowers/brainstormingen amont. - Appels
validate_elaboration. Fermer la phase d'elaboration depuis cette compétence. La décision du cycle de vie appartient à la compétence idea. L'appeler ici dépouille l'appelant de son rôle de scheduler. - Transfert
writing-plans/ doc de conception. Invoquer toute compétence qui produit un plan de mise en œuvre 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 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 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 dans un seul prompt. Le cadence est une question par tour pendant la divergence, puis un seul prompt de convergence final avec 2-3 options. Combiner des questions sans rapport est un signe que vous vous précipitez.