Sentry 提交规范

要解决什么问题

团队一旦采用 Sentry 或类似 issue 驱动的工作流，提交消息就不再是「改了啥」一句话，而是 changelog、审阅和自动关单 的共同输入。格式不统一时，历史难以检索、合并后 issue 关不掉或误关，AI 辅助提交也缺少统一署名方式。

技能如何工作

本技能把 Sentry 提交消息规范 固化成可执行的写作规则，覆盖从分支到页脚的完整链路。

• 分支前置：在功能分支上提交；若在 main/master，先建分支，命名形如 feat/add-user-auth、fix/null-pointer-error。
• 标题行：必填 type，可选 scope；主题用祈使句、现在时，首字母大写、无句号，建议 ≤70 字符；单行总长 ≤100 字符。
• 类型表：feat / fix / ref / perf / docs / test / build / ci / chore / style / meta / license 等，与常见 Conventional Commits 扩展一致。
• 正文：写 what 与 why，不写实现细节；说明动机，必要时对比改前行为。
• 页脚：Fixes #123 合并时关闭 issue；Refs #123 仅关联。变更主要由编码代理生成时，页脚加 Co-Authored-By，且不在主题或正文里写「AI 生成」类文案。

适用边界

规范针对 Sentry 项目语境 与上述类型体系；若团队已绑定其他 commitlint 规则，需对照合并。原则仍是：每次提交单一、可独立审阅，提交后仓库可工作——技能不会替你做原子化拆分，只约束消息形态。