Communitygithub.com

piazambuja/github-profile-site

Créer et publier un site personnel ou un portfolio sur GitHub Pages à l'adresse <compte>.github.io à l'aide de gh CLI : création de dépôt, contenu à partir d'un fichier JSON, Pages via GitHub Actions, déploiement et vérifications. À utiliser lorsque l'utilisateur souhaite un site personnel, un portfolio, un CV en ligne ou une page username.github.io.

Qu'est-ce que github-profile-site ?

Cette compétence permet de créer automatiquement un site personnel ou un portfolio sur GitHub Pages, hébergé à l'adresse `https://<compte>.github.io/`. Elle est idéale pour les développeurs, designers, ou toute personne souhaitant une présence en ligne rapide, accessible et sans dépendances lourdes. Fonctionnant avec les agents IA comme Claude Code ou Cursor, elle orchestre la création du dépôt, la génération du site à partir d'un unique fichier JSON de contenu, l'activation de GitHub Pages via GitHub Actions, le déploiement et les vérifications de qualité. La compétence suit des règles strictes : le nom du dépôt doit être exactement `<compte>.github.io`, le contenu ne doit jamais être inventé, et les données personnelles sont protégées. Elle supporte des extras optionnels comme un blog, un domaine personnalisé ou une marketplace de plugins.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/piazambuja/piazambuja.github.io/tree/main/plugins/career/skills/github-profile-site

Demander à votre IA préférée

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

Documentation

Site personnel sur GitHub Pages

Objectif : un site personnel rapide et accessible à https://<compte>.github.io/, construit à partir d'un seul fichier de contenu que l'utilisateur peut modifier, publié par GitHub Actions à chaque push sur main. Aucun framework et aucune dépendance npm, donc il se construit partout.

Fonctionne pour tout le monde, dans n'importe quel domaine. Rédigez le site dans la langue de l'utilisateur.

Règles strictes

  • Le dépôt doit être nommé exactement <compte>.github.io, où <compte> est le nom d'utilisateur GitHub (ou l'organisation) qui le possède, en minuscules. Seul ce nom publie à la racine (https://<compte>.github.io/). Tout autre nom publie sous un sous-chemin (https://<compte>.github.io/<dépôt>/), et une faute de frappe ou un propriétaire différent signifie que l'URL racine reste une 404. Chaque compte possède un seul tel site.
  • N'inventez jamais de contenu. Pas d'employeurs, dates, titres, métriques, projets ou liens fabriqués. Les faits manquants deviennent un espace réservé visible comme [année de début] et une question à l'utilisateur.
  • Les données personnelles sont publiques une fois poussées, y compris dans l'historique git. Demandez avant de publier un numéro de téléphone, une adresse personnelle, un email personnel ou une date de naissance ; préférez la ville/région, un lien de contact et LinkedIn. Ne validez jamais de secrets ou de fichiers .env.
  • Exécutez les commandes qui créent ou modifient des choses sur GitHub (créer un dépôt, activer Pages, pousser) uniquement après avoir montré à l'utilisateur ce qu'elles vont faire, la première fois. Tout le reste peut être fait immédiatement.

Prérequis

GitHub CLI, installé et connecté. Vérifiez d'abord et corrigez ce qui échoue :

gh --version                        # installation : https://cli.github.com
gh auth status                      # connecté ? quel compte ? quels scopes ?
gh auth login -h github.com -p https -w          # si non connecté (flux navigateur)
gh auth refresh -h github.com -s workflow        # pousser .github/workflows/* nécessite le scope workflow
gh api user --jq .login             # le nom du compte : le dépôt est <ceci>.github.io
git --version
node --version                      # 18+ ; nécessaire uniquement pour exécuter la build localement

Si le site appartient à une organisation, <compte> est le nom de l'organisation et l'utilisateur a besoin de l'autorisation de créer des dépôts dans celle-ci (gh repo create <org>/<org>.github.io).

Étape 1 : vérifier le point de départ

ACCOUNT=$(gh api user --jq .login | tr '[:upper:]' '[:lower:]')
REPO="$ACCOUNT.github.io"
gh repo view "$ACCOUNT/$REPO" --json name,visibility,url 2>/dev/null || echo "le dépôt n'existe pas encore"
gh api "repos/$ACCOUNT/$REPO/pages" 2>/dev/null || echo "Pages non activé"
  • Le dépôt existe avec un site dedans : demander s'il faut le remplacer, le conserver ou migrer son contenu. Ne jamais écraser sans un oui.
  • Le dépôt existe sous un nom différent (ex. portfolio, MyName.github.io sous un autre compte) : proposer de le renommer (gh repo rename <compte>.github.io -R <propriétaire>/<ancien>) au lieu d'en créer un second.
  • Sur un plan gratuit, le dépôt doit être public pour que Pages fonctionne.

Étape 2 : recueillir le contenu (demander uniquement ce qui manque, en un seul message)

  1. Nom, rôle ou titre, ville/région (optionnel), et la langue du site.
  2. Deux ou trois phrases sur ce qu'ils font et pour qui, puis un « à propos » plus long s'ils le souhaitent.
  3. Expérience ou projets : titre, organisation, période, une ou deux lignes chacun. Un CV, un export LinkedIn ou une page existante est la source la plus rapide.
  4. Liens : GitHub (rempli automatiquement), LinkedIn, email ou formulaire de contact, autres profils.
  5. Apparence en quelques mots, et tout ce à éviter. Sans préférence, utiliser le défaut sobre dans static/style.css.

Placez les réponses dans content/profile.json (forme dans assets/profile.example.json). Montrez le JSON à l'utilisateur avant de construire, et marquez chaque espace réservé.

Étape 3 : créer le projet

Structure recommandée (le même layout fonctionne pour tout générateur statique) :

<compte>.github.io/
  AGENTS.md                    instructions pour tout agent de codage (modèle : assets/AGENTS.md)
  CLAUDE.md -> AGENTS.md       lien symbolique optionnel, pour que Claude Code lise le même fichier
  README.md                    comment éditer, construire et publier
  content/profile.json         tout le texte du site
  build.mjs                    générateur, Node uniquement, sans dépendances (assets/build.mjs)
  static/style.css             jetons sur :root, mode sombre via prefers-color-scheme
  .github/workflows/deploy.yml build + déploiement vers Pages (assets/deploy.yml)
  .gitignore                   dist/ et node_modules/

Copiez les fichiers du dossier assets/ de cette compétence, puis adaptez-les. scripts/ contient la configuration du dépôt utilisée à l'étape 4. Gardez AGENTS.md neutre vis-à-vis des agents : il décrit le projet, les commandes et les règles de conception, pas un outil spécifique.

mkdir "$REPO" && cd "$REPO" && git init -b main
mkdir -p content static .github/workflows
# copier assets/ : build.mjs, style.css -> static/, deploy.yml -> .github/workflows/,
#               AGENTS.md, profile.example.json -> content/profile.json
ln -s AGENTS.md CLAUDE.md          # optionnel
printf 'dist/\nnode_modules/\n' > .gitignore
node build.mjs && python3 -m http.server 4321 -d dist   # aperçu à http://localhost:4321

Extras optionnels, uniquement si l'utilisateur le demande : une page de projets, un blog (fichiers Markdown rendus au moment de la build), un domaine personnalisé, ou une marketplace de plugins/compétences dans le même dépôt (.claude-plugin/marketplace.json + plugins/<plugin>/, avec le site les listant ; valider avec claude plugin validate . lorsque Claude Code est installé).

Étape 4 : créer le dépôt et activer Pages

Créez toujours le dépôt avec gh, jamais en tapant le nom dans l'interface web : scripts/create-site-repo.sh prend le nom du compte connecté, donc il est toujours exactement <compte>.github.io. Exécutez-le depuis le dossier du site, avec --dry-run d'abord et montrez la sortie à l'utilisateur :

bash <skill-dir>/scripts/create-site-repo.sh --dry-run      # vérifie gh, login, scopes ; affiche ce qu'il fera
bash <skill-dir>/scripts/create-site-repo.sh                # crée le dépôt public, active Pages (Actions), définit origin
# site d'organisation :       ... --org <org>
# dépôt déjà existant :     ... --existing   (uniquement après avoir vérifié avec l'utilisateur ce qu'il contient)

Il s'arrête si gh est manquant ou non connecté, avertit lorsque le jeton ne possède pas le scope workflow, et refuse de toucher un dépôt existant sans --existing. Les mêmes étapes à la main :

gh repo create "$ACCOUNT/$REPO" --public --description "Site personnel"
gh api -X POST "repos/$ACCOUNT/$REPO/pages" -f build_type=workflow   # PUT si Pages existe déjà
git remote add origin "https://github.com/$ACCOUNT/$REPO.git"
gh api "repos/$ACCOUNT/$REPO/pages" --jq '{url: .html_url, source: .build_type}'

Le paramètre Pages se trouve également dans l'interface web sous Settings → Pages → Build and deployment → Source: GitHub Actions.

Étape 5 : déployer

git add -A && git commit -m "Site personnel"
git push -u origin main
gh run watch "$(gh run list --workflow deploy.yml --limit 1 --json databaseId --jq '.[0].databaseId')" --exit-status
curl -sI "https://$REPO/" | head -1      # attendre HTTP/2 200 ; le premier déploiement peut prendre une minute ou deux

Dès lors, chaque push sur main reconstruit et publie. gh workflow run deploy.yml redéploie sans commit.

Étape 6 : vérifier avant de marquer comme terminé

  • Ouvrez l'URL en direct, pas seulement l'aperçu local. Les liens fonctionnent, pas de 404 sur le CSS ou les pages.
  • Prenez des captures d'écran à 1280px et 390px de large, en mode clair et sombre. Pas de défilement horizontal à 390px.
  • Clavier : Tab atteint chaque lien avec un anneau de focus visible. Le contraste du texte répond aux normes WCAG AA dans les deux thèmes.
  • <title>, meta description et lang sont définis ; les images ont alt.
  • Aucun espace réservé comme [année] laissé dans la page publiée, sauf si l'utilisateur a choisi de le garder pour l'instant (dans ce cas, listez-les).

Dépannage

SymptômeCause et correctif
https://<compte>.github.io/ est 404, le site apparaît sous /<dépôt>/Le nom du dépôt n'est pas exactement <compte>.github.io pour le compte propriétaire. Renommer : gh repo rename <compte>.github.io.
404 partout après un run vertLa source Pages est toujours « Deploy from a branch », ou dépôt privé sur un plan gratuit. Réexécuter l'appel build_type=workflow ; rendre le dépôt public (gh repo edit --visibility public --accept-visibility-change-consequences).
Push rejeté : « refusing to allow an OAuth App to create or update workflow »Le jeton n'a pas le scope workflow : gh auth refresh -s workflow.
Job de déploiement : « Branch is not allowed to deploy to github-pages »L'environnement github-pages n'autorise que la branche par défaut. Déployer depuis main, ou ajouter la branche dans Settings → Environments.
gh api .../pages renvoie 409 ou 422Pages existe déjà : utiliser -X PUT au lieu de -X POST.
CSS manquant sur le site en direct uniquementLes chemins absolus supposent la racine. Pour un site de projet (/<dépôt>/), préfixer les chemins avec la base ; assets/build.mjs le fait depuis GITHUB_REPOSITORY.
Ancienne version toujours affichéeCache CDN, jusqu'à ~10 minutes. Vérifiez que le run est terminé et faites un rafraîchissement dur.

Domaine personnalisé (optionnel)

gh api -X PUT "repos/$ACCOUNT/$REPO/pages" -f cname=www.exemple.com
# DNS : CNAME www -> <compte>.github.io ; apex : enregistrements A vers les IPs GitHub Pages (voir docs GitHub)
gh api -X PUT "repos/$ACCOUNT/$REPO/pages" -F https_enforced=true   # une fois le certificat émis

Sortie

Terminez avec : l'URL en direct, l'URL du dépôt, quel fichier éditer pour chaque type de changement (content/profile.json pour le texte, static/style.css pour l'apparence), la liste des espaces réservés encore ouverts, et la commande unique pour prévisualiser localement.

Skills associés