ccg-workflow 1.5.1 → 1.7.0

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