507 commit

Git 提交（commit）

只有用户明确要求 commit（提交）时使用。它可独立调用：做轻量安全复核、同步必要产物、精确暂存、验证并创建真实本地提交；不重复完整 507-review。

安全边界

• 不使用 git add .、git add -A 或其它全量暂存；
• 不纳入调试日志、临时文件、密钥、个人资料、客户数据或无关格式化；
• 发现无法确认归属的改动时停止并请求确认；明确无关且可安全排除的改动保持原状；
• 默认只做本地 commit；push（推送）与对外发布由 507-release 承接，不在本 skill 内执行；
• tag（标签）、版本号、发布渠道和远程元数据必须另有明确授权，交给 507-release。

提交流程

1. 确认范围与状态

检查当前分支、最近提交，以及 staged（已暂存）、unstaged（未暂存）和 untracked（未跟踪）文件。结合用户说明和当前任务，将变更分成：

• 本次工作，应纳入；
• 明确无关，应保留；
• 无法判断，应暂停确认。

分别阅读工作区与暂存区 diff（差异），确认没有临时产物、秘密、无关改动或未完成标记。

2. 同步必要产物

按变更类型判断是否需要同步：

• 根及分层 README.md、doc/README.md 和项目地图；
• CHANGELOG.md 的 Unreleased（未发布）段；
• 架构、运行、迁移、权限或配置说明；
• 稳定项目术语和符合准入门槛的决策记录；
• 版本号定版、manifest 版本号与发布说明的定版迁移由 507-release 承接，不在本 skill 同步。

只补确有必要的内容。纯内部重构、测试或地图调整不强塞用户可见 changelog（变更日志）条目。

3. 运行验证

先运行最相关的测试、lint（静态检查）、类型检查、构建或 smoke test（冒烟测试），再按项目分层要求扩大。无法运行时说明原因和可复验方式，不假装已验证。

4. 精确暂存

逐路径暂存本次工作文件。暂存后重新检查：

• git status --short；
• staged diff；
• 是否混入无关文件；
• 是否遗漏本次必要文件。

暂存区为空或主题混杂时，不创建空提交或把多个主题硬塞进一个 commit。

5. 创建提交

遵循项目已有提交规范；默认使用 Conventional Commits（约定式提交）：

type: 中文描述

[可选正文：解释为什么]

主题行简洁，一次提交只做一件事。根据变更选择 feat、fix、refactor、docs、test、chore、perf、ci、build 或项目规定类型，然后执行真实 git commit。

6. 提交后确认

• 输出短 commit hash（提交哈希）和最终提交信息；
• 再次运行 git status --short；
• 明确工作区是否干净，或仍有哪些预期保留改动；
• 若获授权创建发布 tag，确认 tag、版本号和 changelog 版本段一致；
• 明确没有执行 push，推送与发布交给 507-release，除非用户已单独授权。

与审查的边界

507-review 是完整的 Standards/Spec/Code Quality（规范/需求/质量）审查；本 skill 只做提交前必要的轻量安全复核。发现需要实质修复的问题时停止提交，路由到相应 skill，处理并验证后再回来提交。

完成与接力

• 完成信号：相关变更已精确暂存、必要验证通过并生成真实本地 commit；提交后工作区状态已报告。
• 产物：commit hash、提交信息、验证结果与剩余工作区状态；默认没有 push。
• 候选出口：发现实质问题时进入 507-fix、507-test、507-map 或相应实施并在修正后返回；本地提交完成后通常直接结束；用户要求推送或对外发布时进入 507-release。
• 回退条件：暂存区主题混杂、验证失败或必要产物缺失时停止提交，不创建“先提交再说”的半成品 commit。