Code Dev

核心功能

code-dev 是一套强制规范化的 Git 开发工作流技能，通过 Subagent 代理执行完整的 feature/fix 开发周期。其核心设计围绕"安全优先"原则，内置多重约束机制防止常见的开发风险。

显著优点

1. 流程刚性约束：四大禁止规则（禁推 main、禁跳 PR、禁盲目开发、禁表面修复）通过代码级强制执行，而非仅靠文档约定
2. Subagent 架构：将开发任务隔离在独立会话中运行，支持 bailian/glm-5 高思考模式，实现复杂任务的可靠分解
3. 前置理解机制：Feature 开发前强制代码库调研（查重用 helper、评估影响范围、确定最小修改），Fix 前强制根因分析（复现→定位→根因→方案→影响评估），显著降低技术债务
4. 自动化质量关卡：内置 code-review 技能调用、类型检查、lint、单元测试等硬性检查点
5. 完整工具链集成：原生支持 git + gh CLI，PR 创建自动化

潜在局限性

• 模型依赖：指定 bailian/glm-5 模型，若该模型不可用或需切换需手动调整
• 单点分支策略：强制以 develop 为基线，对使用 main 直接开发或 GitLab Flow 的团队需要 fork 改造
• Subagent 开销：每次开发任务启动独立会话，简单变更可能产生额外延迟
• GitHub 中心化：依赖 gh CLI 和 GITHUB_TOKEN，对 GitLab、Gitee 等平台支持需扩展

适合人群

• 中型以上团队寻求标准化开发流程
• 需要防止"直接改线上"事故的安全敏感项目
• 新成员 onboarding，通过强制流程降低认知负担
• 追求 Conventional Commits + PR Review 文化的工程团队

常规风险

| 风险类型 | 说明 |

|---------|------|

| 权限风险 | 需 `filesystem:read/write` + `subprocess:exec`，恶意 skill 可篡改代码 |

| Token 泄露 | `GITHUB_TOKEN` 若配置不当可能在 Subagent 日志中暴露 |

| 模型幻觉 | Subagent 可能生成"看起来正确"但实际错误的代码库理解结论 |

| 流程绕过 | 用户可通过手动 `git push` 绕过 skill 约束，需配合 CI 钩子兜底 |

使用建议

建议配合 GitHub branch protection rules 使用，将 skill 的"软约束"转化为仓库的"硬门槛"。

核心用法

code-dev 是一款专注于规范 Git 开发流程的智能工作流技能，采用纯 Markdown 文档形态，通过 Subagent 模式安全执行完整的软件开发生命周期管理。该技能核心围绕 Feature 分支工作流 设计，强制要求从 develop 分支创建新分支，经过代码实现、自动审查、PR 提交的标准流程，最终合并回 develop 分支，从根本上杜绝直接推送 main 分支的风险操作。

技能执行采用 sessions_spawn 调用 Subagent 完成，配置 bailian/glm-5 模型并启用 thinking: high 深度思考模式。完整流程包含七大阶段：任务分析（确定 feature/fix/docs/refactor 类型）、代码库理解（Feature 必填，避免重复实现）、Bug 根因调研（Fix 必填，禁止表面修复）、分支创建（规范命名如 feature/identity-persistence）、开发实施（最小修改范围 + 测试 + 文档）、强制 Code Review（调用 code-review 技能循环审查）、PR 提交（使用 GitHub CLI 创建标准化 PR）。

显著优点

流程规范性极强：通过硬编码规则（❌ 禁止直接推送 main、❌ 禁止跳过 PR、❌ 禁止未理解代码库就开发）将团队最佳实践固化为强制约束，显著降低因人为疏忽导致的代码冲突和主分支污染风险。

安全执行架构：所有操作通过 Subagent 隔离执行，Skill 本身为纯 Markdown 文档，无动态代码执行能力，从根本上避免恶意代码注入风险。权限申请遵循最小化原则（filesystem:read/write、subprocess:exec），完全匹配 Git 操作需求。

智能化前置分析：Feature 开发强制要求先理解代码库（搜索复用 helper/util、评估影响范围），Fix 强制要求根因分析（复现、定位、分析、评估），避免低效重复开发和修复治标不治本。

标准化产出物：内置分支命名规范（kebab-case）、Conventional Commits 提交规范、PR 描述模板（含代码库理解/Bug 根因/测试清单章节），大幅提升代码审查效率和项目可追溯性。

开放生态集成：与 code-review 技能深度联动形成质量门禁，支持 GitHub CLI 原生集成，可选 GITHUB_TOKEN 认证，无缝对接现有 DevOps 工具链。

潜在缺点与局限性

依赖 Subagent 运行环境：必须使用支持 sessions_spawn 和 Subagent 的运行时，对基础环境有特定要求，轻量级 Agent 环境可能无法直接使用。

GitHub 生态绑定较深：PR 创建依赖 gh CLI 工具，代码审查流程针对 GitHub Pull Request 设计，使用 GitLab、Gitee 等其他 Git 托管平台的团队需要额外适配。

无图形化界面：纯命令行和 Markdown 交互形态，对习惯 GUI 工具（如 GitKraken、SourceTree）的开发者存在学习成本。

权限申请较宽泛：虽然合理，但 subprocess:exec 权限在严格安全环境中可能需要额外审批，部分企业安全策略可能限制此类权限授予。

T3 来源维护风险：由个人开发者（LuciusCao）维护，虽采用 MIT 开源协议且仓库公开透明，但长期维护稳定性和企业级 SLA 保障弱于商业产品。

适合的目标群体

• 中小型技术团队：缺乏专职 DevOps 工程师，需要快速建立规范 Git 流程的创业公司或研发团队
• 开源项目维护者：希望贡献者遵循统一贡献规范的社区项目
• 代码质量敏感型组织：金融、医疗等对主分支稳定性要求极高的行业开发团队
• 远程协作团队：异步沟通为主，需要标准化流程减少沟通成本的分布式团队
• Git 工作流教育场景：用于培训新成员理解 Feature Branch Workflow 和 Code Review 最佳实践

常规使用风险

性能方面：Subagent 调用 bailian/glm-5 模型并启用高思考模式，复杂任务分析可能产生较高 Token 消耗和延迟，建议对简单任务评估是否需降级模型配置。

依赖项风险：依赖本地 Git 环境、GitHub CLI (gh) 工具链，以及可选的 GITHUB_TOKEN 环境变量。若环境配置缺失或 Token 过期/权限不足，将导致流程中断。

权限管理风险：虽然 Skill 本身安全，但 Subagent 执行的 Git 操作具有实际文件系统变更能力，建议配合分支保护规则（Branch Protection Rules）在服务端进行二次防护，避免 Subagent 配置错误或提示注入导致的意外推送。

凭证安全：GITHUB_TOKEN 作为可选依赖，用户需通过安全机制（如 GitHub Actions Secrets、本地凭证管理器）注入，禁止硬编码在配置文件中。

模型输出稳定性：LLM 生成的分支命名、PR 描述等内容可能存在格式偏差，建议关键项目配合人工复核环节。