git-commit-specification について
Git のコミット規約を整える開発者向けのスキルです。変更の意図やコミット種別、コミット範囲の整理に加え、基本的な事前確認を扱い、高リスクな履歴操作は標準の対象にしません。
主な機能
- 01コミットメッセージの指針
- 02feat、fix などの種別選択
- 03コミット範囲の整理
- 04コミット前の基本確認
- 05Issue 番号に関するチーム規約
活用シーン
- 01機能や修正のコミットメッセージ作成
- 02目的の異なる変更のコミット分割
- 03コミット前の範囲と機密情報の確認
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/git-commit-specificationを入力して読み込まれたか確認します。
詳細
プロジェクトの README よりGit 提交规范
适用场景
- 编写 commit message
- 判断本次改动应归类为
feat、fix、refactor等哪一类 - 整理提交边界，避免一个提交塞入多类无关改动
- 提交前做最基本的自检
不适用场景
- 讨论具体业务实现方案
- 修改 Git 历史或做高风险 Git 操作
- 只是创建分支，但不涉及提交规范本身
快速指导
- 这个 skill 关注的是“提交如何表达改动意图”，不是 Git 命令大全。
- commit message 优先表达改动性质和目的，常见类型包括：
feat：新增能力fix：修复问题refactor：重构但不改外部行为perf：性能优化test：测试补充或调整docs：文档变更chore：构建、配置、工具链维护
- 提交信息格式保持简洁稳定，例如：
feat: 添加流水线模板功能 #1234 - 一个提交只表达一类主要意图；如果混入多个独立目的，优先拆分提交。
- 提交前先做最小自检：改动范围是否聚焦、是否包含敏感信息、是否通过必要验证。
- 高风险历史整理操作不应作为默认建议写进主 skill；如确有需要，应按具体场景单独判断。
高信号规则
- commit message 的核心是让评审者快速理解“这次改动为什么存在”
- 类型选择要服务于改动意图，不要机械套用
- 提交边界清楚，比 message 写得花更重要
- Issue 编号、范围标记等信息应服从团队约定，但不要盖过主语义
关键陷阱
- 一个提交同时混入功能、重构、修复和格式化
- message 只写“update”或“fix bug”这类低信息描述
- 把交互式、破坏性或高风险 Git 操作当成默认规范
延伸阅读
- 如需准备 PR，可在当前改动基础上补充评审上下文和验证结果
- 如需处理高风险 Git 历史整理，按具体仓库流程单独判断，不在本 skill 中默认展开
コメント
Markdown 対応