Communitygithub.com

Daniel-DB-hub/developer-portfolio

À utiliser lors de la création de branches, de la mise en scène de fichiers, des commits, des pushs, des rebases, de l'ouverture ou de la fusion de pull requests, de la préparation de versions, ou de la modification des paramètres du dépôt GitHub dans ce projet.

Qu'est-ce que developer-portfolio ?

Ce skill définit un workflow Git strict et reproductible pour les agents IA (tels que Claude Code, Cursor, Codex). Il impose que `production` reste la seule branche à longue durée de vie, interdit toute action directe sur celle-ci et exige la création de branches de tâche éphémères. Les noms de branches doivent suivre des préfixes conventionnels comme `feat/`, `fix/`, `docs/`, etc., en kebab-case. Avant chaque commit, l'agent exécute `git status`, `git diff` et `git diff --staged`, vérifie l'absence de secrets ou de données sensibles, et utilise des messages de commit conventionnels. Les pushs vers `production` sont prohibés ; toute modification de production passe par une pull request avec fusion `squash`. Le skill inclut également un point d'arrêt : Claude doit obtenir une approbation explicite avant de fusionner. Enfin, un rapport de complétion détaillé est généré, couvrant la branche, les commits, les vérifications, l'état de la PR, l'audit de confidentialité et les risques résiduels. Il est conçu pour les développeurs et les équipes utilisant GitHub comme plateforme de collaboration.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Daniel-DB-hub/developer-portfolio/tree/HEAD/.claude/skills/following-git-workflow

Demander à votre IA préférée

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

Documentation

Suivre le workflow Git

Règle fondamentale

production est la seule branche à longue durée de vie. Ne jamais travailler directement dessus.

Avant toute action d'écriture Git :

  1. Exécuter git status --short --branch.
  2. Confirmer qu'il n'y a pas de fichiers ou de modifications inattendus.
  3. Récupérer le dépôt distant.
  4. Créer ou basculer vers une branche de tâche éphémère.
  5. Limiter la branche à un seul objectif.

Noms de branches

Utiliser :

  • feat/<scope>
  • fix/<scope>
  • hotfix/<scope>
  • test/<scope>
  • docs/<scope>
  • refactor/<scope>
  • chore/<scope>

Utiliser des minuscules en kebab-case. Ne jamais utiliser main, dev-production, changes, update, ou des noms vagues similaires.

Avant le commit

  1. Examiner git diff et git diff --staged.
  2. Supprimer les fichiers non liés.
  3. S'arrêter si des secrets, des preuves privées, des URL internes, des sessions IA brutes, des données clients ou des données étudiants apparaissent.
  4. Exécuter les vérifications pertinentes pour le périmètre modifié.
  5. Utiliser un message de commit conventionnel.
  6. Ne jamais ajouter de co-auteur IA sauf demande explicite.

Push et pull request

  • Ne jamais pousser directement vers production.
  • Ne jamais forcer le push de production.
  • Ne jamais contourner les hooks ou les vérifications obligatoires.
  • Ne jamais utiliser --force simple.
  • Utiliser --force-with-lease sur une branche de tâche uniquement après approbation explicite.
  • Toute modification de production passe par une pull request.
  • Suivre .github/pull_request_template.md.

Limite de fusion

Claude doit s'arrêter avant toute fusion, sauf si Randi approuve explicitement la fusion de la pull request spécifique dans la conversation en cours.

Utiliser uniquement la fusion squash. Supprimer la branche de tâche après la fusion.

Rapport de complétion

Rapporter :

  • Branche
  • Commits
  • Vérifications effectuées et résultats
  • État de la pull request
  • Revue de confidentialité
  • Risques restants
  • Si l'approbation de fusion est toujours requise

Politique complète

Lire et suivre :

  • docs/governance/git-workflow.md
  • docs/governance/github-configuration.md

Skills associés