仅本地提交

问题：一次改动常常被 git add -A 和一句 update 压扁

多人协作的仓库里，最让人头疼的往往不是写代码，而是提交信息。开发者想的通常是「先存一下本地」，但顺手执行的 git add -A && git commit -m "update" 会把与本次任务无关的改动一起吞进去：调试用的 console.log、改了一半的样式、某次实验性的分支文件。评审者看提交历史时，无法按主题快速定位这次到底动了什么。反过来，也有开发者为了一条提交反复在编辑器里和 Git 的交互式提示较劲，打乱了原本的工作节奏。

「仅本地提交」（规范名 @kunlungrowth/git-commit-only）就是为这一步设计的：它只负责把当前改动变成一个干净、可追溯的本地提交，不触碰任何远端。

工作方式：先看清楚，再决定提交什么

这个技能的核心流程分五步，每一步都围绕「不丢改动、不越界、不误推」三个约束。

步骤 1 — 检查状态：先跑 git status --short 和 git branch --show-current，再分别看 git diff --cached --stat 与 git diff --cached；如果没有暂存内容，退回 git diff --stat 观察未暂存改动。整个过程不丢弃、不回滚用户的任何文件。

步骤 2 — 暂存：用户要求全部改动时用 git add -A；指定范围时只暂存对应路径；逻辑上可分组的改动用 git add -p 逐步确认。暂存后再次 git status --short 复核。一个硬性安全协议是：.env、凭证、私钥、token 等密钥文件禁止留在暂存区。

步骤 3 — 生成提交信息：采用 Conventional Commit 格式，即 type(scope): 中文摘要。关键点是 type 和 scope 要根据实际 diff 内容推断，而不是照抄文件名。非简单改动要写 2–5 个分段正文，按受影响区域组织，附上改动列表；如果跑过测试、校验或 hook，追加「测试：」或「验证：」分段。

步骤 4 — 提交：用多个 -m 参数无交互地执行 git commit，保证正文被完整保留。两个禁止项：禁止 --no-verify（即使 hook 耗时）；hook 失败时先修原因再提交，而不是绕过。

步骤 5 — 汇报：输出一个结构化的 CommitResult 工件，包含提交哈希、分支、已提交文件摘要、已运行的校验，以及一个明确的 pushed: false。下游可以把这个结果交给 git-pushing-fast（推送）或 git-weekly-report（汇总）继续处理。

适用边界：它不做哪些事

这个技能只回答「怎么把这次改动提交好」，不回答「要不要推」。以下场景不属于它的范围：

• 提交并推送 — 那是 git-pushing-fast 的职责
• 双分支合并 — 交给 git-push-secondary-merge-primary
• --force-push、rebase、squash、amend 等改写历史的操作
• 创建 PR、周报、changelog 等文档产物
• git reset --hard、git checkout -- 等破坏性命令

换句话说，当你说完「先提交别推」之后，这个技能会在当前分支留下一个符合仓库风格的本地提交，并明确告诉你：什么都没发出去。剩下的推送、合并、出报告，是另外几个技能的事。