Commit

Auto Git Commit & Push

当用户输入 commit 时，把当前暂存区已有的内容提交到本地仓库并推送到远程（依次执行 git commit → git push，不执行 git add，只提交用户已自行 git add 到暂存区的内容），推送完成后再补齐项目标配（README/LICENSE/CHANGELOG/VERSION/About/Sponsors，含版权人/署名引用名字归一为 All Contributors）。敏感内容扫描、cache 文件/目录检测是 git commit 之前的两项检测（均针对暂存区已有内容，任一命中即终止）；版本号一致性检测（项目根有 VERSION 文件才查）及其余项目标配检测全部放在 git push 之后，不阻塞提交流程。

核心定位：先提交推送，再补标配

• 触发与终止规则（2026-07-15 用户立，最高优先级；2026-09-06 增补 main 分支感知，2026-09-07 修订为 main 直推）：
  • 触发判定：只由用户当前这条消息含 /commit 且**意图确为「现在执行提交」**才触发——不看历史消息（历史里有 /commit 不触发、不续跑）；当前消息即便字面含 /commit 也要先理解意图，若是在讨论 / 举例 / 引用 /commit 或意图非提交（如「这条含 /commit 但不是要 commit」），不触发。不自发、不续跑、不自动进入。
  • main 分支直接提交并推送（2026-09-07 用户修订：main 不设分支保护、不限制直接 push——2026-09-06 的「main 仅本地提交」模式废止）：当前在 main（或 master）分支 → 走正常完整流程：commit 前两项检测（敏感扫描 + cache 检测）与 git commit 照常执行，git push 直推远程 main——普通文件处理修改（文档、版本号 bump、配置等杂事）与 main 对齐场景走这条通道，不经 PR。详见执行流程第 0 步。
  • 命中即彻底终止：流程中一旦命中敏感内容扫描或 cache 检测，立即终止本次 /commit（不 commit / push），不存在「暂停 → 等用户处理 → 从断点继续」；要再次提交，用户须重新输入 /commit 从头走完整流程。（版本号一致性检测不阻塞提交，已移至 push 后第 9k 步处理。）
• 本 skill 依次执行 git commit、git push：提交暂存区已有的内容到本地仓库，再推送到远程（不执行 git add，提交内容以用户自行 git add 到暂存区的为准）。
• 两步用 && 串联成一条命令一次性跑完（2026-07-17 用户立；2026-08-01 修订：去除 git add，改为只提交暂存区）：git commit + git push 两步优先用 && 组合成一个 Bash 命令一次执行，不拆成多次 Bash 调用、不中途停下来向用户列命令确认——用户输入 /commit 即明确授权当次 commit+push（全局 ~/.claude/CLAUDE.md「Git 写操作必须先征得同意」段的例外已写明），再列命令确认是多余的反 confirm。commit 信息基于 git diff --cached + git status（暂存区已有内容）生成，随后直接 git commit -m "<msg>" && git push 一条命令跑完两步。若 auto mode 权限分类器拦下其中某一条 git 写命令，不要退缩去问用户——改用 && 串联的组合命令继续执行（组合命令作为整体更易被识别为 commit 流程、不易被单点拦截）；commit 前的两项硬性检测（敏感内容扫描 + cache 检测，均针对暂存区已有内容）照常先做完、通过后才进入串联执行。main 直推场景同样是 git commit && git push 一条命令跑完（见第 0/8 步）。本条同样适用 /release 等其它用户主动触发即授权的 skill。
• commit 前检测有两项：敏感内容扫描 + cache 文件/目录检测（均针对暂存区已有内容）；版本号一致性检测（项目根有 VERSION 文件才查）与 README/LOGO/徽章/版权署名/版权人与署名引用名字归一/LICENSE.md/CHANGELOG.md 与 VERSION 文件/About/仓库 Sponsors 按钮 等「项目标配」检测全部放在 git push 之后（第 9 步）——先提交推送代码，再补标配，补的内容作为新工作区改动，本次未提交；本 skill 不执行 git add，需用户自行 git add 后下次 /commit 提交。
• 标配检测：缺则自动补上；齐全则在项目根 .commit-cache.md 标记，下次跳过重复检测。
• 严禁执行 git push --force、git reset --hard 等破坏性操作。
• 严禁编辑、删除、格式化项目文件（例外仅七类：① README/LICENSE 标配补全——可编辑 README.md/README_cn.md（顶部 LOGO/徽章居中块 + 移除 Forks/Stars/Last Commit 等动态徽章（第 9l 步；团队仓库的 Visitors 访问量徽章属允许例外、不删） + persona 说明块 + 底部版权署名段 + 版权人/署名引用名字归一为 All Contributors（第 9g 步）+ 语言基调修正：把 README.md 里「本该用英文却写成中文」的正文改为英文（特殊场景的中文保留不动）+ 英文版跳中文版链接文字统一为「简体中文」（第 9h 步））、创建 assets/logo.svg、创建 LICENSE.md、删除冗余的其它格式 license 文件（只保留 LICENSE.md）；② 项目根 .commit-cache.md 写入缓存标记（不存在则新建）；③ 全局 ~/.claude/CLAUDE.md 的「智能体命名注册表」追加新 agent 行（仅 9d 起名时，不改已有行）；④ cache 检测——第 3 步检测到的 cache 文件/目录可新增进 .gitignore；⑤ 版本滞后提示（第 9j 步，2026-09-06 改提示制）——检测到 VERSION 滞后时只报告并指引 /bump，不就地修改任何文件（版本号的实际修改归 bump skill 在 bump 分支上执行）；⑥ 版本号一致性同步（第 9k 步）——检测到 VERSION 与各文件版本号不一致时，以 VERSION 为唯一权威，更新 package.json、package-lock.json、CHANGELOG.md、主 manifest、README 的版本号到与 VERSION 一致（不动 VERSION 自身）；⑦ 新建 CHANGELOG.md 与 VERSION 文件（第 9m 步）——检测到项目缺这两个文件时按 9m 规则创建，不改动 .gitignore 的其它部分。
• 敏感内容扫描、cache 检测均在 git commit 之前执行一次（针对暂存区已有内容）；git commit 之后不再重复。（版本号一致性检测已移至 push 后第 9k 步，不阻塞提交。）

执行流程

0. 分支感知（最前置的硬性检查，先于一切其它步骤；2026-09-07 用户修订：main 不设分支保护、不限制直接 push——2026-09-06 的「main 仅本地提交」模式废止，main 恢复直推）：运行 git rev-parse --abbrev-ref HEAD 获取当前分支名。

   • 当前在 main（或 master）（无论仓库有无提交历史）→ 走正常完整流程：第 1-7 步照常（敏感扫描、cache 检测、git commit），第 8 步 git push 直推远程 main——普通文件处理修改（文档、版本号 bump、配置等杂事）与 main 对齐场景走这条通道，不经 PR。
   • 当前在功能分支（存在测试用例的软件开发项目走 dev-workflow 的常态）→ 放行，继续第 1 步（第 8 步将自动走 push → PR → 等 CI 绿 → squash 合并链）。

1. 运行 git status，确认当前处于 git 仓库中。判断暂存区是否已有内容（本 skill 只提交暂存区已有的内容，不执行 git add）。

   • 暂存区为空（无任何已暂存的改动）→ 告知用户「暂存区无内容可提交（本 skill 不执行 git add，请先自行 git add 要提交的内容）」并结束流程（无提交则不推送）。
   • 暂存区有内容 → 继续下一步。

2. 敏感内容扫描（git commit 前一次性硬性检查，针对暂存区已有内容，本次操作仅此一次）：检查暂存区即将被提交（commit）的所有文件，是否含敏感或不宜入库内容。这些文件 = 暂存区已有内容（用户此前自行 git add 的文件；本 skill 不执行 git add，故不扫工作区未暂存改动）。常见类别包括：

   • 凭证与密钥：.env、.env.*、*.pem、*.key、id_rsa 等私钥、API key、token、密码、数据库连接串；
   • 凭证目录：.ssh/、.aws/、.gcloud/、secrets/、credentials/ 等；
   • 本地私有配置：.claude/ 中含个人设置/记忆的文件、.idea/、.vscode/ 中含个人配置的文件；
   • 敏感行为记录（2026-08-23 扩充，防「代理交易行为记录」类泄漏——不只拦「值」、也拦把「身份 + 绕行手段」串成故事的行为叙述）：
     • 公网 IP 字面量：暂存内容中出现公网 IPv4 字面量（含 IP 串、; 分隔的 IP 清单）即告警——本地回环（127.x / 192.168.x / 10.x / 172.16-31.x / ::1）与已知公共服务 IP（如 8.8.8.8、1.1.1.1）除外；技术文档确需引用 IP 时逐个判断（测试网段 192.0.2.x / 198.51.100.x / 203.0.113.x 属文档示例地址、放行）；
     • 代理服务商标识：代理订阅商名称（如 Just My Socks / JMS）、代理节点入口域名体系、节点代号（如 c56s* 系列）；
     • 券商监管报文：监管拒单错误码 + 报文原文引用（如 code=1200、"Under regulatory requirements..." 类整段券商报文）；
     • 地域规避叙述：「境内 IP 被拒、境外出口受理」「翻墙 / 科学上网 / 绕过监管」类把身份与绕行手段串成完整故事线的叙述（合规要求本身的中性表述不拦——「网络环境须满足券商合规要求」可写，「同一账户境内拒境外受理的实测对比」不写）。 命中上述任一类 → 与其它敏感内容同等处理（终止 + 列出 + 提示改写为中性表述——技术结论保留、节点 / 出口 / 报文实值移入本机 gitignore 配置）。
   • 其他不宜入库内容：大文件、二进制、本地数据库文件等。

   扫描对象（仅暂存区已有内容，本 skill 不 git add，故不扫工作区未暂存改动）：

   • 暂存区已有内容：git diff --cached --name-only（用户此前自行 git add 的文件）。

   扫描方式：

   • 列出上述文件，按敏感路径/文件名模式匹配；
   • 对全部暂存文件跑内容正则扫描（不只抽样——凭证与 IP 类特征串靠逐文件 grep，模式含：私钥头 -----BEGIN、token 特征、公网 IPv4 正则、代理商标识关键词、监管报文关键词、地域规避叙述关键词）；
   • 对命中或可疑文件抽样读取内容，确认是否含明文敏感信息。

   结果处理：

   • 未发现敏感内容 → 继续后续流程；
   • 发现敏感内容 → 立即终止本次 /commit，不执行 git commit、不执行 git push，向用户列出：
     1. 每个涉及敏感内容的文件路径；
     2. 文件中具体的敏感内容片段（可截断，标出敏感字段）；
     3. 处理建议（从暂存区移除 git restore --staged <file>、加入 .gitignore、删除敏感内容等）。本 skill 自身不从暂存区移除文件、不修改 .gitignore、不改动工作区，处理由用户自行完成。 本次 /commit 就此终止、不续跑（不「等用户处理后从第 1 步继续」）。用户处理完敏感内容后，须重新输入 /commit 才会从头走完整流程。

3. cache 文件/目录检测（与敏感扫描并列的 git commit 前硬性检测，针对暂存区已有内容）：扫描暂存区文件清单（git diff --cached --name-only）中，名字含 cache 的——常见如 cache/ 目录、__pycache__/、.cache/、*.cache、<skill>/cache/（如 find-skill 的 cache/）等运行时缓存（本地生成、不应入库）。

   • 结果处理：
     • 未发现 cache → 继续后续流程（第 4 步取暂存区清单）；
     • 发现 cache 文件/目录 → 自动在 .gitignore 追加对应忽略规则（例外④允许：仅新增忽略本次检测到的 cache 路径，不改 .gitignore 其它部分），然后立即终止本次 /commit，不执行 git commit、不执行 git push，向用户汇报：发现的 cache 文件/目录清单 + 已写入 .gitignore 的忽略规则 + 提示用户自行从暂存区移除 cache（git restore --staged <cache路径> 或 git rm --cached -r <cache目录>）后重新 /commit。本次 /commit 就此终止、不续跑（不「等用户确认后从第 1 步继续」）；用户须重新输入 /commit 走完整流程。

4. 运行 git status / git diff --cached --name-only，获取本次暂存区已有的文件清单（按类别分组：新增、修改、删除）。

5. 获取当前分支名与远程仓库地址（git remote -v）。

6. 根据 git diff --cached --stat / git diff --cached 生成简洁英文提交信息（1-2 句话，说明本次改动的性质）。

7. 运行 git commit -m "<生成的提交信息>" 提交暂存区内容。本步与第 8 步 push 用 && 串联成一条命令执行（不拆开、不中途停下确认，分类器拦单条也不退缩——详见「核心定位」段「两步用 && 串联一条命令跑完」；main 直推与功能分支 PR 链场景均如此串联）。

8. 执行推送与 PR 链（2026-09-06 用户立：功能分支自动走 PR 链；2026-09-07 修订：main 恢复直推，PR 链的 auto-merge 改为等 CI 绿后合并——分支保护已全量撤除，GitHub 仅对「有不满足合并要求的 PR」提供 auto-merge，无 required checks 的仓库设 --auto 无意义）。先检查远程仓库（git remote -v），按情形处理：

   • 无 origin（remote 为空） → 主动创建 GitHub 远程仓库再推送：
     • 仓库名取项目目录名（basename "$PWD"），可见性 --public（本 skill 服务于开源项目）；
     • gh repo create <仓库名> --public --source=. --remote=origin --push（一条命令完成：创建公开仓库 + 设置 origin + 推送当前分支）；
     • 前置：gh 已认证（gh auth status）。未认证 → 如实报告、跳过创建与推送，继续第 9 步；
     • 创建失败（重名冲突 / 网络等）→ 如实报告错误，不自行重试或破坏性解决；
     • 创建并推送成功后，第 9c 步的前置条件（有 origin + push 成功）即满足。
   • 有 origin，当前在 main（含全新仓库初始提交，与既有仓库的普通文件修改 / main 对齐）→ git push -u origin main（已有上游时 git push）；推送冲突或非 fast-forward 如实报告，不破坏性解决（禁止 --force）。
   • 有 origin，当前在功能分支（存在测试用例的软件开发项目，dev-workflow 场景）→ 依次执行 PR 链：
     1. 推送分支：无上游 git push -u origin <分支名>，有上游 git push；
     2. 该分支是否已有 open PR：gh pr list --head <分支名> --state open --json number——有则复用（本次提交自动进入该 PR，不重复创建），并顺带检查现 PR 标题：若不达意（等于分支名、单词、dev / update / wip 类无信息量标题）→ 用 gh pr edit <PR> --title "<具体标题>" 按下方标准修正；无则创建——PR 标题必须具体，表达本次新增的功能或解决的问题（2026-09-06 用户立：禁止像 "dev" 那样只写分支名）：由智能体基于 git diff --cached 与 commit 内容生成，格式为 conventional 前缀 + 具体描述（如 feat: resolve model slot references to env slots when signed out、test: add regression coverage for the tool group summary、fix: captureCommand throws instead of returning code 1 on missing binary），禁止分支名、单词、泛称作标题；gh pr create --title "<生成的标题>" --body "<描述：从 commit 信息与改动摘要展开>"。PR 标题经 squash 合并后就是 main 上的 commit 标题，是 main 历史与日后溯源检索的主要线索，信息量必须够；
     3. 等 CI 完成并合并：gh pr checks <PR号或分支名> --watch 等 CI 结束（全绿退出码 0、有失败非 0）→ 绿则 gh pr merge <PR号或分支名> --squash --delete-branch（squash 合并 + 删远端分支）；红则不合并，报告失败 job 与看日志的命令（gh run view <id> --log-failed），修复后再次 /commit 推送会自动进入同一 PR 重新评估。CI 长时间不动或无 checks 上报（fork 仓库 PR 不触发 CI、workflow 缺失等）→ 如实报告，不阻塞第 9 步。等待 CI 是流程固有环节（有测试项目的全量用例需数分钟），--watch 挂着等即可；若会话不便久等，报告 PR 号与查看命令，由用户稍后 gh pr merge <PR> --squash --delete-branch 手动收尾。
   • 推送过程中如遇冲突或其他错误，将错误信息如实报告给用户，不自行尝试破坏性解决（禁止 --force）。

9. 项目标配检测（git push 之后，最后一步）：提交推送已完成，这里补齐项目标配。push 失败时仍进入本步（9a/9b/9d/9g/9h/9k/9l/9m 是本地检测；9e 永久跳过，见第 9e 步），但 9c 需 push 成功。先读项目根 .commit-cache.md（不存在则视为无缓存、稍后新建），按缓存标记跳过已确认的项（见「.commit-cache.md 检测缓存」）；对未跳过的项逐一检测，缺则补、齐则记标记，不再停下阻塞。补的内容作为新工作区改动，本次未提交；本 skill 不执行 git add，需用户自行 git add 后下次 /commit 提交。

   例外（跳过整个第 9 步）：若当前仓库根目录名（basename "$(git rev-parse --show-toplevel)"）为 xhqing——这是 GitHub 账号同名 Profile 仓库，仅含一个 README.md 用于在 GitHub 个人主页展示，非常规项目——直接跳过本步全部检测（9a/9b/9c/9d/9e/9f/9g/9h/9i/9j/9k/9l/9m）与 .commit-cache.md 缓存读写，不做任何 README/LICENSE/About 补全，直接进入汇报。

   9a. README 标配（标记 readme-standard）：README.md 英文版 + README_cn.md 中文版，两版顶部 LOGO/徽章块一致并互链（英文版 [简体中文](README_cn.md)、中文版 [English](README.md)），底部有版权与许可证 + 署名方式 + 项目地址引用段。

   • 双语：无 README.md → 创建英文版最小 README；无 README_cn.md → 基于 README.md 翻译创建中文版。
   • 语言基调（2026-08-01 修订，替代原「语言纯度」）：README.md 以美式英文为主（特殊场景可用任何语言），README_cn.md 以简体中文为主（特殊场景可用任何语言）。默认英文版写英文、中文版写中文，但不追求「逐字纯净」——正文里需要保留的中文专有名词、人名、机构名、产品名、引用原文、代码示例、注音等属「特殊场景」，可按需混入主语言之外的字词，不视为违规。
     • 扫描 README.md 发现中文时逐处语义判断（不再机械地「见中文即违规」）：属特殊场景（如上列举）→ 保留不动；属「本该用英文却写成了中文」（典型如整段中文叙述塞进英文版、或正文随手用了中文词而非通用英文术语）→ 改为英文。
     • LOGO（assets/logo.svg 里 <text>/嵌入文字）与徽章（URL 参数、alt 文本）：默认用英文（项目名、AI Agent 等 Type 标签是面向全球读者的视觉元素）；仅当项目名本身就是中文、或有意做双语 LOGO 时保留中文（属特殊场景）。
     • README_cn.md 反向同理：以简体中文为主，必要的英文术语、代码、引用原文保留，不追求逐字纯净。
   • LOGO：README.md 无图片引用或图片不存在 → 按 LOGO 生成规则创建 assets/logo.svg，并在两版顶部插入 <div align="center"><img ...></div>（已有居中 div 则在其中插入）。
   • 徽章：README.md 无 img.shields.io → 在 LOGO 下方插入徽章行并同步两版。
   • 版权与署名：两版底部缺「版权与许可证说明 + 署名方式 + 项目地址引用方式」→ 追加完整段（英文版 ## License & Attribution，中文版 ## 版权与署名）：① 版权 Copyright (c) <年份> All Contributors + 许可证（链 LICENSE.md）；② 署名方式（致谢 + 保留版权声明 + 注明来源）；③ 项目地址引用（origin 的 GitHub URL，无 remote 则用 https://github.com/<git user>/<目录名>）。版权人统一 All Contributors；已存在的具体人名（含已有版权段里的）由 9g 主动归一，本步不重复扫描。
   • 项目类型推断（定 Type 徽章 + LOGO 配色/emoji）：package.json 有 engines.vscode → VSCode Extension（Type-VSCode%20Extension-0078D4，蓝）；目录名以 Agent 结尾或 README/CLAUDE.md 自述为 agent → AI Agent（Type-AI%20Agent-FF1493，按角色）；package.json 有 main/exports 且无上述特征 → Library（Type-Library-9CF，青）；否则 → Project（Type-Project-lightgrey，紫）。
   • LOGO 生成（assets/logo.svg）：640×200、圆角 rx=28、线性渐变、左侧大 emoji（按主题选，无把握用 ⚙️）+ 项目名 + 副标题（<类型> · <一句话描述>）；结构对齐 DigiVendAgent logo.svg 模板。
   • 徽章组合（标准三枚，固定为 License / Version / Type，不按 remote 区分数量、不依赖 remote）：① License——从 LICENSE.md/package.json.license 推断（MIT→License-MIT-yellow、Apache-2.0→License-Apache_2.0-blue、GPL-3.0→License-GPL_v3-blue，无则跳过本枚）；② Version——版本号取 VERSION 文件（VERSION 尚不存在时，按 9m「版本号取值顺序」兜底：package.json 顶层 version → 主 manifest 版本字段 → 已有 CHANGELOG.md 顶部最新实际版本标题 → 1.0.0），徽章 URL 形如 https://img.shields.io/badge/Version-<v>x.x.x-blue（<v> 为可选前缀，版本号纯数字如 1.2.3）；③ Type——由上方「项目类型推断」定。三枚统一用静态 badge 端点（img.shields.io/badge/...），不使用 github/stars/、github/forks/、github/last-commit/ 等 GitHub 动态数值 / 时间徽章——这些随仓库变动的徽章不展示在 README，已存在的由第 9l 步负责清理。Version 徽章里的版本号后续由 9j（版本滞后 bump）/ 9k（版本号一致性同步）随 VERSION 一起更新。
   • Visitors 访问量徽章（团队仓库允许的例外，2026-08-16 立）：团队各仓库（agent 主仓库及其子项目）在标准三枚之外另挂一枚 Visitors 徽章——shields.io endpoint 形式，URL 指向 xhqing/xhqing 仓库的 traffic/badges/<repo>.json（<repo> 为当前仓库目录名，如 https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/xhqing/xhqing/main/traffic/badges/DayTradingAgent.json），alt="Visitors"（badge JSON 的 label 字段为 Visits/day，即展示日均访问量）。数据由 xhqing 仓库集中式采集（官方 Traffic API、按日去重累计）。为什么允许：它不是 shields.io 实时抓取 GitHub 的动态数值徽章，而是指向静态 JSON 的 endpoint 徽章，与「不含动态徽章」不冲突；属团队统一部署的访问统计例外。9a 不主动补挂（挂徽章是团队部署动作、非项目标配缺失——数据源 JSON 由 xhqing 采集流程按仓库生成，非本仓库可自行补造）；已挂的不动，9l 检测时对这一种 URL 形态豁免（详见 9l）。边界：只豁免这一种 URL 形态；komarev / seeyoufarm 等第三方计数图片及其它动态徽章仍按违规处理。
   • 只补不删：不改动用户已有的 LOGO/徽章/正文（语言基调修正除外：把 README.md 里「本该用英文却写成中文」的正文改为英文是允许的，特殊场景的中文保留不动）。README 双语 + LOGO + 徽章 + 版权署名段全齐 → 写 <!-- commit-skill: readme-standard = ok --> + 日期行。

   9b. LICENSE.md（标记 license）：根目录只保留 LICENSE.md，不与其它格式 license 文件重复。

   • 无 LICENSE.md → 创建（若有 LICENSE/LICENSE.txt 等同名文件则复制其内容，否则用 MIT 模板）；版权人统一用 All Contributors（覆盖原文件里的具体人名）。已存在 LICENSE.md 里写死的具体人名归一由 9g 处理。
   • 创建后、或 LICENSE.md 已存在时，若根目录还有其它格式 license 文件（LICENSE、LICENSE.txt 等）→ 删除冗余，只留 LICENSE.md。
   • LICENSE.md 存在且无冗余 → 写 <!-- commit-skill: license = ok --> + 日期行。

   9c. GitHub About（标记 github-about）：确保 GitHub repo About 有中英双语 description 与 topics。

   • 前置：origin 指向 github.com 且 gh 已认证、且第 8 步 push 成功。任一不满足 → 跳过、不记录、如实报告（如「无 GitHub remote / push 未成功，跳过 About 检测」）。
   • gh repo view <user/repo> --json description,repositoryTopics 取当前 About。
     • description 中英双语判定：description 须同时含英文与中文（结构形如「English summary | 简体中文摘要」，英文部分以美式英文为主（特殊场景可用任何语言）、中文部分以简体中文为主（特殊场景可用任何语言））。
       • 已是中英双语（既含英文也含中文）→ 视为合规，保留不动。
       • 仅含英文或为空 → 缺中文，用 gh repo edit --description "<English summary> | <简体中文摘要>" 补成双语（中文部分从 README 中文段提取或由英文翻译为简体中文，英文部分以美式英文为主，总长 < 350 字符）。
       • 仅含中文 → 缺英文，用同样命令补上英文部分（从 README/package.json description 提取或翻译为英文，拼成「English | 中文」双语，总长 < 350 字符）。
     • topics 判定：为空 → 按项目类型 + 关键词推断，gh repo edit --add-topic a --add-topic b ... 补全（多个 --add-topic 写字面量，勿用 shell 变量拼接）；非空 → 保留不动。
     • topics 推断：VSCode 扩展 → vscode/vscode-extension；性能监控 → performance/monitoring；macOS 依赖 → macos；TypeScript → typescript；Claude Code 构建 → claude-code；Agent → ai-agent。按实际命中选取，不强加。
   • 补全（或检测发现已配）后 → 写 <!-- commit-skill: github-about = ok --> + 日期行。

   9d. Agent 拟人名（标记 agent-persona）：项目目录名以 Agent 结尾时，必须有一个蕴含主要能力含义的拟人化名字并写进 README（项目核心内容为代表 Agent 能力的 skills / rules / memory / mcp 等，名字即 Agent 的身份）。

   • 触发：目录名以 Agent 结尾。不以 Agent 结尾 → 跳过本项、不记录。
   • 检测已有：① 查全局 ~/.claude/CLAUDE.md 的「智能体命名注册表」，该仓库已在表中 → 名字即定，README 引用之；② 否则看 README（中英任一）是否已有 persona 说明块（如 > **<Name>** — <一句话能力说明> 形式）。两者皆无 → 视为缺名。
   • 缺名则起名：
     • 查重：新名不得与注册表已有名（Scout / Wright / Buzz / Vendy / Echo / Kit / Victor 等）重复，首字母尽量错开以利辨识；
     • 语义：名字要蕴含该 Agent 的主要能力（双关优先，如修补维护类取 Tinker「修补匠」、制造生产类取 Wright「制造匠」），避免直白工具名（如 Patcher）；
     • 写入：在两版 README 标题正下方加 persona 说明块（emoji + 名字 + 一句话能力说明），中英一致；
     • 起名后把新名字追加进全局 ~/.claude/CLAUDE.md 的「智能体命名注册表」（新起一行 | **<名字>** | <仓库目录名> | <职称> | <主要职责> |，不改已有行；若该 agent 不属销售流水线，在表下「流水线顺序」句补注其独立）；
   • 已有名字（注册表命中或 README persona 块已存在）或新起并写入后 → 写 <!-- commit-skill: agent-persona = ok --> + 日期行（注明名字）。

   9e. AutoMemory 目录（标记 automemory）：永久跳过——不检测、不补全、不写标记。

   • 原因：全局 AutoMemory 已禁用（~/.claude/settings.json 设 autoMemoryEnabled: false，2026-07-20 用户立）。按全局 ~/.claude/CLAUDE.md 约定，新建项目一律不配 AutoMemory——不建 .claude/memory/、不填 autoMemoryDirectory、.gitignore 不挂 memory 条目。
   • 因此本步不做任何检测与补全：不创建/编辑 .claude/settings.local.json、不创建 .claude/settings.local.example.json、不向 .gitignore 写 memory 相关内容（settings.local.json 的忽略与 .claude/memory/ 的入库由项目脚手架阶段处理，非本 skill 职责）。
   • .commit-cache.md不写 automemory 标记（该标记在本约定下永久不出现）。
   • 边界：若日后重新启用 AutoMemory，恢复本步检测逻辑即可（届时需同步恢复「例外④ AutoMemory 配置」与缓存段 automemory 标记示例）。

   9g. 版权人/署名引用名字归一（标记 attribution-name）：README.md（英文版）、README_cn.md（中文版）、LICENSE.md 三份文件里，凡是代表「本项目版权人 / 作者」身份的名字，统一使用 All Contributors，不出现具体个人名（如 Huaqing Xu、xhqing 等）。与 9a/9b 互补——9a 只在「缺段则补」、9b 只在「创建 LICENSE」时写入 All Contributors，已存在文件里写死的具体人名由本步主动归一。

   • 触发：所有项目（凡有 README/LICENSE 的都扫，与 9a/9b 一致）。xhqing Profile 仓库仍走第 9 步开头的例外、整个跳过，9g 不例外。
   • 扫描对象（三份文件，不存在的跳过）：README.md、README_cn.md、LICENSE.md。
   • 扫描位置（仅两类，避免误伤正文）：
     1. 版权声明行：Copyright (c) <年份> <持有人> / Copyright <年份> <持有人> / © <年份> <持有人> 等中英文变体——持有人位置 ≠ All Contributors → 改为 All Contributors。
     2. 署名说明段：README 的 ## License & Attribution / ## 版权与署名 段落内（LICENSE.md 一般无此段，只看版权声明行）——凡「作为本项目作者/版权人被引用」的具体名字（by <Name>、作者：<Name>、© <Name>、<Name> (<email>)、裸人名、@handle 等）→ 改为 All Contributors。
   • 不改（排除清单）：
     • GitHub 仓库地址里的 user（如 github.com/xhqing/repo 中的 xhqing）——仓库归属事实、非版权人；改了会让链接指向不存在的仓库、失效；
     • Agent 拟人名（9d 写入的 Scout / Wright / Victor 等）——角色身份、非版权人，与 9d 冲突；
     • 第三方依赖/工具署名（依赖库自带的版权声明）——非本项目版权人；
     • 项目名本身。
   • 判定方式：由 CC 语义判断「该名字是否代表本项目版权人/作者」（非纯正则）；拿不准的保留不动并在汇报里列出，不擅自改。
   • 三份文件均无具体人名（版权人/署名引用位置已是 All Contributors 或无可改位置）→ 写 <!-- commit-skill: attribution-name = ok --> + 日期行。

   9h. 英文版 README 跳转中文版链接文字（标记 readme-link-text）：英文版 README.md 里指向中文版（README_cn.md）的跳转链接，其呈现文字统一为「简体中文」，不允许只写「中文」两个字。与 9a 互补——9a 管「两版是否互链」，本步专门校正「英文版里跳转中文版的链接文字是否符合规范」。

   • 触发/前置：README.md 与 README_cn.md 均存在。缺任一 → 跳过、不记录（由 9a 先补齐双语，下次 /commit 再检测本步）。
   • 检测：扫描 README.md 里所有指向 README_cn.md 的 markdown 链接（形如 [<文字>](README_cn.md)，含 ./README_cn.md 等路径变体）。
   • 修正：链接文字 ≠「简体中文」（常见为只有「中文」二字，或「Chinese」「繁体中文」等其它写法）→ 改为 [简体中文](<原链接目标>)，只改呈现文字、不动链接目标。
   • 英文版当前没有指向中文版的链接 → 本步不负责补链接（互链由 9a 补，9a 补时直接用「简体中文」），跳过、不记录。
   • 链接文字已是「简体中文」→ 写 <!-- commit-skill: readme-link-text = ok --> + 日期行。

   9i. 仓库 Sponsors 按钮（标记 repo-sponsors）：确保 GitHub 仓库页会显示 Sponsor 按钮（仓库主页右侧「Sponsor this project」按钮，由 FUNDING.yml 驱动，区别于 README 里自定义的赞助块 / 收款码）。

   • 机制：Sponsor 按钮由 FUNDING.yml 驱动，文件可放在仓库根目录或 .github/ 子目录。<username>/.github 仓库的 FUNDING.yml 会作为该用户所有仓库的默认 sponsor 配置（除非某仓库自己有 FUNDING.yml 覆盖）。按全局 ~/.claude/CLAUDE.md 约定，统一只在 xhqing/.github 仓库放一份 github: xhqing，不在每个项目里单独放 .github/FUNDING.yml——赞助配置不是项目主体内容。
   • 前置：gh 已认证（gh auth status）。未认证 → 跳过、不记录、如实报告（如「gh 未认证，跳过 Sponsors 检测」）。
   • 检测（判断当前仓库在 GitHub 上是否会显示 Sponsor 按钮，二者任一满足即「就绪」）：
     1. 当前仓库有自己的 FUNDING.yml（.github/FUNDING.yml 或根目录 FUNDING.yml）且含有效 sponsor 键（github: / patreon: / ko_fi: / buy_me_a_coffee: / open_collective: / custom: 任一）→ 已就绪（尊重现状，不主动移除；按全局约定 agent 项目不应有，但本步不负责清理）；
     2. 否则查全局 xhqing/.github 仓库的 FUNDING.yml（根目录或 .github/ 子目录）是否存在且含有效 sponsor 键（约定为 github: xhqing）→ 存在则已就绪（默认配置对该用户所有 GitHub 仓库生效）。
   • 未就绪则修复（两者皆无）：按全局约定，通过 gh api 在 xhqing/.github 仓库创建 / 更新 FUNDING.yml，内容为 github: xhqing + 注释模板（赞助平台说明 + 文档链接 + 其它平台注释行）。用 gh api -X PUT repos/xhqing/.github/contents/FUNDING.yml -f message="Add FUNDING.yml for GitHub Sponsors" -f content="<base64 编码的内容>"（若该文件已存在但内容不含有效 sponsor 键，先 GET 取 sha，再带上 -f sha=<sha> 更新）。这是跨仓库远程写操作（写的是 xhqing/.github 而非当前项目，区别于本 skill 其它只动当前项目的步骤），但内容确定、是全局默认配置、符合用户「让所有仓库都显示 Sponsor 按钮」的意图，直接执行；创建 / 更新失败（网络 / 权限等）→ 如实报告，不强行重试、不动当前项目文件。
   • 已就绪（检测通过）或修复成功后 → 写 <!-- commit-skill: repo-sponsors = ok --> + 日期行（注明「全局默认 xhqing/.github/FUNDING.yml 就绪」或「当前仓库自有 FUNDING.yml」）。

   9j. 版本滞后检测（提示制，2026-09-06 改）（不写缓存标记、每次 /commit 必查）：检测 VERSION 标注的当前版本是否已落后于代码实际进度——若该版本已经在 GitHub Release 发布（该版本号对应的 Release / tag 已存在），且仓库里该版本之后又有新的提交，说明代码已往前走但版本号没跟上。检测到滞后时不就地修改任何文件（版本号修改归 bump skill 在 main 上统一执行——功能分支禁止碰版本号，就地 bump 会写进功能分支违反并行纪律），改为在汇报中报告滞后并指引：「版本滞后 N 个待发布提交，发版时统一 bump——执行 /bump（bump skill：对齐 main → 在 main 上改齐版本号 → /commit 直推）」。与第 9k 步互补：9k 管横向（各文件版本号与 VERSION 对齐），本步管纵向（VERSION 是否落后于已发布进度，提示发版路径）。

   • 触发 / 前置：项目根有 VERSION 文件 + 有 origin 指向 github.com + gh 已认证（gh auth status）+ 第 8 步 push 成功。任一不满足 → 跳过、不记录（如「无 VERSION / 无 GitHub remote / push 未成功，跳过版本滞后检测」）。
   • 检测逻辑：
     1. 读 VERSION 取基准版本号（trim 首尾空白 / 换行），如 2.1.0。
     2. 查该版本是否已在 GitHub Release 发布：先 gh release view "v<版本>"（仓库惯用 v 前缀 tag）；提示 not found 则再试不带 v 的 gh release view "<版本>"。任一能查到 → 该版本已发布；都查不到 → 未发布，版本未滞后（VERSION 指向尚未发布的下一版），正常通过。
     3. 该版本已发布 → 查仓库里该版本 tag 之后是否有新提交：先确保本地有该 tag（git fetch --tags，浅克隆 / 未 fetch 标签时必要），再 git rev-list --count <实际tag>..HEAD，结果 > 0 → 有新提交；结果 = 0 → 该版本发布后无改动，正常通过。
     4. 两者同时满足 → 版本滞后：汇报滞后状态（当前 VERSION / 最新已发布版本 / 待发布提交数）+ 指引 /bump。不改文件、不就地 bump。
   • 不写缓存标记：版本滞后状态随每次提交 / 每次发版动态变化，每次 /commit 都要重新查，故 .commit-cache.md不写 version-staleness 标记、永不跳过本步。
   • 例外：当前仓库根目录名为 xhqing（Profile 仓库）→ 随第 9 步开头例外整个跳过，9j 不例外。

   9k. 版本号一致性检测与同步（不写缓存标记、每次 /commit 必查）：检测 VERSION 与项目里各处版本号是否横向一致——VERSION 是唯一权威源（对齐全局 ~/.claude/CLAUDE.md「版本信息一致性」规则），其余涉及版本号的文件若与 VERSION 不一致，则以 VERSION 为准自动同步（不动 VERSION 自身）。与 9j 互补：9j 管纵向（VERSION 是否落后于已发布进度、必要时向上 bump 并同步各文件），本步管横向（VERSION 与各文件版本号是否对齐、以 VERSION 为准补齐）；两者都在 push 之后、都不阻塞、都不写缓存标记、都每次必查。本步排在 9j 之后：若 9j 已 bump VERSION 并同步各文件，则本步复查时各处应已一致、无需再改；若 9j 未触发（VERSION 未滞后），但某文件版本号偏离了 VERSION（典型如手动改了 VERSION 但 package.json / CHANGELOG 未跟上），则由本步补齐。

   • 触发 / 前置：项目根有 VERSION 文件（本步只比对本地文件，不要求 origin / gh / push 成功——push 失败也照常检测）。无 VERSION → 跳过、不记录、不同步。xhqing Profile 仓库随第 9 步开头例外整个跳过。

   • 检测逻辑：

     1. 读 VERSION 取基准版本号（trim 首尾空白/换行），如 2.1.1。
     2. 允许前缀差异：剥离前导的 v / Version / "version": 等修饰性前缀与引号、标点后，比较核心的 major.minor.patch 三段数字逐一相同即视为一致（如 v2.1.1、Version 2.1.1、"version": "2.1.1" 与 2.1.1 均算一致）；后缀（-beta、-rc.1、+build 等 pre-release / build metadata）不属于前缀、不自动豁免，需判断是否为有意区分。
     3. 逐一比对须比对的位置（存在的才查，各自提取版本号字串并 trim 后与基准比核心三段数字）：
        1. package.json 顶层 version 字段；
        2. package-lock.json 顶层 version 字段（仅顶层，不查 packages 内各依赖版本）；
        3. CHANGELOG.md 里最新一条实际版本标题（跳过 ## [Unreleased] 占位符，取其下第一条形如 ## [2.1.0] / ## 2.1.0 的版本标题）；
        4. 项目主 manifest 的版本字段：manifest.json、pyproject.toml（version = "x"）、Cargo.toml（version = "x"）、*.csproj（<Version>x</Version>）——存在才查；
        5. README（README.md / README_cn.md）里显式声明当前版本的文字（如「Current version: x」「当前版本：x」、版本徽章），仅取「声明当前发布版本」的位置，不抓 changelog 历史版本、不抓依赖版本、不抓安装命令示例里的版本号。

   • 结果处理（不阻塞——push 已完成，同步后的版本号作为新工作区改动，本次未提交；本 skill 不执行 git add，需用户自行 git add 后下次 /commit 提交）：

     • 无 VERSION 文件 → 跳过；
     • 各位置版本号均与基准一致 → 无事可做，正常通过；
     • 发现不一致 → 以 VERSION 为唯一权威，把偏离的文件同步到基准版本号（不动 VERSION）：
       1. package.json：顶层 version 字段改为基准版本号；
       2. package-lock.json：顶层 version 字段改为基准版本号（仅顶层，不动 packages 内各依赖版本）；
       3. CHANGELOG.md：若顶部有 ## [Unreleased] 段且其下第一条实际版本标题 < 基准版本号 → 把 ## [Unreleased] 改为 ## [基准版本号] - <今天日期 YYYY-MM-DD>（其下的 Added / Changed 等内容即归入该版本；不要改已发布版本的历史条目）；若顶部无 Unreleased 段、最新实际版本标题就低于基准 → 在最顶部新增 ## [基准版本号] - <今天日期>（依据近期提交补简要改动说明）；
       4. 主 manifest：manifest.json / pyproject.toml（version = "x"）/ Cargo.toml（version = "x"）/ *.csproj（<Version>x</Version>）——存在才改为基准版本号；
       5. README（README.md / README_cn.md）：显式声明当前版本的位置（「Current version: x」「当前版本：x」、版本徽章里的版本号）——存在才改为基准版本号；不抓 changelog 历史版本、不抓依赖版本、不抓安装命令示例。

   • 不写缓存标记：版本号一致性状态随每次改动动态变化，每次 /commit 都要重新查，故 .commit-cache.md不写 version-consistency 标记、永不跳过本步。

     9l. README 徽章组合合规（标记 readme-badges）：README.md（英文版）、README_cn.md（中文版）的徽章行必须符合新规矩——标准徽章固定为 License / Version / Type 三枚（静态 img.shields.io/badge/... 端点），不得包含 Forks / Stars / Last Commit 等 GitHub 动态数值 / 时间徽章（即 URL 路径含 github/forks/、github/stars/、github/last-commit/ 的徽章，含 ?style=social 等参数变体）。允许例外（2026-08-16 立）：团队仓库的 Visitors 访问量徽章——URL 为 shields.io endpoint 且指向 raw.githubusercontent.com/xhqing/xhqing/main/traffic/badges/ 下 JSON 的那一枚（详见 9a「Visitors 访问量徽章」段）——不属违规、不删。与 9a 互补——9a 管「该有的徽章是否齐全」（其「徽章组合」用静态三枚、不添加动态徽章），本步专门清理「已存在的动态徽章」。

   • 触发：所有项目（凡有 README 的都扫，与 9a 一致）。xhqing Profile 仓库仍走第 9 步开头的例外、整个跳过，9l 不例外。

   • 扫描对象（两份文件，不存在的跳过）：README.md、README_cn.md。

   • 检测：扫描徽章行里所有 img.shields.io 徽章，命中 URL 路径含 github/forks/、github/stars/、github/last-commit/ 之一的 → 视为违规徽章；但 URL 含 xhqing/xhqing/main/traffic/badges/ 的 endpoint 徽章（Visitors 访问量徽章）先排除——它不在三类违规之列。

   • 修正：删除该违规徽章所在的整行 markdown（形如 ![...](https://img.shields.io/github/stars/...)），其余徽章（License / Version / Type、Visitors 访问量徽章及其它合规徽章）/ LOGO / 正文一律保留。本步突破 9a「只补不删」原则，仅针对上述三类动态徽章删除——不删其它徽章、不删 LOGO、不动正文。

   • 两份文件均无上述三类违规徽章（或某份文件不存在）→ 写 <!-- commit-skill: readme-badges = ok --> + 日期行。

   9m. CHANGELOG.md 与 VERSION 文件（标记 changelog-version）：任何项目都必须有 CHANGELOG.md 与 VERSION 两个文件（2026-08-03 用户立）——它们是「CHANGELOG 记录纪律」「版本信息一致性」规则的落地载体（这两条规则现无条件生效、无缺省豁免），也是 9j 版本滞后检测、9k 版本号一致性检测的检测对象。

   • 触发：所有项目（除 xhqing Profile 仓库随第 9 步开头例外整个跳过外，9m 不例外）。
   • 本步与 9j/9k 的关系：本步排在 9j/9k 之后。首次 /commit 若项目缺 VERSION，9j/9k 按「无 VERSION」跳过、由本步创建；自下次 /commit 起 9j/9k 正常执行。
   • 版本号取值顺序（新建时共用）：① package.json 顶层 version；② 主 manifest 的版本字段（manifest.json / pyproject.toml（version = "x"）/ Cargo.toml（version = "x"）/ *.csproj（<Version>x</Version>））；③ 已有的 CHANGELOG.md 顶部最新实际版本标题（仅建 VERSION 时可用，CHANGELOG.md 尚不存在则跳过）；④ 以上皆无 → 1.0.0。
   • 无 VERSION → 新建：文件内容为纯数字版本号（无 v 前缀）+ 换行（如 1.0.0\n）。
   • 无 CHANGELOG.md → 新建：顶部写 ## [<当前版本号>] - <今天日期 YYYY-MM-DD>（当前版本号 = 已有 / 本次新建的 VERSION；VERSION 尚无则按上方取值顺序），其下写该版本摘要（新项目写「初始版本」说明 + 按当前已知内容简要记录）；不写 [Unreleased] 占位——新建即用具体版本号标题，与 9k「最新实际版本标题须与 VERSION 一致」天然对齐，避免下次 /commit 被 9k 再改。
   • 两者均存在 → 无事可做。
   • 新建 / 确认存在后 → 写 <!-- commit-skill: changelog-version = ok --> + 日期行。

   第 9 步是收尾，补全/标记后直接进入汇报，不再阻塞提交。

10. 执行 git status（汇报收尾动作，整个流程的最后一步，2026-09-05 用户立；同日修订：代码块首行加 >> git status 命令标记）：进入汇报时，作为汇报的最后一件事执行一次 git status，并把该命令的输出原样以代码块方式直接输出——不加工、不总结、不截断、不做额外解读。代码块首行固定加一行 >> git status 命令标记（提示符样式，让用户一眼看出这段是 git status 的执行输出；该标记行是呈现格式、不算命令输出的一部分，其余各行才是原样输出）。无论流程是完整走完（commit + push + 第 9 步标配检测与补全）还是中途终止（敏感内容扫描 / cache 检测命中），汇报都以这个 git status 代码块收尾——让用户直接看到本次 /commit 结束时工作区与暂存区的真实状态。格式示例：

    >> git status
    On branch main
    Your branch is up to date with 'origin/main'.
    
    nothing to commit, working tree clean
    

.commit-cache.md 检测缓存

项目根 .commit-cache.md 是「commit skill 检测缓存」的专用载体文件：不存在 → 新建（只含缓存内容，不碰项目的 CLAUDE.md）；存在 → 末尾追加（不破坏已有内容）。commit skill 不再在项目 CLAUDE.md 里写缓存——CLAUDE.md 由项目脚手架维护、只承载项目说明，缓存独立到这个文件。文件统一格式，九类标记各自写入、互不依赖：

# commit skill 检测缓存

本文件由 commit skill（`/commit`）自动维护，记录项目标配检测的就绪状态，供后续 `/commit` 跳过重复检测。请勿手动编辑——commit skill 会按检测结果增补标记。

<!-- commit-skill: readme-standard = ok -->
- README 中英双语 + LOGO + 徽章 + 版权署名：已就绪（YYYY-MM-DD 确认）

<!-- commit-skill: license = ok -->
- LICENSE.md：已存在（YYYY-MM-DD 确认）

<!-- commit-skill: github-about = ok -->
- GitHub About：已配置（中英双语 description + topics，YYYY-MM-DD）

<!-- commit-skill: agent-persona = ok -->
- Agent 拟人名：已写入 README（<名字>，YYYY-MM-DD）

<!-- commit-skill: attribution-name = ok -->
- 版权人/署名引用名字：已归一为 All Contributors（YYYY-MM-DD 确认）

<!-- commit-skill: readme-link-text = ok -->
- 英文版 README 跳转中文版链接文字：已统一为「简体中文」（YYYY-MM-DD 确认）

<!-- commit-skill: repo-sponsors = ok -->
- 仓库 Sponsors 按钮：已就绪（xhqing/.github 全局默认 FUNDING.yml，YYYY-MM-DD 确认）

<!-- commit-skill: readme-badges = ok -->
- README 徽章：徽章组合合规（License/Version/Type 三枚，不含 Forks/Stars/Last Commit；团队 Visitors 徽章属允许例外）（YYYY-MM-DD 确认）

<!-- commit-skill: changelog-version = ok -->
- CHANGELOG.md 与 VERSION 文件：已存在（YYYY-MM-DD 确认）

• readme-standard 标记：第 9a 步检测到 README 中英双语（README.md 以美式英文为主、README_cn.md 以简体中文为主） + LOGO + 徽章 + 版权署名段全齐时写入。
• license 标记：第 9b 步检测到 LICENSE.md 存在（且无冗余）时写入。
• github-about 标记：第 9c 步补全 About（或检测发现已配）后写入。
• agent-persona 标记：第 9d 步检测到 README 已有拟人名（或新起并写入）后写入；仅以 Agent 结尾的项目适用。
• automemory 标记：永久不写入——9e 已随全局 AutoMemory 禁用而永久跳过（详见第 9e 步），缓存段不再出现该标记。
• attribution-name 标记：第 9g 步检测到 README（中英两版）与 LICENSE.md 的版权人/署名引用名字均已归一为 All Contributors（或无可改位置）后写入。
• readme-link-text 标记：第 9h 步检测到英文版 README.md 里指向 README_cn.md 的跳转链接文字已是「简体中文」（或英文版暂无该链接、留待 9a 补）后写入。
• repo-sponsors 标记：第 9i 步检测到 Sponsor 按钮配置就绪（当前仓库自有 FUNDING.yml，或全局 xhqing/.github/FUNDING.yml 默认配置生效）或修复成功后写入。
• readme-badges 标记：第 9l 步检测到 README（中英两版）徽章组合合规——标准三枚（License / Version / Type）齐全且不含 Forks / Stars / Last Commit 等动态徽章（团队仓库的 Visitors 访问量徽章属允许例外，不算违规；或某份文件不存在）后写入。
• changelog-version 标记：第 9m 步检测到项目根已有 CHANGELOG.md 与 VERSION 两个文件（或缺失时新建完成）后写入。
• version-staleness 标记：永不写入——9j 版本滞后检测反映 VERSION 当前是否落后于代码进度，状态随每次提交 / 每次发版动态变化，每次 /commit 都要重新查 GitHub Release + git log，不缓存、不跳过。
• version-consistency 标记：永不写入——9k 版本号一致性检测反映 VERSION 与各文件版本号当前是否对齐，状态随每次改动动态变化，每次 /commit 都要重新比对本地文件，不缓存、不跳过。
• 后续 /commit 第 9 步读此文件，按标记跳过对应检测；缺哪个标记就做哪项检测，只补缺的标记（9j 版本滞后检测、9k 版本号一致性检测均无标记、每次必查，不受此缓存机制影响）。
• 该 .commit-cache.md 与本次补全的 README/LICENSE 等都是 push 之后产生的工作区改动，本次未提交；本 skill 不执行 git add，需用户自行 git add 后下次 /commit 一并提交（本地存在即足以跳过检测）。

注意

• 本 skill 先完成「git commit + git push」（不执行 git add，只提交暂存区已有内容；main 直推与功能分支 PR 链均如此，见第 0/8 步），再在第 9 步补齐项目标配（README/LICENSE/CHANGELOG/VERSION/About/Sponsors，含版权人/署名引用名字归一）；标配检测不阻塞提交推送。
• commit + push 用 && 串联成一条命令一次跑完（2026-07-17 用户立；2026-08-01 修订：去除 git add，只提交暂存区）：不拆成多次 Bash 调用、不中途停下来向用户列命令确认（/commit 触发即授权当次完整流程）；auto mode 权限分类器拦下其中某条 git 写命令也不退缩去问用户——改用 && 组合命令继续执行。详见「核心定位」段「两步用 && 串联一条命令跑完」。
• 敏感内容扫描、cache 检测均在 git commit 之前执行一次（针对暂存区已有内容），是 commit 前的两项硬性检测；git commit 之后不再重复。（版本号一致性检测已移至 push 后第 9k 步，不阻塞提交。）
• 禁止 git push --force、git reset --hard 等破坏性操作。
• 无远程仓库时：第 8 步检测到 git remote -v 为空，会用 gh repo create <目录名> --public --source=. --remote=origin --push 主动创建公开 GitHub 仓库并推送（需 gh 已认证；未认证或创建失败则如实报告、跳过）。
• 不随意删除文件；处理敏感内容由用户自行完成。编辑/删除项目文件的例外仅七类：① README/LICENSE 标配补全（可编辑 README.md/README_cn.md 顶部 LOGO/徽章居中块 + 移除 Forks/Stars/Last Commit 等动态徽章（第 9l 步；团队仓库的 Visitors 访问量徽章属允许例外、不删） + persona 说明块 + 底部版权署名段 + 版权人/署名引用名字归一为 All Contributors（第 9g 步）+ 语言基调修正（把 README.md 里「本该用英文却写成中文」的正文改为英文，特殊场景的中文保留不动）+ 英文版跳中文版链接文字统一为「简体中文」（第 9h 步）、创建 assets/logo.svg、创建 LICENSE.md、删除冗余的其它格式 license 文件只保留 LICENSE.md）；② 项目根 .commit-cache.md 写入缓存标记（不存在则新建）；③ 全局 ~/.claude/CLAUDE.md 的「智能体命名注册表」追加新 agent 行（仅 9d 起名时，不改已有行）；④ cache 检测（第 3 步检测到的 cache 文件/目录可新增进 .gitignore）；⑤ 版本滞后提示（第 9j 步，提示制）——检测到 VERSION 滞后时只报告并指引 /bump，不就地修改文件；⑥ 版本号一致性同步（第 9k 步）——检测到 VERSION 与各文件版本号不一致时，以 VERSION 为唯一权威，更新 package.json/package-lock.json/CHANGELOG.md/主 manifest/README 的版本号到与 VERSION 一致（不动 VERSION 自身）；⑦ 新建 CHANGELOG.md 与 VERSION 文件（第 9m 步）——检测到项目缺这两个文件时按 9m 规则创建。其余文件及 .gitignore 其它部分严禁改动/删除。
• 推送冲突或错误如实报告，不自行破坏性解决。

汇报

报告提交与推送结果：本次提交的暂存区文件清单（按新增、修改、删除分组）、commit hash、分支名、远程仓库地址、推送是否成功、推送的提交范围（如适用）；功能分支场景加报 PR 链状态：PR 号（新建或复用）、CI 等待与合并结果（绿灯已 squash 合并 + 删分支 / 红灯未合并——报失败 job 与看日志命令 / 会话未等完 CI——报 PR 号与手动合并命令 gh pr merge <PR> --squash --delete-branch），并提醒——/release 发版前先确认 PR 已合并进 main（gh pr view <PR> --json state 或看 main 提交历史）；若因发现敏感内容而终止，则列出对应文件清单、敏感片段与处理建议；若因发现 cache 文件/目录而终止，则列出 cache 清单、已写入 .gitignore 的忽略规则，并提示用户从暂存区移除 cache（git restore --staged / git rm --cached）。（版本号不一致不再终止提交——已移至 push 后第 9k 步处理。）并提示「本次 /commit 已终止，处理 / 确认后需重新输入 /commit 走完整流程」。随后报告第 9 步项目标配检测的结果：补了哪些内容（logo.svg、README/README_cn 改动或新建、徽章清单（License / Version / Type 三枚补全情况，含移除 Forks / Stars / Last Commit 等动态徽章，如有；团队仓库已挂的 Visitors 访问量徽章属允许例外、如实报告「保留未动」）、版权署名段、persona 拟人名、LICENSE.md 新建/冗余删除、About 的 description/topics、版权人/署名引用名字归一为 All Contributors 的改动、英文版 README 跳中文版链接文字统一为「简体中文」的改动、仓库 Sponsors 按钮（检测 / 修复 xhqing/.github 全局 FUNDING.yml）的改动、CHANGELOG.md 与 VERSION 文件（第 9m 步）的新建结果（缺哪个建哪个 + 版本号取值来源）或已存在确认、版本滞后检测的结果（VERSION 是否滞后；若滞后则报告：当前 VERSION / 最新已发布版本 / 待发布提交数 + 指引「发版时统一 bump，执行 /bump」——不就地修改文件）、版本号一致性检测的结果（VERSION 与各文件是否一致；若不一致则报告：以 VERSION 为准同步了哪些文件 + 各自旧值→新值））以及写入了哪些缓存标记；提醒「本次补全的标配内容是新工作区改动，本 skill 不执行 git add，需用户自行 git add 后再 /commit 才会提交（功能分支上，下次 /commit 的内容会自动进入同一个 PR）」。汇报的最后一件事（2026-09-05 用户立；同日修订：代码块首行加 >> git status 命令标记）：执行 git status，把该命令的输出原样以代码块方式直接输出——不加工、不总结、不截断、不做额外解读，代码块首行固定加一行 >> git status 命令标记（让用户一眼看出这是 git status 的执行输出；标记行是呈现格式、不算命令输出的一部分）；无论流程走完还是中途终止（敏感内容扫描 / cache 检测命中），汇报都以这个 git status 代码块收尾（对应执行流程第 10 步）。