核心用法
本Skill提供一套标准化的Git开发工作流自动化框架，专为中大型项目的协作开发设计。它通过智能触发机制判断是否介入：当用户使用"开发"、"实现"、"新功能"、"修复"、"提交PR"等关键词，且预估工作量超过30分钟或涉及3个以上文件时，Skill自动激活。核心执行模式采用Subagent隔离架构——所有实际代码操作均通过sessions_spawn委派给子Agent完成，主Agent仅负责流程编排与决策。
完整开发流程分为七个阶段：任务分析（确定类型与分支名）→代码库理解（Feature必须，避免重复造轮子）→Bug根因调研（Fix必须，禁止症状修复）→分支创建（从develop切出，规范命名）→开发实施（最小修改+测试+文档+类型检查）→Code Review（强制调用code-review技能循环审查）→提交PR（基于develop，附带标准化描述模板）。
Skill内置严格的安全红线：禁止直接推送main、禁止跳过PR流程、禁止在未理解代码库时开发新功能、禁止未找到根因时修复Bug。
显著优点
流程规范性极强：强制Conventional Commits规范、kebab-case分支命名、PR描述模板，从机制上杜绝"随手提交"的坏习惯。对于团队新人，这相当于内置了一位24小时在线的技术负责人。
Subagent安全架构：代码执行与主Agent隔离，即使子Agent出现异常，也不会影响主会话状态。这是目前Agent编程中最安全的执行模式之一。
复杂度自适应触发：通过工作量预估和文件数量双重判断，既避免简单修改被过度流程化，又确保复杂变更进入受控流程。
知识沉淀设计：Feature开发前的代码库理解环节强制输出"已有helper/util"、"影响的功能"、"最小修改范围"等分析，Fix必须记录"Bug表现-触发条件-根因位置-修复方案"，天然形成技术决策文档。
潜在缺点与局限性
触发门槛可能遗漏风险变更：正则复杂度评估依赖"预估时间"这一主观判断，若用户低估复杂度，可能导致本应收管的变更直接执行。建议配合代码行数或圈复杂度等客观指标。
GitHub CLI强依赖：gh pr create等命令要求预装gh工具并配置GITHUB_TOKEN，纯Git环境或GitLab/GitCode平台用户需要额外适配。
Code Review单点瓶颈：流程强制调用code-review技能，但未定义该技能不可用时（如未安装或超时）的降级策略。
中文指令触发局限：触发词均为中文（"开发"、"修复"等），英文工作流用户可能无法激活。
版本号不一致：文档声明v1.2与元数据v1.0.7存在差异，虽不影响功能，但反映维护精细度不足。
适合的目标群体
- 技术团队负责人：需为团队建立标准化Git工作流，减少代码审查人力投入
- 开源项目维护者：通过自动化强制PR流程，降低恶意代码直推风险
- 全栈/后端开发者：频繁处理多文件Feature开发或复杂Bug修复，需要系统化的变更管理
- DevOps工程师：作为CI/CD前置环节，确保入仓代码符合规范
- Agent编程学习者：研究Subagent模式和安全隔离的最佳实践案例
不适合场景：单文件快速修复、个人本地原型开发、已建立完整CI/CD流水线的大型企业（可能流程冲突）。
使用风险
性能风险：Subagent创建和销毁存在固定开销，对于高频小任务，流程耗时可能超过实际编码时间。建议在批量任务场景下关闭自动触发。
依赖项风险：强制依赖git和gh命令行工具，Windows用户需额外配置Git Bash或WSL环境。GITHUB_TOKEN权限配置不当可能导致PR创建失败。
流程僵化风险：过度规范可能抑制紧急热修的响应速度。虽然Skill禁止直接推main，但真实生产故障可能需要绕过PR的特权操作，用户需理解何时人工接管。
审查盲区：code-review技能为另一独立组件，其审查质量直接影响本Skill输出质量。若code-review存在漏检，本Skill无法二次拦截。
数据泄露风险：PR描述模板要求填写"Bug表现"、"影响功能"等，可能无意暴露敏感业务信息。建议在处理安全相关代码时人工审核PR内容。