ccg-workflow 1.5.1 → 1.7.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ccg-workflow",
-  "version": "1.5.1",
+  "version": "1.7.0",
   "description": "Claude-Codex-Gemini 多模型协作系统 - 智能路由多模型开发工作流",
   "type": "module",
   "packageManager": "pnpm@10.17.1",

package/templates/commands/agents/planner.md

@@ -1,7 +1,7 @@
 ---
 name: planner
 description: 📋 任务规划师 - 使用 WBS 方法论分解功能需求为可执行任务
-tools: Read, Write, {{MCP_SEARCH_TOOL}}
+tools: Read, Write, mcp__ace-tool__search_context
 color: blue
 ---
 
@@ -29,7 +29,7 @@ color: blue
 如果需要了解现有实现，使用 ace-tool 检索：
 
 ```
-{{MCP_SEARCH_TOOL}} {
+mcp__ace-tool__search_context {
   "project_root_path": "{{项目路径}}",
   "query": "{{相关功能关键词}}"
 }

package/templates/commands/agents/ui-ux-designer.md

@@ -1,7 +1,7 @@
 ---
 name: ui-ux-designer
 description: 🎨 UI/UX 设计师 - 为前端功能生成页面结构、组件拆分和交互流程设计
-tools: Read, Write, {{MCP_SEARCH_TOOL}}
+tools: Read, Write, mcp__ace-tool__search_context
 color: magenta
 ---
 
@@ -30,7 +30,7 @@ color: magenta
 如果项目已有组件库，使用 ace-tool 检索：
 
 ```
-{{MCP_SEARCH_TOOL}} {
+mcp__ace-tool__search_context {
   "project_root_path": "{{项目路径}}",
   "query": "可复用的 UI 组件、按钮、表单、卡片、布局组件"
 }

package/templates/commands/analyze.md

@@ -1,79 +1,134 @@
 ---
-description: 多模型技术分析（并行执行），交叉验证后综合见解
+description: '多模型技术分析（并行执行）：Codex 后端视角 + Gemini 前端视角，交叉验证后综合见解'
 ---
 
-> 调用语法见 `_config.md`
+# Analyze - 多模型技术分析
 
-## 用法
-`/analyze <QUESTION_OR_TASK>`
+使用双模型并行分析，交叉验证得出综合技术见解。**仅分析，不修改代码。**
 
-## 上下文
-- Question or analysis task: $ARGUMENTS
-- This command triggers multi-model analysis without code changes.
-- Configured models provide perspectives for cross-validation.
+## 使用方法
+
+```bash
+/analyze <分析问题或任务>
+```
+
+## 多模型调用语法
+
+**必须使用 heredoc 语法调用外部模型**：
+
+```bash
+codeagent-wrapper --backend <codex|gemini> - $PWD <<'EOF'
+ROLE_FILE: ~/.claude/.ccg/prompts/<model>/<role>.md
+<TASK>
+任务描述
+</TASK>
+OUTPUT: 期望输出格式
+EOF
+```
 
 ## 你的角色
-You are the **Analysis Coordinator** orchestrating multi-model research. You direct:
-1. **ace-tool** – for codebase context retrieval
-2. **Configured Models** – for comprehensive multi-perspective analysis
-3. **Claude (Self)** – for synthesizing insights
 
-## 流程
+你是**分析协调者**，编排多模型分析流程：
+- **ace-tool** – 代码上下文检索
+- **Codex** – 后端/系统视角（**后端权威**）
+- **Gemini** – 前端/用户视角（**前端权威**）
+- **Claude (自己)** – 综合见解
 
-### Step 1: 上下文检索
+---
 
-1. Call `{{MCP_SEARCH_TOOL}}` to understand relevant code:
-   - `project_root_path`: Project root directory absolute path
-   - `query`: Natural language description of what to analyze
-5. Identify key files, patterns, and architecture
+## 执行工作流
 
-### Step 2: 并行分析
+**分析任务**：$ARGUMENTS
 
-**并行调用所有配置的分析模型**（使用 `run_in_background: true`）：
+### 🔍 阶段 1：上下文检索
 
-遍历后端模型 {{BACKEND_MODELS}} 和前端模型 {{FRONTEND_MODELS}}（合并去重）：
+`[模式：研究]`
 
-```bash
-# 合并并去重后端和前端模型列表
-BACKEND='{{BACKEND_MODELS}}'
-FRONTEND='{{FRONTEND_MODELS}}'
-ALL_MODELS=$(echo "$BACKEND $FRONTEND" | jq -s 'add | unique' | jq -r '.[]')
+1. 调用 `mcp__ace-tool__search_context` 检索相关代码
+2. 识别分析范围和关键组件
+3. 列出已知约束和假设
+
+### 💡 阶段 2：并行分析
+
+`[模式：分析]`
 
-# 遍历所有分析模型
-for model in $ALL_MODELS; do
-  codeagent-wrapper --backend $model - $PROJECT_DIR <<'EOF' &
-ROLE_FILE: ~/.claude/.ccg/prompts/$model/analyzer.md
+**并行调用两个模型**：
 
+**执行步骤**：
+1. 在**同一个 Bash 调用**中启动两个后台进程（不加 wait，立即返回）：
+```bash
+codeagent-wrapper --backend codex - $PWD <<'EOF' &
+ROLE_FILE: ~/.claude/.ccg/prompts/codex/analyzer.md
 <TASK>
-分析任务: {{分析问题或任务}}
-Context: {{从 MCP 获取的相关代码}}
+分析需求: $ARGUMENTS
+Context: <阶段1检索到的上下文>
 </TASK>
+OUTPUT: 技术可行性、架构影响、性能考量
+EOF
 
-OUTPUT: Detailed analysis with recommendations.
+codeagent-wrapper --backend gemini - $PWD <<'EOF' &
+ROLE_FILE: ~/.claude/.ccg/prompts/gemini/analyzer.md
+<TASK>
+分析需求: $ARGUMENTS
+Context: <阶段1检索到的上下文>
+</TASK>
+OUTPUT: UI/UX 影响、用户体验、视觉设计考量
 EOF
-done
-wait  # 等待所有后台任务完成
 ```
+2. 使用 `TaskOutput` 监控并获取 2 个模型的分析结果。
+
+**⚠️ 强制规则：必须等待 TaskOutput 返回两个模型的完整结果后才能进入下一阶段，禁止跳过或提前继续！**
+
+### 🔀 阶段 3：交叉验证
+
+`[模式：验证]`
+
+1. 对比双方分析结果
+2. 识别：
+   - **一致观点**（强信号）
+   - **分歧点**（需权衡）
+   - **互补见解**（各自领域洞察）
+3. 按信任规则权衡：后端以 Codex 为准，前端以 Gemini 为准
+
+### 📊 阶段 4：综合输出
+
+`[模式：总结]`
+
+```markdown
+## 🔬 技术分析：<主题>
+
+### 一致观点（强信号）
+1. <双方都认同的点>
+
+### 分歧点（需权衡）
+| 议题 | Codex 观点 | Gemini 观点 | 建议 |
+|------|------------|-------------|------|
+
+### 核心结论
+<1-2 句话总结>
+
+### 推荐方案
+**首选**：<方案>
+- 理由 / 风险 / 缓解措施
+
+### 后续行动
+1. [ ] <具体步骤>
+```
+
+---
+
+## 适用场景
+
+| 场景 | 示例 |
+|------|------|
+| 技术选型 | "比较 Redux vs Zustand" |
+| 架构评估 | "评估微服务拆分方案" |
+| 性能分析 | "分析 API 响应慢的原因" |
+| 安全审计 | "评估认证模块安全性" |
+
+## 关键规则
 
-### Step 3: 交叉验证
-使用 `TaskOutput` 获取所有任务的结果，然后：
-1. Compare perspectives from all configured models
-2. Identify agreements and disagreements
-3. Evaluate trade-offs objectively
-4. Weight opinions based on model strengths
-
-### Step 4: 综合输出
-Present unified analysis combining all perspectives.
-
-## 输出格式
-1. **Configuration** – models used for analysis
-2. **Context Overview** – relevant codebase elements
-3. **Model Perspectives** – analysis from each configured model
-4. **Synthesis** – combined insights and trade-offs
-5. **Recommendations** – actionable next steps
-
-## 注意事项
-- This command is for analysis only, no code changes
-- **Use `run_in_background: true` for parallel execution** to avoid blocking
-- 多模型结果交叉验证，取长补短
-- Use HEREDOC syntax (`<<'EOF'`) to avoid shell escaping issues
+1. **仅分析不修改** – 本命令不执行任何代码变更
+2. **使用后台进程 `&` + `TaskOutput` 获取结果**
+3. **必须等待所有模型返回完整结果后才能进入下一阶段**，禁止跳过或提前继续
+4. **信任规则** – 后端以 Codex 为准，前端以 Gemini 为准

package/templates/commands/backend.md

@@ -1,70 +1,129 @@
 ---
-description: 后端/逻辑/算法任务，自动路由到配置的后端模型进行原型生成和审计
+description: '后端专项工作流（研究→构思→计划→执行→优化→评审），Codex主导'
 ---
 
-> 调用语法见 `_config.md`
+# Backend - 后端专项开发
 
-## 用法
-`/backend <LOGIC_TASK_DESCRIPTION>`
+## 使用方法
+
+```bash
+/backend <后端任务描述>
+```
 
 ## 上下文
-- Backend/logic task to implement: $ARGUMENTS
-- This command routes to your configured backend models.
-- Default authority for algorithms, APIs, and business logic.
+
+- 后端任务：$ARGUMENTS
+- Codex 主导，Gemini 辅助参考
+- 适用：API设计、算法实现、数据库优化、业务逻辑
 
 ## 你的角色
-You are the **Backend Orchestrator** specializing in server-side logic. You coordinate:
-1. **ace-tool** – for retrieving existing backend code and architecture
-2. **Configured Backend Models** – for generating logic, algorithms, and API implementations
-3. **Claude (Self)** – for refactoring prototypes into production code
 
-## 流程
+你是**后端编排者**，协调多模型完成服务端任务（研究 → 构思 → 计划 → 执行 → 优化 → 评审），用中文协助用户。
+
+**协作模型**：
+- **Codex** – 后端逻辑、算法（**后端权威，可信赖**）
+- **Gemini** – 前端视角（**后端意见仅供参考**）
+- **Claude (自己)** – 编排、计划、执行、交付
+
+[沟通守则]
+
+1. 响应以模式标签 `[模式：X]` 开始，初始为 `[模式：研究]`
+2. 严格按 `研究 → 构思 → 计划 → 执行 → 优化 → 评审` 顺序流转
+
+---
+
+## 多模型调用语法
+
+```bash
+# Codex 调用（后端主力）
+~/.claude/bin/codeagent-wrapper --backend codex - "$PWD" <<'EOF'
+[角色提示词内容]
+
+[任务内容]
+EOF
+
+# Gemini 调用（前端参考）
+~/.claude/bin/codeagent-wrapper --backend gemini - "$PWD" <<'EOF'
+[任务内容]
+EOF
+```
+
+---
+
+## 核心工作流
+
+### 🔍 阶段 1：研究
+
+`[模式：研究]` - 理解需求并收集上下文
 
-### Step 1: 上下文检索
-1. Call `{{MCP_SEARCH_TOOL}}` to understand existing architecture:
-   - `project_root_path`: Project root directory absolute path
-   - `query`: Natural language description of the backend task
-2. Identify API patterns, data models, services, and dependencies
+1. 检索现有 API、数据模型、服务架构
+2. 需求完整性评分（0-10 分）：≥7 继续，<7 停止补充
 
-### Step 2: 调用后端模型生成原型
+### 💡 阶段 2：构思
 
-使用配置的后端主模型 ({{BACKEND_PRIMARY}}) 生成后端原型：
+`[模式：构思]` - Codex 主导分析
+
+**调用示例**：
 
 ```bash
-codeagent-wrapper --backend {{BACKEND_PRIMARY}} - $PROJECT_DIR <<'EOF'
-ROLE_FILE: ~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/architect.md
+~/.claude/bin/codeagent-wrapper --backend codex - "$PWD" <<'EOF'
+你是后端分析专家，擅长 API 设计、算法、数据库优化。
 
-<TASK>
-实现后端功能: {{后端任务描述}}
-Context: {{从 MCP 获取的 API 架构和数据模型}}
-</TASK>
+任务：分析以下后端需求，提供设计方案
+- API 接口设计
+- 数据模型结构
+- 性能与安全考虑
+- 错误处理策略
 
-OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications.
+需求：[具体任务描述]
 EOF
 ```
 
-### Step 4: 重构与实施
-1. Review model prototype(s) as "dirty prototype"
-2. If multiple models, cross-validate and select best patterns
-3. Refactor into clean, maintainable code
-4. Ensure proper error handling and security
-
-### Step 5: 审计
-
-Call configured backend model(s) to review the final implementation:
-- 使用 `reviewer` 角色
-- 审查内容: security, performance, error handling
-- 输出: `Review comments only`
-
-## 输出格式
-1. **Configuration** – models and strategy being used
-2. **Architecture Analysis** – existing patterns and dependencies
-3. **Model Prototype(s)** – raw prototypes from configured models
-4. **Refined Implementation** – production-ready backend code
-5. **Audit Feedback** – security and performance review
-
-## 注意事项
-- Codex excels at complex logic and debugging
-- Codex uses read-only sandbox by default
-- Always request Unified Diff Patch format
-- Use HEREDOC syntax (`<<'EOF'`) to avoid shell escaping issues
+**⚠️ 等待 Codex 返回后继续**
+
+输出方案（至少 2 个），等待用户选择。
+
+### 📋 阶段 3：计划
+
+`[模式：计划]` - Codex 主导规划
+
+调用 Codex（`architect.md`）→ 文件结构、函数/类设计、依赖
+
+**⚠️ 等待 Codex 返回后继续**
+
+Claude 综合规划，请求用户批准后存入 `.claude/plan/任务名.md`
+
+### ⚡ 阶段 4：执行
+
+`[模式：执行]` - 代码开发
+
+- 严格按批准的计划实施
+- 遵循项目现有代码规范
+- 确保错误处理、安全性、性能优化
+
+### 🚀 阶段 5：优化
+
+`[模式：优化]` - Codex 主导审查
+
+调用 Codex（`reviewer.md`）→ 安全性、性能、错误处理、API规范
+
+**⚠️ 等待 Codex 返回后继续**
+
+整合审查意见，用户确认后执行优化。
+
+### ✅ 阶段 6：评审
+
+`[模式：评审]` - 最终评估
+
+- 对照计划检查完成情况
+- 运行测试验证功能
+- 报告问题与建议
+
+---
+
+## 关键规则
+
+1. **Codex 后端意见可信赖**
+2. **Gemini 后端意见仅供参考**
+3. 外部模型对文件系统**零写入权限**
+4. Claude 负责所有代码写入和文件操作

package/templates/commands/clean-branches.md

@@ -1,102 +1,117 @@
 ---
-description: 安全查找并清理已合并或过期的 Git 分支，支持 dry-run 模式与自定义基准/保护分支
-allowed-tools: Read(**), Exec(git fetch, git config, git branch, git remote, git push, git for-each-ref, git log), Write()
-argument-hint: [--base <branch>] [--stale <days>] [--remote] [--force] [--dry-run] [--yes]
-# examples:
-#   - /git-cleanBranches --dry-run
-#   - /git-cleanBranches --base release/v2.1 --stale 90
-#   - /git-cleanBranches --remote --yes
+description: '清理 Git 分支：安全清理已合并或过期分支，默认 dry-run 模式'
 ---
 
-# Claude Command: Clean Branches
+# Clean-Branches - 清理 Git 分支
 
-该命令**安全地**识别并清理**已合并**或**长期未更新 (stale)** 的 Git 分支。
-默认以**只读预览 (`--dry-run`)** 模式运行，需明确指令才会执行删除操作。
+安全识别并清理已合并或长期未更新的分支。
+
+## 使用方法
+
+```bash
+/clean-branches [options]
+```
+
+## 选项
+
+| 选项 | 说明 |
+|------|------|
+| `--base <branch>` | 基准分支（默认 main/master） |
+| `--stale <days>` | 清理超过 N 天未更新的分支 |
+| `--remote` | 同时清理远程分支 |
+| `--dry-run` | 只预览，不执行（**默认**） |
+| `--yes` | 跳过确认直接删除 |
+| `--force` | 强制删除未合并分支 |
 
 ---
 
-## Usage
+## 执行工作流
 
-```bash
-# [最安全] 预览将要清理的分支，不执行任何删除
-/git-cleanBranches --dry-run
+### 🔍 阶段 1：预检
 
-# 清理已合并到 main 且超过 90 天未动的本地分支 (需逐一确认)
-/git-cleanBranches --stale 90
+`[模式：准备]`
 
-# 清理已合并到 release/v2.1 的本地与远程分支 (自动确认)
-/git-cleanBranches --base release/v2.1 --remote --yes
+1. 同步远端：`git fetch --all --prune`
+2. 读取保护分支配置
+3. 确定基准分支
 
-# [危险] 强制删除一个未合并的本地分支
-/git-cleanBranches --force outdated-feature
-```
+### 📋 阶段 2：分析识别
 
-### Options
+`[模式：分析]`
 
-- `--base <branch>`：指定清理的基准分支（默认为仓库的 `main`/`master`）。
-- `--stale <days>`：清理超过指定天数未提交的分支（默认不启用）。
-- `--remote`：同时清理远程已合并/过期的分支。
-- `--dry-run`：**默认行为**。仅列出将要删除的分支，不执行任何操作。
-- `--yes`：跳过逐一确认的步骤，直接删除所有已识别的分支（适合 CI/CD）。
-- `--force`：使用 `-D` 强制删除本地分支（即使未合并）。
+**已合并分支**：
+- 已完全合并到 `--base` 的分支
 
----
+**过期分支**（如指定 `--stale`）：
+- 最后提交在 N 天前的分支
 
-## What This Command Does
+**排除**：
+- 从待清理列表中移除保护分支
 
-1. **配置与安全预检**
-   - **更新信息**：自动执行 `git fetch --all --prune`，确保分支状态最新。
-   - **读取保护分支**：从 Git 配置读取不应被清理的分支列表（见下文“Configuration”）。
-   - **确定基准**：使用 `--base` 参数或自动识别的 `main`/`master` 作为比较基准。
+### 📊 阶段 3：报告预览
 
-2. **分析识别（Find）**
-   - **已合并分支**：找出已完全合并到 `--base` 的本地（及远程，如加 `--remote`）分支。
-   - **过期分支**：如指定 `--stale <days>`，找出最后一次提交在 N 天前的分支。
-   - **排除保护分支**：从待清理列表中移除所有已配置的保护分支。
+`[模式：报告]`
 
-3. **报告预览（Report）**
-   - 清晰列出“将要删除的已合并分支”与“将要删除的过期分支”。
-   - 若无 `--yes` 参数，**命令到此结束**，等待用户确认后再次执行（不带 `--dry-run`）。
+```markdown
+## 将要删除的分支
 
-4. **执行清理（Execute）**
-   - **仅在不带 `--dry-run` 且用户确认后**（或带 `--yes`）执行。
-   - 逐一删除已识别的分支，除非用户在交互式确认中选择跳过。
-   - 本地用 `git branch -d <branch>`；远程用 `git push origin --delete <branch>`。
-   - 若指定 `--force`，本地删除会改用 `git branch -D <branch>`。
+### 已合并分支
+- feature/old-feature (合并于 3 天前)
+- bugfix/fixed-issue (合并于 7 天前)
 
----
+### 过期分支
+- experiment/old-test (最后更新 90 天前)
+```
+
+### ✅ 阶段 4：执行清理
 
-## Configuration (一次配置，永久生效)
+`[模式：执行]`
 
-为防止误删重要分支（如 `develop`, `release/*`），请在仓库的 Git 配置中添加保护规则。命令会自动读取。
+仅在不带 `--dry-run` 且确认后执行：
 
 ```bash
-# 保护 develop 分支
-git config --add branch.cleanup.protected develop
+# 本地分支
+git branch -d <branch>
 
-# 保护所有 release/ 开头的分支 (通配符)
+# 远程分支（如果 --remote）
+git push origin --delete <branch>
+
+# 强制删除（如果 --force）
+git branch -D <branch>
+```
+
+---
+
+## 保护分支配置
+
+```bash
+# 添加保护分支
+git config --add branch.cleanup.protected develop
 git config --add branch.cleanup.protected 'release/*'
 
-# 查看所有已配置的保护分支
+# 查看保护分支
 git config --get-all branch.cleanup.protected
 ```
 
 ---
 
-## Best Practices for Embedded Devs
+## 示例
+
+```bash
+# 预览将清理的分支
+/clean-branches --dry-run
 
-- **优先 `--dry-run`**：养成先预览再执行的习惯。
-- **活用 `--base`**：维护长期 `release` 分支时，用它来清理已合并到该 release 的 `feature` 或 `hotfix` 分支。
-- **谨慎 `--force`**：除非你百分百确定某个未合并分支是无用功，否则不要强制删除。
-- **团队协作**：在清理共享的远程分支前，先在团队频道通知一声。
-- **定期运行**：每月或每季度运行一次，保持仓库清爽。
+# 清理已合并且超过 90 天未动的分支
+/clean-branches --stale 90
 
----
+# 清理已合并到 release/v2.1 的分支
+/clean-branches --base release/v2.1 --remote --yes
+```
 
-## Why This Version Is Better
+## 最佳实践
 
-- ✅ **更安全**：默认只读预览，且有可配置的保护分支列表。
-- ✅ **更灵活**：支持自定义基准分支，完美适配 `release` / `develop` 工作流。
-- ✅ **更兼容**：避免了在不同系统上行为不一的 `date -d` 等命令。
-- ✅ **更直观**：将复杂的 16 步清单，浓缩成一个带安全选项的、可直接执行的命令。
-- ✅ **风格一致**：与 `/commit` 命令共享相似的参数设计与文档结构。
+1. **优先 dry-run** – 先预览再执行
+2. **活用 --base** – 适配 release 工作流
+3. **谨慎 --force** – 除非确定无用
+4. **团队协作** – 清理远程分支前先通知
+5. **定期运行** – 每月/季度一次保持清爽