Commits Git conventionnels

VérifiéSûr

Crée des commits conventionnels expliquant le pourquoi des changements, avec format type(scope): description. Utile pour standardiser l'historique Git et faciliter la génération de changelogs, notamment lors de la validation de modifications.

Spar Skills Guide Bot
DeveloppementIntermédiaire
15002/06/2026
Claude Code
#git#conventional-commits#commit#version-control#workflow

Recommandé pour

Notre avis

Cette compétence permet de créer des commits conventionnels expliquant pourquoi les modifications ont été effectuées, en suivant le format type(scope): description.

Points forts

  • Génère automatiquement des messages de commit conventionnels avec le format approprié
  • Analyse le contexte Git pour détecter les fichiers modifiés et les changements stagés
  • Gère les scénarios complexes comme l'amendement, le fixup et le squash
  • Intègre la gestion des plans actifs et l'archivage après commit

Limites

  • Nécessite que l'agent dispose des permissions d'exécution Git
  • Peut ne pas détecter parfaitement le scope approprié pour chaque modification
  • La gestion des hooks d'échec peut nécessiter une intervention manuelle
Quand l'utiliser

Utilisez cette compétence lorsque vous souhaitez effectuer un commit avec un message bien formaté et conforme aux conventions, ou pour amender, fixup ou squasher des commits existants.

Quand l'éviter

Évitez de l'utiliser si vous préférez écrire manuellement vos messages de commit ou si le projet n'utilise pas les commits conventionnels.

Analyse de sécurité

Sûr
Score qualité95/100

The skill uses only git commands and file utilities for conventional commits, plus ct plan archive/list. No destructive ops, network access, or external data processing. Hook failure handling is cautious and safe.

Aucun point d'attention détecté

Exemples

Commit staged changes
Commit my staged changes with a descriptive conventional message.
Amend previous commit
Amend the last commit to include the new changes and update the message.
Squash recent commits
Squash the last three commits into one with a clear message.

name: commit description: "Use when the user wants to commit, save changes, create a conventional commit, amend a commit, make a fixup commit, or squash commits." user-invocable: true context: fork agent: general-purpose model: haiku allowed-tools:

  • "Bash(git status)"
  • "Bash(git diff:*)"
  • "Bash(git log:*)"
  • "Bash(git add:*)"
  • "Bash(git commit:*)"
  • "Bash(git notes:*)"
  • "Bash(git branch:*)"
  • "Bash(git rev-parse:*)"
  • Read
  • Glob
  • Grep
  • AskUserQuestion
  • TaskList
  • TaskGet
  • "Bash(ct plan archive:*)"
  • "Bash(ct plan list:*)"

Commit

Create conventional commits explaining WHY changes were made.

Context

Status: !git status -sb 2>/dev/null Staged diff: !git diff --cached --stat 2>/dev/null Recent commits: !git log --oneline -5 2>/dev/null

Main thread / foreground only. Workers never commit — they lack full-branch context to write meaningful messages.

Steps

  1. Analyze: review context above. If nothing staged, read full git diff. If staged, read git diff --cached for details.

  2. Message: conventional commit format — type(scope): description, max 72 chars, lowercase, no period, imperative mood. Types: feat|fix|perf|docs|test|style|build|ci|chore|revert. Scope: primary area or omit if global. Multi-line: blank line then body wrapping at 72 chars explaining motivation not mechanics. If task active (TaskList, filter by project + status=in_progress), append ID: fix(auth): handle token expiry (task-<id>)

  3. Execute using HEREDOC for clean formatting:

    git commit -m "$(cat <<'EOF'
    type(scope): description
    EOF
    )"
    

Post-commit

  1. Plan archive: after successful commit, archive active plans. ct plan list --json returns array of {name, path} — iterate and archive each:
    ct plan list --json
    # For each entry: ct plan archive <path>
    
    Skip silently if no active plans or ct not available.

If gt plugin is loaded → suggest /gt:submit. Otherwise → suggest git push.

Hook Failures

Two scenarios require different recovery:

  • Hooks modify files (formatters, auto-fixers): stage changes and amend — git add -u && git commit --amend --no-edit. Safe because the commit already landed; amend just includes the formatter's tweaks.
  • Hooks reject the commit (lint errors, test failures): show the error, explain the issue, suggest a fix. Do NOT retry automatically — let user decide. After fix, create a NEW commit (don't amend — the original commit never landed, so amend would modify the wrong commit).

Special Ops

  • Amend (--amend): analyze previous commit + new changes, update message if scope changed. Use --no-edit only when new changes don't alter the commit's purpose.
  • Fixup (--fixup=<SHA>): correction targeting a specific earlier commit. User must rebase to squash later.
  • Squash: combine multiple commits — unify message around primary purpose, not a laundry list.

Edge Cases

  • Nothing staged → ask "Stage all changes?" (all vs tracked vs select)
  • Multiple unrelated changes → use /split-commit to separate
  • Clean tree → "No changes to commit"
Skills similaires