AgentSkillsCN

conventional-commit

采用常规提交规范进行 Git 提交。适用于创建提交或撰写提交信息时使用。

SKILL.md
--- frontmatter
name: conventional-commit
description: Git commit guidelines using conventional commits. Use when creating commits or writing commit messages.
license: MIT

Git Commit and Pull Request Guidelines

Conventional Commits Format

code
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit Types

  • •feat: New features (correlates with MINOR in semantic versioning)
  • •fix: Bug fixes (correlates with PATCH in semantic versioning)
  • •docs: Documentation only changes
  • •refactor: Code changes that neither fix bugs nor add features
  • •perf: Performance improvements
  • •test: Adding or modifying tests
  • •chore: Maintenance tasks, dependency updates, etc.
  • •style: Code style changes (formatting, missing semicolons, etc.)
  • •build: Changes to build system or dependencies
  • •ci: Changes to CI configuration files and scripts

Scope Guidelines

  • •Scope is OPTIONAL: only add when it provides clarity
  • •Use lowercase, placed in parentheses after type: feat(transcription):
  • •Prefer specific component/module names over generic terms
  • •Your current practice is good: component names (EditRecordingDialog), feature areas (transcription, sound)
  • •Avoid overly generic scopes like ui or backend unless truly appropriate

When to Use Scope

  • •When the change is localized to a specific component/module
  • •When it helps distinguish between similar changes
  • •When working in a large codebase with distinct areas

When NOT to Use Scope

  • •When the change affects multiple areas equally
  • •When the type alone is sufficiently descriptive
  • •For small, obvious changes

Description Rules

  • •Start with lowercase immediately after the colon and space
  • •Use imperative mood ("add" not "added" or "adds")
  • •No period at the end
  • •Keep under 50-72 characters on first line

Breaking Changes

  • •Add ! after type/scope, before colon: feat(api)!: change endpoint structure
  • •Include BREAKING CHANGE: in the footer with details
  • •These trigger MAJOR version bumps in semantic versioning

Examples Following Your Style:

  • •feat(transcription): add model selection for OpenAI providers
  • •fix(sound): resolve audio import paths in assets module
  • •refactor(EditRecordingDialog): implement working copy pattern
  • •docs(README): clarify cost comparison section
  • •chore: update dependencies to latest versions
  • •fix!: change default transcription API endpoint

Commit Messages Best Practices

  • •NEVER include Claude Code or opencode watermarks or attribution
  • •Each commit should represent a single, atomic change
  • •Write commits for future developers (including yourself)
  • •If you need more than one line to describe what you did, consider splitting the commit