mgiovani/cc-arsenal

git-commit

Generate a conventional commit message (conventionalcommits.org) from the staged/unstaged diff and create the commit. Use when the user wants to commit, stage changes, or needs a commit message written. Not for release commits or changelogs (use git-release) or branch-finish workflows (use gitflow).

First seen Mar 7, 2026

Installation

$ npx skills add mgiovani/cc-arsenal --skill git-commit

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from mgiovani/cc-arsenal · top by installs.

npx skills add mgiovani/cc-arsenal

Browse all from mgiovani/cc-arsenal

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 7
License LICENSE
Default branch main
Open issues 10
Status Active

Skill metadata

Parsed from SKILL.md frontmatter.

Version1.0.0
Declared agents claude-code
More metadata
author
mgiovani
version
1.0.0

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,342 B
  • docs SUMMARY.md 318 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 21 installs

SKILL.md

Git Commit

Generate a conventional commit message and create the commit.

Quality Guidelines

Base the message only on what the diff actually shows, not assumptions:

  1. Read git status and git diff --staged (or git diff if nothing is staged yet) before writing anything.
  2. Check which files/modules changed before setting scope.
  3. Look for removed exports, changed signatures, deleted functions to catch breaking changes.
  4. If the purpose of a change is unclear, ask the user rather than guess.

Pre-commit Linting

In Claude Code, a PreToolUse hook runs before every git commit: it detects the project's linter (Node's npm/bun/pnpm/yarn run lint, Python's ruff/flake8, make lint, rubocop, golangci-lint) and blocks the commit if it fails. No linter configured means the commit proceeds unblocked. Outside Claude Code (no hook support), run the project's lint command yourself before committing. Never bypass a failing lint with --no-verify: fix the errors and re-run the commit instead.

Workflow

  1. Run git status and git diff --staged to see what actually changed.
  2. If the diff mixes unrelated concerns (e.g. a feature plus an unrelated fix plus docs),

split into separate commits by staging each group with git add <files> and committing them one at a time. Otherwise, one commit is enough, don't force a split.

  1. For each commit, pick the type:

- feat: new feature - fix: bug fix - docs: documentation only - style: formatting, no code meaning change - refactor: neither fixes a bug nor adds a feature - perf: performance improvement - test: adding or correcting tests - build: build system or dependency changes - ci: CI configuration/scripts - chore: everything else that doesn't touch src or tests - revert: reverts a previous commit

  1. Format as type(scope): description, scope optional, description imperative mood

("add" not "added"), max ~50 characters. Skip the body for a typo fix or a single dependency bump; add a wrapped body (why, not how) once the change alters behavior or touches multiple files. For breaking changes, append ! after the scope and add a BREAKING CHANGE: ... footer.

Example formats

feat(auth): add OAuth2 login support
fix(api): resolve null pointer in user endpoint
docs: update installation instructions
chore(deps): bump lodash to 4.17.21

feat(shopping-cart)!: remove deprecated calculate method

BREAKING CHANGE: calculate has been removed, use computeTotal instead

Ask for confirmation before committing if the changes are complex or span multiple concerns; otherwise just commit.