请严格按照以下步骤顺序执行，不要跳过任何判断：
1. 状态检测与暂存策略 (Check & Stage Strategy)
你需要通过执行命令来明确区分“已暂存”和“未暂存”的内容。
- •第一步：检查暂存区
- •执行命令：
git diff --cached --name-only - •判断逻辑：
- •如果有输出（即暂存区有文件）：
- •✅ 锁定范围：接下来的分析和提交仅针对这些已暂存的文件。
- •🚫 禁止操作：不要执行
git add，保持暂存区现状。
- •如果没有输出（即暂存区为空）：
- •执行命令：
git status --porcelain - •如果输出为空：🛑 终止流程，告知用户无变更。
- •如果输出不为空（有未暂存或未追踪的文件）：
- •执行命令：
git add . - •✅ 锁定范围：接下来的分析针对所有文件。
- •执行命令：
- •执行命令：
- •如果有输出（即暂存区有文件）：
- •执行命令：
2. 深度上下文分析 (Deep Context Analysis)
不要只看 diff 的表面，你需要理解代码的意图。
- •获取变更内容：
- •如果刚才锁定的范围是“原暂存区”，使用
git diff --cached。 - •如果刚才执行了
git add .，同样使用git diff --cached。
- •如果刚才锁定的范围是“原暂存区”，使用
- •关键：读取文件上下文
- •对于 diff 中修改的核心文件，必须使用文件读取工具（如
read_file）查看修改处前后的完整代码，以区分fix、feat或refactor。
- •对于 diff 中修改的核心文件，必须使用文件读取工具（如
3. 历史风格一致性校验 (Historical Consistency Check)
- •获取历史记录
- •执行命令：
git log -n 10
- •执行命令：
- •分析一致性模式：
- •Scope (范围) 习惯：观察之前的提交是如何定义范围的。
- •例如：是使用文件名
(user-controller)，还是模块名(auth)，还是目录简写(api)？你生成的 Scope 必须遵循此模式。
- •例如：是使用文件名
- •描述粒度：观察之前的描述是偏向“技术实现细节”还是“业务价值”。
- •特殊标记：检查是否有项目特定的前缀或 ID 引用要求（如果本次 Prompt 规范未覆盖）。
- •Scope (范围) 习惯：观察之前的提交是如何定义范围的。
4. 生成提交信息 (Generate Message)
基于 深度分析(Step 2) 和 历史一致性(Step 3) 的结果，构建符合 Conventional Commits 和 Emoji 规范的提交信息。
- •语言要求：必须使用 中文。
- •一致性强制要求：
- •Scope：必须复用历史记录中已存在的 Scope 命名逻辑（除非是全新的模块）。
- •格式：严格遵守下方的 [提交信息规范]，但措辞风格向历史记录靠拢。
5. 执行与验证 (Execute & Verify)
使用生成的提交信息执行 Git 提交命令。为了在 Windows/PowerShell 等环境下 100% 确保正文格式（如列表项的单换行）不丢失，必须使用临时文件方式。
- •执行步骤：
- •使用
write工具将完整的提交信息写入一个临时文件（如commit.msg）。 - •执行命令：
git commit -F commit.msg - •执行命令：
del commit.msg(Windows) 或rm commit.msg(Linux/macOS)
- •使用
- •强制验证：
- •提交完成后，必须执行
git log -1检查输出。若发现正文丢失或格式严重错乱，必须使用git commit --amend配合临时文件重新修正。
- •提交完成后，必须执行
- •关于签名：
- •不要在命令中显式添加
-S参数。请依赖 Git 的本地配置（如commit.gpgsign）来自动处理签名。
- •不要在命令中显式添加
提交信息规范 (Commit Standards)
格式结构
text
<emoji> <类型>[可选范围]: <描述> [可选正文：详细解释变更原因和内容]
Scope 识别与提取逻辑：
- •优先原则：严格复用
git log中的既有 Scope。 - •目录推断：若无历史参考，根据修改文件路径提取核心模块名。
- •
src/components/Button.tsx->(components) - •
skill/git-commit/SKILL.md->(git-commit)
- •
- •全局变更：若涉及多个模块或根目录配置，不写 Scope。
行长度规范：每行建议控制在 72 个字符以内。标题行必须精炼，正文内容若过长请手动换行。
Emoji 与类型对照表
| Emoji | 类型 (Type) | 适用场景 |
|---|---|---|
| ✨ | feat | 引入新功能 (Minor version) |
| 🐛 | fix | 修复 Bug (Patch version) |
| 📚 | docs | 仅修改文档 |
| 🎨 | style | 代码格式调整 (空格、分号等，不影响逻辑) |
| ♻️ | refactor | 代码重构 (非新增功能也非修复 Bug) |
| ⚡️ | perf | 性能优化 |
| 🧪 | test | 添加或修改测试 |
| 📦 | build | 构建系统或外部依赖变更 |
| 🚀 | ci | CI/CD 配置变更 |
| 🧹 | chore | 日常维护、工具配置等 |
| ⏪ | revert | 撤销之前的提交 |
示例场景
场景 1：历史记录显示 Scope 偏好模块名
- •你执行
git log发现记录多为feat(auth): ...,fix(payment): ...。 - •当前修改了
src/login/utils.ts。 - •你生成的信息应为：
✨ feat(auth): 添加登录重试机制(而不是feat(utils)或feat(login/utils))。
场景 2：用户完全没操作 Git，直接让你提交
- •你执行状态检查 ->
git add .-> 读取src/api.ts。 - •你执行
git log，发现最近都是⚡️ perf(network): ...风格。 - •你提交：
git commit -m "⚡️ perf(network): 调整请求超时时间以优化体验"。
开始执行
请立即按照【步骤 1】检查暂存区状态，并开始流程。