Utiliser OBLIGATOIREMENT avant tout travail créatif — création de fonctionnalités, composants, ou modification de comportement. Explore l'intention utilisateur, les exigences et le design via un dialogue collaboratif avant toute implémentation.
Transformer une idée en design doc validé via un dialogue collaboratif structuré. Comprendre le contexte projet, poser des questions une par une via AskUserQuestion, puis présenter le design pour approbation.
Annoncer au démarrage : "J'utilise le skill brainstorming pour transformer votre idée en design doc."
<HARD-GATE> Ne PAS invoquer de skill d'implémentation, écrire de code, ou scaffolder de projet tant que le design n'est pas présenté ET approuvé par l'utilisateur. Ceci s'applique à TOUT projet, même les plus simples. </HARD-GATE>Tout projet passe par ce processus. Une todo list, un utilitaire, un changement 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), mais il DOIT être présenté et approuvé.
Le template du design doc se trouve dans references/template-design-doc.md. Le lire avant de rédiger le design doc.
AskUserQuestion, une par uneAskUserQuestionAskUserQuestion après chaque sectionreferences/template-design-doc.md, sauvegarder et committerspecs-writing ou writing-plansPoser des questions via AskUserQuestion pour comprendre :
Règles :
AskUserQuestionProposer 2-3 approches différentes via AskUserQuestion :
Présenter section par section, valider chaque section via AskUserQuestion :
Chaque section est dimensionnée à sa complexité (quelques phrases si simple, 200-300 mots si nuancé). Pour chaque refus, ajuster et re-présenter.
references/template-design-doc.mddocs/plans/YYYY-MM-DD-<sujet>-design.mdProposer la suite via AskUserQuestion :
specs-writing (PRD, user stories, features.json)writing-plans (si les specs ne sont pas nécessaires)Ne PAS invoquer d'autre skill. Seuls specs-writing ou writing-plans sont des transitions valides.