在 Git 工作树有变更需本地提交时，生成逻辑分组清晰…

当用户要求把已暂存或未暂存的本地变更按仓库约定提交为一条或多条清晰 commit 时使用。

适用场景

解决思路

1. 只从当前工作树创建本地提交，不 push、不创建 PR；完整 ship 流程使用 `ce-commit-push-pr`。
2. 完成标准：每个逻辑变更都已提交，提交时显式列出文件，提交信息说明结果，且 `git status` 中这些变更已干净。
3. 停止条件：工作树干净、无内容可提交时停止。
4. 采集上下文时，每个命令都作为独立 shell 工具调用，只传程序+参数；不要用 `;`、`&&`、`||`、管道、`$(...)` 或重定向连接，否则在 Windows PowerShell 下会失败。
5. 非零退出码是正常状态，需解释其含义，不要把它抑制成失败。
6. 运行 `git status` 查看工作树状态；非零/空表示不是 git 仓库，停止。
7. 运行 `git diff HEAD` 查看未提交变更；非零/空表示尚无提交的仓库/没有提交历史。
8. 运行 `git branch --show-current` 查看当前分支；输出为空表示 detached HEAD。
9. 运行 `git log --oneline -10` 查看近期提交信息风格；失败表示尚无提交的仓库、无历史。
10. 运行 `git rev-parse --abbrev-ref origin/HEAD` 查看远端默认分支；若没有 `origin/HEAD` 或输出裸 `HEAD`，尝试 `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'`，否则用 `main`。
11. 把这些上下文视为快照；提交前若可能发生变化，重新读取分支和已暂存文件集。
12. 默认分支名：从 `origin/HEAD` 去掉开头的 `origin/`（如 `origin/trunk` → `trunk`）；所有“是否在默认分支？”检查都用这个裸名称，绝不要与 `origin/<name>` 比较。
13. 按 workflow 0 先运行上述所有上下文命令（每个独立 shell 调用），然后继续。
14. 若 `git status` 显示没有已暂存、已修改或未跟踪文件，报告并停止；不要仅凭 `git diff HEAD` 判断干净，因为它会漏掉未跟踪文件。
15. 若处于 detached HEAD，或处于默认分支（`main`/`master`/上面得到的裸默认分支名），基于变更内容创建特性分支 `git checkout -b <name>`，然后重新读取 `git branch --show-current`；不要询问——仅提交也不能把工作只留在 detached HEAD 或默认分支；若派生名称已存在，选择不冲突的后缀。
16. 提交约定：优先匹配上下文中已有的项目提交约定；否则匹配最近日志模式；否则使用 conventional commits `type(scope): description`。使用 conventional commits 且 `fix`/`feat` 都适用时，默认用 `fix:`（修复损坏或缺失行为），把 `feat:` 保留给新能力；用户覆盖优先。
17. 逻辑提交：若变更文件能清楚拆分为不同关注点，做多个提交（仅文件级，最多 2–3 个，不用 `git add -p`）；若模糊，做单个提交。
18. 提交信息 subject 用祈使句并说明结果（现在能做什么或修好了什么），不是文件列表；仅当动机或取舍从 subject 不明显时才写正文。若本次提交已有计划 Implementation Unit ID（来自对话、调用方，或文件属于同一 unit），在括号中追加该 unit 的 U-ID——`(U3)` 表示 unit 3；不要主动寻找计划；当提交跨 unit、unit 不明确或没有计划在手时省略。
19. 消息示例：坏 `Update checkout.rb` / `Add tests and fix stuff`；好 `Fix double-submit on checkout`；好 `Add per-subscription mute (U3)`。
20. 暂存和提交：只暂存具名文件（绝不用 `git add -A` 或 `git add .`）。若调用带有 `exclude:<paths>`，遵守它：这些文件无论其他变化如何都保持未提交，并在报告中说明已排除。
21. 用文件写入工具把完整提交信息（subject 行、空行、可选正文）写到仓库外文件，然后每个提交组用两次调用完成暂存和提交：`git add file1 file2 file3`；`git commit -F <message-file> -- file1 file2 file3`。
22. `-F` 不经过 shell 解析消息：`$`、引号、反引号或多行正文在任何 shell 下都按字面传递，无需满足引用规则；Git 正常的空白清理仍会生效（去除行尾空格、折叠连续空行），这对提交信息没问题。
23. `git commit` 末尾的路径列表是必需的：裸 `git commit` 会取整个索引，因此本次运行前已暂存的任何内容（调用方的 `exclude:` 路径，或用户暂存但未指定的工作）会被带入提交；指定路径可只提交该组，并保留其他索引项不动。
24. 确认：运行 `git status`；报告 hash 和 subject。

适用边界 · 注意事项

• 需要 push 或创建 PR、走完整 ship 流程时，改用 `ce-commit-push-pr`。
• 当前目录不是 Git 仓库时，停止，不要继续提交流程。
• 工作树已干净（无 staged、modified、untracked 文件）时，无需提交，报告并停止。