Git Workflow Skill
安全的 Git 开发流程，通过 Subagent 执行。
⚠️ 核心规则（不可违反）
┌─────────────────────────────────────────────────────────┐
│ ❌ 禁止直接推送到 main 分支 │
│ ❌ 禁止跳过 PR 流程 │
│ ❌ 禁止在未理解代码库的情况下开发新功能 │
│ ❌ 禁止在未找到 Bug 根因的情况下修复 Bug │
│ │
│ ✅ 必须从 develop 创建新分支 │
│ ✅ 必须通过 PR 合并到 develop │
│ ✅ 必须使用 code-review 技能审查代码 │
└─────────────────────────────────────────────────────────┘
执行方式
⚠️ 所有开发任务必须通过 Subagent 执行：
sessions_spawn({
runtime: "subagent",
mode: "run",
model: "bailian/glm-5",
thinking: "high",
task: "{任务描述}"
});
完整流程
Phase 1: 任务分析
1. 确定任务类型（feature / fix / docs / refactor）
2. 生成分支名称（feature/xxx, fix/xxx）
3. 确认目标分支 = develop（永远是 develop！）
Phase 2: 代码库理解（Feature 必须执行）
⚠️ 对于新 Feature，必须先充分理解当前代码库：
┌─────────────────────────────────────────────────────────┐
│ 检查清单： │
│ │
│ □ 是否已有类似的 helper/util 方法？ │
│ □ 会影响哪些现有功能？ │
│ □ 需要修改哪些文件？ │
│ □ 哪些代码是不必要修改的？ │
│ │
│ 避免： │
│ ❌ 重复实现 helper/util 方法 │
│ ❌ 影响当前功能 │
│ ❌ 修改不必要的代码 │
└─────────────────────────────────────────────────────────┘
执行步骤：
- 搜索相关代码文件（grep, find）
- 阅读相关模块的实现
- 识别可复用的 helper/util
- 确定最小修改范围
Phase 3: Bug 根因调研（Fix 必须执行）
⚠️ 对于 Bug 修复，必须完全充分调研找到 Bug 的产生原因：
┌─────────────────────────────────────────────────────────┐
│ 调研清单： │
│ │
│ □ Bug 的具体表现是什么？ │
│ □ Bug 在什么条件下触发？ │
│ □ Bug 的根因在哪里？（代码位置） │
│ □ 修复方案是什么？是否会影响其他功能？ │
│ │
│ 禁止： │
│ ❌ 在未找到根因的情况下修复 │
│ ❌ 只修复表面症状而不修复根因 │
└─────────────────────────────────────────────────────────┘
执行步骤：
- 复现 Bug（如果能）
- 定位 Bug 代码位置
- 分析根因
- 设计修复方案
- 评估影响范围
Phase 4: 分支创建
# 1. 确保 develop 是最新的
git checkout develop
git pull origin develop
# 2. 创建新分支（规范命名）
git checkout -b {type}/{name}
# 示例
# feature/identity-persistence
# fix/cors-validation
# docs/api-reference
Phase 5: 开发实施
必须包含：
- ✅ 代码实现（最小修改范围）
- ✅ 单元测试
- ✅ 文档更新（API、README、CHANGELOG）
- ✅ 类型检查通过
- ✅ Lint 通过
注意业务边界：
- 只修改必要的代码
- 不影响无关功能
- 测试覆盖新逻辑和边界情况
Phase 6: Code Review（必须执行）
⚠️ 实现完成后，必须使用 code-review 技能进行自动审查：
// 触发 code-review skill
sessions_spawn({
runtime: "subagent",
mode: "run",
thinking: "high",
task: `使用 code-review 技能审查当前变更：
- 分支: {branchName}
- 对比: develop...HEAD`
});
审查循环：
- 运行 code-review
- 修复发现的问题
- 再次审查，直到无新问题
Phase 7: 提交 PR
审查通过后提交 PR 到 develop：
# 推送分支
git push origin {branchName}
# 创建 PR
gh pr create --base develop --head {branchName} \
--title "{type}: {简短描述}" \
--body "{PR 描述}"
PR 描述模板：
## 变更内容
- 变更 1
- 变更 2
## 代码库理解（Feature）
- 已有的 helper/util：xxx
- 影响的功能：xxx
- 最小修改范围：xxx
## Bug 根因分析（Fix）
- Bug 表现：xxx
- 触发条件：xxx
- 根因位置：xxx
- 修复方案：xxx
## 测试
- [ ] 单元测试通过
- [ ] 类型检查通过
- [ ] Lint 通过
- [ ] Code Review 通过
## 相关 Issue
Closes #{issue-number}
流程结束
提交 PR 后流程结束。
后续由用户决定：
- 手动 Review PR
- 让其他 Agent Review PR
- 合并 PR
分支命名规范
| 类型 | 格式 | 示例 |
|---|---|---|
| Feature | feature/{name} | feature/identity-persistence |
| Fix | fix/{name} | fix/cors-validation |
| Docs | docs/{name} | docs/api-reference |
| Refactor | refactor/{name} | refactor/message-queue |
命名规则：
- 使用 kebab-case（小写 + 连字符）
- 简短但描述性强
Commit Message 规范
{type}({scope}): {description}
[optional body]
[optional footer]
类型：
| Type | 用途 |
|---|---|
feat | 新功能 |
fix | Bug 修复 |
docs | 文档更新 |
refactor | 重构 |
test | 测试相关 |
chore | 构建/工具/依赖 |
Subagent Task 模板
启动开发任务时使用此模板：
sessions_spawn({
runtime: "subagent",
mode: "run",
model: "bailian/glm-5",
thinking: "high",
cwd: "{projectDir}",
task: `你是 Git Workflow 开发助手。
## 任务信息
- 类型：{feature|fix}
- 描述：{taskDescription}
- 分支名称：{branchName}
## ⚠️ 如果是 Feature，必须先理解代码库：
1. 搜索相关代码文件
2. 阅读相关模块实现
3. 识别可复用的 helper/util
4. 确定最小修改范围
避免：
- 重复实现 helper/util 方法
- 影响当前功能
- 修改不必要的代码
## ⚠️ 如果是 Fix，必须先找到 Bug 根因：
1. 复现 Bug（如果能）
2. 定位 Bug 代码位置
3. 分析根因
4. 设计修复方案
5. 评估影响范围
## 开发流程
1. 从 develop 创建分支：{branchName}
2. 实现变更（最小修改范围）
3. 编写测试
4. 更新文档
5. 运行检查（typecheck, lint, test）
## 完成后
1. 使用 code-review 技能审查代码
2. 修复发现的问题
3. 再次审查，直到无新问题
4. 提交 PR 到 develop
## 安全规则
- ❌ 不要推送到 main
- ❌ 不要跳过 code-review
- ✅ 必须从 develop 创建分支
- ✅ 必须 PR 到 develop`
});
Key Points
- Subagent 执行 - 所有开发任务通过 subagent 完成
- 模型配置 -
bailian/glm-5+thinking: "high" - Feature 先理解 - 避免重复实现、影响现有功能
- Fix 先找根因 - 禁止只修复表面症状
- develop 分支 - 所有 PR 都合并到 develop
- Code Review - 实现完成后必须审查
- PR 结束流程 - 提交 PR 后等待人工或其他 Agent Review