Décrire une interface à une IA avec le bon vocabulaire UI

# Applique le guide « Décrire une interface à une IA avec le bon vocabulaire UI » dans ton agent

## Objectif
Pour décrire une interface à une IA, pars du résultat utilisateur, nomme le concept si tu le connais, puis précise le déclencheur, le contenu, le comportement, les états et les contraintes. Termine par des critères observables. Exemple : « Ouvre un popover non modal au clic, garde le focus clavier logique, ferme-le avec Échap et replace le focus sur le bouton » est plus fiable que « ajoute une petite popup moderne ».

## Prérequis
- Inspecte le dépôt, la documentation et les conventions existantes.
- Confirme que le besoin correspond au périmètre du guide : Pour expliquer ton interface à un assistant IA, décris son but, ses composants, ses comportements, ses états et des critères vérifiables.
- Préserve les décisions correctes déjà en place.

## Étapes du guide
- 1. Séparer les cinq couches d’une demande UI — Les mots « menu », « popup », « champ intelligent » ou « panneau » décrivent souvent plusieurs concepts. Avant de choisir une primitive, décompose la demande. Le but explique ce que la personne essaie d’accomplir. Le concept donne un nom partagé. Le comportement décrit ce qui se passe. Les états montrent les variations. L’apparence règle la présentation sans redéfinir la fonction.
- 2. Désambiguïser avec une question comportementale — Une question sur le comportement réduit mieux l’ambiguïté qu’une dizaine d’adjectifs visuels.
- 3. La structure d’un prompt UI exécutable — Commence par demander l’inspection de l’existant si l’agent travaille dans un dépôt. Nomme ensuite le changement local et les éléments à préserver. Décris le scénario utilisateur, puis le comportement attendu dans un ordre observable. Ajoute les contraintes techniques uniquement lorsqu’elles sont vérifiées dans le projet.
- 4. Le nom visuel ne suffit pas à définir l’accessibilité — Privilégie d’abord les éléments HTML natifs lorsqu’ils portent déjà le comportement recherché. Les rôles ARIA décrivent une sémantique aux technologies d’assistance ; ils n’ajoutent pas automatiquement le clavier, le focus ou les états. L’ARIA Authoring Practices Guide propose des modèles et exemples utiles, mais précise qu’il ne s’agit ni d’un standard normatif complet ni d’un design system prêt pour la production.
- 5. Vérifier l’interface générée comme un contrat — Relis le résultat en trois passages. Le premier confirme la mission : la personne peut-elle accomplir la tâche ? Le deuxième inspecte le comportement : états, focus, fermeture, retour arrière, scroll et responsive. Le troisième vérifie l’intégration : composants existants réutilisés, périmètre de fichiers limité et tests pertinents.
- 6. Distingue le modèle du composant utilisable — Pour « un panneau à côté de mon article », précise si l’article reste utilisable, comment le panneau se ferme et où va le focus clavier. Compare ces observations au modèle d’accessibilité pertinent avant de choisir un nom de composant.

## Critères d’acceptation — Checklist d’un prompt UI précis
- Le but utilisateur tient en une phrase et décrit un résultat.
- Le concept canonique est nommé ou laissé explicitement à désambiguïser.
- Déclencheur, contenu, comportement et fermeture sont précisés.
- Les états principal, vide, chargement, erreur et cas limite pertinents sont couverts.
- Les exigences clavier, focus, nom accessible et tactile sont observables.
- L’apparence est séparée du contrat comportemental.
- Les composants, tokens et dépendances existants doivent être réutilisés.
- La sortie attendue inclut des critères d’acceptation et les validations encore manuelles.

## Garde-fous
- Montre d’abord les changements envisagés avant toute action externe.
- Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite.
- Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu.

## Format de sortie
- Résultat obtenu ou verdict.
- Fichiers ou actions concernés.
- Vérifications exécutées et preuves observables.
- Blocages ou limites restantes.

• Prérequis · Le contexte réel du projet : dépôt, documentation et contraintes existantes

# Ancre le guide dans le projet

## Objectif
Transforme les étapes appliquées en conventions durables du dépôt.

## Contrôles
- Relie chaque décision prise à l’étape du guide qui la justifie.
- Ajoute la checklist aux revues concernées.
- Note les cas hors périmètre pour les guides voisins.

## Garde-fous
- Montre d’abord les changements envisagés avant toute action externe.
- Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite.
- Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu.

## Format de sortie
- Résultat obtenu ou verdict.
- Fichiers ou actions concernés.
- Vérifications exécutées et preuves observables.
- Blocages ou limites restantes.

sha256:3a65a86072db03f5baa809b4db59314a51803640605077d7a83574492c6c1c7a

# Diagnostique une application ratée du guide « Décrire une interface à une IA avec le bon vocabulaire UI »

## Symptôme observé
[DÉCRIS ICI LE SYMPTÔME]

## Contrôles observables
- Rejoue les étapes dans l’ordre et note la première qui diverge :
- 1. Séparer les cinq couches d’une demande UI — Les mots « menu », « popup », « champ intelligent » ou « panneau » décrivent souvent plusieurs concepts. Avant de choisir une primitive, décompose la demande. Le but explique ce que la personne essaie d’accomplir. Le concept donne un nom partagé. Le comportement décrit ce qui se passe. Les états montrent les variations. L’apparence règle la présentation sans redéfinir la fonction.
- 2. Désambiguïser avec une question comportementale — Une question sur le comportement réduit mieux l’ambiguïté qu’une dizaine d’adjectifs visuels.
- 3. La structure d’un prompt UI exécutable — Commence par demander l’inspection de l’existant si l’agent travaille dans un dépôt. Nomme ensuite le changement local et les éléments à préserver. Décris le scénario utilisateur, puis le comportement attendu dans un ordre observable. Ajoute les contraintes techniques uniquement lorsqu’elles sont vérifiées dans le projet.
- 4. Le nom visuel ne suffit pas à définir l’accessibilité — Privilégie d’abord les éléments HTML natifs lorsqu’ils portent déjà le comportement recherché. Les rôles ARIA décrivent une sémantique aux technologies d’assistance ; ils n’ajoutent pas automatiquement le clavier, le focus ou les états. L’ARIA Authoring Practices Guide propose des modèles et exemples utiles, mais précise qu’il ne s’agit ni d’un standard normatif complet ni d’un design system prêt pour la production.
- 5. Vérifier l’interface générée comme un contrat — Relis le résultat en trois passages. Le premier confirme la mission : la personne peut-elle accomplir la tâche ? Le deuxième inspecte le comportement : états, focus, fermeture, retour arrière, scroll et responsive. Le troisième vérifie l’intégration : composants existants réutilisés, périmètre de fichiers limité et tests pertinents.
- 6. Distingue le modèle du composant utilisable — Pour « un panneau à côté de mon article », précise si l’article reste utilisable, comment le panneau se ferme et où va le focus clavier. Compare ces observations au modèle d’accessibilité pertinent avant de choisir un nom de composant.

## Causes possibles
- Une étape a été sautée ou exécutée hors ordre.
- Le besoin réel sort du périmètre du guide.
- Un critère de la checklist n’a jamais été vérifié.

## Corrections bornées
- Reprends uniquement l’étape divergente et ce qui en dépend.
- Documente l’écart si le périmètre du guide ne couvre pas le besoin.

## Vérification finale — Checklist d’un prompt UI précis
- Le but utilisateur tient en une phrase et décrit un résultat.
- Le concept canonique est nommé ou laissé explicitement à désambiguïser.
- Déclencheur, contenu, comportement et fermeture sont précisés.
- Les états principal, vide, chargement, erreur et cas limite pertinents sont couverts.
- Les exigences clavier, focus, nom accessible et tactile sont observables.
- L’apparence est séparée du contrat comportemental.
- Les composants, tokens et dépendances existants doivent être réutilisés.
- La sortie attendue inclut des critères d’acceptation et les validations encore manuelles.

## Garde-fous
- Montre d’abord les changements envisagés avant toute action externe.
- Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite.
- Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu.

## Format de sortie
- Résultat obtenu ou verdict.
- Fichiers ou actions concernés.
- Vérifications exécutées et preuves observables.
- Blocages ou limites restantes.

• Prérequis · Le contexte réel du projet : dépôt, documentation et contraintes existantes

# Préviens la prochaine dérive

## Objectif
Fais de la première étape divergente un contrôle explicite du projet.

## Contrôles
- Ajoute un contrôle ciblé sur l’étape qui a divergé.
- Vérifie la checklist sur un second cas réel.
- Documente la limite de périmètre rencontrée.

## Garde-fous
- Montre d’abord les changements envisagés avant toute action externe.
- Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite.
- Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu.

## Format de sortie
- Résultat obtenu ou verdict.
- Fichiers ou actions concernés.
- Vérifications exécutées et preuves observables.
- Blocages ou limites restantes.

sha256:18c0eff8595c08d8ba2e6ddfa65ada43d49c9a17b1914445a12e5e934051658b