AgentSkillsCN

git-commit

根据 Conventional Commits 规范,自动生成专业且语义清晰的提交信息。适用场景包括:(1) 编写提交信息;(2) 为版本控制总结代码变更;(3) 准备变更日志或发布说明;(4) 强化提交信息的标准化要求。触发词:「编写提交信息」、「Git 提交」、「描述这些更改」、「Conventional Commit」、「我该提交什么」、「变更日志条目」。

SKILL.md
--- frontmatter
name: git-commit
description: >
  Generate professional, semantic commit messages following Conventional Commits specification.
  Use when: (1) writing commit messages, (2) summarizing code changes for version control,
  (3) preparing changelogs or release notes, (4) enforcing commit message standards.
  Triggers: "write commit message", "git commit", "describe these changes",
  "conventional commit", "what should I commit as", "changelog entry".

Git Commit Message Generator

Generate clear, semantic commit messages following the Conventional Commits specification and best practices from major open-source projects.

Conventional Commits Format

code
<type>(<scope>): <description>

[optional body]

[optional footer(s)]

Types

TypeDescriptionExample
featNew featurefeat(auth): add OAuth2 login
fixBug fixfix(api): handle null response
docsDocumentation onlydocs(readme): add setup instructions
styleFormatting, no code changestyle: fix indentation
refactorCode restructuringrefactor(db): extract query builder
perfPerformance improvementperf(images): add lazy loading
testAdding/fixing teststest(auth): add login unit tests
buildBuild system changesbuild: upgrade webpack to v5
ciCI configurationci: add GitHub Actions workflow
choreMaintenance taskschore: update dependencies
revertRevert previous commitrevert: undo feat(auth) commit

Scope (optional)

  • Module/component name: auth, api, ui, db
  • Feature area: login, checkout, search
  • Layer: frontend, backend, infra

Writing Guidelines

Description (subject line)

  • Use imperative mood: "add" not "added" or "adds"
  • No capitalization at start
  • No period at end
  • Max 50 characters (hard limit: 72)
  • Complete the sentence: "This commit will..."

Body (when needed)

  • Explain what and why, not how
  • Wrap at 72 characters
  • Use bullet points for multiple changes
  • Reference issues: Fixes #123, Closes #456

Footer

  • Breaking changes: BREAKING CHANGE: <description>
  • Issue references: Refs: #123, #456
  • Co-authors: Co-authored-by: Name <email>

Examples

Simple feature

code
feat(search): add fuzzy matching support

Bug fix with context

code
fix(auth): prevent session timeout on active users

Users were being logged out even during active sessions due to
the token refresh not resetting the timeout timer.

Fixes #234

Breaking change

code
feat(api)!: change response format to JSON:API spec

BREAKING CHANGE: API responses now follow JSON:API specification.
All clients must update their response parsing logic.

Migration guide: docs/migration/v2-api.md

Multiple changes (consider splitting)

code
refactor(db): restructure user module

- Extract UserRepository from UserService
- Add connection pooling configuration
- Implement query result caching

Part of #567 (database optimization initiative)

Commit Analysis Workflow

When asked to generate a commit message:

  1. Analyze the diff - Understand what changed
  2. Identify the type - Is it a feature, fix, refactor, etc.?
  3. Determine scope - What module/area is affected?
  4. Write subject - Concise summary in imperative mood
  5. Add body if needed - For non-obvious changes
  6. Check breaking changes - Note any API changes

Anti-patterns to Avoid

  • fix: fix bug (not descriptive)
  • update code (missing type and detail)
  • WIP (don't commit work in progress)
  • misc changes (be specific)
  • Commits with unrelated changes (split them)

Emoji Convention (optional)

Some projects use emoji prefixes:

EmojiType
feat
🐛fix
📚docs
♻️refactor
perf
🧪test
🔧config
🚀deploy

Example: ✨ feat(auth): add biometric login

References