think

Vue d’ensemble de la skill think

Ce que fait la skill think

think est une skill d’aide à la décision qui sert à transformer une idée floue en plan clair et validé avant quiconque n’écrive du code. Elle est particulièrement adaptée à la conception de fonctionnalités, aux choix d’architecture, à l’analyse des compromis et aux questions du type « faut-il le faire ? », quand le besoin principal est le jugement, pas l’implémentation.

Qui devrait l’installer

Installez la skill think si vous avez souvent besoin d’aide pour des décisions produit, une direction technique ou une planification cadrée dans un workflow centré sur le repo. Elle est surtout utile quand une demande commence par « planifie ça », « quelle est la meilleure approche », « doit-on garder ça ? » ou toute autre question de valeur ou d’arbitrage.

Ce qui la distingue

Cette skill a une ligne claire : elle pousse à formuler une recommandation concrète, indique ce qui pourrait faire changer cette recommandation et évite de partir trop tôt dans le code. Cela rend think for Decision Support plus puissant qu’un simple prompt de brainstorming lorsqu’il faut produire une réponse directement exploitable pour décider.

Comment utiliser la skill think

Installer et déclencher la skill

Installez-la avec npx skills add tw93/Waza --skill think. Ensuite, utilisez-la quand la tâche consiste à choisir, structurer ou valider une direction plutôt qu’à corriger un défaut connu. L’étape think install est simple, mais la qualité dépend du fait de lui donner un vrai contexte de décision.

Donner le bon format d’entrée

Un bon prompt think usage doit inclure l’objectif, les contraintes, le public cible et la décision réellement ouverte. Par exemple : « Nous avons besoin d’un onboarding plus rapide pour des administrateurs SMB ; nous pouvons changer l’UI uniquement, nous ne pouvons pas ajouter de travail backend ce sprint, et nous voulons une recommandation avec les compromis. »

Lire le bon fichier en premier

Commencez par SKILL.md, car le repo est volontairement minimal et ne contient ni dossiers rules/, ni references/, ni resources/. Les conseils pratiques principaux se trouvent dans le corps même de la skill : mode léger, mode d’évaluation, et règle de rester hors de l’implémentation tant que rien n’a été approuvé.

Utiliser le workflow comme un entonnoir de décision

Un bon flux think guide suit cette logique : formuler la décision, lister les contraintes, demander la meilleure voie, puis ne demander un plan avec risques et alternatives que si c’est nécessaire. Si vous hésitez entre le mode léger et le mode complet, précisez si le problème est déjà bien défini ; ce seul détail change fortement la sortie.

FAQ sur la skill think

La skill think sert-elle seulement aux nouvelles fonctionnalités ?

Non. Elle est aussi utile pour les décisions d’architecture, les arbitrages produit, les refontes avec de vrais compromis et les questions du type « est-ce que ça vaut le coup ? ». En revanche, ce n’est pas le meilleur choix pour des corrections de bugs simples ou des retouches minimes dont la réponse est déjà évidente.

En quoi est-ce différent d’un prompt classique ?

Un prompt classique produit souvent des options floues. La skill think est conçue pour forcer une décision : une voie recommandée, des compromis explicites et une frontière nette contre le codage avant approbation. Elle est donc plus adaptée lorsqu’il faut un plan qui puisse être relu par un collègue ou un décideur.

La skill think est-elle adaptée aux débutants ?

Oui, si la personne peut décrire l’objectif en langage simple. Les débutants en tirent le plus de valeur lorsqu’ils donnent le problème, les contraintes et le résultat souhaité, même sans connaître les termes techniques.

Quand ne faut-il pas utiliser think ?

Ne l’utilisez pas si vous connaissez déjà la correction et que vous avez seulement besoin d’exécuter, ou si la tâche est assez ciblée pour qu’une modification directe soit plus rapide qu’une analyse. Elle apporte aussi moins de valeur s’il n’y a pas de vraie décision à prendre et qu’il suffit d’une réécriture rapide.

Comment améliorer la skill think

Donner un contexte digne d’une vraie décision

Les meilleurs inputs pour think skill incluent l’état actuel, l’état cible, les contraintes non négociables et la définition du succès. Par exemple, « Nous devons réduire le temps de configuration de 10 minutes à 2 minutes, conserver le backend actuel et éviter toute nouvelle dépendance » donne de meilleurs conseils que « améliorer l’onboarding ».

Demander une décision, pas seulement des idées

Si vous voulez un meilleur think usage, demandez une recommandation argumentée, pas une liste de possibilités. Bon : « Choisis une approche et explique pourquoi elle l’emporte dans ces contraintes. » Faible : « Donne-moi quelques idées. »

Rendre visibles les compromis qui comptent

Indiquez ce qui est prioritaire : vitesse, maintenabilité, coût, UX, risque ou capacité de l’équipe. Cela aide think for Decision Support à produire un plan aligné sur vos priorités plutôt qu’une réponse générique fondée sur les bonnes pratiques.

Itérer avec des contraintes plus nettes

Si le premier résultat reste trop large, resserrez-le avec un seul suivi : ajoutez une échéance, une dépendance interdite, un utilisateur cible ou un composant à conserver absolument. Le moyen le plus rapide d’améliorer la sortie consiste à transformer les hypothèses implicites en contraintes explicites avant de demander le plan suivant.