Communitygithub.com

constantinehuzenko/skills

Transforme un contenu en une page défilante ciblée, qui se lit comme des diapositives, une question par écran, chacune allant plus loin, avec une réponse d'une ou deux phrases et une scène interactive que le lecteur manipule. À utiliser quand l'utilisateur demande un artefact, une page ou du HTML à partir d'un contenu (recherche, rapport, plan ou voyage, décision ou comparaison, classement, explication), quand une page devient un mur de texte, ou quand l'utilisateur dit « slide it ». Se charge en parallèle d'`artifact-design`. Pas pour les présentations .pptx ou les diaporamas traditionnels.

Qu'est-ce que skills ?

Ce skill, nommé « Slide it », transforme n'importe quel contenu en une expérience de présentation interactive : une page web défilante, structurée comme une série de diapositives, où chaque écran répond à une question clé. Il est conçu pour les agents IA (Claude Code, Cursor, Codex, etc.) qui génèrent des artefacts HTML. L'agent analyse le contenu (recherche, rapport, plan, comparaison), identifie un point principal, puis planifie 4 à 7 écrans. Pour chaque écran, il doit produire une question courte, une réponse concise, et surtout une « scène » animée ou interactive (par exemple, un flux de clients, des particules dans un moteur, un graphique évolutif) que le lecteur peut manipuler via un seul contrôle (curseur, bouton). Le skill impose des règles strictes de conception : une palette de couleurs cohérente, une mise en page adaptée aux mobiles et ordinateurs, des animations automatiques qui s'arrêtent pour la lecture, et une structure de code basée sur un kit HTML donné. L'objectif est de rendre l'information compréhensible visuellement et immédiatement, en évitant les murs de texte. Le skill inclut des exemples et des fichiers de style de référence, et exige une vérification finale (screenshot ou revue de code) avant publication.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/constantinehuzenko/skills/tree/HEAD/skills/slide-it

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Slide it

Construis la page comme une présentation : une pile d'écrans, chacun répondant à une question. La question est écrite en petit, la réponse en une ou deux phrases en grand, et en dessous une scène animée montre le phénomène : des clients qui font la queue, de l'air traversant un moteur, de l'argent suivant des biens. Le lecteur interagit avec un seul contrôle et voit la scène changer, comprenant ainsi par l'observation ; il peut s'arrêter à chaque écran en ayant compris quelque chose. La page donne l'impression d'être une application bien conçue pour son sujet. artifact-design gère les règles de la plateforme (thèmes, largeur téléphone, CDN, le contrôle unique) ; l'utilisateur a installé ce skill, donc là où ses règles diffèrent des valeurs par défaut d'artifact-design, considère-les comme les propres directives de l'utilisateur.

1. Trouver le point principal

Écris une phrase : ce que le lecteur doit comprendre ou décider après le premier écran.

2. Ouvrir l'exemple le plus proche

Ouvre l'exemple le plus proche de ce contenu et lis-le en entier avant de planifier : examples/explainer.html (comment quelque chose fonctionne), examples/decision.html (faut-il, lequel), examples/plan.html (un plan, un voyage, une chronologie). Il établit le niveau attendu pour la structure, les scènes et le code ; construis cette page de la même manière.

3. Planifier les écrans

Liste les écrans. L'écran 1 permet au lecteur de trouver le point principal en regardant et en jouant. Chaque écran suivant répond à la question soulevée par le précédent (pourquoi, comment, combien, ensuite) ; un nouveau sujet commence seulement lorsque le contenu change de thème. De quatre à sept écrans.

Pour chaque écran, écris dans ta réponse :

  • la question à laquelle il répond, formulée comme le lecteur la poserait ou la chercherait, claire en elle-même, en cinq mots ou moins (« Combien de temps pour 10 000 ? », pas « Combien de temps cela va-t-il prendre ? » ; elle s'affiche en petit au-dessus de la réponse et nomme l'écran dans le menu). La question de l'écran 1 nomme le sujet, de sorte qu'un lecteur arrivant sur la page sache de quoi il s'agit ;
  • la réponse, en une ou deux phrases ;
  • la scène, en une ligne : ce qui est à l'écran, ce qui se passe, ce que fait le lecteur, et quel nombre est lu sur la scène.

Les scènes proviennent de quelques motifs : suivre une unité dans le système, des flux traversant des étapes, un mécanisme qui tourne, une nuée d'agents suivant une règle, des traceurs dans un champ, une relecture avec un curseur, une division avant/après, ou un réservoir qui se remplit et se vide. Une ligne qui dit « un contrôle, un nombre et une barre », avec rien à l'écran qui soit la chose elle-même, est un tableau de bord : réécris-la comme une scène.

La scène illustre ; tout nombre réel sur la page provient du contenu et est étiqueté s'il s'agit d'une estimation.

Chaque écran a son propre pli « Plus » replié sous sa scène pour le reste de l'histoire de cet écran : quelques points courts, les chiffres derrière, une réserve. Les sources, et ce qui ne sert aucun écran, vont dans une seule section « Notes complètes » repliée à la fin, ou sont laissés de côté.

Tu as terminé quand chaque écran a une question, une réponse, une ligne de scène, et au plus 40 mots de texte hors de son pli (les étiquettes et les nombres ne comptent pas).

4. Choisir le style

Nomme l'application que les gens utiliseraient pour ce sujet (un voyage : une appli de voyage ; une décision commerciale : un outil professionnel moderne) et ouvre uniquement ce fichier dans styles/. Un style nommé par l'utilisateur le remplace. Prends la palette et la typographie du style et donne à chaque écran une grande zone de sa couleur.

5. Construire

  • Construis à partir de kit/screens.html, comme les exemples : chaque écran dans le DOM sur une page qui défile normalement, les questions listées sur le bord droit sur un ordinateur, toujours visibles (onglets sur un téléphone), un pli « Plus » par écran, des notes complètes à la fin, et un commutateur clair/sombre.
  • Chaque scène s'ouvre déjà en montrant le point principal (à mi-chemin, pas une image vide à zéro), se joue automatiquement quand son écran entre dans le champ de vision pendant environ dix secondes, puis s'arrête sur sa dernière image pour que la page reste immobile pendant que le lecteur lit. Déplacer le contrôle la rejoue avec le nouveau réglage, et un appui la met en pause. En mode de mouvement réduit, elle repose sur une image fixe qui montre toujours le point principal. Le nombre se trouve sur la scène comme une étiquette, pas comme le héros de l'écran.
  • Dispose chaque écran comme une vue d'application : la scène est l'élément le plus grand, occupe toute la largeur sur un téléphone et contient une scène large et centrée sur un ordinateur, avec la réponse au-dessus en grand.
  • Quand une scène représente une chose physique (un appareil, une machine, un bâtiment, une partie du corps), lis d'abord figures.md : il décide entre le kit isométrique, un dessin en 2D ou aucun dessin.

Écris la page directement avec tes outils de fichiers, en copiant de l'exemple à la main ; les scripts peuvent ne pas être autorisés à s'exécuter, donc la page ne dépend jamais d'un script.

Tu as terminé quand chaque écran prévu est sur la page avec sa scène en fonctionnement.

6. Vérifier

Si tu peux afficher la page, prends une capture d'écran de l'écran 1 en largeur téléphone ; sinon, lis son code. Réponds par oui ou non :

  • Y a-t-il à l'écran la chose elle-même, et non un graphique de celle-ci ?
  • Bouge-t-elle, et le contrôle du lecteur change-t-il ce qu'elle fait ?
  • Le lecteur peut-il comprendre quoi faire en quelques secondes ?
  • Le style changerait-il si le sujet changeait ?

Compte aussi : écrans (4 à 7) et mots hors des plis (40 ou moins chacun). Corrige ce qui échoue en un seul passage, puis publie.

Skills associés