核心用法
code-dev 是一个结构化的 Git 开发流程技能，通过 Subagent 模式执行标准化的 feature/bug 开发全周期。其核心流程为：任务分析 → 代码库理解/Bug 根因调研 → 分支创建 → 开发实施 → 强制 Code Review → 提交 PR。技能强制要求从 develop 分支切出新分支，禁止直接推送 main，并必须在提交前使用 code-review 技能进行自动化审查。
显著优点
1. 流程标准化：提供完整的分支命名规范（feature/xxx, fix/xxx）、Commit Message 规范（Conventional Commits）及 PR 模板，降低团队沟通成本
2. 风险前置控制：Feature 开发前强制代码库调研，避免重复实现和功能冲突；Bug 修复前强制根因分析，杜绝"症状修复"
3. 强制质量门禁：集成 code-review 技能作为必经环节，形成"实现→审查→修复→再审查"的闭环
4. 安全设计：通过环境变量权限控制（GITHUB_TOKEN）和文件系统沙箱，限制操作范围
潜在缺点与局限性
1. 流程刚性：强制 Subagent 执行和 develop 分支策略，对于个人快速原型开发或非常规 Git 工作流（如 trunk-based）适配性较差
2. 依赖外部工具：需预装 git 和 gh (GitHub CLI)，且 GITHUB_TOKEN 配置增加了初始 setup 复杂度
3. 审查瓶颈：code-review 环节可能引入延迟，紧急 hotfix 场景下缺乏快速通道机制
4. 平台锁定：PR 创建深度依赖 GitHub CLI，对 GitLab、Gitee 等其他平台支持不足
适合人群
- 中小型技术团队寻求规范 Git 工作流
- 开源项目维护者需要标准化贡献流程
- 需要强制代码审查机制但缺乏 DevOps 基建的项目
- 多人协作场景下的新人 onboarding 工具
常规风险
1. 权限风险：gh pr create 需要写权限，TOKEN 泄露可能导致仓库被篡改；建议配置最小权限 Token
2. 分支污染：若用户本地 develop 分支未同步，可能基于旧代码开发；技能已包含 git pull 但仍依赖用户环境
3. Subagent 隔离失效：虽然设计为 Subagent 执行，但实际权限配置为 read-write 文件系统访问，存在越界修改风险
4. 审查流于形式：code-review 技能本身的审查质量依赖底层模型能力，可能产生"伪通过"