Marcussyl/cursor-skills

批量提交（Commit in batches）

将未提交的工作拆分为多个逻辑清晰的提交。每个提交应能独立审查，并且包含该切分所需的所有文件。

安全规则（始终遵守）

• 绝不修改 git 配置。
• 除非用户明确要求，绝不强制推送、硬重置或执行其他破坏性 Git 操作。
• 除非用户明确要求，绝不跳过钩子（--no-verify 等）。
• 绝不暂存密钥（.env、凭据、密钥等）。给出警告并排除它们。
• 除非用户对修改提交的规则已完全满足，绝不使用 git commit --amend。
• 如果提交钩子失败，修复问题并创建新提交；不要修改失败的提交。
• 不在提交信息中添加 Co-authored-by: Cursor。

1. 检查

尽可能并行执行：

• git status
• git diff 和 git diff --staged
• git log -5 --oneline 了解提交信息风格
• git remote -v 和分支跟踪信息（git status -sb）

如果没有可提交的内容，则停止并告知用户。

2. 规划批次

根据用途对更改分组，而不仅仅依据文件类型。示例：

• 一个功能或用户可见行为及其测试和文档
• 一个错误修复及仅用于修复它的文件
• 独立的、不混入其他功能的代码重构
• 限定在某一领域的杂项或工具配置（依赖、CI、配置）

规则：

• 不要在一笔提交中混合不相关的功能。
• 将配套文件包含在同一个批次中（例如，一次变更所涉及的 schema + entity + migration + 调用点）。
• 如果一个文件涉及多个关注点，优先将其归入主要批次，或在提交前说明权衡。
• 按顺序列出批次：基础部分优先（共享类型、配置），然后是功能，最后是仅文档（如果它们依赖于前面的提交）。

向用户展示一个简短计划：批次编号、文件或路径、提议的约定式提交主题。然后继续，除非用户反对。

3. 提交每个批次

对每个批次，依次执行：

1. 仅暂存该批次（git add 指定路径；避免 git add -A，除非整个工作区就是一个批次）。
2. 用 git diff --staged 再次检查确保没有混入无关更改。
3. 写一个约定式提交主题（feat、fix、chore、docs、refactor、test 等），专注于原因。
4. 如果分支名包含 issue 编号，则将 #<issue> 附加到主题后（GitLab 风格）。
5. 提交。在 Windows PowerShell 上，使用 git commit -m 'subject'（或多个 -m 表示简短正文）。在 Bash 上，使用 HEREDOC 编写提交信息即可。
6. 重复直到工作区对于意图的变更而言是干净的。

4. 推送到 GitHub（或远程仓库）

完成所有批次后：

• 如果 origin（或用户命名的远程仓库）存在且分支需要被发布，当上游不存在时运行 git push -u origin HEAD，否则运行 git push。
• 绝不强制推送 main 或 master 分支。
• 如果推送被拒绝，报告错误并建议拉取/变基；除非用户明确要求，绝不强制推送。
• 如果没有远程仓库，则说明提交仅存在于本地，并询问是否要添加远程仓库。

5. 报告

摘要：

• 每个提交的哈希值和主题（最新的在最后或使用编号列表）。
• 推送结果（URL 或分支信息，如果可用）。
• 任何有意未暂存的内容（密钥、仅本地文件）。

与 commit-msg 的关系

commit-msg 从已经暂存的文件中建议一行提交信息，但不执行提交。本技能规划、暂存、分多步提交并推送。