← ClaudeAtlas

git-conventionslisted

Conventional commits et garde-fous git. Se charge sur : git commit, git push, git branch, git checkout -b, git merge, git rebase, git reset, git pull, git cherry-pick, git revert, création de PR (gh pr create), édition de message de commit. Couvre : messages conventional (feat:, fix:, refactor:, docs:, chore:, test:, style:, perf:, build:, ci:), nommage de branches (feat/*, fix/*, chore/*), messages et descriptions de PR, garde-fous destructifs (force push, reset --hard, branch -D, clean -f, push --force). Hors /codebloom:push qui gère son propre flow. Ne se charge PAS quand : opération git en lecture seule (git status, git log, git diff, git show, git blame).
vendeesign/codebloom · ★ 3 · Code & Development · score 67
Install: claude install-skill vendeesign/codebloom
# Git Conventions — Guide automatique Ce skill s'active quand des opérations git sont effectuées en dehors de la commande `/codebloom:push`. ## Conventional Commits Format : `type(scope): description` ### Types | Type | Quand | |------|-------| | `feat` | Nouvelle fonctionnalité | | `fix` | Correction de bug | | `refactor` | Restructuration sans changement de comportement | | `docs` | Documentation uniquement | | `test` | Ajout ou modification de tests | | `chore` | Maintenance, config, CI | | `style` | Formatage, espaces, points-virgules | | `perf` | Amélioration de performance | ### Règles de message - **Impératif** : "add feature" pas "added feature" - **Minuscule** : pas de majuscule après le type - **Court** : max 72 caractères pour la première ligne - **Descriptif** : expliquer le "pourquoi" dans le body si nécessaire - **Scope** : optionnel, indique le module/composant concerné ### Exemples ``` feat(auth): add JWT token refresh fix(api): handle timeout on slow connections refactor: extract validation logic into helpers docs: update API endpoints in README ``` ## Nommage de branches Format : `type/description-courte` ``` feature/user-auth fix/login-timeout chore/update-deps refactor/api-structure ``` ## Granularité des commits - **Un commit = un changement logique** — pas un dump de fin de journée - Séparer refactoring et feature dans des commits distincts - Si le message nécessite "et" → probablement 2 commits - Commit fréquent en local, squash si nécessa