用途
git-commit 用于从当前工作区改动创建一条精心编写的 Git 提交。当用户表达“commit”“commit this”“save my changes”“create a commit”或类似提交意愿时触发。技能描述中未提供更多触发细节，暂未提供。
主要能力
该技能围绕一次提交的完整流程提供规范化操作，包括：收集仓库状态上下文、判断提交信息约定、评估是否拆分为多个逻辑提交、暂存并提交、提交后确认。所有操作都通过 Git 命令完成，不依赖额外服务。
使用方式
技能按以下五个步骤执行。
步骤 1：收集上下文
运行以下命令了解当前状态：
git status
git diff HEAD
git branch --show-current
git log --oneline -10
git rev-parse --abbrev-ref origin/HEAD
最后一条命令返回远端默认分支（如 origin/main），去掉 origin/ 前缀即为分支名。若该命令失败或返回裸 HEAD，可尝试：
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
若两者都失败，回退到 main。
如果 git status 显示工作区干净（无已暂存、已修改或未跟踪文件），则报告没有可提交内容并停止。
运行 git branch --show-current。若结果为空，说明仓库处于游离 HEAD 状态。若用户希望将工作附到分支上，需说明提交前需要分支，并询问是否现在创建功能分支。使用平台提供的阻塞式提问工具（Claude Code 中为 AskUserQuestion，Codex 中为 request_user_input，Gemini 中为 ask_user）。若没有提问工具，则列出选项并等待用户回复后再继续。
若用户选择创建分支，则根据改动内容推导名称，用 git checkout -b <branch-name> 创建，然后再次运行 git branch --show-current，并将结果作为后续流程的当前分支名。
若用户拒绝，则继续在游离 HEAD 状态下提交。
步骤 2：确定提交信息约定
按以下优先级顺序：
- 已在上下文中的仓库约定：若项目指令（AGENTS.md、CLAUDE.md 或类似文件）已加载并规定了提交信息约定，则遵循它们。不要重新读取这些文件，它们在会话开始时已加载。
- 最近提交历史：若没有明确记录的约定，检查步骤 1 中最近 10 条提交。若出现清晰模式（例如约定式提交、工单前缀、emoji 前缀），则匹配该模式。
- 默认：约定式提交：若以上两者都未提供模式，则使用约定式提交格式：type(scope): description，其中 type 为 feat、fix、docs、refactor、test、chore、perf、ci、style、build 之一。
步骤 3：考虑逻辑提交
在全部暂存之前，扫描改动文件是否属于天然不同的关注点。若修改文件明显可分为独立逻辑变更（例如一个目录的重构与另一个目录的新功能，或针对不同变更的测试文件与源文件），则为每组创建独立提交。
保持轻量：
- 仅在文件级别分组，不要使用 git add -p 或尝试拆分文件内的代码块。
- 若区分明显（不同功能、不相关的修复），则拆分。若模糊不清，一次提交即可。
- 两到三个逻辑提交是理想区间，不要过度切分成大量微小提交。
步骤 4：暂存并提交
运行 git branch --show-current。若返回 main、master 或步骤 1 中解析出的默认分支，则警告用户并询问是继续在此提交还是先创建功能分支。使用平台的阻塞式提问工具（同上）。若没有提问工具，则列出选项并等待用户回复后再继续。若用户选择创建分支，则根据改动内容推导名称，用 git checkout -b <branch-name> 创建，然后再次运行 git branch --show-current，并将结果作为后续流程的当前分支名。
暂存相关文件。优先按名称暂存特定文件，而非 git add -A 或 git add .，以避免意外包含敏感文件（.env、凭据）或不相关改动。
编写提交信息：
- 主题行：简洁、祈使语气，聚焦为什么而非做了什么。遵循步骤 2 确定的约定。
- 正文（需要时）：用空行分隔的正文，用于非简单变更。解释动机、权衡或未来读者需要了解的内容。显而易见的单一目的变更可省略正文。
使用 heredoc 保留格式：
git commit -m "$(cat <<'EOF'
type(scope): subject line here
Optional body explaining why this change was made,
not just what changed.
EOF
)"
步骤 5：确认
提交后运行 git status 验证成功，报告提交哈希与主题行。
适用场景
适用于在 Git 仓库中进行日常提交操作，尤其是希望提交信息规范化、避免误提交敏感文件、并在必要时拆分逻辑提交的场景。技能本身描述中未限定具体项目或语言，暂未提供更多适用场景说明。
限制
- 仅在文件级别分组，不支持拆分文件内代码块。
- 需要交互式提问工具时的体验依赖平台支持，否则需手动等待用户回复。
- 关于收费、价格、平台支持范围、性能效果等信息，资料中暂未提供。