mveplus/claude-skills

Site « Comment ça marche »

Produisez un diaporama sans dépendances dans site/ qui explique une base de code depuis le pourquoi jusqu'au code, avec des démos interactives reflétant la vraie logique du projet, et un job CI qui le publie. Implémentation de référence : https://mveplus.github.io/onair-led-sign-firmware/ (19 diapositives, 4 simulations ; source dans https://github.com/mveplus/onair-led-sign-firmware/tree/main/site).

Modèles dans le répertoire templates/ de cette compétence :

Fichier	Copier vers	Objectif
index.html	site/index.html	Chrome de la page + modèles de diapositives à cloner
deck.css	site/deck.css	Tokens de thème, mise en page, composants
deck.js	site/deck.js	Navigation, vue d'ensemble, routage par hachage, boucle d'images, assistant de progression
app.js	site/app.js	Starter pour les démos du projet (câblage des étapes, hook d'image)
github-pages.yml	.github/workflows/pages.yml	Déploiement GitHub Pages
gitlab-ci.yml	fusionner dans .gitlab-ci.yml	Déploiement GitLab Pages

Le code de démo spécifique au projet va dans site/app.js (et les styles dans un éventuel site/app.css) ; gardez deck.js et deck.css génériques.

Processus

1. Demander avant de construire (un appel AskUserQuestion)

Vérifiez d'abord git remote -v pour que la question d'hébergement reflète la réalité. Si le remote est GitHub et que l'utilisateur dit GitLab (ou l'inverse), posez la question. Posez au maximum quatre questions :

• Hébergement : GitHub Pages, GitLab Pages, ou les deux.
• Audience/profondeur : mixte (d'abord l'idée, puis une plongée en profondeur ; défaut), développeurs, ou non‑développeurs.
• Démos interactives : proposez 3–4 candidats spécifiques à ce projet, trouvés par un survol rapide (machines d'état, logique de temporisation/seuil, flux de requêtes, maths ou formules, constructeurs de configuration). multiSelect.
• Optionnellement : une contrainte de langue ou de marque, si le dépôt en suggère une.

2. Lire le code correctement

Lisez les points d'entrée, les modules principaux, le README/doc et les fichiers CI. Pour chaque affirmation que les diapositives feront (timeouts, seuils, valeurs par défaut, sujets, endpoints, ce qu'un reset efface), récupérez‑la depuis le code, pas depuis le README. Gardez une liste des écarts doc‑vs‑code et des impasses (par ex. un job CI dont le consommateur n'existe pas). Montrez le comportement réel du code sur les diapositives et signalez la liste à l'utilisateur à la fin. Ne corrigez jamais en silence les diapositives pour qu'elles correspondent à la documentation.

3. Plan (~12–20 diapositives), groupées en chapitres

Arc typique : titre (avec un élément interactif ludique) → l'idée / le problème → vue d'ensemble (architecture cliquable) → flux de requêtes/données (animeur de progression) → une diapositive par composant majeur → résilience / gestion des pannes → sécurité / secrets → build, CI, livraison → récapitulatif des principes de conception avec liens. Chaque diapositive a besoin d'un data-chapter et d'un data-title.

4. Construire

• Copiez les modèles et clonez les motifs de diapositives dans index.html (hero, deux colonnes avec une carte, animent de progression, grille d'infos).
• Les simulations réutilisent l'algorithme réel du projet : portez la fonction (maths entières, seuils, ordre) et citez son nom sur la diapositive. Une simulation qui semble juste est un bug.
• Utilisez Deck.onFrame(slideId, fn) pour l'animation, afin que seule la diapositive visible s'anime. Utilisez Deck.stepper(...) pour les séquences pas à pas.
• Diagrammes : SVG inline utilisant les tokens CSS ; rien d'externe. Pas de CDN et pas de polices à charger, pour que le site fonctionne hors ligne et sur des Pages restreintes.
• Images : copiez‑les dans site/img/, redimensionnées avec métadonnées supprimées (avec ImageMagick : magick in -auto-orient -strip -resize 1200x -quality 80 out.jpg). Vérifiez les images originales du dépôt pour les EXIF GPS (par ex. identify -format '%[EXIF:GPSLatitude]' ou exiftool -gps:all) et prévenez l'utilisateur si des données sont trouvées. Les photos de téléphone portent souvent la position où elles ont été prises. Une fois poussées, elles sont dans l'historique git : les supprimer nécessite une réécriture d'historique, c'est la décision de l'utilisateur.

5. Câblage de publication

• GitHub : copiez github-pages.yml. Pages doit être activé une fois avec source = Actions (Settings → Pages), ou avec la commande ci-dessous. Donnez des commandes que l'utilisateur copiera dans un bloc de code sans rien après. Le point de fin d'une phrase copié avec la commande se retrouve dans l'argument (build_type=workflow.), et l'API le rejette :

  gh api -X POST repos/OWNER/REPO/pages -f build_type=workflow
  

  Il ne déploie que depuis la branche par défaut.
• GitLab : fusionnez le job pages dans tout .gitlab-ci.yml existant ; ne l'écrasez pas. Pages s'active automatiquement ; l'URL est affichée sous Deploy → Pages.
• Ajoutez un court paragraphe de lien dans la section d'aperçu / « Comment ça marche » du README.

6. Vérifier avant de signaler

• node --check site/*.js
• Servez avec python3 -m http.server 8765 --bind 127.0.0.1 --directory site (en arrière‑plan). Si un outil d'automatisation de navigateur est disponible (par ex. Claude dans Chrome), ouvrez le site, capturez chaque chapitre, et pilotez chaque démo en exécutant du JavaScript dans la page (.click(), PointerEvents dispatchés) plutôt qu'en cliquant sur des coordonnées : les captures sont souvent redimensionnées par rapport aux pixels CSS, donc les clics sur coordonnées ratent. Si la fenêtre ne peut pas être redimensionnée, vérifiez la largeur téléphone en chargeant le site dans un iframe de 380 px et cherchez des éléments avec getBoundingClientRect().right > 381.
• Sans outil de navigateur, dites à l'utilisateur quelles pages et démos vérifier manuellement. Ne signalez pas le site comme testé.
• Fermez les onglets que vous avez ouverts et arrêtez le serveur ensuite.

7. Remettre

Demandez avant de commiter ou pousser. Ensuite, sur une branche : un commit pour le site, des commits séparés pour les éventuelles corrections de code demandées par l'utilisateur. Rapportez : ce qui a été construit, comment activer Pages, la liste des écarts, et tout ce qui n'a pas été testé (par ex. matériel).

Règles de style

• Thème sombre par défaut (tokens dans deck.css), avec un accent rouge que vous pouvez re‑teinter par projet via --accent.
• Texte simple et concret. Expliquez pourquoi un choix de conception existe, pas seulement ce qu'il fait.
• Les extraits de code sont courts et réels (taillés dans la source, avec un commentaire nommant le fichier).
• Clavier : ←/→/Espace/PageUp/PageDown/Début/Fin, O pour la vue d'ensemble, Échap pour fermer. Balayage tactile. Chaque diapositive a sa propre URL (#/slide-id).