maumoya/pro-portfolio-dev

PRO Portfolio DEV

GitHub user in, live portfolio out. Les scripts récupèrent, construisent, vérifient et publient ; vous faites la seule chose qu'ils ne peuvent pas faire : choisir les projets et écrire un texte honnête et percutant. Les chemins sont relatifs au dossier de cette compétence. Travaillez dans un dossier temporaire, par exemple portfolio/.

1 · Récupération (faits uniquement)

python3 scripts/fetch.py USER --out portfolio/repos.json (2 appels API publics, sans jeton). Il affiche les principaux dépôts. Ce sont les seuls faits que vous pouvez utiliser ; n'inventez jamais d'étoiles, d'utilisateurs ou de résultats.

2 · Planification (demandez, puis écrivez portfolio/plan.json)

Demandez en un seul message, avec des valeurs par défaut que l'utilisateur peut accepter en disant « go » :

• Qui et pour qui : nom, rôle, le public (recruteurs, clients, pairs). Par défaut : le nom GitHub et la bio.
• Projets : proposez les 4 à 9 plus solides (étoiles, pushes récents, une page d'accueil, une description claire) ; ils choisissent.
• Compétences et expérience à rendre recherchables (optionnel), et liens de contact.
• Où il vit : USER.github.io (racine) ou le dossier docs/ d'un dépôt. L'URL doit être définitive.

Ensuite, écrivez plan.json (schéma et règles de copie : references/plan.md). Règles de copie en bref : titre ≤8 mots, accroche dit quoi + pour qui, chaque projet a un pitch d'une ligne (l'avantage, pas la stack) et une ligne facultative proof qui cite un nombre trouvé dans le README de ce dépôt ou les données GitHub, jamais inventé.

Langues : les chaînes UI pour 10 langues sont livrées dans scripts/ui.json. Pour traduire le propre texte de l'utilisateur, ajoutez plan.t.<lang> et traduisez par le sens, comme un rédacteur natif le dirait dans cette langue, pas mot à mot (voir references/plan.md, « Translating »). Relisez ensuite chaque langue une fois en tant que lecteur natif et corrigez ce qui sonne littéral.

3 · Construction et vérification

python3 scripts/build.py portfolio/repos.json portfolio/plan.json --out portfolio/site
python3 scripts/check.py portfolio/site

check.py doit afficher PASS. Ouvrez portfolio/site/index.html dans un navigateur et regardez-le avant de publier : essayez la recherche avec une faute de frappe, passez en arabe (de droite à gauche) et un thème sombre.

4 · Publication (vers l'extérieur : demandez d'abord)

Montrez à l'utilisateur la page et la cible, et obtenez un oui. Ensuite : bash scripts/publish.sh portfolio/site REPO_CLONE URL [--folder root|docs] --yes Cela valide, pousse, active Pages si nécessaire et interroge jusqu'à ce que la nouvelle construction soit en ligne, affichant LIVE … in N s.

5 · Mesure et rapport

Rapportez en ≤4 lignes : l'URL en direct, le temps LIVE, le score de check.py, et le SEO / accessibilité / performance Lighthouse depuis PageSpeed Insights (pagespeed.web.dev, gratuit) ou un lighthouse local s'il est installé.

Terminé lorsque

• check.py affiche PASS sur le site construit.
• Chaque projet sur la page est un vrai dépôt de l'utilisateur, et chaque nombre sur la page provient des données GitHub ou d'un README.
• L'URL en direct renvoie la nouvelle construction (publish.sh a affiché LIVE), ou l'utilisateur a choisi de ne pas publier.

Jamais

• Inventer des projets, métriques, employeurs ou témoignages. Demandez plutôt.
• Pusher, publier ou activer Pages sans le oui de l'utilisateur.
• Ajouter des traqueurs, des analyses, des cookies ou des scripts externes. La page ne fait aucune requête tierce.
• Écraser un site existant sans montrer les changements (publish.sh sans --yes est la simulation).