用途：这是一份提交粒度规约，供智能体在任何可能修改代码、配置、测试等任务开始时参照，确保编码过程中按原子单位频繁提交。适用于需要清晰版本历史、便于代码审查的开发工作流。
主要能力与规则：要求每次提交只包含一个关注点；任何提交都必须保持可构建、测试通过，禁止提交导致应用无法启动或测试失败的状态；功能新增与缺陷修复必须和重构、拼写修正、格式调整分开提交；追求数行到数十行、一目了然的小改动。禁止将多个问题捆绑成一次大提交，禁止形如 Fix multiple issues 的提交信息，也禁止等全部任务完成后再做一次大提交。
使用方式：作业开始前用 git status --short --untracked-files=all 查看既有变更，若已有 staged、unstaged 或 untracked 变更，不得与自己的作业混在一起，作业对象重叠时先确认处理方式。随后把任务拆成可提交的小单位，并为每个单位确定所需验证命令。每个逻辑变更完成后，运行该变更所需的测试、类型检查、lint 和差异确认；验证失败需修复至通过。只暂存自己修改的对象，用 git diff --cached --stat 与 git diff --cached --name-status 核对提交范围，再依 kf-g-git-commit-japanese-commit-message 规范撰写提交信息，然后对只有一个关注点的已暂存状态执行 git commit。
分离规则：功能变更与重构不放入同一提交；格式、拼写、重命名、import 整理与功能变更分开；仅当有助审查时才允许测试新增与实现变更同一提交；生成文件、索引文件更新若属于同一逻辑变更可与源改动同提交；多文件改动若属同一逻辑变更可单次提交，同一文件内无关修改则需拆分。用户明确请求提交时，以 kf-g-git-commit-staged-only-rules 优先，仅提交请求时已暂存的变更；仅在用户明确使用 /genshijin-commit 时优先外部 skill。完成后简要报告所创建的提交、验证内容及未提交变更情况。
限制：资料未提供该 skill 的安装命令、平台支持、收费与效果数据。