Create Commit Message
根据项目 commitlint 配置生成规范的提交消息。
工作流程
明确变更范围
智能检测变更范围：
当用户未明确指定分析哪些变更时，执行以下逻辑：
检查变更状态：使用 git diff --cached 和 git diff 检查暂存区和工作区。
根据检测结果决定：
- •仅存在暂存变更 → 自动分析暂存变更，生成前先告知："检测到暂存区有变更，正在为暂存区生成提交消息..."
- •仅存在未暂存变更 → 自动分析未暂存变更，生成前先告知："检测到工作区有变更，正在为未暂存变更生成提交消息..."
- •两者都存在 → 必须询问用户指定范围：
- •暂存区变更（staged changes）？
- •未暂存变更（unstaged changes）？
- •全部变更（all changes）？
获取对应的变更内容：
- •暂存区变更：使用
git diff --cached - •未暂存变更：使用
git diff - •全部变更：使用
git diff HEAD
读取项目配置
动态读取最新的 commitlint 配置：
- •读取commitlint.config.ts
- •执行
pnpm exec commitlint --print-config获取完整配置
分析变更
分析变更时必须：
区分主要变更和次要变更：
- •主要：核心功能改动、新增特性、bug 修复
- •次要：因主要变更引起的连锁改动（如重命名导致的 import 更新）
评估变更一致性：
- •所有变更是否服务于单一目的？
- •如果包含多个不相关的改动，建议用户拆分提交
识别不确定的意图：
- •无法准确判断变更目的时，必须向用户请求澄清
- •不要猜测或假设
生成提交消息
根据 commitlint 配置生成消息，遵循：
仅使用项目配置的规则：
- •不引用 Angular 约定、常规提交指南或仓库历史
- •严格遵循读取的配置
使用正确的语言：
- •若用户未明确说明，使用用户的目标语言
聚焦主要变更：
- •提交消息描述主要变更目的
- •次要变更可在详细描述中简要提及
保持简洁准确：
- •清晰描述"做了什么"和"为什么"
- •避免冗余信息
输出格式
仅提供提交消息内容，不执行提交操作：
code
type(scope): subject body footer
使用代码块展示，方便用户复制。
约束检查清单
在生成前确认：
- • 已明确变更范围
- • 已读取最新 commitlint 配置
- • 已区分主要和次要变更
- • 变更符合单一目的原则（或已建议拆分）
- • 不确定的地方已向用户澄清
- • 使用正确的语言
- • 仅提供消息，不执行提交
交互原则
- •保持简洁：避免过多解释，直接提供结果
- •明确范围：智能检测时，生成前必须告知用户是根据哪个范围生成的
- •主动询问：范围不明或意图不清时立即询问
- •建设性建议：发现问题时提供改进建议
- •尊重配置：严格遵循项目规则，不添加个人偏好
示例交互流程
仅有暂存变更（自动检测）
用户: 帮我生成提交消息
助手: 检测到暂存区有变更，正在为暂存区生成提交消息...
[读取配置和变更，分析后提供消息]
code
feat(auth): 添加用户登录功能 实现 JWT 认证和会话管理
同时存在暂存和未暂存变更（需询问）
用户: 帮我生成提交消息
助手: 检测到暂存区和工作区都有变更，需要为哪些变更生成提交消息？
- •暂存区变更
- •未暂存变更
- •全部变更
用户: 暂存区
助手: [分析暂存区变更后提供消息]
code
fix(auth): 修复登录状态持久化问题
常见场景处理
自动检测变更范围
智能检测后必须先告知用户：
当检测到单一类型的变更时，在生成前说明：
- •"检测到暂存区有变更，正在为暂存区生成提交消息..."
- •"检测到工作区有变更，正在为未暂存变更生成提交消息..."
当检测到多种类型的变更时，明确询问：
"检测到暂存区和工作区都有变更，需要为哪些变更生成提交消息？
- •暂存区变更
- •未暂存变更
- •全部变更"
多个不相关的变更
检测到多个不相关改动时：
"检测到多个独立的变更：
- •用户认证功能
- •首页样式调整
建议拆分为两个独立的提交。是否需要指导如何拆分？"
变更意图不明确
无法确定变更目的时：
"这些更改的主要目的是什么？
- •修复某个问题？
- •添加新功能？
- •重构代码？"
仅有次要变更
所有变更都是次要的（如格式化、导入排序）：
按实际情况生成对应的 type（如 style, chore），不要忽略这些变更。