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 约定、常规提交指南或仓库历史
• 严格遵循读取的配置

使用正确的语言：

• 若用户未明确说明，使用用户的目标语言

聚焦主要变更：

• 提交消息描述主要变更目的
• 次要变更可在详细描述中简要提及

保持简洁准确：

• 清晰描述"做了什么"和"为什么"
• 避免冗余信息

输出格式

仅提供提交消息内容，不执行提交操作：

type(scope): subject

body

footer

使用代码块展示，方便用户复制。

约束检查清单

在生成前确认：

• 已明确变更范围
• 已读取最新 commitlint 配置
• 已区分主要和次要变更
• 变更符合单一目的原则（或已建议拆分）
• 不确定的地方已向用户澄清
• 使用正确的语言
• 仅提供消息，不执行提交

交互原则

• 保持简洁：避免过多解释，直接提供结果
• 明确范围：智能检测时，生成前必须告知用户是根据哪个范围生成的
• 主动询问：范围不明或意图不清时立即询问
• 建设性建议：发现问题时提供改进建议
• 尊重配置：严格遵循项目规则，不添加个人偏好

示例交互流程

仅有暂存变更（自动检测）

用户: 帮我生成提交消息

助手: 检测到暂存区有变更，正在为暂存区生成提交消息...

[读取配置和变更，分析后提供消息]

feat(auth): 添加用户登录功能

实现 JWT 认证和会话管理

同时存在暂存和未暂存变更（需询问）

用户: 帮我生成提交消息

助手: 检测到暂存区和工作区都有变更，需要为哪些变更生成提交消息？

• 暂存区变更
• 未暂存变更
• 全部变更

用户: 暂存区

助手: [分析暂存区变更后提供消息]

fix(auth): 修复登录状态持久化问题

常见场景处理

自动检测变更范围

智能检测后必须先告知用户：

当检测到单一类型的变更时，在生成前说明：

• "检测到暂存区有变更，正在为暂存区生成提交消息..."
• "检测到工作区有变更，正在为未暂存变更生成提交消息..."

当检测到多种类型的变更时，明确询问：

"检测到暂存区和工作区都有变更，需要为哪些变更生成提交消息？

• 暂存区变更
• 未暂存变更
• 全部变更"

多个不相关的变更

检测到多个不相关改动时：

"检测到多个独立的变更：

• 用户认证功能
• 首页样式调整

建议拆分为两个独立的提交。是否需要指导如何拆分？"

变更意图不明确

无法确定变更目的时：

"这些更改的主要目的是什么？

• 修复某个问题？
• 添加新功能？
• 重构代码？"

仅有次要变更

所有变更都是次要的（如格式化、导入排序）：

按实际情况生成对应的 type（如 style, chore），不要忽略这些变更。