JZKK720/cubecloud-skilldbundle-setup

De l'idée au design

Transformez des idées en conceptions et spécifications complètes grâce à un dialogue naturel collaboratif.

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

Anti-modèle : « C'est trop simple pour avoir besoin d'un design »

Chaque projet passe par ce processus. Une liste de tâches, un utilitaire à une seule fonction, une modification de configuration — tous. Les projets « simples » sont ceux où des hypothèses non examinées causent le plus de travail gaspillé. La conception peut être courte (quelques phrases pour des projets vraiment simples), mais vous DEVEZ la présenter et obtenir l'approbation.

Liste de contrôle

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

1. Explorer le contexte du projet — vérifier les fichiers, la documentation, les commits récents
2. Poser des questions de clarification — une par une, comprendre le but, les contraintes et les critères de succès
3. Proposer 2-3 approches — avec leurs compromis et votre recommandation
4. Présenter la conception — en sections adaptées à leur complexité, obtenir l'approbation de l'utilisateur après chaque section
5. Rédiger le document de conception — enregistrer dans docs/superpowers/specs/YYYY-MM-DD-<sujet>-design.md et le versionner
6. Auto-relecture de la spécification — vérification rapide en ligne pour les espaces réservés, contradictions, ambiguïtés, périmètre
7. L'utilisateur révise la spécification écrite — demander à l'utilisateur de réviser le fichier de spécification avant de continuer
8. Transition vers l'implémentation — invoquer la compétence writing-plans pour créer un plan d'implémentation

Flux du processus

flowchart TD
    A[Explorer le contexte du projet] --> B[Poser des questions de clarification]
    B --> C[Proposer 2-3 approches]
    C --> D[Présenter les sections de conception]
    D --> E{L'utilisateur approuve la conception?}
    E -- non, réviser --> D
    E -- oui --> F[Rédiger le document de conception]
    F --> G[Auto-relecture de la spécification<br/>corriger en ligne]
    G --> H{L'utilisateur révise la spécification?}
    H -- modifications demandées --> F
    H -- approuvée --> I[Invoquer la compétence writing-plans]

L'état terminal est l'invocation de writing-plans. N'invoquez AUCUNE compétence d'implémentation. La SEULE compétence que vous invoquez après celle-ci est writing-plans.

Le processus

Comprendre l'idée :

• Vérifiez d'abord l'état actuel du projet (fichiers, documentation, commits récents)
• Avant de poser des questions détaillées, évaluez le périmètre : si la demande décrit plusieurs sous-systèmes indépendants (par ex. « construire une plateforme avec chat, stockage de fichiers, facturation et analytics »), signalez-le immédiatement. Ne passez pas de temps à affiner les détails d'un projet qui doit d'abord être décomposé.
• Si le projet est trop volumineux pour une seule spécification, aidez l'utilisateur à le décomposer en sous-projets : quelles sont les pièces indépendantes, comment elles se relient, dans quel ordre les construire ? Concevez ensuite le premier sous-projet selon le flux normal. Chaque sous-projet a son propre cycle spécification → plan → implémentation.
• Pour les projets de périmètre approprié, posez des questions une par une pour affiner l'idée
• Privilégiez les questions à choix multiples lorsque c'est possible, mais les questions ouvertes conviennent aussi
• Une seule question par message — si un sujet nécessite plus d'exploration, divisez-le en plusieurs questions
• Concentrez-vous sur la compréhension de : le but, les contraintes, les critères de succès

Explorer les approches :

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

Présenter la conception :

• Une fois que vous pensez avoir compris ce que vous construisez, présentez la conception
• Adaptez chaque section à sa complexité : quelques phrases si c'est simple, jusqu'à 200-300 mots si c'est nuancé
• Demandez après chaque section si cela semble correct jusqu'à présent
• Couvrez : architecture, composants, flux de données, gestion des erreurs, tests
• Soyez prêt à revenir en arrière et à clarifier si quelque chose n'a pas de sens

Concevoir pour l'isolement et la clarté :

• Divisez le système en unités plus petites qui ont chacune un objectif clair, communiquent via des interfaces bien définies, et peuvent être comprises et testées indépendamment
• Pour chaque unité, vous devez pouvoir répondre à : que fait-elle, comment l'utilise-t-on, et de quoi dépend-elle ?
• Quelqu'un peut-il comprendre ce qu'une unité fait sans lire ses internes ? Pouvez-vous changer les internes sans casser les consommateurs ? Si non, les limites doivent être retravaillées.
• Les unités plus petites et bien délimitées sont également plus faciles à manipuler pour vous — vous raisonnez mieux sur le code que vous pouvez garder en contexte à la fois, et vos modifications sont plus fiables lorsque les fichiers sont ciblés. Lorsqu'un fichier devient volumineux, c'est souvent le signe qu'il fait trop de choses.

Travailler dans des bases de code existantes :

• Explorez la structure actuelle avant de proposer des modifications. Suivez les schémas existants.
• Là où le code existant a des problèmes qui affectent le travail (par ex. un fichier devenu trop volumineux, des limites floues, des responsabilités emmêlées), incluez des améliorations ciblées dans le cadre de la conception — comme le ferait un bon développeur qui améliore le code dans lequel il travaille.
• Ne proposez pas de refactoring non lié. Restez concentré sur ce qui sert l'objectif actuel.

Après la conception

Documentation :

• Écrivez la conception validée (spécification) dans docs/superpowers/specs/YYYY-MM-DD-<sujet>-design.md
  • (Les préférences utilisateur concernant l'emplacement de la spécification remplacent cette valeur par défaut)
• Versionez le document de conception dans git

Auto-relecture de la spécification : Après avoir rédigé le document de spécification, examinez-le d'un œil neuf :

1. Recherche d'espaces réservés : Y a-t-il des « À DÉFINIR », « TODO », des sections incomplètes ou des exigences vagues ? Corrigez-les.
2. Cohérence interne : Des sections se contredisent-elles ? L'architecture correspond-elle aux descriptions des fonctionnalités ?
3. Vérification du périmètre : Est-ce suffisamment ciblé pour un seul plan d'implémentation, ou faut-il une décomposition ?
4. Vérification de l'ambiguïté : Une exigence pourrait-elle être interprétée de deux manières différentes ? Si oui, choisissez-en une et rendez-la explicite.

Corrigez les problèmes directement. Pas besoin de re-revoir — corrigez et passez à la suite.

Porte de révision par l'utilisateur : Une fois la boucle de relecture de la spécification terminée, demandez à l'utilisateur de réviser la spécification écrite avant de continuer :

« Spécification écrite et versionnée dans <chemin>. Veuillez la réviser et me faire savoir si vous souhaitez apporter des modifications avant que nous commencions à rédiger le plan d'implémentation. »

Attendez la réponse de l'utilisateur. S'il demande des modifications, apportez-les et relancez la boucle de relecture de la spécification. Ne continuez que lorsque l'utilisateur approuve.

Implémentation :

• Invoquez la compétence writing-plans pour créer un plan d'implémentation détaillé
• N'invoquez AUCUNE autre compétence. writing-plans est la prochaine étape.

Principes clés

• Une question à la fois — Ne submergez pas avec plusieurs questions
• Choix multiples privilégiés — Plus facile à répondre qu'une question ouverte quand c'est possible
• YAGNI impitoyablement — Supprimez les fonctionnalité inutiles de toutes les conceptions
• Explorez les alternatives — Proposez toujours 2-3 approches avant de vous fixer
• Validation incrémentale — Présentez la conception, obtenez l'approbation avant de continuer
• Soyez flexible — Revenez en arrière et clarifiez quand quelque chose n'a pas de sens

Ce qui a été supprimé du skill amont

Le skill « brainstorming » original (obra/superpowers) incluait une fonctionnalité « Visual Companion » : un serveur navigateur Node.js (scripts/server.cjs, scripts/start-server.sh, scripts/stop-server.sh) pour afficher des maquettes dans un onglet de navigateur pendant le brainstorming. SkillSpector a bloqué le skill pour abus de paramètres d'outil dans stop-server.sh.

Ce port supprime complètement Visual Companion. La méthodologie de base — dialogue de conception collaboratif, hard gate, auto-relecture de la spécification, porte de révision par l'utilisateur, transition vers writing-plans — est une pure guidance processuelle sans scripts, sans shells et sans serveur externe. Elle est sûre par construction.

Si vous avez besoin d'afficher des maquettes ou des diagrammes pendant une conversation de conception, utilisez les outils natifs de l'agent (les outils MCP navigateur, la génération d'images, ou les diagrammes Mermaid/ASCII en ligne dans le chat) plutôt qu'un serveur intégré.