ccg-workflow 2.1.15 → 3.0.0

package/templates/engine/strategies/git-action.md

@@ -0,0 +1,43 @@
+# Strategy: Git Action — Git 操作
+
+> 适用于 Git 相关操作。委托给现有的专用命令，不重复实现。
+
+## 适用条件
+- 用户请求 commit / rollback / branch 管理 / worktree 等 Git 操作
+- 任何复杂度级别
+
+---
+
+## 路由表
+
+根据用户请求中的关键词，加载对应的现有命令文件并按其指令执行：
+
+| 关键词 | 命令文件 | 说明 |
+|--------|---------|------|
+| commit, 提交 | `~/.claude/commands/ccg/commit.md` | 智能提交（conventional commit） |
+| rollback, 回滚, revert, undo | `~/.claude/commands/ccg/rollback.md` | 交互式回滚 |
+| clean branch, 清理分支 | `~/.claude/commands/ccg/clean-branches.md` | 清理已合并分支 |
+| worktree | `~/.claude/commands/ccg/worktree.md` | Worktree 管理 |
+
+## 执行方式
+
+1. 匹配关键词确定目标命令
+2. `Read("目标命令文件路径")` 加载完整指令
+3. 将用户的 `$ARGUMENTS` 作为该命令的输入
+4. 严格按照命令文件的指令执行
+
+## 未匹配的 Git 操作
+
+如果用户的 Git 请求不匹配上述任何命令（如 `push`, `merge`, `cherry-pick`, `stash` 等）：
+- Claude 直接处理
+- 遵循 Git 安全原则：
+  - 破坏性操作（force push, reset --hard）前必须确认
+  - 不自动 push 到远程（除非用户明确要求）
+  - 优先创建新 commit 而非 amend
+
+---
+
+## 铁律
+
+- **不重复实现** — 现有命令已经过充分测试，直接委托
+- **保持一致性** — 用户通过 `/ccg commit` 和 `/ccg:commit` 应得到相同结果

package/templates/engine/strategies/guided-develop.md

@@ -0,0 +1,208 @@
+# Strategy: Guided Develop — 引导式开发
+
+> 适用于中等复杂度的功能开发。可选调用外部模型进行领域分析。
+
+## 适用条件
+- 复杂度 M（2-5 文件，单模块）
+- 需要一定规划但不需要完整的多模型协作
+- 风险 low 或 medium
+
+---
+
+## 工作流状态机
+
+[phase-state:1-requirements]
+当前阶段：需求增强
+📍 Next: 需求结构化后进入上下文检索
+[/phase-state:1-requirements]
+
+[phase-state:2-context]
+当前阶段：上下文检索
+Gate: 需求已增强 ✓
+📍 Next: 上下文收集完毕后判断是否需要外部模型分析
+[/phase-state:2-context]
+
+[phase-state:3-analysis]
+当前阶段：领域分析（可选外部模型）
+Gate: 上下文已收集 ✓
+📍 Next: 分析完成后进入规划阶段
+[/phase-state:3-analysis]
+
+[phase-state:4-plan]
+当前阶段：规划
+Gate: 分析已完成 ✓
+📍 Next: 用户确认计划后进入实施
+[/phase-state:4-plan]
+
+[phase-state:5-implement]
+当前阶段：实施
+Gate: 用户已确认计划 ✓（HARD STOP）
+📍 Next: 实施完成后进入验证
+[/phase-state:5-implement]
+
+[phase-state:6-verify]
+当前阶段：验证
+Gate: 实施已完成 ✓
+📍 Next: 验证通过后报告结果
+[/phase-state:6-verify]
+
+---
+
+## 阶段详情
+
+### Phase 1: 需求增强 [required]
+
+分析用户的 $ARGUMENTS，补全为结构化需求：
+- **目标**：要实现什么
+- **约束**：不能改什么、需要兼容什么
+- **范围**：哪些文件/模块会受影响
+- **验收标准**：怎样算完成
+
+展示增强后的需求，用户确认或调整。
+
+### Phase 2: 上下文检索 [required]
+
+1. 用 MCP 搜索工具搜索相关代码
+2. 读取目标模块的核心文件
+3. 识别依赖关系和可能的影响范围
+4. 了解现有的测试覆盖情况
+
+### Phase 3: 多模型分析 [required]
+
+**Gate check**: 需求已增强 ✓ 上下文已收集 ✓
+
+**M 复杂度必须调用外部模型进行分析。** 不可跳过。
+
+执行步骤：
+
+1. 确定工作目录：`WORKDIR=$(pwd)`
+2. 根据领域选择模型：
+   - 后端任务 → backend 模型（codex）+ analyzer 角色
+   - 前端任务 → frontend 模型（gemini）+ analyzer 角色
+   - 全栈任务 → 双模型并行
+
+3. **调用 codeagent-wrapper**（必须实际执行，不是读文件）：
+
+```
+Bash({
+  command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--progress --backend codex {{GEMINI_MODEL_FLAG}}- \"$WORKDIR\" <<'CODEAGENT_EOF'\nROLE_FILE: ~/.claude/.ccg/prompts/codex/analyzer.md\n<TASK>\n需求：{增强后的需求}\n上下文：{Phase 2 收集的项目上下文、相关代码摘要}\n</TASK>\nOUTPUT: 技术分析报告（可行性、架构建议、风险评估、实施方案对比）\nCODEAGENT_EOF",
+  run_in_background: true,
+  timeout: 3600000,
+  description: "Backend 模型分析"
+})
+```
+
+如果是全栈任务，同时启动 frontend 模型：
+```
+Bash({
+  command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--progress --backend gemini {{GEMINI_MODEL_FLAG}}- \"$WORKDIR\" <<'CODEAGENT_EOF'\nROLE_FILE: ~/.claude/.ccg/prompts/gemini/analyzer.md\n<TASK>\n需求：{增强后的需求}\n上下文：{Phase 2 收集的项目上下文}\n</TASK>\nOUTPUT: 前端/UX 视角分析报告\nCODEAGENT_EOF",
+  run_in_background: true,
+  timeout: 3600000,
+  description: "Frontend 模型分析"
+})
+```
+
+4. **等待结果**（必须等，不可跳过）：
+```
+TaskOutput({ task_id: "<id>", block: true, timeout: 600000 })
+```
+
+5. 综合模型分析结果，提取关键建议用于 Phase 4 规划
+
+**Task 更新**：`currentPhase → "3-analysis"`, `nextAction → "等待模型分析返回"`
+
+### Phase 4: 规划 [required]
+
+撰写实施计划，输出格式：
+
+```
+📋 实施计划
+
+## 需求
+[增强后的需求摘要]
+
+## 方案
+[选定方案及理由]
+
+## 步骤
+1. [文件路径] — [具体变更]
+2. [文件路径] — [具体变更]
+...
+
+## 影响范围
+- 修改: [文件列表]
+- 新增: [文件列表]（如有）
+- 测试: [需要更新/新增的测试]
+```
+
+将计划持久化到 `.ccg/tasks/{task-name}/plan.md`。
+
+**Task 更新**：
+```
+更新 .ccg/tasks/{task-name}/task.json:
+  currentPhase → "4-plan"
+  gate → "user_approval_required"
+  nextAction → "等待用户审批计划"
+```
+
+**⛔ HARD STOP**：展示计划，等待用户确认后才能进入 Phase 5。
+
+用户确认后：
+```
+更新 task.json: gate → null, currentPhase → "5-implement"
+```
+
+### Phase 5: 实施
+
+1. 严格按计划执行
+2. 遵循项目现有代码规范
+3. 每完成一个主要步骤，简要报告进度
+4. 遇到计划外的问题时告知用户，不自行扩大范围
+
+**Task 更新**：`currentPhase → "5-implement"`, `nextAction → "按计划执行实施"`
+
+### Phase 6: 验证 + 双模型审查 + 质量关卡
+
+1. `git diff` 展示所有变更
+2. 运行测试（如果有）
+
+**⛔ 双模型交叉审查（变更 >30 行时必须执行）：**
+3. 并行调用双模型（`run_in_background: true`，使用 model-router.md 模板）：
+   - backend 模型 + reviewer 角色 — 安全、性能、错误处理
+   - frontend 模型 + reviewer 角色 — 设计一致性（如涉及前端）
+4. 综合审查意见
+
+**⛔ 质量关卡（变更 >30 行时必须逐个调用 Skill，不可跳过）：**
+5. 调用 Skill `verify-quality` — 等待报告
+6. 调用 Skill `verify-security` — 等待报告（涉及 auth/input/crypto 时）
+7. 调用 Skill `verify-change` — 等待报告
+8. Critical 问题必须修复
+4. 检查是否满足验收标准
+5. 输出结果：
+   ```
+   ✅ 开发完成
+     变更: [N] 文件，[M] 行
+     实现: [摘要]
+     测试: [通过/跳过/失败情况]
+     质量: [Critical: N, Warning: N, Info: N]
+     📍 Next: 可以用 /ccg:commit 提交
+   ```
+
+**Task 更新**：`status → "completed"`, `nextAction → "可用 /ccg:commit 提交"`
+
+---
+
+## 升级规则
+
+- 发现涉及 5+ 文件或需要跨模块协调 → 升级到 `full-collaborate`
+- 发现涉及架构级变更 → 升级到 `full-collaborate`
+- 外部模型分析发现重大风险 → 升级到 `full-collaborate`
+
+---
+
+## 铁律
+
+- **Phase 4 计划必须用户确认** — HARD STOP，不可自动跳过
+- **外部模型仅提供建议** — Claude 执行所有文件修改
+- **不扩大范围** — 只做计划内的变更，计划外的报告但不自行处理
+- **增量实施** — 多文件变更时逐文件执行，便于追踪

package/templates/engine/strategies/optimize-measure.md

@@ -0,0 +1,103 @@
+# Strategy: Optimize Measure — 度量驱动优化
+
+> 适用于性能优化，强调先度量后优化。
+
+## 适用条件
+- 用户报告性能问题或要求优化
+- 任何复杂度级别
+- 需要数据驱动的优化决策
+
+## 前置加载（M+ 复杂度时）
+
+```
+Read("~/.claude/.ccg/engine/model-router.md")
+```
+
+---
+
+## 工作流状态机
+
+[phase-state:1-baseline]
+当前阶段：性能基线度量
+📍 Next: 基线建立后进入分析
+[/phase-state:1-baseline]
+
+[phase-state:2-analyze]
+当前阶段：瓶颈分析
+Gate: 基线已建立 ✓
+📍 Next: 瓶颈识别后进入优化
+[/phase-state:2-analyze]
+
+[phase-state:3-optimize]
+当前阶段：针对性优化
+Gate: 瓶颈已识别 ✓
+📍 Next: 优化完成后重新度量
+[/phase-state:3-optimize]
+
+[phase-state:4-measure]
+当前阶段：优化后度量
+Gate: 优化已应用 ✓
+📍 Next: 对比基线验证效果
+[/phase-state:4-measure]
+
+---
+
+## 阶段详情
+
+### Phase 1: 性能基线 [required]
+
+1. 确定度量指标：
+   - 响应时间？吞吐量？内存使用？包大小？加载时间？
+2. 运行基线测试：
+   - `time` 命令 / benchmark / profiler
+   - 记录具体数值
+3. 输出基线：
+   ```
+   📊 性能基线
+     指标: [指标名] = [当前值]
+     测试方式: [如何测量的]
+     目标: [用户期望值，如有]
+   ```
+
+### Phase 2: 瓶颈分析
+
+1. 分析代码找出瓶颈
+2. 对于 M+ 复杂度，可选调用外部模型：
+   - backend 模型: optimizer 角色 — 服务端/算法优化建议
+   - frontend 模型: optimizer 角色 — 前端/加载优化建议
+3. 按影响大小排序瓶颈：
+   ```
+   🔍 瓶颈分析
+     1. [位置] — 预估影响: [高/中/低] — [原因]
+     2. [位置] — 预估影响: [高/中/低] — [原因]
+   ```
+
+### Phase 3: 针对性优化
+
+**一次优化一个瓶颈**（便于验证每个优化的效果）：
+1. 应用优化
+2. 简要说明做了什么
+3. 如果涉及算法变更，确保正确性
+
+### Phase 4: 优化后度量 [required]
+
+1. 使用与 Phase 1 **完全相同的方式**重新度量
+2. 对比基线：
+   ```
+   📊 优化效果
+     指标: [指标名]
+     基线: [优化前值]
+     优化后: [优化后值]
+     提升: [百分比或绝对值]
+     📍 Next: 如需继续优化下一个瓶颈，继续 Phase 2-4 循环
+   ```
+3. 如果效果不明显 → 回退优化，尝试下一个瓶颈
+
+---
+
+## 铁律
+
+- **不可在没有基线的情况下优化** — Phase 1 不可跳过
+- **优化前后必须有数据对比** — Phase 4 不可跳过
+- **一次只优化一个瓶颈** — 便于归因效果
+- **效果不明显必须回退** — 不可保留无效的"优化"

package/templates/engine/strategies/quick-implement.md

@@ -0,0 +1,96 @@
+# Strategy: Quick Implement — 快速实现
+
+> 适用于范围清晰的小功能开发。Claude 独立完成，不调用外部模型。
+
+## 适用条件
+- 复杂度 S（单文件/单组件，<30 行变更）
+- 需求明确，无需架构决策
+- 风险 low
+
+---
+
+## 工作流状态机
+
+[phase-state:1-context]
+当前阶段：上下文收集
+📍 Next: 了解现有代码模式后进入计划阶段
+[/phase-state:1-context]
+
+[phase-state:2-plan]
+当前阶段：简要计划
+Gate: 上下文已收集 ✓
+📍 Next: 用户确认计划后进入实施阶段
+[/phase-state:2-plan]
+
+[phase-state:3-implement]
+当前阶段：实施
+Gate: 用户已确认计划 ✓
+📍 Next: 实施完成后进入验证阶段
+[/phase-state:3-implement]
+
+[phase-state:4-verify]
+当前阶段：验证
+Gate: 实施已完成 ✓
+📍 Next: 验证通过后报告结果
+[/phase-state:4-verify]
+
+---
+
+## 阶段详情
+
+### Phase 1: 上下文收集 [required]
+
+1. 用 MCP 搜索工具或 Grep 搜索与需求相关的现有代码
+2. 读取目标文件，理解：
+   - 现有代码模式和规范
+   - 相关的类型定义/接口
+   - 已有的类似实现（可复用的模式）
+
+### Phase 2: 简要计划 [required]
+
+输出 3-5 步实施计划，简洁明了：
+
+```
+📝 实施计划
+  1. [具体步骤]
+  2. [具体步骤]
+  3. [具体步骤]
+  预计变更: [N] 文件
+```
+
+等待用户确认或调整。
+
+### Phase 3: 实施
+
+1. 按计划逐步执行
+2. 遵循项目现有的代码规范和命名约定
+3. 不引入新的依赖（除非计划中已说明）
+
+### Phase 4: 验证
+
+1. `git diff` 展示变更
+2. 如果项目有测试 → 运行相关测试
+3. **质量快检**（变更 >30 行时）：`/verify-quality` 检测代码质量
+4. 如果涉及认证/输入处理/加密 → `/verify-security` 安全扫描
+5. 输出结果：
+   ```
+   ✅ 实现完成
+     变更: [N] 文件，[M] 行
+     新增: [描述]
+     📍 Next: 可以用 /ccg:commit 提交
+   ```
+
+---
+
+## 升级规则
+
+- 涉及 3+ 文件或需要架构决策 → 升级到 `guided-develop`
+- 涉及认证/数据库等高风险领域 → 升级到 `guided-develop`
+
+---
+
+## 铁律
+
+- **不可跳过 Phase 2 计划步骤** — 即使"很简单"也要列出步骤
+- **不引入未计划的变更** — 只做用户要求的，不"顺手"改其他东西
+- **遵循现有规范** — 新代码必须与现有代码风格一致

package/templates/engine/strategies/refactor-safely.md

@@ -0,0 +1,157 @@
+# Strategy: Refactor Safely — 安全重构
+
+> 适用于代码重构，强调增量执行和测试保护。
+
+## 适用条件
+- 复杂度 M 或以上
+- 重构、整理、提取、简化类任务
+- 需要保证行为不变
+
+## 前置加载（L/XL 复杂度时）
+
+```
+Read("~/.claude/.ccg/engine/model-router.md")
+```
+
+---
+
+## 工作流状态机
+
+[phase-state:1-understand]
+当前阶段：理解现有代码
+📍 Next: 映射完依赖关系后建立测试基线
+[/phase-state:1-understand]
+
+[phase-state:2-baseline]
+当前阶段：建立基线
+Gate: 代码已理解 ✓
+📍 Next: 基线建立后进入规划
+[/phase-state:2-baseline]
+
+[phase-state:3-plan]
+当前阶段：规划重构步骤
+Gate: 测试基线已建立 ✓
+📍 Next: 计划确认后逐步执行
+[/phase-state:3-plan]
+
+[phase-state:4-execute]
+当前阶段：增量执行
+Gate: 用户已确认计划 ✓
+📍 Next: 每步执行后验证测试通过
+[/phase-state:4-execute]
+
+[phase-state:5-verify]
+当前阶段：最终验证
+Gate: 所有步骤已执行 ✓
+📍 Next: 全部测试通过后报告结果
+[/phase-state:5-verify]
+
+---
+
+## 阶段详情
+
+### Phase 1: 理解 [required]
+
+**Task 更新**：`currentPhase → "1-understand"`, `nextAction → "读取代码，映射依赖"`
+
+1. 读取所有涉及重构的文件
+2. 映射依赖关系（谁调用了这些代码？谁被这些代码调用？）
+3. 识别公共 API / 接口边界（这些不能轻易改变）
+4. 记录当前行为特征
+
+### Phase 2: 建立基线 [required]
+
+1. 运行现有测试：`pnpm test` / `go test` / `pytest` 等
+2. 记录测试结果作为基线
+3. 如果没有相关测试 → 告知用户，建议但不强制先补测试
+4. 输出基线状态：
+   ```
+   📊 测试基线
+     通过: [N] 个
+     失败: [M] 个（已有的，非重构引入）
+     覆盖: [相关模块的测试覆盖情况]
+   ```
+
+### Phase 3: 规划
+
+制定增量重构计划，每一步应该能独立通过测试：
+
+```
+📋 重构计划
+
+## 目标
+[重构目标和预期效果]
+
+## 步骤（每步独立可验证）
+1. [步骤描述] — 影响文件: [...]
+2. [步骤描述] — 影响文件: [...]
+...
+
+## 不变量
+- [不应该改变的行为/接口]
+```
+
+对于 L/XL 任务，可选调用外部模型做架构审查。
+
+展示计划，等待用户确认。
+
+### Phase 4: 增量执行
+
+**Task 更新**：`currentPhase → "4-execute"`, `nextAction → "逐步执行重构"`
+
+**逐步执行**，每步之后：
+1. 应用变更
+2. 运行测试
+3. 如果测试通过 → 继续下一步
+4. 如果测试失败 → **立即停止**，分析原因，修复或回退
+
+每步报告：
+```
+Step [N/M]: [描述] — ✅ 测试通过 / ❌ 测试失败
+```
+
+### Phase 5: 最终验证 + 双模型审查 + 质量关卡
+
+1. 运行完整测试套件
+2. 对比基线：确保不引入新的失败
+
+**⛔ 双模型交叉审查（必须执行，使用 model-router.md 调用模板）：**
+
+3. 获取变更：`git diff` 全量输出
+4. 并行调用双模型审查（`run_in_background: true`）：
+   - backend 模型 + reviewer 角色 — 关注安全、性能、错误处理、行为一致性
+   - frontend 模型 + reviewer 角色 — 关注可访问性、设计一致性（如涉及前端）
+5. 等待双模型结果，综合审查意见
+
+**⛔ 质量关卡（必须逐个调用 Skill，不可跳过，不可用自己的判断替代）：**
+
+6. 调用 Skill `verify-quality` — 等待报告
+7. 调用 Skill `verify-security` — 等待报告
+8. 调用 Skill `verify-change` — 等待报告
+
+**综合报告**：双模型审查 + 质量关卡，按严重度分级：
+- Critical → 必须修复后重新验证
+- Warning → 建议修复
+- Info → 供参考
+
+9. `git diff` 展示全部变更
+5. 输出结果：
+   ```
+   ✅ 重构完成
+     步骤: [N] 步全部通过
+     变更: [文件数] 文件，[行数] 行
+     测试: 基线 [N] 通过 → 重构后 [N] 通过
+     质量: [Critical: N, Warning: N, Info: N]
+     📍 Next: /ccg:commit 提交
+   ```
+
+**Task 更新**：`status → "completed"`, `nextAction → "可用 /ccg:commit 提交"`
+
+---
+
+## 铁律
+
+- **不可一次性大改** — 必须拆分为增量步骤
+- **每步必须验证测试** — 测试失败立即停止
+- **保持行为不变** — 除非重构目标明确包含行为变更
+- **不扩大范围** — 只重构用户指定的范围