用途：为开发者提供严格的 Git 提交、分支与 PR 规范，确保提交信息格式统一、变更按逻辑分组、分支命名清晰。
主要能力：
- 提交前门禁：生成提交信息前，先对暂存文件运行 pre-commit-check 技能，覆盖安全（凭据、密钥、.env 文件）、代码质量（DRY、命名、错误处理、死代码）与破坏风险（构建、测试、环境变量）。三项全部通过才继续分组。若该技能不可用，则直接扫描暂存文件中的 .env 真实值、硬编码密钥/令牌/密码、AWS 凭据、私钥（.pem、.key）、连接字符串、.git-credentials、.netrc 等；发现即停止并提醒开发者，解决前拒绝继续。
- 提交信息格式：<type>: <description>，单行、祈使句（Add/Fix/Update）、一次提交一个逻辑变更。类型包括 feat、fix、refactor、docs、style、test、chore。
- 分组策略：按目的而非文件类型分组；同一功能、同一缺陷修复、同一重构或有强依赖的文件归为一组；用途不同、可独立、属于不同逻辑变更的则分开。
- 分支与 PR：小型自包含改动（脚手架、Docker 配置、lint 配置、小修复、依赖更新）可直接提交到 dev；完整功能、大型修复、重大重构需从 dev 建特性分支。分支名用 kebab-case 加类型前缀，如 feat/user-profile、fix/auth-timeout，禁止出现 phase-1、step-2-3 等计划阶段引用。PR 标题用普通描述性英文祈使句，不加 feat:/fix: 前缀，版本由 PR 标签（major/minor/patch）驱动自动升级。
使用方式：开发者请求提交帮助时，先跑提交前门禁，再用 git status 与 git diff 分析真实改动，按逻辑分组生成信息，列出各组涉及文件，等待开发者明确批准后才执行提交；默认只给方案不执行。
限制：不猜测改动，必须查看实际 diff；不修改文件除非被要求；不在提交、分支或 PR 中引用计划步骤；不手动写版本号。资料未提供具体安装命令与平台支持信息。