commit-message
Commit Message
Generate a high-quality commit message from staged changes following Conventional Commits format.
Context Reuse (Step 0)
See _shared/context-reuse.md for the context reuse protocol.
If DIFF_CONTEXT or RAW_DIFF is already provided, use it directly to save time and tokens.
Read Staged Diff (Step 1)
Run git diff --cached to read staged changes.
If staged diff is empty, tell user to stage files first (e.g., git add <file>), then stop.
Classify Change Type (Step 2)
Infer the most suitable Conventional Commits type:
feat,fix,refactor,docs,style,chore,perf,test
Infer optional scope from changed module/path when clear.
Draft Commit Message (Step 3)
Commit message structure:
Header (required)
Format: type(scope): subject
Why these constraints matter:
- ≤ 72 characters: Git tools truncate longer headers in logs and UIs
- Imperative mood (add/fix/update): Matches Git's own convention ("Merge branch X")
- English subject starts lowercase: Conventional Commits specification requirement
- No trailing period: Standard convention for commit subjects
Examples:
- ✅
fix(auth): handle token refresh race - ❌
fix(auth): Handle token refresh race(uppercase) - ❌
fix(auth): handled token refresh race(past tense)
Body (optional)
Add one blank line after Header, then use list format (2-4 bullet points recommended).
Each bullet should cover what changed and why. This helps future maintainers understand the reasoning behind the change.
Keep concise and specific, include implementation highlights and impact scope.
Footer (optional)
Add one blank line after Body (or after Header if Body omitted).
Use for metadata:
- Breaking changes:
BREAKING CHANGE: <description> - Issue references:
Closes #123,Refs #456 - Co-authors/trailers when needed
Footer content should be factual and directly supported by staged diff/context.
Language and Output Format (Step 4)
See _shared/bilingual-output.md for bilingual output rules.
Default: output both 简体中文 and English versions.
If user explicitly requests single language, output only that language.
Each language gets independent code block with language label above it.
Chinese version: subject and body written in Simplified Chinese (type(scope) remains in English — they are Conventional Commits keywords).
English version: subject and body written in English.
Examples
Simple fix (Header only)
中文
fix(auth): 修复 token 刷新竞态
English
fix(auth): handle token refresh race
Feature with context (Header + Body)
中文
feat(search): 支持结果按更新时间排序
- 新增更新时间排序参数,支持按最近变更优先返回结果。
- 将默认策略从纯相关度改为混合排序,以平衡相关性与时效性。
- 在热门查询场景下更快暴露新内容,提升信息新鲜度。
English
feat(search): support sorting results by updated time
- add an updated-time sorting option to prioritize recently changed content.
- switch default ranking from pure relevance to a hybrid strategy for better balance.
- surface fresh content faster in high-traffic queries to improve recency.
Breaking change (Header + Body + Footer)
中文
refactor(api)!: 重构用户资料更新流程
- 将资料校验与持久化逻辑拆分为独立步骤,降低控制器复杂度。
- 统一错误映射策略,避免不同入口返回不一致状态码。
- 提升模块可测试性,便于后续演进与回归验证。
BREAKING CHANGE: 用户资料更新接口从 PUT /profile 改为 PATCH /users/{id}/profile
Closes #123
English
refactor(api)!: split user profile update pipeline
- separate validation from persistence to reduce controller complexity.
- unify error mapping so different entry points return consistent status codes.
- improve testability to support safer future iterations.
BREAKING CHANGE: profile update endpoint changes from PUT /profile to PATCH /users/{id}/profile
Closes #123
Modern Conventions (Recommended)
- For breaking changes, use bang marker in header (
type(scope)!:) plusBREAKING CHANGE:in footer - Footer trailers should use standardized tokens:
Closes #123,Refs #456,Co-authored-by: Name <email> - Keep Body lines readable (soft wrap around 72-100 chars recommended)
- Avoid noisy wording; prioritize machine-parseable and review-friendly phrasing
Conventions
- Do not fabricate changes not present in staged diff
- Keep terminology consistent with actual code symbols and file paths
- Keep body concise but informative for future review
More from quentinhsu/skills
pr-content
Generate GitHub Pull Request title and description from branch changes. Use this skill whenever the user asks to create PR content, draft a pull request, write PR description, or says things like '生成 PR 内容', '写 PR 描述', '帮我整理 PR 标题和正文', 'generate PR content', 'write PR title and description', 'draft pull request description', 'what should my PR say', or 'help me write this PR'. Also trigger when you see requests for PR templates, PR summaries, or when the user is preparing to open a pull request.
16change-pack
Generate branch name, commit message, and PR content from one shared diff context. Use this skill whenever the user asks to generate multiple git writing artifacts at once, wants to save time by analyzing changes once, or says things like '一口气生成分支名、commit、PR 内容', '链式生成 git 文案', '一次分析改动生成全部', 'generate branch + commit + PR from same diff', 'generate everything', 'all git content from this diff', 'chain generate', or 'one-shot git writing'. This is more efficient than calling individual skills separately because it reads the diff only once and reuses the context.
13branch-name
Generate Git branch names from current branch changes against a base branch. Use this skill whenever the user mentions branch naming, wants to create/rename a branch based on their work, asks for branch name suggestions, or says things like '给这个分支起个名字', '生成分支名', '根据改动起一个 branch 名', 'suggest branch name from diff', 'name this branch based on changes', 'what should I call this branch', or 'name this feature branch'. Also trigger when you see diff-based naming requests or when the user has uncommitted work and asks about branching.
13refactor-migrate
Migrate dependencies, frameworks, or runtime versions with minimal breakage. Use this skill when upgrading libraries, switching frameworks, replacing deprecated APIs, bumping language/runtime versions, or says things like '升级依赖', '迁移到新版本', '替换废弃 API', 'upgrade to v4', 'migrate from X to Y', 'replace deprecated calls', 'bump Node/Python/Go version', 'framework migration', or 'dependency upgrade'. Also trigger when handling breaking changes from a version bump.
3refactor-clean
Perform clean refactoring on any codebase — remove dead code, simplify logic, improve naming, extract abstractions, and reduce complexity without changing behavior. Use this skill when the user asks to clean up code, refactor for readability, reduce complexity, remove unused code, simplify conditionals, flatten nesting, rename for clarity, or says things like '重构一下这段代码', '清理无用代码', '简化逻辑', 'clean up this code', 'refactor for readability', 'reduce complexity', 'remove dead code', 'simplify this function', 'flatten nesting', or 'make this easier to read'. Also trigger when reviewing code quality or performing tech debt cleanup.
3refactor-modernize
Modernize code by replacing legacy patterns with current language features and idiomatic conventions. Use this skill when rewriting old-style code to use modern syntax, adopting new language features, replacing callbacks with async/await, using pattern matching instead of switch, applying modern iteration, or says things like '用现代写法重写', '替换旧语法', '用 async/await 重写回调', 'modernize this code', 'use modern syntax', 'replace legacy patterns', 'convert to async/await', 'use destructuring', 'apply modern idioms', or 'rewrite with current best practices'. Also trigger when adopting new edition features (Rust editions, Python 3.10+ features, ES2024, etc.).
3