GrimNej/portfolio-design

Portfolio Design

Ce skill reconstruit un design de portfolio spécifique pour n'importe qui. Le design est fixe et déjà réglé. Votre travail consiste à collecter les documents de la personne, rédiger son texte dans la bonne voix, générer le site, prouver qu'il fonctionne et le livrer quand elle donne son accord.

Tout se trouve dans ce dossier de compétence :

Chemin	Ce que c'est
template/assets/	CSS, modules JavaScript, polices et bibliothèques externes (GSAP, Lenis) du site. Ne jamais modifier par personne : la build les copie et les thématise.
scripts/build.mjs	Transforme un portfolio.json en site statique final. Node 18+, sans dépendances.
scripts/prepare_photos.py	Découpe le portrait (suppression de l'arrière-plan) et redimensionne la photo de la section À propos.
scripts/discover_github.mjs	Liste les dépôts publics d'un utilisateur GitHub avec leurs accroches README et images de bannière, pour choisir les projets.
scripts/snapshot_github.mjs	Sauvegarde la liste des dépôts publics sur laquelle l'archive se base.
scripts/render_images.py	Génère la carte de partage (og.jpg) et l'icône de favori.
scripts/serve.py	Serveur de prévisualisation locale du site construit.
scripts/qa/run_all.py	Tests de qualité navigateur. Une build n'est pas terminée tant qu'elle ne passe pas.
examples/portfolio.example.json	Configuration complète pour une personne fictive, avec images factices.
reference/	Schéma de configuration, script d'interview, système de design, règles de rédaction, tests de qualité, guide de déploiement.

Dans les commandes ci-dessous, scripts/… désigne le dossier de cette compétence (utilisez le chemin absolu pour les exécuter) et portfolio/… est le dossier du projet de la personne dans son répertoire de travail.

Lisez reference/config-schema.md avant d'écrire une configuration et reference/copywriting.md avant d'écrire du texte.

Règles de base

• Rien ne devient public sans un oui clair. Pas de git push, pas de déploiement, pas de création de dépôt tant que la personne n'a pas approuvé cette étape spécifique. Construire et prévisualiser localement est acceptable.
• Confidentialité. Seules les données GitHub publiques sont utilisées (les deux scripts GitHub utilisent intentionnellement l'API non authentifiée). Avant que l'archive ne soit mise en ligne, montrez la liste des dépôts publics qu'elle affichera et demandez lesquels masquer. Ne mettez jamais de numéro de téléphone, d'adresse postale ou de dépôt privé sur la page, sauf si la personne le demande.
• Leurs photos leur appartiennent. Travaillez sur des copies dans le dossier du projet. Ne les téléchargez nulle part ailleurs que sur le site qu'ils approuvent.
• Le design est le produit. N'ajoutez pas de sections, ne changez pas de polices et ne restylez pas de composants parce qu'une personne demande quelque chose de vague. Ajustez le contenu, le préréglage de thème, la mascotte et le texte. S'ils veulent quelque chose de structurel, dites ce que cela coûterait et confirmez d'abord.
• Le texte est rédigé, pas rempli. Leurs notes sont matière première. Rédigez chaque ligne dans leur voix, respectez les limites de longueur et montrez-leur avant de construire la version finale.

Flux de travail

1. Vérifier la chaîne d'outils

node --version          # 18 ou plus récent
python --version        # 3.10 ou plus récent
python -m pip install playwright pillow numpy
python -m playwright install chromium

La suppression d'arrière-plan du portrait nécessite python -m pip install "rembg[cpu]" (télécharge un modèle d'environ 1 Go au premier lancement). Si ce n'est pas possible, demandez un portrait qui a déjà un fond transparent et utilisez --no-cutout.

Convenez d'un dossier de projet avec la personne (par défaut : ./portfolio/ dans le répertoire courant). Organisation :

portfolio/
  portfolio.json      # la configuration que vous écrivez
  photos/             # leurs photos originales (jamais publiées telles quelles)
  work/               # bannières et captures d'écran des projets
  site/               # sortie de build : ce dossier est déployé

2. Interview

Suivez reference/interview.md. Elle se déroule en dix courtes séries et utilise AskUserQuestion pour chaque choix qui a des options sensées (thème, mascotte, quels dépôts mettre en avant, quels liens dans le héros). Les informations libres (notes biographiques, descriptions de projets) sont demandées en texte clair. Posez une série à la fois et proposez de rédiger tout ce que la personne n'a pas envie d'écrire.

Domaines, dans l'ordre :

1. Identité : nom complet, alias ou pseudo utilisé, titre court, email, ville et pays (fuseau horaire pour l'horloge en direct), langues.
2. Photos : portrait tête-épaules (le découpage du héros) et éventuellement une seconde photo pour la section À propos.
3. Liens : tous les profils qu'ils souhaitent lister ; choisissez deux à quatre pour la rangée du héros.
4. Héros et À propos : ce qu'ils font en un souffle, puis deux courts paragraphes sur leur façon de travailler.
5. Ce qu'ils construisent : quatre types de travail, un mot chacun, avec une ligne de description et une animation au survol (agents, automation, context, launch, code, data, design).
6. Projets : jusqu'à six projets vedettes et jusqu'à trois quêtes secondaires. Lancez d'abord discover_github.mjs et proposez des candidats.
7. Archive : afficher ou non tous les dépôts publics, et lesquels masquer.
8. Stack : listes d'outils groupés, et les 12 à 24 outils qui deviendront des balles dans la fosse.
9. Processus, contact, bandes : trois étapes de processus, la ligne de contact, les deux bandes défilantes.
10. Apparence et extras : préréglage de thème, mascotte (nom, voix, ou désactivée), URL du site et où il sera hébergé.

3. Rassembler les documents du projet

node scripts/discover_github.mjs --user <utilisateur-github> --out portfolio/discovery.json
node scripts/discover_github.mjs --user <utilisateur-github> --out portfolio/discovery.json --download portfolio/work --repos RepoA,RepoB

Le premier lancement liste les dépôts publics avec leur accroche README, leurs images et leurs liens en direct. Le second sauvegarde la première image README de chaque dépôt choisi. Chaque projet vedette a besoin d'au moins une image de prévisualisation. Bonnes sources, dans l'ordre : la bannière README, une capture d'écran de l'application en direct (utilisez Playwright à 1600x900), une bannière générée dans le style de examples/assets/*.svg. Vérifiez chaque image : pas de secrets dans les captures d'écran, rien de flou, format large (16:9 ou approchant).

4. Préparer les photos

python scripts/prepare_photos.py --portrait portfolio/photos/portrait.jpg \
  --about portfolio/photos/about.jpg --about-gray --out portfolio/photos/out

Ouvrez le résultat et regardez-le. Le découpage doit avoir des bords nets, pas de zones transparentes et la tête près du haut. Si la photo À propos coupe mal un visage, relancez avec --about-focus x,y (fractions de 0 à 1 de l'image). Pointez person.photos.portrait et .about dans la configuration vers les fichiers dans out/.

5. Écrire la configuration et construire

Écrivez portfolio/portfolio.json (schéma : reference/config-schema.md ; exemple fonctionnel : examples/portfolio.example.json). Les chemins qu'il contient sont relatifs au fichier de configuration. Ensuite :

node scripts/build.mjs --config portfolio/portfolio.json --out portfolio/site
node scripts/snapshot_github.mjs --user <utilisateur-github> --site portfolio/site   # seulement si l'archive est activée
python scripts/render_images.py --site portfolio/site

La construction s'arrête avec un message clair lorsqu'un champ obligatoire manque. Les avertissements concernant des icônes inconnues signifient que la balle affiche son nom sous forme de texte ; choisissez un slug dans data/simple-icons.json ou laissez-le.

6. Prévisualiser

Servez le site en arrière-plan et donnez l'URL à la personne :

python scripts/serve.py --site portfolio/site --port 4321

Utilisez ce serveur plutôt que python -m http.server : le serveur standard abandonne les connexions lorsque la page demande plusieurs fichiers à la fois, ce qui se traduit par des échecs QA aléatoires. Il envoie également des en-têtes no-cache (une reconstruction se voit après un rechargement) et sert 404.html pour les chemins inconnus comme GitHub Pages.

7. Tests de qualité

python scripts/qa/run_all.py --url http://127.0.0.1:4321/ --out portfolio/qa

Toutes les vérifications doivent réussir (reference/quality-gates.md explique chacune et comment corriger les échecs habituels). Ensuite, regardez vous-même les captures d'écran dans portfolio/qa/shots/, section par section, sur ordinateur et téléphone. Les vérifications automatisées détectent les collisions et les débordements ; vos yeux repèrent les sauts de ligne maladroits, les images faibles et les textes qui sonnent faux. Corrigez, reconstruisez, relancez. Exécutez --full une fois avant de déployer.

8. Revoir avec la personne

Parcourez la prévisualisation avec elle : héros, À propos, rangées, projets, archive, fosse, processus, contact, chat mascotte. Recueillez les modifications, appliquez-les à la configuration (pas aux fichiers construits), reconstruisez et relancez les tests QA.

9. Déployer (uniquement après un oui clair)

Suivez reference/deploy.md : GitHub Pages (site utilisateur ou site projet), domaine personnalisé, et les paramètres Cloudflare qui importent. Après le déploiement, exécutez les vérifications en direct :

python scripts/qa/run_all.py --url https://leur-domaine/ --only smoke,live --out portfolio/qa-live

Si la vérification « email not rewritten » échoue, l'Offuscation d'adresse email de Cloudflare est activée et casse l'anneau « Let's talk » ; la correction se trouve dans reference/deploy.md.

Modifier les choses plus tard

Modifiez portfolio.json, reconstruisez, relancez les tests QA, redéployez. Chaque construction appose de nouvelles chaînes ?v= sur chaque ressource, donc les navigateurs et CDN prennent en compte le changement sans avoir à vider manuellement le cache.