jove525/portfolio-builder

Portfolio Builder

Transforme le travail d'une personne en un portfolio d'une seule page. Claude planifie le contenu dans le chat, le verrouille dans un BRIEF.md, puis transmet les invites Claude Code. Claude Code construit localement, pousse sur GitHub, Netlify déploie. Claude audite ensuite le dépôt et le site en direct.

Règles d'écriture pour tout ce que produit cette compétence : voix directe et décontractée, phrases courtes, pas de tirets cadratins (uniquement des traits d'union normaux).

Phase 1 : Recueillir avant de demander

• Récupérer ce qui est déjà connu : mémoire, conversations passées, sites en direct (les récupérer pour de vraies listes de fonctionnalités et du copy).
• Rédiger d'abord un inventaire de contenu. Ne jamais commencer par un questionnaire vierge.

Phase 2 : Rédiger le brief v1, puis poser au maximum 4 décisions

Rédiger les sections avec du vrai copy, puis ne demander que ce qui modifie la construction :

1. Public principal (clients, recruteurs, ou les deux, et lequel mène).
2. Contraintes de visibilité (employeur actuel nommé ou générique ; tout ce qui doit rester privé).
3. Quels projets inclure.
4. Où il vit (un sous-domaine Netlify pour commencer est suffisant).

Garde-fous :

• Aucune métrique, témoignage ou client inventé.
• Aucune affirmation que la personne n'a pas faite (ex. travail en IA dans un emploi quotidien qu'elle n'a pas fait).
• Les victoires d'équipe créditées comme victoires d'équipe.
• Si l'employeur reste générique, supprimer également les détails qui l'identifient quand même (listes de pays, titres exacts plus secteur). Dire « cinq marchés », pas la liste.
• Surveiller la formulation régionale (ex. « marchés asiatiques » quand un pays s'étend sur plusieurs continents) et les pronoms vagues dans le copy héroïque.

Règle d'inclusion des projets : un projet mérite une place quand il est en ligne et montre une compétence que le public paierait. Trop d'entreprises signale « pas de temps pour vous ». Les travaux en sommeil ou passés vont dans une petite rangée « Du labo », étiquetée honnêtement. Les projets sans nom ou non lancés attendent.

Outils : lister uniquement les outils utilisés concrètement. Les outils simplement connus vont dans une note en bas de ligne (« Également à l'aise avec X et Y »).

Phase 3 : Combler les lacunes

Demander : nom d'affichage, photo, une capture d'écran par construction, URLs en direct, URL GitHub, email de contact, réseaux sociaux. Réécrire tout copy de site fourni pour qu'il soit adapté au portfolio (ce que c'est, pour qui, ce qu'ils ont construit). Chaque lien de carte doit pointer vers une page en direct qui décrit réellement cet élément. Si la page n'est pas prête, pas de lien et l'étiqueter (ex. « Lancement »). Reporter tout ce qui n'est pas prêt (lien de réservation, « travaillez avec moi », témoignages) dans une liste « Plus tard » au lieu de bloquer la v1.

Phase 4 : Verrouiller BRIEF.md

Rédiger BRIEF.md avec ces sections, dans l'ordre :

• Objectif (test des 10 secondes : ce qu'ils construisent, la preuve, comment les joindre)
• Public
• Règles pour le copy (voix, pas de tirets cadratins, garde-fous de visibilité et d'exactitude, utiliser le copy tel qu'écrit)
• Technique (HTML/CSS/JS vanilla pur, pas d'étape de build ; index.html, styles.css, main.js, /assets ; GitHub + Netlify ; Lighthouse 95+ ; mobile first)
• Direction de design (par défaut Apple-like : police Inter ou système, espacement généreux, largeur max ~1080px, blocs de texte ~680px, grands titres serrés, palette neutre, rayon de carte 20-24px, bordures ultrafines, un accent utilisé avec parcimonie, clair/foncé avec commutateur, fondu subtil respectant la réduction de mouvement, captures d'écran dans un cadre de navigateur minimal, nav collante floutée)
• Règles de mise en page (intégrer dès le départ) :
  • La nav et chaque section partagent un seul conteneur, donc tous les bords gauches s'alignent.
  • Un jeton d'espacement de section (environ 96px desktop, 56px mobile) pour chaque espace ; pas de paddings empilés.
  • Le héros tient au-dessus du pli sur 1366x768 et 375x812, barres d'outils du navigateur incluses (environ 650px et 635px visibles).
  • Titre : text-wrap joli sur mobile, balance sur desktop ; pas de sauts de ligne forcés.
  • Chaque section a un titre ou une étiquette de sourcil visible, donc rien ne flotte.
• Actifs (chemins de fichiers exacts ; captures d'écran converties en WebP avec des tailles mobiles plus petites, chargées paresseusement sous le pli ; espace réservé si manquant, jamais d'image cassée)
• Contenu de la page, de haut en bas, avec le copy final : Héros, Ce que je fais (3 cartes), Réalisations (carte en vedette + grille + rangée de labo), Comment je construis, Outils (pastilles groupées), Bande de fond, Principes (dans les propres mots de la personne, pas de citations empruntées), Contact, Pied de page
• SEO et méta (titre, description, image OG, favicon, HTML sémantique, texte alternatif, états de focus, contraste AA)
• Détails préremplis : URL du dépôt, sous-domaine préféré plus fallback, poignées sociales, email, pour que Claude Code n'ait pas à demander
• Plus tard (pas dans v1)

Couleur d'accent : choisir une qui se distingue des couleurs dans les captures d'écran des constructions. Donner les valeurs hex exactes pour le mode clair et foncé, et vérifier le contraste AA pour les liens ET le texte des boutons sur l'accent dans les deux modes (les boutons en mode foncé nécessitent généralement du texte sombre sur un accent clair).

Livrer BRIEF.md en tant que fichier.

Phase 5 : Étapes de configuration + 4 invites

Configuration (une fois) :

1. Créer un dépôt GitHub vide, puis git clone <url-du-dépôt> dans un dossier local pour que git soit déjà câblé.
2. Placer BRIEF.md à la racine ; ajouter /assets et /assets/shots avec les fichiers nommés.
3. Ouvrir Claude Code dans ce dossier.

Invite 1, Planifier :

Lisez BRIEF.md entièrement. N'écrivez pas encore de code.
Donnez-moi un court plan de construction : structure de fichiers, mise en page section par section, les jetons de couleur et l'échelle typographique que vous utiliserez, et toute question ou conflit que vous voyez dans le brief. Tenez-le en dessous d'un écran.
Couleur d'accent : <HEX_CLAIR> en mode clair, <HEX_FONCÉ> en mode foncé. Utilisez-la avec parcimonie et confirmez que les deux passent le contraste AA, y compris le texte des boutons.

Aider la personne à répondre à ses questions en une seule réponse copiable.

Invite 2, Construire :

Construisez le site exactement selon BRIEF.md et le plan que nous avons convenu.
- Utilisez le copy mot pour mot. Pas de tirets cadratins nulle part.
- HTML pur, CSS, JS vanilla. Pas de frameworks, pas d'étape de build.
- Accent : <HEX_CLAIR> clair, <HEX_FONCÉ> foncé. Tout le reste neutre.
- Suivez les règles de mise en page dans BRIEF.md (conteneur partagé, un jeton d'espacement, héros au-dessus du pli).
- Utilisez les images dans /assets en WebP. Affichez un espace réservé propre si l'une manque.
- Mode clair et foncé, nav collante floutée, fondu au défilement avec support de mouvement réduit.
Quand c'est fait, démarrez un serveur local et donnez-moi l'URL pour que je puisse le réviser.

Invite 3, Peaufiner :

Révisez le site comme un designer senior chez Apple le ferait, puis corrigez ce que vous trouvez :
1. Vérifiez à 375px, 768px, 1366px et 1440px. Pas de défilement horizontal, rien de serré.
2. Tous les bords gauches s'alignent ; chaque espace de section utilise le seul jeton d'espacement.
3. Le héros tient au-dessus du pli avec les barres d'outils du navigateur à 1366 et 375.
4. Le mode foncé a l'air intentionnel, pas inversé. L'accent se lit bien dans les deux modes.
5. Accessibilité : texte alternatif, états de focus, contraste AA, titres sémantiques.
6. Cherchez dans tous les fichiers les tirets cadratins et remplacez-les.
7. Exécutez Lighthouse et obtenez tous les quatre scores à 95+.
Donnez-moi une courte liste de ce que vous avez changé.

Ensuite la personne donne des retours en langage courant jusqu'à satisfaction.

Invite 4, Pousser et déployer :

Ce dossier est déjà cloné depuis <URL_DU_DÉPÔT>.
1. Ajoutez un .gitignore et un netlify.toml (répertoire de publication = racine, en-têtes de cache sensés, et 404 pour BRIEF.md et les PNG sources afin qu'ils ne soient pas publics).
2. Commitez tout avec un message clair et poussez sur main.
3. Connectez le dépôt à Netlify. Essayez <SOUS-DOMAINE> d'abord, fallback <FALLBACK>. Si l'application GitHub de Netlify ne peut pas voir le dépôt, dites-moi comment lui accorder l'accès.

Remarque : Claude Code fait souvent tout (construire, peaufiner et déployer) en une seule fois. C'est bien ; passez à l'audit.

Phase 6 : Audit après le push

Quand le dépôt ou l'URL en direct est partagée :

1. Clonez le dépôt et vérifiez : le copy correspond à BRIEF.md, rien d'inventé, pas de tirets cadratins, pas de noms restreints, tous les liens corrects, images en WebP avec texte alternatif et tailles, méta/OG/favicon présents, fichiers internes bloqués du site en direct.
2. Vérification visuelle du site en direct dans le navigateur à 1440 et 1366 (clair) et 375 (foncé) : alignement des bords, cohérence des espacements, héros au-dessus du pli, habillage du titre, rien qui se chevauche.
3. Donnez les correctifs en une seule invite Claude Code copiable, puis revérifiez après le push. Si le dépôt est vide, dites-le clairement et demandez à la personne de pousser d'abord.

Problèmes connus :

• Netlify ajoute un badge « Propulsé par Netlify » sur les projets du plan Gratuit créés après le 19 août 2026. Il n'est pas dans le code : désactivez-le sous Configuration du projet > Général > Badge Propulsé par Netlify, par projet.
• Les scores Lighthouse en direct depuis des connexions lentes varient ; jugez avec pagespeed.web.dev, pas seulement les exécutions locales.

Phase 7 : Synchroniser le reste de leur présence

Proposer d'aligner le README du profil GitHub (et autres bios) avec le portfolio : même ligne de positionnement, même email de contact, liens vers les constructions en direct et le portfolio, et supprimer les projets que le portfolio a délibérément exclus.