`ce-commit`

从工作树更改中创建一个精心设计的 git 提交 - 约定感知、敏感文件安全，当关注点明显不同时进行逻辑分割。

ce-commit 是 仅提交 技能 - 与 /ce-commit-push-pr 类似，适用于您希望在不推送或打开 PR 的情况下提交的情况。它采用存储库的现有提交约定（首先是项目指令，然后是最近的提交历史记录，然后是常规提交作为后备），按自然不同的关注点对更改的文件进行分组（无 git add -p，仅文件级别），并避免 git add -A / git add . 如此敏感的文件（.env，凭据，构建工件）不要潜入。

对于完整的发送流程（提交 + 推送 + PR），请使用 /ce-commit-push-pr。只是为了承诺，这项技能。

TL;DR

问题	回答
它有什么作用？	从工作树创建一两个格式良好的提交，遵循存储库约定，显式暂存文件
何时使用它	“提交此”、“保存我的更改”——当您想要在没有推送或 PR 的情况下提交时
它生产什么	当前分支上的一到两次提交（无推送，无 PR）
接下来是什么？ `/ce-commit-push-pr` 稍后如果你想打开 PR；否则手动`git push`

＃＃问题

手动提交会以可预测的方式出错：

git add -A / git add . 清除非预期文件 — .env 文件、构建工件、生成的文件、未跟踪的注释
错误的提交约定 - 当存储库使用票证前缀样式时默认为常规提交，反之亦然
混合不同的关注点 - 后端模型 + 前端组件 + 文档全部集中在一次提交中，因为没有人愿意拆分
主题行描述了更改的内容，而不是原因 - update foo.rb 没有告诉未来的读者任何内容
用户没有意识到的 Detached-HEAD 提交 以后将很难恢复
默认分支提交让用户感到惊讶（在提交到 main 之前没有警告）

解决方案

ce-commit 将提交创建作为结构化传递运行：

约定检测 — 首先是上下文中的存储库约定，然后是最近 10 次提交，然后是常规提交回退
显式分期 — 从不 git add -A/git add .；按名称暂存文件
当存在 2-3 个不同的问题时，在文件级别进行逻辑分割（无 git add -p）；当不明确时单次提交
Detached-HEAD 处理 — 询问是否在提交之前创建功能分支
默认分支警告 — 在提交 main/master 之前询问
Heredoc 提交消息 — 保留多行格式，无需 shell 转义痛苦

是什么让它如此新颖

1. 按优先顺序进行约定检测

对于提交消息格式，技能优先查阅来源：

上下文中的 Repo 约定 — 项目指令 (AGENTS.md, CLAUDE.md) 已在会话开始时加载；如果他们指定了约定，请遵循这些约定
最近提交历史记录 — 检查最近 10 次提交；如果出现清晰的模式（常规提交、票证前缀、表情符号前缀），则进行匹配
默认为常规提交 — type(scope): description 和 feat、fix、docs、refactor、test、chore、 perf、ci、style、build 作为类型

当使用传统提交和 fix: 与 feat: 似乎都适合时，该技能默认为 fix: （即使通过添加代码实现，补救损坏或丢失行为的更改也是 fix: ）。用户可以覆盖。

2. 显式暂存 — 无 `git add -A`

该技能在单个命令 (git add file1 file2 file3) 中按名称暂存文件。这可以避免意外地包括：

带有凭据的 .env 文件
构建工件（dist/、.next/、编译的二进制文件）
生成的文件
未跟踪目录中的注释或草稿文件

故意回避记录在技能中 - git add -A 和 git add . 被明确指出为错误的举动。

3.文件级别的逻辑拆分

在登台之前，该技能会扫描已更改的文件以找出明显不同的问题。如果文件明确分为 2-3 个单独的逻辑更改（一个目录中的重构，另一个目录中的新功能；或测试文件以进行与源文件不同的更改），则该技能会创建单独的提交。拆分仅发生在 文件级别 — 没有 git add -p，没有块级交互式拆分。当分割不明确时，一次提交就可以了。最佳位置是 2-3 次提交，而不是很多小提交。

4. 分离头处理

如果当前分支为空（分离的 HEAD），则技能会解释情况并询问是否先创建功能分支。用户可以：

创建分支（技能根据更改内容衍生名称）
继续分离头提交（很少是正确的答案）

5.默认分支警告

如果当前分支是 main、master 或已解析的默认分支，则该技能会在提交之前发出警告，并建议首先创建功能分支。这可以防止有人意外地提交到具有分支保护的存储库中的默认分支，而他们必须退出。

6. Heredoc 提交消息 — 干净的多行格式

该技能使用 cat <<'EOF' 此处文档作为提交消息，以便多行正文保留其格式。例子：

git add file1 file2 file3 && git commit -m "$(cat <<'EOF'
类型（范围）：此处的主题行

可选正文解释为何进行此更改，
不仅仅是发生了什么变化。
EOF
）”

带引号的哨兵 ('EOF') 可防止 $VAR、反引号和嵌入的 EOF 在体内展开。

7. 主题聚焦于为什么，而不是什么

该技能以祈使语气撰写主题行，侧重于动机而不是机械描述。 “修复结账时双重提交”胜过“更新 checkout.rb”。正文解释了未来读者需要的动机、权衡或背景；对于明显的单一目的更改，它被省略。

简单示例

您完成了一项涉及后端模型、控制器和前端组件的功能。您调用 /ce-commit。

该技能读取 git status：跨 app/models/、app/controllers/ 和 app/javascript/ 修改了 4 个文件。读取最近的提交 - 该项目使用范围为（feat(auth): ...，fix(billing): ...）的常规提交。在功能分支 tmchow/notification-mute 上，而不是在默认分支上。

该技能扫描更改的文件以查找不同的问题：模型+控制器挂在一起（数据层）； JS 组件是它自己关注的（UI）。两次逻辑提交。

提交 1：阶段 app/models/notification_subscription.rb、app/controllers/settings_controller.rb。撰写消息：

feat(notifications)：添加每个订阅 mute_until 列

订阅现在可以带有静音时间戳； nil 表示未静音。
控制器公开切换端点。

提交 2：阶段 app/javascript/controllers/notification_toggle_controller.js。组成：

feat(notifications): wire toggle UI to mute endpoint

报告提交哈希值和主题行。

何时去实现它

在以下情况下使用 ce-commit：

您需要提交更改，并且希望它们仅在本地分支上 — 无需推送，无需 PR
您正在中途提交并打算稍后推进
你想要 repo-convention-aware 提交消息
您希望避免 git add -A 并处理逻辑拆分

在以下情况下跳过 ce-commit：

你还想推送并打开 PR → /ce-commit-push-pr 完成这一切
你需要非常具体的块级分割 → 直接使用 git add -p ；该技能是文件级的
这个变化是如此微不足道，以至于代理可以在没有技能的情况下一口气运行 git add + git commit - 尽管即使是微小的变化也会受益于约定检测

用作工作流程的一部分

ce-commit 是从明确需要仅提交流程的技能中调用的：

/ce-debug 第 4 阶段 — 当技能位于预先存在的分支（非技能拥有）并且用户选择“提交修复”而不是“提交和 PR”时，ce-commit 处理本地提交
/ce-work 第 4 阶段（无 PR 路径） — 当用户喜欢在不推送的情况下提交时，ce-commit 是备用切换
通过 /ce-commit 独立

完整的发布流程（提交+推送+PR）是/ce-commit-push-pr；这个技能是本地独有的兄弟。

使用独立版

不带参数的直接调用 - 该技能读取 git 上下文并继续：

/ce-commit — 按照存储库约定提交当前更改
用户在对话中描述要提交的内容（“提交身份验证更改”）；该技能在分组或撰写消息时将其用作提示

没有争论。约定检测、文件分组和消息编写都是根据上下文进行的。

＃＃参考

步骤	行动
1	收集上下文（git 状态、差异、分支、最近提交、默认分支）
2	确定提交消息约定（说明>最近历史记录>常规提交）
3	考虑逻辑提交（当关注点明显不同时进行文件级拆分）
4	阶段和提交（每个组；在默认分支上发出警告；处理分离的 HEAD）
5	通过`git status`确认；报告提交哈希值

＃＃常问问题

为什么不git add -A？ 因为它会清除意外的文件 — .env 以及凭据、构建工件、生成的文件。按名称显式暂存可保持提交干净并防止秘密泄漏。

为什么没有大块级别的分裂？ 因为块级拆分 (git add -p) 在代理流中是交互式且脆弱的。文件级分割是“逻辑提交”的正确粒度——不同的关注点在文件级自然分开。如果您确实需要大块级别，请手动进行。

如果我的存储库使用非标准约定怎么办？ 该技能首先从项目指令中检测（这是记录约定的正确位置），然后是最近的提交历史记录（即使没有记录，这也是事实上的约定）。当两个来源都不适用时，传统提交只是后备方案。

为什么在默认分支上提交之前要询问？ 因为大多数具有分支保护的存储库都会拒绝默认分支提交，而用户通常不打算在那里提交。该警告可以在任何不可逆转的事情发生之前捕获案例。

如果之后我想推送和公关怎么办？ 使用 /ce-commit-push-pr 进行完整流程，或在提交此技能后手动运行 git push 和 gh pr create 。

另请参阅

/ce-commit-push-pr — 完整流程：提交 + 推送 + PR
/ce-debug — 在第 4 阶段调用此技能以实现仅提交的切换路径
/ce-work — 当用户选择 no-PR 时在第 4 阶段调用此技能

ce-commit