Agent Skills: Git Commit Message Generator

Generates conventional commit messages from git diffs. Use when you need well-formatted commit messages following Conventional Commits.

UncategorizedID: vasilyu1983/AI-Agents-public/dev-git-commit-message

Install this agent skill to your local

pnpm dlx add-skill https://github.com/vasilyu1983/AI-Agents-public/tree/HEAD/frameworks/shared-skills/skills/dev-git-commit-message

Skill Files

Browse the full folder contents for dev-git-commit-message.

Download Skill

Loading file tree…

frameworks/shared-skills/skills/dev-git-commit-message/SKILL.md

Skill Metadata

Name
dev-git-commit-message
Description
"Generates or validates Conventional Commits messages from staged diffs. Use when drafting commit messages, checking repo rules, or inferring scope from changed files."

Git Commit Message Generator

Generate or validate Conventional Commits for the staged surface.

Default posture: subject line first; body only when risk, rationale, or breaking-change detail is needed; standard types only unless the repo already defines custom ones; never claim behavior not visible in the diff.

Quick Reference

| Need | Default | Reference | |------|---------|-----------| | Pick a type | feat/fix/perf/refactor/docs/test/build/ci/chore/style/revert | Type Selection table below | | Format a subject | type(scope): imperative summary, ≤72 chars (50 ideal), no trailing period | Pre-Commit Message Checklist below | | Mark a breaking change | ! after type/scope, or a BREAKING CHANGE: footer | Breaking Change Format table below | | Decide on a body | Only for risk, non-obvious rationale, or breaking-change detail | Body Required? table below | | Handle AI-authored commits | No tool attribution ever; Assisted-by: trailer only if the repo opts in | AI-Authored Commits below | | Pick a release/changelog tool | release-please for reviewed PR releases; semantic-release for full automation; changesets for monorepos | references/changelog-generation-guide.md | | Scope a monorepo commit | package/app/service directory name, one level deep, stable over time | references/monorepo-commit-conventions.md | | Validate a message locally | python scripts/commit_validator.py validate --message "..." | Scripts section below |

Decision Tables

Mode Selection

| Trigger | Mode | Action | |---------|------|--------| | User provides staged diff or asks to commit | Generate | Inspect staged surface, produce primary + alternatives | | User provides an existing message string | Validate | Check rules, return PASS/WARN/FAIL + exact rewrite | | Staged diff mixes unrelated areas | Split | Recommend split commits before generating | | No staged changes | Stop | Report "no staged changes" |

Type Selection

| Change | Type | Notes | |--------|------|-------| | New user- or API-visible capability | feat | Triggers MINOR bump | | Incorrect behavior corrected | fix | Triggers PATCH bump | | Measurable speed or memory improvement | perf | Triggers PATCH bump | | Structure improved, behavior unchanged | refactor | No release by default | | Documentation only | docs | No release by default | | Tests only | test | No release by default | | Build tooling or packaging | build | No release by default | | CI/CD workflow | ci | No release by default | | Repo hygiene, no product change | chore | No release by default | | Whitespace or formatting only | style | No release by default | | Reverting a prior commit | revert | Triggers PATCH bump | | Security fix | fix(security): | Prefer standard type + scope over custom security: type | | Prompt/skill/YAML behavioral change | feat or fix | Do not classify by file extension alone |

Scope Selection

| Situation | Action | |-----------|--------| | Repo has a scope map in config.yaml | Use mapped scope | | One directory or package clearly dominates | Use that name, lowercase kebab-case | | Change spans 2+ stable areas equally | Use broader parent scope or omit | | Repository-wide change | Omit scope | | Monorepo with independently versioned packages | See references/monorepo-commit-conventions.md |

Body Required?

| Condition | Include body? | |-----------|--------------| | Subject is self-explanatory | No | | Reason is non-obvious from subject | Yes — one sentence why | | Security-sensitive or risky change | Yes — risk/rollback note | | Breaking change | Yes — BREAKING CHANGE: footer required | | Caller requests detailed template | Yes — use assets/template-commit-message.md |

Breaking Change Format

| Signal | Format | |--------|--------| | Inline marker | feat(api)!: change auth to OAuth2 | | Footer | BREAKING CHANGE: <migration summary> | | Both | Acceptable; footer body gets the detail |

Before/After Examples

BAD:  update
GOOD: docs(readme): add deployment instructions

BAD:  fix stuff
GOOD: fix(cart): prevent negative quantity on rapid add

BAD:  feat: added user dashboard (past tense, missing scope)
GOOD: feat(dashboard): add analytics overview panel

BAD:  feat: add search (generated by Copilot)
GOOD: feat(search): add full-text product search

BAD:  feat(api): add comprehensive user search endpoint with full-text search across all profile fields including bio and location
GOOD: feat(api): add full-text user search endpoint

BAD:  feat: add dashboard, fix auth bug, update deps  (mixed concerns)
GOOD: (3 separate commits)
      feat(dashboard): add analytics overview panel
      fix(auth): correct token refresh race condition
      chore(deps): update react to 18.3.0

Pre-Commit Message Checklist

  • [ ] Starts with a valid type prefix (feat, fix, docs, test, refactor, perf, build, ci, chore, style, revert)
  • [ ] Subject is 72 characters or fewer (50 preferred)
  • [ ] Imperative mood: "add" not "added", "fix" not "fixing"
  • [ ] No trailing period on subject line
  • [ ] Scope, if used, matches repo conventions (lowercase kebab-case)
  • [ ] Single logical change; unrelated concerns split into separate commits
  • [ ] No tool/assistant attribution in subject or body
  • [ ] No generic placeholders: "update", "fix stuff", "WIP", "misc"
  • [ ] Breaking changes marked with ! or BREAKING CHANGE: footer
  • [ ] Body present only when needed; answers "why", not "what"

Workflow

  1. Decide mode from the Mode Selection table above.
  2. For generate mode, inspect staged changes in this order:
    • git diff --staged --name-status
    • git diff --staged --stat
    • git diff --staged --unified=1 only when type, scope, or risk is ambiguous
  3. Classify type and scope using the tables above.
  4. Detect scope from config.yaml first, then from the nearest stable directory.
  5. Generate: one primary suggestion, up to two alternatives when scope or emphasis is ambiguous, short rationale.
  6. Validate: run all checklist items, return PASS/WARN/FAIL with exact rewrite on failure.
  7. If the diff mixes unrelated work, recommend split commits before offering a combined message.

Output Contract

Generate

[NOTE] Suggested commit messages (3 files changed)

PRIMARY:
fix(auth): reject expired refresh tokens

ALTERNATIVES:
1. fix(api): reject expired refresh tokens
2. fix: reject expired refresh tokens during rotation

RATIONALE:
- Type: fix
- Scope: auth
- Signals: token validation path, regression test update, no new feature surface

Validate

VALIDATION: WARN

Message:
feat: update stuff

Issues:
- `update stuff` is too vague
- summary should name the changed behavior or surface

Suggested fix:
feat(auth): add refresh token rotation

AI-Authored Commits

The commit message describes the change, not the tool that produced it. Apply the same rules regardless of whether a human or an AI agent drafted the code.

Banned in subject and body: generated by, co-authored-by: <ai-tool>, via copilot, via claude, chatgpt, ai assistant, bot.

If your team requires an audit trail for AI-assisted code, add an Assisted-by: trailer as an opt-in team policy (not a default). Keep it out of the subject line. Example:

feat(search): add full-text product search

Assisted-by: claude-sonnet-4-6

This is an organizational opt-in pattern, not a general requirement. The default rule remains: no attribution.

Assisted-by: is a distinct trailer from Co-Authored-By: — several large open-source projects (Linux Kernel, Apache Software Foundation, LLVM, QEMU) have converged on Assisted-by: through 2026 specifically because Co-Authored-By: implies authorship/copyright standing that an AI tool cannot hold or sign a CLA for. If a repo already uses Co-Authored-By: <ai-tool> by convention, do not silently rewrite it to Assisted-by: — flag the distinction and let the maintainer choose; changing trailer conventions after history exists breaks blame/provenance tooling that greps for the old trailer.

Repo Policy Checks

Block or rewrite messages that:

  • omit the type prefix
  • use vague summaries: update, fix stuff, change code, WIP, misc
  • include assistant/tool attribution (see above)
  • overstate impact not visible in the diff
  • use past tense or gerund after the type prefix
  • exceed 72 characters on the subject line
  • end the subject line with a period

Scripts

| Script | Purpose | |--------|---------| | scripts/commit_validator.py | Validate a single message, lint a history file, or generate a Markdown quality report |

# Validate one message
python scripts/commit_validator.py validate --message "feat(auth): add refresh token rotation"

# Lint a batch history file
python scripts/commit_validator.py lint --input data/sample-commit-history.json

# Generate a full Markdown report
python scripts/commit_validator.py report --input data/sample-commit-history.json --output report.md

See scripts/README.md for the full quick-start, input format, and rule reference.

Worktree PR Loop

Use this skill as the commit step inside the broader worktree-first delivery loop defined by ../dev-git-workflow/SKILL.md.

In that loop: create or enter feature worktree → make code changes → stage intentionally → use this skill → run repo gate → open PR.

If the staged diff mixes several unrelated surfaces, stop and recommend split commits before the PR step.

Known Traps

  • Inferring scope from filenames alone, producing scopes that do not match the repo's bounded-context map.
  • Compressing unrelated changes into one "clean" conventional commit, destroying revert and release-note usefulness.
  • Treating AI-generated summaries as authoritative when the diff still contains hidden migrations or breaking changes.
  • Optimizing for lint-pass format while losing the operational intent maintainers need for incident archaeology.
  • Using ! or BREAKING CHANGE casually and creating noisy downstream automation.

Navigation

Fact-Checking

  • Conventional Commits spec is v1.0.0 (stable as of July 2026; no v2 released).
  • commitlint is at v21.x (21.2.1 as of July 2026); requires Node 22+; config uses ESM (export default { extends: [...] }).
  • standard-version is deprecated, not archived — the repo carries a deprecation notice pointing to release-please (GitHub-native) or the community fork commit-and-tag-version. Do not recommend it for new projects either way.
  • release-please-action is at v5 (Node 24 runtime, April 2026 breaking change); the underlying release-please package is at v17.x. Re-check the major tag before pinning a workflow — this skill will drift again.
  • semantic-release is at v25.x as of mid-2026 and actively maintained (recent work adds npm trusted publishing).
  • For current tooling, hook behavior, or release-automation recommendations, verify against primary sources in data/sources.json and use web search when available — pinned major-version numbers in this skill are a snapshot, not a guarantee.
  • If browsing is unavailable, mark volatile tool guidance as unverified.

Learnings Loop

Before applying this skill on a non-trivial task, read learnings.consolidated.md in this directory (and learnings.md if present).

After applying it, if you encountered a pattern worth remembering, append one dated bullet to learnings.md via agents-skills-feedback-loop/scripts/append_learning.py. Do not modify SKILL.md itself.