ccg-workflow 1.6.0 → 1.7.1

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. **定期运行** – 每月/季度一次保持清爽

package/templates/commands/commit.md

@@ -1,158 +1,122 @@
 ---
-description: 仅用 Git 分析改动并自动生成 conventional commit 信息（可选 emoji）；必要时建议拆分提交，默认运行本地 Git 钩子（可 --no-verify 跳过）
-allowed-tools: Read(**), Exec(git status, git diff, git add, git restore --staged, git commit, git rev-parse, git config), Write(.git/COMMIT_EDITMSG)
-argument-hint: [--no-verify] [--all] [--amend] [--signoff] [--emoji] [--scope <scope>] [--type <type>]
-# examples:
-#   - /git-commit                           # 分析当前改动，生成提交信息
-#   - /git-commit --all                     # 暂存所有改动并提交
-#   - /git-commit --no-verify               # 跳过 Git 钩子检查
-#   - /git-commit --emoji                   # 在提交信息中包含 emoji
-#   - /git-commit --scope ui --type feat    # 指定作用域和类型
-#   - /git-commit --amend --signoff         # 修补上次提交并签名
+description: '智能 Git 提交：分析改动生成 Conventional Commit 信息，支持拆分建议'
 ---
 
-# Claude Command: Commit (Git-only)
+# Commit - 智能 Git 提交
 
-该命令在**不依赖任何包管理器/构建工具**的前提下，仅通过 **Git**：
+分析当前改动，生成 Conventional Commits 风格的提交信息。
 
-- 读取改动（staged/unstaged）
-- 判断是否需要**拆分为多次提交**
-- 为每个提交生成 **Conventional Commits** 风格的信息（可选 emoji）
-- 按需执行 `git add` 与 `git commit`（默认运行本地 Git 钩子；可 `--no-verify` 跳过）
-
----
-
-## Usage
+## 使用方法
 
 ```bash
-/git-commit
-/git-commit --no-verify
-/git-commit --emoji
-/git-commit --all --signoff
-/git-commit --amend
-/git-commit --scope ui --type feat --emoji
+/commit [options]
 ```
 
-### Options
-
-- `--no-verify`：跳过本地 Git 钩子（`pre-commit`/`commit-msg` 等）。
-- `--all`：当暂存区为空时，自动 `git add -A` 将所有改动纳入本次提交。
-- `--amend`：在不创建新提交的情况下**修补**上一次提交（保持提交作者与时间，除非本地 Git 配置另有指定）。
-- `--signoff`：附加 `Signed-off-by` 行（遵循 DCO 流程时使用）。
-- `--emoji`：在提交信息中包含 emoji 前缀（省略则使用纯文本）。
-- `--scope <scope>`：指定提交作用域（如 `ui`、`docs`、`api`），写入消息头部。
-- `--type <type>`：强制提交类型（如 `feat`、`fix`、`docs` 等），覆盖自动判断。
+## 选项
 
-> 注：如框架不支持交互式确认，可在 front-matter 中开启 `confirm: true` 以避免误操作。
+| 选项 | 说明 |
+|------|------|
+| `--no-verify` | 跳过 Git 钩子 |
+| `--all` | 暂存所有改动 |
+| `--amend` | 修补上次提交 |
+| `--signoff` | 附加签名 |
+| `--emoji` | 包含 emoji 前缀 |
+| `--scope <scope>` | 指定作用域 |
+| `--type <type>` | 指定提交类型 |
 
 ---
 
-## What This Command Does
+## 执行工作流
 
-1. **仓库/分支校验**
-   - 通过 `git rev-parse --is-inside-work-tree` 判断是否位于 Git 仓库。
-   - 读取当前分支/HEAD 状态；如处于 rebase/merge 冲突状态，先提示处理冲突后再继续。
+### 🔍 阶段 1：仓库校验
 
-2. **改动检测**
-   - 用 `git status --porcelain` 与 `git diff` 获取已暂存与未暂存的改动。
-   - 若已暂存文件为 0：
-     - 若传入 `--all` → 执行 `git add -A`。
-     - 否则提示你选择：继续仅分析未暂存改动并给出**建议**，或取消命令后手动分组暂存。
+`[模式：检查]`
 
-3. **拆分建议（Split Heuristics）**
-   - 按**关注点**、**文件模式**、**改动类型**聚类（示例：源代码 vs 文档、测试；不同目录/包；新增 vs 删除）。
-   - 若检测到**多组独立变更**或 diff 规模过大（如 > 300 行 / 跨多个顶级目录），建议拆分提交，并给出每一组的 pathspec（便于后续执行 `git add <paths>`）。
+1. 验证 Git 仓库状态
+2. 检测 rebase/merge 冲突
+3. 读取当前分支/HEAD 状态
 
-4. **提交信息生成（Conventional 规范，可选 Emoji）**
-   - 自动推断 `type`（`feat`/`fix`/`docs`/`refactor`/`test`/`chore`/`perf`/`style`/`ci`/`revert` …）与可选 `scope`。
-   - 生成消息头：`[<emoji>] <type>(<scope>)?: <subject>`（首行 ≤ 72 字符，祈使语气，仅在使用 `--emoji` 时包含 emoji）。
-   - 生成消息体：要点列表（动机、实现要点、影响范围、BREAKING CHANGE 如有）。
-   - 根据 Git 历史提交的主要语言选择提交信息语言。优先检查最近提交主题（例如 `git log -n 50 --pretty=%s`）判断中文/英文；若无法判断，则回退到仓库主要语言或英文。
-   - 将草稿写入 `.git/COMMIT_EDITMSG`，并用于 `git commit`。
+### 📋 阶段 2：改动检测
 
-5. **执行提交**
-   - 单提交场景：`git commit [-S] [--no-verify] [-s] -F .git/COMMIT_EDITMSG`
-   - 多提交场景（如接受拆分建议）：按分组给出 `git add <paths> && git commit ...` 的明确指令；若允许执行则逐一完成。
+`[模式：分析]`
 
-6. **安全回滚**
-   - 如误暂存，可用 `git restore --staged <paths>` 撤回暂存（命令会给出指令，不修改文件内容）。
+1. 获取已暂存与未暂存改动
+2. 若暂存区为空：
+   - `--all` → 执行 `git add -A`
+   - 否则提示选择
 
----
+### ✂️ 阶段 3：拆分建议
 
-## Best Practices for Commits
+`[模式：建议]`
 
-- **Atomic commits**：一次提交只做一件事，便于回溯与审阅。
-- **先分组再提交**：按目录/模块/功能点拆分。
-- **清晰主题**：首行 ≤ 72 字符，祈使语气（如 “add… / fix…”）。
-- **正文含上下文**：说明动机、方案、影响范围、风险与后续工作。
-- **遵循 Conventional Commits**：`<type>(<scope>): <subject>`。
+按以下维度聚类：
+- 关注点（源代码 vs 文档/测试）
+- 文件模式（不同目录/包）
+- 改动类型（新增 vs 删除）
 
----
+若检测到多组独立变更（>300 行 / 跨多个顶级目录），建议拆分。
 
-## Type 与 Emoji 映射（使用 --emoji 时）
+### ✍️ 阶段 4：生成提交信息
 
-- ✨ `feat`：新增功能
-- 🐛 `fix`：缺陷修复（含 🔥 删除代码/文件、🚑️ 紧急修复、👽️ 适配外部 API 变更、🔒️ 安全修复、🚨 解决告警、💚 修复 CI）
-- 📝 `docs`：文档与注释
-- 🎨 `style`：风格/格式（不改语义）
-- ♻️ `refactor`：重构（不新增功能、不修缺陷）
-- ⚡️ `perf`：性能优化
-- ✅ `test`：新增/修复测试、快照
-- 🔧 `chore`：构建/工具/杂务（合并分支、更新配置、发布标记、依赖 pin、.gitignore 等）
-- 👷 `ci`：CI/CD 配置与脚本
-- ⏪️ `revert`：回滚提交
-- 💥 `feat`：破坏性变更（`BREAKING CHANGE:` 段落中说明）
+`[模式：生成]`
 
-> 若传入 `--type`/`--scope`，将**覆盖**自动推断。
-> 仅在指定 `--emoji` 标志时才会包含 emoji。
+**格式**：`[emoji] <type>(<scope>): <subject>`
 
----
+- 首行 ≤ 72 字符
+- 祈使语气
+- 消息体：动机、实现要点、影响范围
+
+**语言**：根据最近 50 次提交判断中文/英文
 
-## Guidelines for Splitting Commits
+### ✅ 阶段 5：执行提交
 
-1. **不同关注点**：互不相关的功能/模块改动应拆分。
-2. **不同类型**：不要将 `feat`、`fix`、`refactor` 混在同一提交。
-3. **文件模式**：源代码 vs 文档/测试/配置分组提交。
-4. **规模阈值**：超大 diff（示例：>300 行或跨多个顶级目录）建议拆分。
-5. **可回滚性**：确保每个提交可独立回退。
+`[模式：执行]`
+
+```bash
+git commit [-S] [--no-verify] [-s] -F .git/COMMIT_EDITMSG
+```
 
 ---
 
-## Examples
+## Type 与 Emoji 映射
+
+| Emoji | Type | 说明 |
+|-------|------|------|
+| ✨ | `feat` | 新增功能 |
+| 🐛 | `fix` | 缺陷修复 |
+| 📝 | `docs` | 文档更新 |
+| 🎨 | `style` | 代码格式 |
+| ♻️ | `refactor` | 重构 |
+| ⚡️ | `perf` | 性能优化 |
+| ✅ | `test` | 测试相关 |
+| 🔧 | `chore` | 构建/工具 |
+| 👷 | `ci` | CI/CD |
+| ⏪️ | `revert` | 回滚 |
 
-**Good (使用 --emoji)**
+---
 
-- ✨ feat(ui): add user authentication flow
-- 🐛 fix(api): handle token refresh race condition
-- 📝 docs: update API usage examples
-- ♻️ refactor(core): extract retry logic into helper
-- ✅ test: add unit tests for rate limiter
-- 🔧 chore: update git hooks and repository settings
-- ⏪️ revert: revert "feat(core): introduce streaming API"
+## 示例
 
-**Good (不使用 --emoji)**
+```bash
+# 基本提交
+/commit
 
-- feat(ui): add user authentication flow
-- fix(api): handle token refresh race condition
-- docs: update API usage examples
-- refactor(core): extract retry logic into helper
-- test: add unit tests for rate limiter
-- chore: update git hooks and repository settings
-- revert: revert "feat(core): introduce streaming API"
+# 暂存所有并提交
+/commit --all
 
-**Split Example**
+# 带 emoji 提交
+/commit --emoji
 
-- `feat(types): add new type defs for payment method`
-- `docs: update API docs for new types`
-- `test: add unit tests for payment types`
-- `fix: address linter warnings in new files` ←（如你的仓库有钩子报错）
+# 指定类型和作用域
+/commit --scope ui --type feat --emoji
 
----
+# 修补上次提交
+/commit --amend --signoff
+```
 
-## Important Notes
+## 关键规则
 
-- **仅使用 Git**：不调用任何包管理器/构建命令（无 `pnpm`/`npm`/`yarn` 等）。
-- **尊重钩子**：默认执行本地 Git 钩子；使用 `--no-verify` 可跳过。
-- **不改源码内容**：命令只读写 `.git/COMMIT_EDITMSG` 与暂存区；不会直接编辑工作区文件。
-- **安全提示**：在 rebase/merge 冲突、detached HEAD 等状态下会先提示处理/确认再继续。
-- **可审可控**：如开启 `confirm: true`，每个实际 `git add`/`git commit` 步骤都会进行二次确认。
+1. **仅使用 Git** – 不调用包管理器
+2. **尊重钩子** – 默认执行，`--no-verify` 可跳过
+3. **不改源码** – 只读写 `.git/COMMIT_EDITMSG`
+4. **原子提交** – 一次提交只做一件事

package/templates/commands/debug.md

@@ -1,133 +1,160 @@
 ---
-description: UltraThink 多模型调试（Codex 后端诊断 + Gemini 前端诊断）
+description: '多模型调试：Codex 后端诊断 + Gemini 前端诊断，交叉验证定位问题'
 ---
 
-## 用法
-`/debug <问题描述>`
+# Debug - 多模型调试
 
-## 上下文
-- 问题描述: $ARGUMENTS
-- 使用 ace-tool 检索相关代码上下文
-- Codex 专注后端/逻辑问题，Gemini 专注前端/UI问题
+双模型并行诊断，交叉验证快速定位问题根因。
 
-## 流程
+## 多模型调用语法
 
-### Phase 1: 上下文检索
+**⚠️ 必须使用 heredoc 语法调用外部模型**：
 
-1. 调用 `mcp__ace-tool__search_context` 检索相关代码:
-   - `project_root_path`: 项目根目录绝对路径
-   - `query`: 问题的自然语言描述
-2. 收集错误日志、堆栈信息、复现步骤
-3. 识别问题涉及的模块（前端/后端/全栈）
+```bash
+~/.claude/bin/codeagent-wrapper --backend <codex|gemini> - "$PWD" <<'EOF'
+<任务内容>
+EOF
+```
 
-### Phase 2: 并行诊断
+- `--backend codex` – 后端/逻辑问题诊断
+- `--backend gemini` – 前端/UI 问题诊断
+- `$PWD` – 当前工作目录
 
-**同时启动两个后台任务**（`run_in_background: true`）：
+---
 
-**调用方式**: 使用 `Bash` 工具调用 `codeagent-wrapper`
+## 使用方法
 
 ```bash
-# Codex 后端诊断
-codeagent-wrapper --backend {{BACKEND_PRIMARY}} - $PROJECT_DIR <<'EOF'
-ROLE_FILE: ~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/debugger.md
+/debug <问题描述>
+```
 
-<TASK>
-诊断问题: {{问题描述}}
-Context: {{从 ace-tool 获取的相关代码}}
-</TASK>
+## 你的角色
 
-OUTPUT: Structured diagnostic report. No code modifications.
-EOF
-```
+你是**调试协调者**，编排多模型诊断流程：
+- **Codex** – 后端诊断（**后端问题权威**）
+- **Gemini** – 前端诊断（**前端问题权威**）
+- **Claude (自己)** – 综合诊断、执行修复
 
-```bash
-# Gemini 前端诊断
-codeagent-wrapper --backend {{FRONTEND_PRIMARY}} - $PROJECT_DIR <<'EOF'
-ROLE_FILE: ~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/debugger.md
+---
 
-<TASK>
-诊断问题: {{问题描述}}
-Context: {{从 ace-tool 获取的相关代码}}
-</TASK>
+## 执行工作流
 
-OUTPUT: Structured diagnostic report. No code modifications.
-EOF
-```
+**问题描述**：$ARGUMENTS
+
+### 🔍 阶段 0：Prompt 增强（可选）
+
+`[模式：准备]` - 增强问题描述
+
+**如果 ace-tool MCP 可用**，调用 `mcp__ace-tool__enhance_prompt`：
+- 输入原始问题描述
+- 获取增强后的详细问题分析
+- 用增强后的描述替代原始 $ARGUMENTS
+
+### 🔍 阶段 1：上下文收集
+
+`[模式：研究]`
+
+1. 调用 `mcp__ace-tool__search_context` 检索相关代码（如可用）
+2. 收集错误日志、堆栈信息、复现步骤
+3. 识别问题类型：[后端/前端/全栈]
+
+### 🔬 阶段 2：并行诊断
 
-- **Codex** + `debugger` 角色 → 后端诊断
-- **Gemini** + `debugger` 角色 → 前端诊断
+`[模式：诊断]`
 
-### Phase 3: 假设整合
+**并行调用 Codex + Gemini**：
 
-1. 收集两个模型的诊断报告（使用 `TaskOutput`）
-2. 交叉验证：识别重叠和互补的假设
-3. **UltraThink 综合**：
-   - 整合所有假设，按可能性排序
-   - 筛选出 **Top 1-2 最可能原因**
-   - 设计验证策略
+**执行步骤**：
+1. 使用 **Bash 工具的 `run_in_background: true` 参数**启动两个后台进程：
 
-### Phase 4: 用户确认（Hard Stop）
+**Codex 诊断进程**：
+```
+Bash({
+  command: "~/.claude/bin/codeagent-wrapper --backend codex - \"$PWD\" <<'EOF_CODEX'
+角色：后端调试专家
+
+问题：$ARGUMENTS
+
+任务：
+1. 分析逻辑错误、数据流、异常处理
+2. 检查 API、数据库、服务间通信
+3. 输出诊断假设（按可能性排序）
+EOF_CODEX",
+  run_in_background: true,
+  timeout: 3600000,
+  description: "Codex 后端诊断"
+})
+```
 
-输出格式：
+**Gemini 诊断进程**：
+```
+Bash({
+  command: "~/.claude/bin/codeagent-wrapper --backend gemini - \"$PWD\" <<'EOF_GEMINI'
+角色：前端调试专家
+
+问题：$ARGUMENTS
+
+任务：
+1. 分析 UI 渲染、状态管理、事件绑定
+2. 检查组件生命周期、样式冲突
+3. 输出诊断假设（按可能性排序）
+EOF_GEMINI",
+  run_in_background: true,
+  timeout: 3600000,
+  description: "Gemini 前端诊断"
+})
 ```
+
+2. 使用 `TaskOutput` 监控并获取 2 个模型的诊断结果。
+
+**⚠️ 强制规则：必须等待 TaskOutput 返回两个模型的完整结果后才能进入下一阶段，禁止跳过或提前继续！**
+
+### 🔀 阶段 3：假设整合
+
+`[模式：验证]`
+
+1. 交叉验证双方诊断结果
+2. 筛选 **Top 1-2 最可能原因**
+3. 设计验证策略
+
+### ⛔ 阶段 4：用户确认（Hard Stop）
+
+`[模式：确认]`
+
+```markdown
 ## 🔍 诊断结果
 
 ### Codex 分析（后端视角）
-<Codex 诊断摘要>
+<诊断摘要>
 
 ### Gemini 分析（前端视角）
-<Gemini 诊断摘要>
+<诊断摘要>
 
 ### 综合诊断
 **最可能原因**：<具体诊断>
-**证据**：<支持证据>
 **验证方案**：<如何确认>
 
 ---
 **确认后我将执行修复。是否继续？(Y/N)**
 ```
 
-⚠️ **必须等待用户确认后才能进入 Phase 5**
-
-### Phase 5: 修复与验证
-
-1. 根据确认的诊断实施修复
-2. 修复完成后，**并行调用** Codex + Gemini + `reviewer` 角色审查修复
-3. 综合审查意见，确认问题解决
-
-## 输出格式
-
-```
-## Phase 1: 上下文检索
-- 检索到 X 个相关文件
-- 问题类型: [前端/后端/全栈]
-
-## Phase 2: 并行诊断
-### Codex 诊断
-<诊断内容>
-
-### Gemini 诊断
-<诊断内容>
+**⚠️ 必须等待用户确认后才能进入阶段 5**
 
-## Phase 3: 综合分析
-### Top 假设
-1. [最可能原因] - 可能性: High
-2. [次可能原因] - 可能性: Medium
+### 🔧 阶段 5：修复与验证
 
-### 验证策略
-- [具体验证步骤]
+`[模式：执行]`
 
-## Phase 4: 确认
-**是否按此诊断进行修复？(Y/N)**
+用户确认后：
+1. 根据诊断实施修复
+2. 运行测试验证修复
+3. **可选**：并行调用 Codex + Gemini 审查修复
 
-## Phase 5: 修复验证（用户确认后）
-- 修复内容: <具体修改>
-- 双模型审查: <审查结果>
-```
+---
 
-## 关键原则
+## 关键规则
 
-1. **不假设，先验证** - 所有假设需要证据支持
-2. **并行诊断** - 充分利用双模型的不同视角
-3. **用户确认** - 修复前必须获得确认
-4. **交叉审查** - 修复后双模型验证
+1. **heredoc 语法** – 外部模型调用必须使用 heredoc
+2. **使用 Bash 工具的 `run_in_background: true` 参数 + `TaskOutput` 获取结果**
+3. **必须等待所有模型返回完整结果后才能进入下一阶段**，禁止跳过或提前继续
+4. **用户确认** – 修复前必须获得确认
+5. **信任规则** – 后端问题以 Codex 为准，前端问题以 Gemini 为准