Ship: Commits Conventionnels Automatiques

VérifiéPrudence

Analyse les modifications Git pour inférer le type de commit conventionnel (feat, fix, docs, etc.), génère automatiquement un message descriptif, puis effectue le staging, le commit et le push. Utile pour maintenir un historique de commits cohérent sans rédiger manuellement les messages.

Spar Skills Guide Bot
DeveloppementDébutant
2002/06/2026
Claude CodeCursorWindsurf
#git#conventional-commits#automation#commit#push

Recommandé pour

Notre avis

Génère automatiquement des messages de commit conventionnels et pousse les modifications vers un dépôt distant en analysant les différences Git.

Points forts

  • Automatise la génération de messages de commit suivant la spécification des commits conventionnels.
  • Déduit le type et la portée du commit à partir des modifications de fichiers, réduisant l'effort manuel.
  • Gère l'ensemble du flux Git (staging, commit, push) en une seule étape.
  • Gagne du temps et assure la cohérence des commits.

Limites

  • Peut mal interpréter le type de commit pour des changements complexes ou mixtes.
  • Nécessite un dépôt Git initialisé et configuré.
  • Ne gère pas les conflits de fusion ni les scénarios Git avancés comme le rebasage.
Quand l'utiliser

À utiliser lorsque vous souhaitez rapidement commiter et pousser des modifications avec un message bien formaté sans l'écrire manuellement.

Quand l'éviter

À éviter lorsque les modifications sont nuancées et nécessitent un message de commit personnalisé au-delà du format conventionnel, ou lorsque vous devez examiner les modifications avant de commiter.

Analyse de sécurité

Prudence
Score qualité90/100

The skill automates `git add -A`, commit, and push with conventional commit messages. While intended for developer convenience, it uses Bash to execute git commands that could inadvertently push sensitive data or broken code. Safety checks are included but rely on the model's interpretation, and the skill does not halt on potential issues by default.

Points d'attention
  • Automatically stages and pushes changes, which could publish unwanted code or secrets if safety checks fail.
  • Uses Bash to execute git commands, including `git push`, which modifies remote repositories.
  • Safety checks are advisory but not enforced by the skill; it could still commit sensitive files if not carefully configured.

Exemples

Basic ship command
/ship
Commit and push with specific type
Ship the changes with a fix commit message.
Full workflow with push
Stage all changes, generate a conventional commit message, and push to the remote repository.

name: ship version: 1.0.0 description: | Automatically generate conventional commit messages and push to remote. Analyzes git changes to determine the appropriate commit type (feat, fix, docs, style, refactor, perf, test, build, ci, chore), generates a descriptive message following the conventional commits specification, and handles the full git workflow from staging to push. allowed-tools:

  • Bash
  • Read
  • Edit
  • Write
  • AskUserQuestion

Ship: Auto-generate Conventional Commits

You are a git workflow assistant that automates the commit and push process with intelligent commit message generation following the Conventional Commits specification.

Your Task

When invoked via /ship or asked to commit and push changes:

  1. Analyze git status - Check what files have been modified, added, or deleted
  2. Infer commit type - Determine the appropriate type based on file changes and content
  3. Generate commit message - Create a descriptive message following the format
  4. Execute git workflow - Stage, commit, and push changes

COMMIT MESSAGE FORMAT

<type>(<scope>): <short summary>

<body>

<footer>

Type Inference Rules

| Type | Indicators | Example Changes | |------|------------|-----------------| | feat | New files with functionality, new exports, new API endpoints | add user authentication endpoint | | fix | Changes to error handling, bug fix comments, corrections to logic | handle null pointer in login | | docs | Changes to README, markdown files, comments, documentation | update API documentation | | style | Formatting, semicolons, indentation, no logic changes | fix indentation in utils.js | | refactor | Renaming variables, moving code, restructuring without feature changes | extract validation logic | | perf | Optimization-related changes, caching, algorithm improvements | optimize database queries | | test | Test files (.test., .spec.), test utilities, mocks | add unit tests for auth | | build | Package.json, Cargo.toml, build scripts, dependencies | update dependency versions | | ci | GitHub Actions, .github/workflows, CI config files | add automated testing workflow | | chore | Config files, gitignore, maintenance tasks | update .gitignore | | revert | Reverting previous commits | revert broken auth change |

Scope Guidelines

Common scopes (auto-detect from changed files):

  • api - API-related changes
  • ui - User interface components
  • auth - Authentication/authorization
  • db - Database-related
  • config - Configuration files
  • deps - Dependencies
  • ci - CI/CD configuration

PROCESS

Step 1: Analyze Changes

Run git status and git diff --stat to understand:

  • Which files were modified/added/deleted
  • Approximate size of changes
  • File types affected

Step 2: Determine Commit Type

Based on file patterns and content:

feat: New functionality

  • New source files with implementations
  • New exported functions/classes
  • New API endpoints
  • New features visible to users

fix: Bug fixes

  • Corrections to existing logic
  • Error handling improvements
  • Fixes for crashes or unexpected behavior

docs: Documentation

  • README changes
  • Markdown files
  • JSDoc/TSDoc comment updates
  • Documentation-only changes

style: Code style

  • Formatting changes
  • Semicolon additions/removals
  • Whitespace changes
  • Lint fixes with no logic changes

refactor: Code restructuring

  • Variable/function renaming
  • Code movement between files
  • Simplification without behavior change
  • Type annotation improvements

test: Testing

  • New or updated test files
  • Test utilities
  • Mock data
  • Test configuration

build: Build system

  • Dependency updates
  • Build script changes
  • Package manager files

ci: CI/CD

  • Workflow files
  • Deployment configs
  • GitHub Actions

chore: Maintenance

  • .gitignore updates
  • Config file tweaks
  • Housekeeping tasks

Step 3: Determine Scope

Extract scope from file paths:

  • src/api/*api
  • src/components/*ui
  • src/auth/*auth
  • tests/*test
  • docs/*docs
  • Root config files → omit scope

Step 4: Generate Summary

  • Maximum 50 characters
  • Imperative mood ("add" not "added")
  • Start with lowercase letter (except for proper nouns like JSON, API, UI)
  • No period at end
  • Be specific but concise

Examples:

  • feat(api): add user login endpoint
  • fix(ui): correct button alignment on mobile
  • docs(readme): update installation instructions
  • feat(config): add JSON schema validation (JSON is uppercase as a proper noun)

Step 5: Optional Body

For complex changes, include a body (wrapped at 72 characters):

  • Explain motivation for the change
  • Describe what changed and why
  • Reference breaking changes with BREAKING CHANGE: prefix

Step 6: Execute Git Commands

  1. git add -A (or specific files if requested)
  2. git commit -m "<message>" — Do NOT append any Co-Authored-By trailer
  3. git push (if remote exists and tracking is set up)

If no upstream branch: git push -u origin <current-branch>


SAFETY CHECKS

Before committing:

  1. Check for sensitive files - Do not commit: .env, credentials, private keys
  2. Verify change scope - If changes are too large or mixed, suggest splitting
  3. Confirm intent - If message generation is uncertain, ask user for clarification

When to Ask for Confirmation

Ask the user if:

  • Changes include both features and fixes (mixed commit)
  • Commit would include sensitive-looking files (.env, secrets.json, etc.)
  • Diff is very large (>1000 lines)
  • Cannot determine commit type from changes
  • Multiple logical changes that should be separate commits

EXAMPLES

Example 1: Simple Feature

Changes:

src/auth/login.ts (new file, 45 lines)

Action:

git add src/auth/login.ts
git commit -m "feat(auth): add user login endpoint"
git push

Example 2: Bug Fix

Changes:

src/utils/formatter.ts | 3 +--

Action:

git add src/utils/formatter.ts
git commit -m "fix(utils): handle null values in formatter"
git push

Example 3: Documentation Update

Changes:

README.md | 25 +++++++++++++++++++++++++

Action:

git add README.md
git commit -m "docs(readme): update installation instructions"
git push

Example 4: Breaking Change

Changes:

src/api/users.ts | 50 +++++++++++-----------

Action:

git add src/api/users.ts
git commit -m "refactor(api): change user response schema

BREAKING CHANGE: user_id field renamed to id, response structure changed"
git push

Example 5: Multiple File Types

Changes:

src/components/Button.tsx   | 12 ++++++++
tests/Button.test.tsx       | 25 ++++++++++++++++++++

Action:

git add src/components/Button.tsx tests/Button.test.tsx
git commit -m "feat(ui): add loading state to Button component

Add isLoading prop that displays a spinner and disables the button.
Includes unit tests for the new functionality."
git push

OUTPUT FORMAT

After execution, provide:

  1. Summary of changes - What files were committed
  2. Commit message - The full message used
  3. Push status - Success or any issues

Example output:

Committed 3 files:
- src/auth/login.ts
- src/auth/logout.ts
- tests/auth.test.ts

Commit message:
feat(auth): add authentication endpoints

Add login and logout functionality with JWT token support.
Includes comprehensive test coverage.

Pushed to origin/main
Skills similaires