用途
git-workflow 是一套 Git 协作规范与流程约束。根据资料描述，它会在创建 Git 提交、PR 或代码审查之前被自动调用（AUTO-INVOKE）。其目标是把提交信息、分支命名、PR 内容与代码审查的标准固定下来，减少协作中的随意性与遗漏。资料同时明确了一条语言规则：始终使用用户所用的语言回应，用户用中文提问就用中文，用英文提问就用英文。
主要能力
提交信息规范
采用 Conventional Commits 格式：<type>: <short description>。类型与使用场景如下：
- feat：新功能或新合约
- fix：修复缺陷
- refactor：不改变行为的代码重构
- test：新增或更新测试
- docs：文档变更
- chore：构建配置、依赖更新、工具链
- security：安全修复或加固
提交工作流
- 暂存前运行 git diff 复查全部变更。
- 精确暂存指定文件，避免使用 git add .，以防提交 .env 或构建产物（artifacts）。
- 提交信息要简洁，描述原因（why）而非行为（what）。
- 绝不添加 Co-Authored-By 行，提交信息只包含描述内容。
- 只做提交，除非明确要求，绝不执行 git push。
- 绝不直接推送到 main/master，始终使用功能分支。
分支命名
- feat/<name>，例如 feat/staking-pool
- fix/<name>，例如 fix/reentrancy-guard
- refactor/<name>，例如 refactor/token-structure
PR 要求
每个 PR 必须包含：
- 变更说明：改了什么、为什么改
- 测试结果：forge test 输出（全部通过）
- Gas 影响：受影响函数的 forge test --gas-report 对比
- 部署影响：是否影响已部署合约？是否需要迁移？
- 审查重点：需要仔细审查的具体区域
代码审查规则
- 标准变更：至少 1 名维护者批准
- 安全相关变更：至少 2 名维护者批准
- AI 生成代码：合并前必须通过人工审查与 forge test
- 合约升级：需要全团队审查，并在分叉环境（fork）上进行升级模拟
AI 辅助规则
- AI 生成的代码在提交前必须通过 forge test
- 始终审查 AI 输出中的导入路径是否正确、访问控制是否恰当、Gas 影响如何
- 在 AI 提示词中包含相关文件路径与测试用例，以获得更好结果
- AI 生成代码后运行 forge fmt，确保格式一致
适用场景
该技能面向使用 Solidity / Foundry 工具链（涉及 forge test、forge fmt、gas 报告、合约升级模拟）的协作团队，适合需要统一提交、分支、PR 与审查标准的项目，尤其适用于对安全审批有分级要求、并希望规范 AI 生成代码进入代码库流程的场景。
限制
资料未提供安装方式、调用参数、支持平台与工具版本的说明，这些信息暂未提供。