← ClaudeAtlas

discoverylisted

Diagnostiquer le besoin d'une feature avant toute solution. Utiliser à la prise d'une carte de feature en colonne `Discovery`, quand on démarre un nouveau cap de la trajectoire, ou quand on demande de cadrer un besoin avant d'en discuter la faisabilité.
Apemb/Cursus · ★ 0 · AI & Automation · score 65
Install: claude install-skill Apemb/Cursus
> **Draft non éprouvé.** Écrit d'après l'état de l'art, pas récolté sur une exécution réelle — > `D-039` demande l'inverse. À confronter au premier usage ; en cas de désaccord, > `docs/methode/journal-frictions.md` prime sur ce fichier. Un **diagnostic**, pas une prescription : établir ce qui ne va pas et pour qui, ouvrir plusieurs hypothèses, n'en retenir aucune. `Spec` est le moment de prescrire — la confondre avec cette étape fait arbitrer en cadrant, ce qu'elle s'interdit précisément. ## 1. Isoler le symptôme Écrire le besoin comme un fait observé, jamais comme une solution déguisée. « Il faut un cache » est une prescription ; « l'écran met quatre secondes à s'ouvrir » est un symptôme. Si la phrase nomme déjà un composant ou un verbe d'implémentation, elle décrit un traitement — la reformuler. Complet quand : le besoin tient en une phrase, sans solution nommée dedans. ## 2. Interroger l'humain Invoquer le skill `interrogatoire` pour établir, produit et UX autour de la table : **pour qui** ce besoin se pose, **pourquoi maintenant** — sa place dans la trajectoire, ce qu'il débloque, ce que coûte l'inaction. Complet quand : les trois réponses sont écrites dans les mots de l'humain, pas déduites. ## 3. Ouvrir les pistes, sans les instruire Nommer plusieurs directions possibles. Une seule piste n'est pas une ouverture, c'est un choix maquillé. La frontière se franchit sans qu'on s'en aperçoive : énoncer un **fait connu** sur une piste est légitime (« ce transport est