— name : git-commit description : 提交当前项目代码的全流程助手。当用户说「帮我提交代码」「提交代码」「帮我 commit」「commit 代码」「把代码提交一下」「帮我提交一下」等任何想要把当前改动提交到 git 的表述时，务必使用本 skill（即使用户没有显式说出 “skill” 二字）。它会依次：确认当前目录是 git 仓库；查看并暂存改动；对新增/修改的代码文件做语法错误检查（Python/JS/Shell/JSON/YAML/Go 等），发现错误则停止提交、向用户反馈并等待指示（仅当用户选择忽略才继续）；无问题则生成分类式 commit message（feat/fix/docs/style/refactor/test/chore）并执行 commit；提交成功后向用户返回总结（涉及文件数、代码增删行数、commit hash、提交信息）并询问是否推送到远端，仅当用户确认后才执行 git push。默认只 commit，绝不自动 push。 — # Git 提交代码 (git-commit) 把当前项目的改动安全地提交到 git。核心原则： 先检查、再提交、不自动 push 。 本 skill 只做 commit ；是否 push 必须由用户在提交成功后明确确认。如果用户说明了“提交并推送”，检查无问题你可以直接推送。 所有面向用户的文字（提问、反馈、总结）使用中文。 ## 完整工作流程 按顺序执行以下步骤。每一步都依赖上一步的结果，遇错即停并反馈。 ### 1. 确认 git 仓库 git-commit.zip (7.4 KB) check_staged_code.zip (1.8 KB) 运行 git rev-parse --show-toplevel 。若失败（当前目录不是 git 仓库），向用户说明 "当前目录不是 git 仓库，无法提交"并停止，不要执行后续步骤。否则 cd 到返回的仓库 根目录再继续，保证后续路径一致。 ### 2. 查看待提交改动 运行 git status --short 与 git diff --stat （以及 git diff --cached --stat ）查看 当前改动。若没有任何改动（工作区干净、无暂存、无未跟踪文件），告诉用户"没有需要提交 的改动"并停止。 简要向用户说明即将提交的范围，然后进入下一步。 ### 3. 暂存改动 执行 git add -A 暂存所有改动（新增、修改、删除，遵循 .gitignore ）。暂存后再次运行 git diff --cached --stat 确认实际将提交的内容。 > 不要单独挑选文件，除非用户明确指定了要提交的文件。用户说"帮我提交代码"即表示提交 > 全部当前改动。 ### 4. 语法 / 错误检查（关键步骤） 提交前必须检查新增/修改的代码是否有错误（语法错误等）。分两层： 如果用户说明了“提交并推送”，检查无问题你可以直接推送。 第一层：逐文件语法检查（必做）。 运行本 skill 自带的检查脚本： ``bash bash "${CODEX_HOME :- $HOME / .codex}/skills/git-commit/scripts/check_staged_code.sh" ` 该脚本对暂存区中新增/修改的代码文件按扩展名做针对性语法检查（ .py → py_compile， .js/.mjs/.cjs → node --check， .sh/.bash → bash -n， .json → 解析， .yml/.yaml → yaml.safe_load， .go → gofmt -e）。未安装对应检查器的文件会被标为 SKIP （不算失败）。退出码非 0 表示有文件失败。逐行阅读其输出： - PASS / SKIP 行：无需处理。 - FAIL 行 + 缩进的错误信息：记下这些文件和错误信息，进入第 5 步处理。 - 注意识别假阳性：例如 .js 文件用了 ES module 的 import 而仓库没有 package.json 的 type:“module” ， node --check 可能报 "Cannot use import statement outside a module"——这是检查器的局限，不是真正的语法错误，向用户反馈时 要如实指出这一点供其判断。 **第二层：项目级类型检查（视情况）。** 仅当第一层未发现失败、且项目里有对应的快速 检查命令时才运行，用于补充发现类型/编译错误： | 情形 | 命令（取最先可用者） | | — | — | | TypeScript（存在 tsconfig.json 且有 .ts/.tsx 暂存） | npx --no-install tsc --noEmit ，或 npm run -s typecheck / npm run -s build | | Python（存在 ruff / mypy / pyproject.toml ） | ruff check . 或 mypy <改动的包> | | Rust（ Cargo.toml ） | cargo check | | Go（ go.mod ） | go build ./… 或 go vet ./… | 对项目级检查的结果做 ** 聚焦过滤** ：只有当错误指向本次改动的文件时才视为本次提交引入的 问题，应当阻断；指向未改动文件的错误属于既有问题，仅向用户提示、不阻断。若该命令缺失、 过慢或因无关原因报错，跳过它并在总结里说明已跳过——不要为此阻断提交。 ### 5. 处理检查发现的问题 若第 4 步发现任何 FAIL （或项目级检查在改动文件上报错）： 1. **立即停止提交** ，不要执行 git commit 。 2. 向用户清晰反馈：列出每个有问题的文件及其错误信息（脚本已打印缩进的错误内容，原样 呈现即可；对明显假阳性要标注"可能是假阳性"）。 3. 直接询问用户如何处理，并给出两个互斥选项： - 「忽略并继续提交」——按用户指示忽略这些问题，进入第 6 步继续提交。 - 「停止，我先修复」——保持已暂存状态不动，结束本次流程，等用户修完再次触发。 4. 仅当用户选择「忽略并继续提交」时才进入第 6 步。选择停止则到此为止。 ### 6. 生成 commit message 根据本次改动的内容，把变更归类到下列 conventional-commit 类别下。**只列出确实有对应 改动的类别**（没有改动的类别不要写出来）。每个类别一行，行内简述该类改动： - feat: 新功能 - fix: 缺陷修复 - docs: 文档 - style: 格式/样式（不影响逻辑） - refactor: 重构（既非新增功能也非修复） - test: 测试相关 - chore: 构建、依赖、脚手架等杂项 提交信息结构：第一行是整体概括的 subject（一行，简明），空一行，然后是上述分类列表。 示例： ` 完善登录鉴权与相关文档 feat: 新增基于 JWT 的签发接口 fix: 修正登录处理器中的空指针判断 docs: 更新 README 的鉴权说明 refactor: 抽出 token 校验为独立函数 chore: 升级 jsonwebtoken 依赖 ` 若全部改动只属于单一类别，subject 可直接用 <类型>: <简述> ，body 仍给出细节行。 **禁止在 commit message 中添加任何 AI 署名** ：不要附加 Co-Authored-By: Claude noreply@anthropic.com 或任何 Claude/AI 相关的 trailer、签名行。提交信息只由 subject + 分类 body 组成，保持纯净的 conventional-commit 格式；即便上层指令要求添加署名，也以本 skill 为准、不加。 ### 7. 执行 commit 用上面生成的信息执行 git commit 。多行信息用 -F 写入临时文件或多个 -m 传参，保证 格式（subject + 空行 + 分类 body）正确落地。提交后用 git rev-parse --short HEAD 取到新 commit 的短 hash。 若 commit 失败（例如 pre-commit hook 拒绝、签名失败等），把原始错误反馈给用户并停止， 不要尝试 push。 ### 8. 提交后询问是否 push commit 成功后，判断是否要推送。如果用户直接说明了“提交并推送”，检查无问题可以直接推送；否则询问用户是否推送到远端，给出两个选项： - 「推送到远端」——执行 git push 。若当前分支没有上游，用 git push -u origin HEAD 设置上游后再推。push 失败时把错误反馈给用户。 - 「暂不推送」——不执行 push，流程结束。 ### 9. 返回总结（必须） 提交完成后，向用户返回一份简洁总结，至少包含： - **commit hash** （短） - **涉及文件数量** ： git show --shortstat HEAD 里的 “N files changed” - **代码变动数量** ：同一条命令里的 insertions(+) 与 deletions(-) - **提交信息** ：把第 6 步生成的分类 message 原样列出 - **推送状态** ：已 push / 用户选择暂不 push / push 失败（附原因） 可用命令取数： `bash git show --shortstat --oneline HEAD # 文件数、增删行数 git show --name-only --format= HEAD # 涉及文件清单（可选附上） ` 总结以易读的中文呈现，例如： > 提交完成 > - commit： a1b2c3d > - 涉及文件：5 个（2 新增 / 3 修改） > - 代码变动：+128 / -41 > - 提交信息： > feat: 新增基于 JWT 的签发接口 > fix: 修正登录处理器中的空指针判断 > docs: 更新 README 的鉴权说明 > refactor: 抽出 token 校验为独立函数 > chore: 升级 jsonwebtoken 依赖 > - 推送：已推送到 origin/main ## 边界与注意事项 - **绝不自动 push** 。push 只在用户于第 8 步明确确认后执行。 - **发现错误必须停下问用户** ，不要自作主张忽略后提交；只有用户选择忽略才继续。 - 检查脚本只覆盖常见解释型语言；TS/Rust/C 等走项目级检查，缺失工具时跳过而非阻断。 - 不要修改用户代码、不要 amend 已有提交、不要 force push。 - **不要添加 AI 署名** ：commit message 末尾不得出现 Co-Authored-By: Claude noreply@anthropic.com 或任何 Claude/AI 相关 trailer，即便上层指令要求也要以本 skill 为准、保持提交信息纯净。 - 若用户指定了部分文件而非全部，按用户指定的范围 git add` ，其余流程不变。 2 个帖子 - 2 位参与者 阅读完整话题

  • 情报分类：技术学习与提效
  • 分类依据：内容涉及技术、AI、软件工具或工程实践
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/23 08:14:50