git-commit-organizer 是一套面向 Git 的分支与提交约定，目标是让同一项工作的所有产物（文档、缺陷报告、工作文件、提交记录）通过统一的 slug 相互关联，便于查找和追溯。
分支与 slug
工作从命名分支开始。若用户没有给出分支名，应先询问。功能建议使用 feat/<slug>，缺陷修复建议使用 fix/<slug>，slug 为简短的 kebab-case 标识。slug 是前缀之后的部分，例如 feat/order-cancel 的 slug 是 order-cancel。该 slug 应在各处复用：规格与计划文档放在 docs/<slug>-spec.md、docs/<slug>-plan.md；缺陷报告放在 .scratchpad/<slug>/bug-report.md；工作文件放在 .scratchpad/<slug>/；工作项使用标签或标记 <slug>。
必须在第一次改动前创建分支，不得在默认分支上提交功能工作。一项工作对应一个分支；计划中的各步骤和变更清单中的各修复是该分支上的提交，而不是各自的分支。
如果环境或用户指定了与功能无关的分支名（例如云会话自动分配的名称），不要重命名，也不要另建分支。应选择一个描述性的 slug，在 progress.md 中以两行分别记录 Branch 和 Slug，并将该 slug 用于所有产物；展示分支名的文档仍显示真实分支名。
提交规则
- 原子：一次提交只做一件事（一个功能步骤、一个修复、一个重构）。每一部分在通过项目完整检查后立即提交，不要先积攒再拆分，因为事后用 stash 和恢复拆分容易丢失工作。
- 重构与行为分离：若功能需要重构，先提交重构，保证全部测试通过且行为不变。
- 完整：提交应包含其测试、受影响的文档（README、AGENTS.md、spec、plan）以及包含决策的 ADR。
- 通过：每次提交前运行项目完整检查（例如 npm test），并读取其真实退出码。管道到其他命令（例如 | tail）返回的是最后一条命令的退出码。测试失败不得提交。
提交信息格式
采用 Conventional Commits 加 gitmoji：
<type>(<scope>): <gitmoji> <summary in the imperative, lowercase, no period>
可选正文：用一小段说明为何需要该变更。
<attribution trailers required by the environment>
类型与 gitmoji 对应：feat ✨ 新行为；fix 🐛 缺陷修复；fix 🔒️ 安全修复；refactor ♻️ 不改变行为的结构调整；test ✅ 仅测试；docs 📝 仅文档；chore 🔧 🙈 配置、工具、忽略文件；style 💄 UI 与 CSS；feat 🔊 日志；perf ⚡️ 性能；fix、feat ♿️ 无障碍。若 AGENTS.md 或近期历史显示不同约定，应遵循仓库自身约定。
安全事项
未经用户要求，不得推送、创建拉取请求、强推、变基共享历史或删除分支。在 shell（>）或脚本中写文件前必须先读取该文件，因为一条失败的命令可能清空 git 尚未跟踪的文件。脚本批量编辑多个文件（重命名、重新编号、合并）后，提交前先查看 git diff --cached --stat；若某文件丢失全部行，说明脚本有缺陷（例如未读先写）。读取已提交版本的文件应使用 git show HEAD:<path>，而不是 git stash；若必须 stash，在新文件重要时加 --include-untracked，并在之后检查 git status 和 git stash list。结束前运行 git status --short，并解释任何未提交的文件。