Que fait imagine-it ?
Transformez une spécification en maquette spéculative : un petit ensemble de fichiers .html simples qui montrent à quoi pourrait ressembler une fonctionnalité dans ce produit. Il s'agit d'un support de discussion destiné à recueillir des réactions humaines, pas d'un code de production — la rapidité et la plausibilité priment donc sur l'exhaustivité.
Entrée (toutes optionnelles, dans n'importe quel ordre) : une URL d'issue/PR ou #123, une clé ou URL Jira, un chemin de fichier, du texte libre, ainsi que des indicateurs :
--wireframe— force un rendu en niveaux de gris (fil de fer) plutôt que l'apparence du dépôt.--out <dir>— répertoire de sortie racine (par défaut.imagine-it/à la racine du dépôt). La sortie va toujours dans<out>/<slug>/.--screens <n>— limite ou force le nombre de fichiers écran.--screenshot[=png|jpeg]— capture également des images des écrans (PNG par défaut).--states— avec une capture, capture chaque état, pas seulement l'état initial.--viewport <WxH>— taille de capture (par défaut 1440x900 ; 390x844 pour les produits conçus d'abord pour le mobile).--notes— capture avec la superposition de notes de spécification activée (désactivée par défaut).
Sans entrée, la spécification est la conversation en cours.
Flux de travail
Exécutez les étapes dans l'ordre. Chacune produit un artefact que la suivante consomme ; conservez-les dans vos notes de travail — seul le HTML est écrit sur le disque.
1. Digestion de la spécification
Récupérez et distillez la spécification en un résumé de spécification : titre, slug, objectif, acteurs, points d'entrée, flux principal, entités avec des exemples de valeurs réalistes, états, critères d'acceptation numérotés AC-1…, hors périmètre, hypothèses, questions ouvertes.
Chaque lacune que vous comblez devient une hypothèse ; les décisions que seul un humain peut prendre deviennent des questions ouvertes. Continuez d'avancer — ne demandez à l'utilisateur que lorsqu'aucune spécification n'existe nulle part (aucun argument, rien dans la conversation).
Terminé lorsque : chaque champ du résumé est rempli (ou explicitement « aucun ») et que chaque CA est numéroté. Détails, récupération source par source et un exemple : references/context-intake.md.
2. Cahier des charges design
Parcourez le dépôt en lecture seule et rédigez un cahier des charges design : mode (haute fidélité ou fil de fer), stack technique, un bloc :root de jetons prêt à être collé utilisant les noms de variables canoniques, mode sombre, coque applicative, notes sur les composants, 1 à 3 écrans de référence les plus proches de la fonctionnalité, style d'icônes, locale de l'interface utilisateur, et les fichiers sources d'où tout provient.
Si votre environnement prend en charge les sous-agents, déléguez ce parcours à un sous-agent et ne récupérez que le cahier des charges ; sinon, effectuez le parcours en ligne dans le même budget de lecture. Le mode est fil de fer lorsque --wireframe est passé ou que le dépôt n'a pas d'interface à imiter ; indiquez pourquoi dans le cahier des charges. Mettez ensuite à jour les points d'entrée du résumé avec les vraies routes/libellés trouvés.
Terminé lorsque : le bloc de jetons utilise chaque nom de variable canonique (sauf fil de fer : Jetons = aucun) et que chaque groupe de jetons cite un fichier source. Matrice de détection de stack, où se cachent les jetons, noms canoniques : references/design-discovery.md.
3. Plan des écrans
Décidez des fichiers avant d'écrire du HTML : un tableau de # | fichier | objectif | états | CA couverts, dans l'ordre du flux. Un fichier par vue distincte ou superposition riche en contenu ; les états (vide, chargement, erreur, succès…) vivent sous forme de sections à l'intérieur de leur écran. Autant que nécessaire, aussi peu que possible — typiquement 2 à 6.
Terminé lorsque : chaque CA apparaît dans la colonne « CA couverts » d'au moins une ligne. Règles et un exemple : references/screen-planning.md.
4. Génération
Écrivez dans <out>/<slug>/ :
index.html hub : résumé de la spécification, flux, couverture des CA, hypothèses, questions ouvertes, sources design
styles.css jetons du cahier des charges + assets/base.css textuellement + styles des composants de la fonctionnalité
ii.js copié textuellement depuis assets/ii.js (barre d'outils de maquette : navigation, notes, états, thème)
01-<screen>.html un par ligne du plan des écrans
02-<screen>.html
Commencez à partir de assets/index-template.html et assets/screen-template.html ; copiez assets/base.css et assets/ii.js depuis ce dossier de compétence. Imitez les écrans de référence : même coque, libellés de navigation, formes des composants et ton du texte, dans le langage d'interface du dépôt. Remplissez avec des données réalistes du domaine. Marquez chaque élément qui satisfait un CA avec data-note="AC-n : …" et chaque choix de conception spéculatif avec data-note="NOTE : …".
La sortie est du HTML/CSS simple autonome avec un petit JS vanilla, ouvert directement depuis le disque : liens relatifs uniquement, icônes SVG en ligne, polices de secours système pour les polices du dépôt. Contrat de sortie complet et liste de vérification avant livraison : references/html-conventions.md.
5. Vérification
Exécutez la liste de vérification avant livraison dans references/html-conventions.md. Terminé lorsque chaque élément de la liste est validé ; corrigez et revérifiez sinon.
6. Capture (uniquement avec --screenshot)
Ignorée entièrement sans indicateur de capture. Sinon, générez les images des écrans planifiés (et du hub, en dernier) dans <out>/<slug>/screenshots/ et ajoutez une section Captures d'écran à index.html. Un problème de capture ne bloque jamais l'exécution.
Terminé lorsque : chaque image planifiée existe, n'est pas vide, a les bons octets magiques, et la première image a été visualisée ; les captures ignorées sont signalées avec la commande manuelle. Indicateurs, clair/sombre, conventions de nommage, échelle d'outils et solutions de repli : references/screenshots.md.
7. Remise
Répondez avec : le chemin vers index.html, le tableau du plan des écrans, les chemins des captures d'écran (ainsi que les captures ignorées et leur commande manuelle), les hypothèses et questions ouvertes, et une proposition pour l'ouvrir (start sur Windows, open sur macOS, xdg-open sur Linux). Si <out> se trouve dans le dépôt et n'est pas déjà ignoré, suggérez de l'ajouter à .gitignore.
Suivi : reconstruisez le contexte à partir de <out>/<slug>/index.html (hypothèses, sources design) et styles.css ; ne reparcourez pas le dépôt ; conservez le slug ; mettez à jour index.html pour correspondre ; réexécutez l'étape 5 (et, si des captures d'écran existaient, recapturez les écrans concernés et le hub).