Transformer les Idées en Designs

Aidez à transformer les idées en designs et specs entièrement formés par le biais d'un dialogue collaboratif naturel.

Commencez par comprendre le contexte du projet actuel, puis posez les questions une par une pour affiner l'idée. Une fois que vous comprenez ce que vous construisez, présentez le design et obtenez l'approbation de l'utilisateur.

N'INVOQUEZ AUCUNE skill d'implémentation, n'écrivez AUCUN code, ne générez AUCUN scaffold de projet, et ne prenez AUCUNE action d'implémentation avant d'avoir présenté un design et que l'utilisateur l'ait approuvé. Cela s'applique à TOUS les projets, indépendamment de leur apparente simplicité.

Anti-Motif : « C'est Trop Simple Pour Avoir Besoin d'un Design »

Tous les projets passent par ce processus. Une liste de tâches, un utilitaire à une seule fonction, une modification de config — tous. Les projets « simples » sont ceux où les hypothèses non examinées causent le plus de travail perdu. Le design peut être court (quelques phrases pour les projets vraiment simples), mais vous DEVEZ le présenter et obtenir l'approbation.

Checklist

Vous DEVEZ créer une tâche pour chacun de ces éléments et les compléter dans l'ordre :

Explorer le contexte du projet — vérifier les fichiers, les docs, les commits récents
Offrir un compagnon visuel (si le sujet impliquera des questions visuelles) — c'est son propre message, non combiné avec une question clarifiante. Voir la section Compagnon Visuel ci-dessous.
Poser des questions clarifiantes — une par une, comprendre l'objectif/les contraintes/les critères de succès
Proposer 2-3 approches — avec les compromis et votre recommandation
Présenter le design — en sections proportionnées à leur complexité, obtenir l'approbation de l'utilisateur après chaque section
Écrire le document de design — enregistrer dans docs/superpowers/specs/YYYY-MM-DD--design.md et committer
Boucle d'examen des specs — dispatcher le subagent spec-document-reviewer avec un contexte d'examen précisément élaboré (jamais votre historique de session) ; corriger les problèmes et re-dispatcher jusqu'à approbation (max 3 itérations, puis remonter à l'humain)
L'utilisateur examine la spec écrite — demander à l'utilisateur d'examiner le fichier de spec avant de procéder
Transition vers l'implémentation — invoquer la skill writing-plans pour créer un plan d'implémentation

Flux de Processus

digraph brainstorming {
"Explorer le contexte du projet" [shape=box];
"Questions visuelles à venir ?" [shape=diamond];
"Offrir Compagnon Visuel\n(message propre, aucun autre contenu)" [shape=box];
"Poser des questions clarifiantes" [shape=box];
"Proposer 2-3 approches" [shape=box];
"Présenter sections du design" [shape=box];
"L'utilisateur approuve le design ?" [shape=diamond];
"Écrire le document de design" [shape=box];
"Boucle d'examen des specs" [shape=box];
"L'examen des specs est passé ?" [shape=diamond];
"L'utilisateur examine la spec ?" [shape=diamond];
"Invoquer la skill writing-plans" [shape=doublecircle];
"Explorer le contexte du projet" -> "Questions visuelles à venir ?";
"Questions visuelles à venir ?" -> "Offrir Compagnon Visuel\n(message propre, aucun autre contenu)" [label="oui"];
"Questions visuelles à venir ?" -> "Poser des questions clarifiantes" [label="non"];
"Offrir Compagnon Visuel\n(message propre, aucun autre contenu)" -> "Poser des questions clarifiantes";
"Poser des questions clarifiantes" -> "Proposer 2-3 approches";
"Proposer 2-3 approches" -> "Présenter sections du design";
"Présenter sections du design" -> "L'utilisateur approuve le design ?";
"L'utilisateur approuve le design ?" -> "Présenter sections du design" [label="non, réviser"];
"L'utilisateur approuve le design ?" -> "Écrire le document de design" [label="oui"];
"Écrire le document de design" -> "Boucle d'examen des specs";
"Boucle d'examen des specs" -> "L'examen des specs est passé ?";
"L'examen des specs est passé ?" -> "Boucle d'examen des specs" [label="problèmes trouvés,\ncorriger et re-dispatcher"];
"L'examen des specs est passé ?" -> "L'utilisateur examine la spec ?" [label="approuvé"];
"L'utilisateur examine la spec ?" -> "Écrire le document de design" [label="changements demandés"];
"L'utilisateur examine la spec ?" -> "Invoquer la skill writing-plans" [label="approuvé"];
}

L'état terminal est l'invocation de writing-plans. N'INVOQUEZ PAS frontend-design, mcp-builder, ou toute autre skill d'implémentation. La SEULE skill que vous invoquez après brainstorming est writing-plans.

Le Processus

Comprendre l'idée :

Vérifiez d'abord l'état actuel du projet (fichiers, docs, commits récents)
Avant de poser des questions détaillées, évaluez l'envergure : si la demande décrit plusieurs sous-systèmes indépendants (p. ex., « construire une plateforme avec chat, stockage de fichiers, facturation et analytique »), signalez cela immédiatement. Ne perdez pas de questions à affiner les détails d'un projet qui doit d'abord être décomposé.
Si le projet est trop volumineux pour une seule spec, aidez l'utilisateur à le décomposer en sous-projets : quelles sont les pièces indépendantes, comment sont-elles liées, dans quel ordre doivent-elles être construites ? Ensuite, brainstormez le premier sous-projet selon le flux de design normal. Chaque sous-projet obtient son propre cycle spec → plan → implémentation.
Pour les projets d'envergure appropriée, posez des questions une par une pour affiner l'idée
Préférez les questions à choix multiples quand c'est possible, mais l'ouvert est aussi acceptable
Une seule question par message - si un sujet nécessite plus d'exploration, divisez-le en plusieurs questions
Concentrez-vous sur la compréhension : objectif, contraintes, critères de succès

Explorer les approches :

Proposez 2-3 approches différentes avec les compromis
Présentez les options de manière conversationnelle avec votre recommandation et votre raisonnement
Commencez par votre option recommandée et expliquez pourquoi

Présenter le design :

Une fois que vous croyez comprendre ce que vous construisez, présentez le design
Adaptez chaque section à sa complexité : quelques phrases si simple, jusqu'à 200-300 mots si nuancé
Demandez après chaque section si cela semble correct jusque-là
Couvrez : architecture, composants, flux de données, gestion d'erreurs, tests
Soyez prêt à revenir en arrière et clarifier si quelque chose n'a pas de sens

Design pour l'isolation et la clarté :

Divisez le système en unités plus petites qui ont chacune un objectif clair, communiquent par des interfaces bien définies, et peuvent être comprises et testées indépendamment
Pour chaque unité, vous devriez pouvoir répondre : qu'est-ce qu'elle fait, comment l'utilise-t-on, et de quoi dépend-elle ?
Quelqu'un peut-il comprendre ce qu'une unité fait sans lire ses internals ? Pouvez-vous changer les internals sans casser les consommateurs ? Si non, les limites ont besoin de travail.
Des unités plus petites et bien délimitées sont aussi plus faciles à gérer — vous raisonnez mieux sur le code que vous pouvez tenir en contexte à la fois, et vos modifications sont plus fiables quand les fichiers sont concentrés. Quand un fichier devient grand, c'est souvent un signal qu'il en fait trop.

Travailler dans des codebases existantes :

Explorez la structure actuelle avant de proposer des changements. Suivez les motifs existants.
Où le code existant a des problèmes qui affectent le travail (p. ex., un fichier devenu trop grand, des limites peu claires, des responsabilités enchevêtrées), incluez des améliorations ciblées dans le design — comme le ferait un bon développeur en améliorant le code qu'il travaille.
Ne proposez pas de refactoring non lié. Restez concentré sur ce qui sert l'objectif actuel.

Après le Design

Documentation :

Écrivez le design validé (spec) dans docs/superpowers/specs/YYYY-MM-DD--design.md
(Les préférences de l'utilisateur pour l'emplacement des specs remplacent ce défaut)
Utilisez la skill elements-of-style:writing-clearly-and-concisely si disponible
Committez le document de design à git

Boucle d'Examen des Specs :

Après avoir écrit le document de spec :

Dispatcher le subagent spec-document-reviewer (voir spec-document-reviewer-prompt.md)
Si Problèmes Trouvés : corriger, re-dispatcher, répéter jusqu'à Approbation
Si la boucle dépasse 3 itérations, remonter à l'humain pour orientation

Gate d'Examen Utilisateur :

Après que la boucle d'examen des specs soit passée, demandez à l'utilisateur d'examiner la spec écrite avant de procéder :

« Spec écrite et committée à docs/superpowers/specs/. Veuillez l'examiner et me dire si vous voulez apporter des changements avant de commencer à écrire le plan d'implémentation. »

Attendez la réponse de l'utilisateur. S'il demande des changements, apportez-les et re-lancez la boucle d'examen des specs. Procédez seulement une fois que l'utilisateur approuve.

Implémentation :

Invoquez la skill writing-plans pour créer un plan d'implémentation détaillé
N'INVOQUEZ AUCUNE autre skill. writing-plans est l'étape suivante.

Principes Clés

Une question à la fois - Ne submergez pas avec plusieurs questions
Choix multiples de préférence - Plus facile à répondre que l'ouvert quand c'est possible
YAGNI impitoyablement - Supprimez les fonctionnalités inutiles de tous les designs
Explorez les alternatives - Proposez toujours 2-3 approches avant de vous décider
Validation incrémentale - Présentez le design, obtenez l'approbation avant de continuer
Soyez flexible - Revenez en arrière et clarifiez quand quelque chose n'a pas de sens

Compagnon Visuel

Un compagnon basé sur navigateur pour afficher des mockups, des diagrammes et des options visuelles pendant le brainstorming. Disponible comme outil — non comme mode. Accepter le compagnon signifie qu'il est disponible pour les questions qui bénéficient d'un traitement visuel ; cela ne signifie PAS que chaque question passe par le navigateur.

Offrir le compagnon : Quand vous anticipez que les questions à venir impliqueront du contenu visuel (mockups, mises en page, diagrammes), offrez-le une fois pour consentement :

« Certaines choses sur lesquelles nous travaillons pourraient être plus faciles à expliquer si je peux vous les montrer dans un navigateur web. Je peux préparer des mockups, des diagrammes, des comparaisons et d'autres visuels au fur et à mesure. Cette fonctionnalité est encore nouvelle et peut être gourmande en tokens. Voulez-vous l'essayer ? (Nécessite d'ouvrir une URL locale) »

Cette offre DOIT être son propre message. Ne la combinez pas avec des questions clarifiantes, des résumés de contexte, ou tout autre contenu. Le message doit contenir UNIQUEMENT l'offre ci-dessus et rien d'autre. Attendez la réponse de l'utilisateur avant de continuer. S'il décline, procédez avec le brainstorming en text-only.

Décision par question : Même après que l'utilisateur accepte, décidez POUR CHAQUE QUESTION si vous utilisez le navigateur ou le terminal. Le test : l'utilisateur comprendrait-il cela mieux en le voyant qu'en le lisant ?

Utilisez le navigateur pour le contenu qui EST visuel — mockups, wireframes, comparaisons de mises en page, diagrammes d'architecture, designs visuels côte à côte
Utilisez le terminal pour le contenu qui est texte — questions de requirements, choix conceptuels, listes de compromis, options texte A/B/C/D, décisions d'envergure

Une question sur un sujet UI n'est pas automatiquement une question visuelle. « Que signifie la personnalité dans ce contexte ? » est une question conceptuelle — utilisez le terminal. « Quelle mise en page d'assistant fonctionne mieux ? » est une question visuelle — utilisez le navigateur.

S'ils acceptent le compagnon, lisez le guide détaillé avant de continuer :

skills/brainstorming/visual-companion.md