Commit Messages 技能用于在创建 Git 提交时遵循统一的提交信息规范，格式基于 Conventional Commits。
【前置条件】 提交前需确保工作在 feature 分支上，而非 master 分支。检查当前分支命令： git branch --show-current 若在 master 上，先创建新分支： git checkout -b <type>/<brief-description>
【分支命名】 分支命名遵循模式：{type}/{brief-description}。若工作关联某个 feature epic，可包含 feature ID：{type}/{feature-id}-{brief-description}。示例：feat/add-user-auth、feat/FT050-workflow-automation、fix/resolve-link-validation、docs/workflow-guide、chore/update-ruby-version。
【提交格式】 <type>: <summary>
<body>
<footer> 其中 summary 为必填，body 和 footer 在需要上下文时为可选。
【提交类型】 feat：新功能；fix：缺陷修复；docs：仅文档；style：代码格式（不影响逻辑）；refactor：代码重构（不改变行为）；test：新增或修改测试；chore：构建工具、依赖、配置。
【摘要规则】 少于 50 字符；使用祈使语气（如 “Add feature” 而非 “Added feature”）；首字母大写；结尾不加句号。
【正文指引】 正文用于解释为什么，而非怎么做——代码展示怎么做，提交信息解释为什么。使用祈使语气和现在时；每行 72 字符换行；包含变更动机；必要时对比此前行为。
【示例】 无正文的简单变更：docs: fix typo in workflow guide 带上下文的功能：feat: add link archival endpoint，正文说明实现了 POST /api/v1/links/:id/archive 端点以在不删除的情况下标记链接为归档，并包含校验和数据库迁移。 缺陷修复：fix: resolve popup not opening on Firefox，正文说明 popup.html 因 CSP 问题在 Firefox 加载失败，更新了 manifest.json 的权限。 依赖更新：chore: update Docker base image to Ruby 3.4.2。 重构：refactor: extract link validation to service。 测试新增：test: add archival endpoint tests。
【提交频率】 完成逻辑上完整的工作单元后提交。每次提交应是一个检查点——一段自洽、可独立理解的工作。示例： git commit -m "feat: add archival endpoint skeleton" git commit -m "feat: add archival validation logic" git commit -m "test: add archival endpoint tests" git commit -m "docs: document archival API endpoint" 小而聚焦的提交更易审查，也更容易在需要时回滚。
【Squash Merge 说明】 所有 PR 使用 squash merge，个人的多个提交在合并到 master 时会被合并为一个干净的提交。因此：开发过程中不必纠结于 “fix typo” 这类提交；最终的 squash 提交信息会在合并时润色；master 历史中每个 PR 显示为一次提交。
【Issue 引用】 若项目使用 issue 跟踪（GitHub Issues、Jira、Linear 等），请将 issue ID 引用放在 PR 标题或分支名中，而非提交信息里，以便自动关联和状态更新。示例：分支 feat/GH-128-add-user-auth，PR 标题 feat: add user authentication #128。
【原则】 每次提交应是单一、连贯的变更；提交应能被独立理解；聚焦于变更的原因，而非变更内容。
【参考资料】 Conventional Commits、How to Write a Git Commit Message。