scout

/scout — Où vais-je réellement et comment y arriver ?

Vous avez un problème ou une idée, et l'état honnête est que vous ne savez pas comment le traiter. Pas "laquelle des trois approches" — vous ne voyez pas encore assez bien la destination pour avoir trois approches. Tout le reste de cette collection suppose qu'une cible existe déjà. Celui-ci va la trouver.

Le travail consiste à examiner le terrain, puis choisir l'itinéraire — pas à foncer vers la destination, ni à commencer à construire la première chose qui semble constructible.

Ce que ce n'est PAS — pour que vous invoquiez la bonne compétence :

• Pas grill-me — celle-ci vous interviewe sur un plan que vous avez déjà, en parcourant un arbre de décision en profondeur d'abord. Celle-ci s'exécute avant qu'un plan n'existe et va délibérément en largeur d'abord. Quand scout se termine, grill-me est une prochaine étape raisonnable.
• Pas explain — celle-ci cartographie du code qui existe déjà. Celle-ci cartographie du travail qui n'existe pas.
• Pas root-cause — celle-ci est pour un élément cassé avec un symptôme connu. Utilisez-la d'abord si quelque chose échoue ; explorez la réponse à cela ensuite, si la correction n'est pas évidente.
• Pas validate-plan / ship-check — celles-ci jugent un plan et une différence. scout s'exécute en amont des deux et produit la chose qu'elles jugent.

La porte de retenue — lisez d'abord. Le mode d'échec est la fabrication d'un voyage. Si le premier passage montre que vous pouvez déjà énoncer la destination et les étapes pour y arriver, dites-le et arrêtez-vous : "ceci n'a pas besoin de reconnaissance — voici le plan, allez-y." La plupart des problèmes sont comme ça. La cérémonie sur un chemin clair est un pur coût. De même, si vous avez utilisé cette compétence plutôt que l'utilisateur tapant /scout, confirmez avant de commencer — un interrogatoire non sollicité de vingt questions est une mauvaise surprise.

Les passes

1. Nommer la destination — avant toute autre question

Demandez à quoi ressemble terminé, et réduisez-le à une ou deux lignes. Cela peut être une décision verrouillée, une spécification à transmettre, une migration terminée sur place, une fonctionnalité fonctionnant de bout en bout. Des destinations différentes produisent des itinéraires complètement différents, donc ceci est réglé en premier et jamais supposé.

La destination fixe le périmètre — chaque question ci-dessous est mesurée par rapport à elle. Si l'utilisateur ne peut pas encore la nommer, c'est la première chose à travailler, et rien d'autre ne commence avant qu'elle ne soit nommée.

2. Déployer — en largeur d'abord, et résistez à répondre

Balayez tout l'espace entre ici et la destination et collectez les questions ouvertes. Ne les résolvez pas encore. La tentation de répondre immédiatement à la première question est ce que cette passe existe pour vaincre : la première question que vous remarquez est rarement celle qui décide de la forme, et y répondre tôt signifie planifier la mauvaise chose très soigneusement.

Allez en largeur, pas en profondeur. Visez à faire émerger la question que vous ne saviez pas qu'elle était là.

Les faits, vous les recherchez ; les décisions, vous les demandez. Si quelque chose est vérifiable — le schéma, les appelants, les données réelles, la documentation de la bibliothèque, ce que le code fait aujourd'hui — allez le vérifier, ne posez pas de question dessus. Seules les véritables décisions vont à l'utilisateur.

3. Trier en trois catégories

Catégorie	Test	Ce que vous faites
Claire	Vous pouvez énoncer la question précisément maintenant	Traitez-la (passe 4)
Floue	Vous sentez qu'une question est là mais ne pouvez pas encore la formuler	Une ligne lâche, puis laissez-la
Hors périmètre	Elle se situe au-delà de la destination	Notez-la ; elle ne revient pas

Le test de clarté/flou est si vous pouvez l'énoncer, pas si vous pouvez y répondre. Une question avec une réponse difficile ou inconnue est toujours claire si vous pouvez la formuler exactement — ce sont souvent les plus importantes.

Hors périmètre utilise un test différent — le périmètre, pas la clarté. Quelque chose peut être parfaitement clair et néanmoins hors périmètre parce qu'il est au-delà de la destination. Écartez-le explicitement et dites pourquoi ; il ne revient que si la destination elle-même bouge, et c'est une nouvelle reconnaissance.

Ensuite, ordonnez les questions claires par ce qui débloque le plus — la réponse qui effondre le plus grand nombre d'autres questions passe en premier.

4. Les résoudre, une par une

Posez une question à la fois et attendez. Donnez votre recommandation avec chacune — mais c'est une recommandation, et la décision appartient à l'utilisateur. Ne répondez jamais à une décision en leur nom et ne regroupez jamais les questions ; un mur de cinq questions est déroutant et obtient une réponse paresseuse.

Après chaque réponse, mettez à jour les catégories :

• A-t-elle éclairci du flou en une question réelle et énonçable ? Promouvez-la.
• A-t-elle tué des questions qui n'ont plus d'importance ? Supprimez-les.
• A-t-elle déplacé la destination ? Dites-le haut et fort et revérifiez les autres catégories par rapport à la nouvelle — tout était mesuré par rapport à l'ancienne ligne.

Ne pré-découpez pas le flou en fausses questions pour avoir l'air productif. Le flou est un panneau indicateur, pas une liste de tâches.

5. Arrêtez-vous quand la route est claire

Terminé signifie : plus aucune question claire, et ce qui reste de flou est véritablement reportable ou hors périmètre. Concluez avec la destination, les décisions qui y ont mené, et la prochaine étape concrète.

Ensuite, passez la main — ne construisez pas. scout produit un itinéraire, pas un livrable. Allez en mode planification (ou /validate-plan si un plan en est sorti), puis implémentez. Si vous vous surprenez à écrire du code de production à l'intérieur d'une reconnaissance, vous avez outrepassé la compétence.

La seule exception est un jetable — lorsqu'une question ne peut vraiment pas être réglée sur papier ("ce modèle d'état semble-t-il juste", "à quoi cela devrait-il ressembler"), construisez la plus petite chose brute qui y répond, regardez-la, gardez la réponse et jetez le code.

Traverser les sessions — seulement si vraiment nécessaire

Par défaut, une session, aucun artefact. La plupart des reconnaissances tiennent dans une session, et un fichier écrit pour une conversation qui s'est terminée vingt minutes plus tard n'est que des déchets.

Passez à /handover-save quand — et seulement quand — l'une de ces conditions est vraie :

• la session devient assez longue pour que vous perdiez le fil,
• l'utilisateur veut s'arrêter et reprendre plus tard,
• une question est bloquée par quelque chose en dehors de la conversation (réponse de quelqu'un d'autre, accès à provisionnement, données à collecter d'abord).

Le document de passation contient la destination et les trois catégories. Reprenez avec /handover-resume, qui resynchronise la dérive avant de continuer. Étaler les sessions est ici une échappatoire, pas la conception.

Format de sortie

Affichez la carte quand elle change matériellement — après que la destination est nommée, après le déploiement, et chaque fois qu'une réponse remanie les catégories. Pas à chaque tour.

## Reconnaissance : <l'idée, une ligne>

**Destination :** <à quoi ressemble terminé — tout ce qui suit est mesuré par rapport à cela>

**Décidé**
- <question> → <la réponse>

**Ouvert — clair**
1. <question précisément énoncée>   ← travaille sur celle-ci maintenant
2. <...>

**Toujours flou**
- <ligne lâche> — s'éclaircira une fois que <X> est réglé

**Hors périmètre**
- <ce qui a été écarté> — <pourquoi c'est au-delà de la destination>

Concluez avec : la destination, les décisions dans l'ordre, et l'unique prochaine étape.

Garde-fous

• Largeur avant profondeur. Répondre à la première question avant d'avoir vu tout l'espace est l'échec que cette compétence existe pour empêcher.
• Recherchez-le, ne le demandez pas. Une question à laquelle vous auriez pu répondre avec un grep gaspille le tour de l'utilisateur et sa patience.
• Une question, puis attendez. Recommandez une réponse à chaque fois ; ne décidez jamais à leur place.
• Clarté ≠ capacité à répondre. Le test de flou est "puis-je l'énoncer", pas "puis-je y répondre".
• Le flou n'est pas un backlog. Laissez-le lâche. Le pré-découper en tickets invente du travail que la prochaine réponse pourrait supprimer.
• Hors périmètre est une décision de périmètre, pas une étape. Il va dans sa propre catégorie, jamais dans la liste des décisions.
• La destination peut bouger — annoncez-le quand elle le fait. Re-cibler en silence invalide tous les jugements portés avant.
• Ne construisez pas. Décisions en sortie, pas de livrables. Les prototypes jetables sont la seule exception.
• Pas de fichier par défaut. /handover-save seulement quand le travail dépasse vraiment la session.
• Porte de retenue. "Il n'y a pas de flou ici — vous savez déjà comment faire" est un résultat réel et précieux. N'inventez jamais de questions ouvertes pour justifier l'exécution de la compétence.

---

Cadrage destination-d'abord, déploiement en largeur, test de flou énoncez-le vs répondez-y, et séparation périmètre-vs-clarté adaptés de Matt Pocock's wayfinder (github.com/mattpocock/skills). Sa carte du suivi des problèmes, sa machinerie de tâches enfants et sa règle une-tâche-par-session sont délibérément abandonnées — cette collection persiste à travers les sessions avec /handover-save à la place.