Trouvez Vos Inconnues
Aperçu
L'écart entre la description de la tâche par l'utilisateur (son prompt, son contexte, ses références) et le travail réel (la base de code, ses contraintes, la réalité) est l'endroit où vivent les inconnues. Lorsque l'agent rencontre une inconnue, il devine l'intention de l'utilisateur. Le rôle de cette compétence est d'éliminer les suppositions : aider l'utilisateur à découvrir et nommer ses inconnues avant, pendant et après l'implémentation, de manière itérative – et non comme un plan unique préétabli.
C'est une boîte à outils, pas un pipeline fixe. Diagnostiquez d'abord, puis n'appliquez que les techniques qui correspondent. Ne les exécutez pas toutes sur une tâche triviale.
Les Quatre Inconnues
Classez ce qui manque avant de choisir une technique :
- Connues connues – déjà énoncées dans le prompt.
- Inconnues connues – l'utilisateur sait qu'il n'a pas encore décidé cela.
- Connues inconnues – trop évidentes pour être écrites, mais l'utilisateur les reconnaît au premier coup d'œil (souvent goût visuel/UX).
- Inconnues inconnues – jamais envisagées ; l'utilisateur ne sait pas ce qu'il ignore.
Étape 0 – Diagnostiquer
Avant de faire quoi que ce soit, décidez quelles inconnues dominent et choisissez les techniques en conséquence :
- Domaine inconnu ou coin inconnu de la base de code → Analyse des angles morts (inconnues inconnues).
- Difficile à décrire, « Je le reconnaîtrai quand je le verrai » → Prototype (connues inconnues).
- Direction claire, détails flous → Interviewer l'utilisateur + Rédiger un plan (inconnues connues).
Donnez toujours du contexte sur qui est l'utilisateur et ce qu'il sait déjà – cela affine chaque technique ci-dessous.
Passer à d'Autres Compétences
Utilisez cette compétence comme couche de découverte, pas comme l'ensemble du flux de travail. Après avoir nommé les inconnues, choisissez la plus petite compétence de suivi qui résout l'incertitude suivante.
| Inconnue ou prochain besoin | Passer à | Utiliser quand |
|---|---|---|
| L'utilisateur n'a pas pleinement exprimé son intention | interview-me | Poser une question à la fois jusqu'à ce que le besoin sous-jacent soit clair. |
| Le plan doit être testé sous pression | grill-me ou grill-with-docs | Tester les hypothèses ; utiliser la variante avec docs lorsque des ADR ou des mises à jour de glossaire doivent être capturées. |
| Des faits externes manquent | research ou source-driven-development | Rassembler des preuves de sources primaires avant de décider. |
| L'utilisateur le reconnaîtra quand il le verra | prototype | Montrer des options concrètes avec de fausses données avant de s'engager dans l'implémentation. |
| Le travail nécessite un cahier des charges formel | spec-driven-development | Convertir les contraintes et décisions découvertes en un PRD/cahier des charges. |
| Le travail est trop vaste pour être exécuté directement | planning-and-task-breakdown ou writing-plans | Décomposer le cahier des charges aligné en tranches ordonnées et vérifiables. |
| Les limites des interfaces sont floues | api-and-interface-design ou design-an-interface | Décider des contrats d'API, de module ou de type. |
| La forme de la base de code est l'incertitude | codebase-design ou improve-codebase-architecture | Trouver la bonne limite de module, abstraction ou direction de refactorisation. |
| Le comportement UI ou la qualité visuelle est incertain | frontend-ui-engineering | Transformer les prototypes ou préférences choisis en travail UI de production. |
| Un bug est présent mais la cause est floue | systematic-debugging ou diagnosing-bugs | Reproduire, isoler, hypothéser, instrumenter et corriger. |
| L'implémentation couvre des tâches indépendantes | subagent-driven-development ou dispatching-parallel-agents | Diviser le travail uniquement lorsque les tâches ne partagent pas d'état ou de dépendances séquentielles. |
| Le travail semble terminé | verification-before-completion, requesting-code-review ou code-review | Vérifier les preuves, puis réviser avant de déclarer la tâche terminée ou de fusionner. |
Avant de passer la main, résumez :
- Ce qui est connu maintenant.
- Ce qui reste inconnu.
- Quelle décision changerait l'implémentation.
- Quel artefact doit être transmis : prototype, cahier des charges, notes d'implémentation ou rapport d'acceptation.
Techniques par Phase
Chaque technique a un déclencheur et un template de prompt prêt à envoyer. Adaptez les parties entre crochets.
Explorer (trouver les inconnues)
1. Analyse des angles morts – premier mouvement dans un domaine inconnu.
Je suis en train d'ajouter [X] mais je connais à peine le module [Y] dans cette base de code. Fais une passe d'analyse des angles morts — trouve mes « inconnues inconnues » et explique-les, pour que je puisse t'écrire un meilleur prompt.
2. Prototype – quand ça ne peut pas être décrit, montrez-le. Utilisez de fausses données, pas de backend.
Avant de toucher l'application réelle, crée un fichier HTML qui simule [l'interface] avec de fausses données. Donne-moi 4 directions de design complètement différentes pour que je puisse voir laquelle semble juste.
3. Interviewer l'utilisateur – extrayez les points flous restants.
Pose-moi une question à la fois. Cible les zones ambiguës, et priorise les questions dont la réponse changerait l'architecture.
Planifier (aligner l'intention)
4. Montrer une référence – la meilleure référence est du code source, pas une capture d'écran.
[chemin / bibliothèque] implémente le [comportement] que je veux. Lis-le, puis réimplémente la même sémantique dans [notre stack].
5. Rédiger un plan – mettez en surface les décisions les plus susceptibles de changer, en premier.
Écris un plan d'implémentation HTML, mais mets en haut les décisions que je suis le plus susceptible d'ajuster : changements du modèle de données, nouvelles interfaces de type, tout ce qui est visible par l'utilisateur. Mets les refactorisations mécaniques en dernier – je te fais confiance là-dessus.
Implémenter (capturer les inconnues qui émergent en cours de travail)
6. Notes au fur et à mesure – démarrez une nouvelle session, injectez le cahier des charges/prototype, puis :
Maintiens un fichier implementation-notes.md. Si un cas particulier te force à t'écarter du plan, choisis l'option conservatrice, enregistre-la sous une section « Déviations », et continue.
Livrer (aligner les autres, vérifier que vous avez compris)
7. Explicatif de transfert
Empaquète le prototype, le cahier des charges et les notes d'implémentation dans un seul document que je peux déposer dans le chat pour validation. Mets un GIF de démonstration en haut.
8. Quiz d'acceptation – la règle stricte de l'auteur : le réussir avant de fusionner.
Je veux être sûr de bien comprendre ce changement. Crée un rapport HTML avec le contexte du changement, l'intuition, et ce qui a été fait – puis un quiz en bas que je dois réussir.
Règles de Fonctionnement
- Chaque fois que vous êtes sur le point de deviner l'intention de l'utilisateur, arrêtez-vous et appliquez la technique correspondante à la place.
- Enchaînez les artefacts : prototype → cahier des charges → notes d'implémentation → rapport d'acceptation ; chacun est l'entrée du suivant, de sorte qu'une nouvelle session ne perde pas le contexte.
- Pour une petite tâche,
analyse des angles morts + rédiger un plan + quiz d'acceptationcapture déjà l'essentiel de la valeur. Ne faites pas trop de choses.