home / skills / einverne / dotfiles / git-commit-formatter

git-commit-formatter skill

safe

This skill generates conventional commit messages from staged changes, ensuring clear scope and concise subject lines for consistent project history.

npx playbooks add skill einverne/dotfiles --skill git-commit-formatter

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.3 KB

---
name: git-commit-formatter
description: 生成符合 Conventional Commits 规范的 Git 提交信息。当用户要求生成提交、创建 commit 或写提交信息时使用
---

# Git 提交信息格式化器

## 任务说明

分析暂存区的代码变更，生成符合 Conventional Commits 规范的提交信息。

## 规范说明

提交信息格式：`<type>(<scope>): <subject>`

类型定义：
- feat: 新功能
- fix: 修复缺陷
- docs: 文档更新
- style: 代码格式调整（不影响逻辑）
- refactor: 重构代码
- perf: 性能优化
- test: 测试相关
- build: 构建系统或依赖更新
- ci: CI 配置更新
- chore: 其他不修改源代码的更改

## 执行步骤

1. 运行 `git diff --cached` 查看暂存的变更
2. 分析文件变更，识别主要修改类型
3. 确定影响范围（scope）
4. 生成简洁的主题（subject），限制在 50 字符内
5. 如有重大变更，添加 BREAKING CHANGE 说明

## 质量标准

必须遵守：
- subject 使用动词开头，现在时态
- subject 不以句号结尾
- scope 用括号包裹，可选但建议提供
- 如有详细说明，body 每行不超过 72 字符

## 示例输出

```
feat(auth): 实现 JWT 令牌认证

- 添加 JWT 生成和验证逻辑
- 实现令牌刷新机制
- 添加相关单元测试
```

Overview

This skill generates Git commit messages that conform to the Conventional Commits specification. It inspects staged changes and produces a clear <type>(<scope>): <subject> header plus optional body and BREAKING CHANGE notes. The goal is consistent, concise commits for dotfiles and related tooling changes.

How this skill works

The skill runs a staged-diff analysis (git diff --cached) to identify changed files and detects the dominant change type (feat, fix, docs, etc.). It infers an appropriate scope from file paths (e.g., vimrc, tmux, zsh) and drafts a present-tense subject limited to 50 characters. If larger or breaking adjustments are present, it appends a body with bullet points and a BREAKING CHANGE section as needed.

When to use it

Creating a new commit for dotfiles or configuration updates
When you want Conventional Commits formatting automatically applied
Writing commit messages after staging changes with dotbot or manual staging
Preparing commits that will be parsed by changelog or CI tools
Ensuring consistent commit history across personal configs and tooling

Best practices

Run the formatter after staging only the intended changes (git add)
Choose a single primary change type per commit for clarity
Provide a concise scope based on the affected config (e.g., vim, tmux)
Keep the subject verb-first and present tense, no trailing period
Add a short body when context or steps are required; wrap at 72 chars

Example use cases

feat(vim): add plugin configuration for fzf and ripgrep
fix(tmux): correct pane sizing logic in tmux.conf
docs(zsh): update aliases and document new login flow
chore(dotbot): update installation script and zinit plugin list
perf(vim): optimize plugin load order to reduce startup time

FAQ

How does the skill choose the commit type?

It analyzes file changes and content patterns (new features, bug fixes, docs, build files) to pick the best matching Conventional Commit type; you can override if needed.

What if multiple change types exist in staged changes?

It prefers the dominant change type or suggests splitting into multiple commits for clarity and accurate changelogs.

Will it include a scope automatically?

Yes—scope is inferred from file paths (e.g., vimrc → vim); you can edit or remove the scope before committing.