ccg-workflow 1.6.0 → 1.7.0

package/package.json

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

package/templates/commands/analyze.md

@@ -1,77 +1,134 @@
 ---
-description: 多模型技术分析（并行执行），交叉验证后综合见解
+description: '多模型技术分析（并行执行）：Codex 后端视角 + Gemini 前端视角，交叉验证后综合见解'
 ---
 
-## 用法
-`/analyze <QUESTION_OR_TASK>`
+# Analyze - 多模型技术分析
 
-## 上下文
-- 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__ace-tool__search_context` 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,198 +1,129 @@
 ---
-description: 后端/逻辑/算法任务，自动路由到配置的后端模型进行原型生成和审计
+description: '后端专项工作流（研究→构思→计划→执行→优化→评审），Codex主导'
 ---
 
-## 用法
-`/backend <LOGIC_TASK_DESCRIPTION>`
+# Backend - 后端专项开发
+
+## 使用方法
+
+```bash
+/backend <后端任务描述>
+```
 
 ## 上下文
-- Backend/logic task to implement: $ARGUMENTS
-- This command routes to your configured backend models.
-- Default authority for algorithms, APIs, and business logic.
 
-## ⭐ v1.6.0 重大升级
+- 后端任务：$ARGUMENTS
+- Codex 主导，Gemini 辅助参考
+- 适用：API设计、算法实现、数据库优化、业务逻辑
+
+## 你的角色
 
-**从单模型调用升级为多模型并行工作流！**
+你是**后端编排者**，协调多模型完成服务端任务（研究 → 构思 → 计划 → 执行 → 优化 → 评审），用中文协助用户。
 
-### 新增功能
+**协作模型**：
+- **Codex** – 后端逻辑、算法（**后端权威，可信赖**）
+- **Gemini** – 前端视角（**后端意见仅供参考**）
+- **Claude (自己)** – 编排、计划、执行、交付
 
-✅ **5阶段完整工作流**：
-- Step 1: 上下文检索（MCP）
-- Step 2: **多模型后端分析**（Codex + Gemini 并行） ← 新增
-- Step 3: **多模型原型生成**（所有后端模型并行） ← 增强
-- Step 4: 重构与实施（Claude 综合各模型优势）
-- Step 5: **多模型审计交付**（Codex + Gemini 交叉验证） ← 新增
+[沟通守则]
 
-✅ **交叉验证机制**：
-- Codex 提供深度后端专业知识（算法、调试）
-- Gemini 提供现代架构视角
-- Claude 综合各家所长，重构为生产级代码
+1. 响应以模式标签 `[模式：X]` 开始，初始为 `[模式：研究]`
+2. 严格按 `研究 → 构思 → 计划 → 执行 → 优化 → 评审` 顺序流转
 
-✅ **强制用户确认**：
-- Step 2 分析完成后，会询问"是否继续执行此方案？(Y/N)"
-- 避免盲目执行，确保用户对方案满意
+---
 
-### 与 /ccg:dev 的区别
+## 多模型调用语法
 
-| 特性 | /ccg:backend | /ccg:dev |
-|------|-------------|----------|
-| **模型范围** | 仅后端模型（Codex + Gemini）| 全部模型（前端+后端）|
-| **适用场景** | 后端专项任务 | 全栈功能开发 |
-| **Prompt 增强** | ❌ 不包含 | ✅ Phase 0 |
-| **工作流阶段** | 5 阶段 | 6 阶段（含 Prompt 增强）|
-| **推荐用户** | 后端开发者 | 全栈开发者 |
+```bash
+# Codex 调用（后端主力）
+~/.claude/bin/codeagent-wrapper --backend codex - "$PWD" <<'EOF'
+[角色提示词内容]
 
-### 使用建议
+[任务内容]
+EOF
 
-- 🎯 **纯后端任务**：使用 `/ccg:backend`（如：API 设计、数据库优化、算法实现）
-- 🎯 **全栈功能**：使用 `/ccg:dev`（如：用户登录功能，涉及前后端）
-- 🎯 **需要 Prompt 增强**：使用 `/ccg:dev`（复杂需求，需先优化需求描述）
+# Gemini 调用（前端参考）
+~/.claude/bin/codeagent-wrapper --backend gemini - "$PWD" <<'EOF'
+[任务内容]
+EOF
+```
 
 ---
 
-## 你的角色
-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
+## 核心工作流
 
-## 流程
+### 🔍 阶段 1：研究
 
-### Step 1: 上下文检索
-1. Call `mcp__ace-tool__search_context` 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
-3. 如需求仍不清晰，提出澄清问题
+`[模式：研究]` - 理解需求并收集上下文
 
-### Step 2: 多模型后端分析
+1. 检索现有 API、数据模型、服务架构
+2. 需求完整性评分（0-10 分）：≥7 继续，<7 停止补充
 
-**并行调用所有配置的后端模型进行分析**（使用 `run_in_background: true`）：
+### 💡 阶段 2：构思
 
-遍历 {{BACKEND_MODELS}} 中的每个模型进行后端分析：
-- 每个模型使用对应的 `~/.claude/.ccg/prompts/<模型名>/analyzer.md`
-- 输出：`Structured analysis/diagnostic report`
+`[模式：构思]` - Codex 主导分析
 
-**总共并行调用次数**: {{BACKEND_MODELS}} 长度（例如：配置 codex + gemini = 2次）
+**调用示例**：
 
-调用示例：
 ```bash
-# 遍历后端模型列表（假设配置了 codex 和 gemini）
-for model in codex gemini; do
-  codeagent-wrapper --backend $model - $PROJECT_DIR <<'EOF' &
-ROLE_FILE: ~/.claude/.ccg/prompts/$model/analyzer.md
-
-<TASK>
-分析后端需求: {{后端任务描述}}
-Context: {{从 MCP 获取的 API 架构和数据模型}}
-关注点:
-- API 设计和 RESTful 规范
-- 数据模型和关系设计
-- 业务逻辑复杂度
-- 性能瓶颈和优化点
-- 安全风险和防护措施
-</TASK>
-
-OUTPUT: Structured analysis/diagnostic report.
+~/.claude/bin/codeagent-wrapper --backend codex - "$PWD" <<'EOF'
+你是后端分析专家，擅长 API 设计、算法、数据库优化。
+
+任务：分析以下后端需求，提供设计方案
+- API 接口设计
+- 数据模型结构
+- 性能与安全考虑
+- 错误处理策略
+
+需求：[具体任务描述]
 EOF
-done
 ```
 
-使用 `TaskOutput` 获取所有模型的分析结果，交叉验证后综合方案。
+**⚠️ 等待 Codex 返回后继续**
 
-**强制停止**: 询问用户 **"是否继续执行此方案？(Y/N)"** 并等待确认
+输出方案（至少 2 个），等待用户选择。
 
-### Step 3: 多模型原型生成
+### 📋 阶段 3：计划
 
-**并行调用所有配置的后端模型生成原型**（使用 `run_in_background: true`）：
+`[模式：计划]` - Codex 主导规划
 
-遍历 {{BACKEND_MODELS}} 中的每个模型生成后端原型：
-- 每个模型使用对应的 `~/.claude/.ccg/prompts/<模型名>/architect.md`
-- 输出：`Unified Diff Patch ONLY`
+调用 Codex（`architect.md`）→ 文件结构、函数/类设计、依赖
 
-**总共并行调用次数**: {{BACKEND_MODELS}} 长度（例如：配置 codex + gemini = 2次）
+**⚠️ 等待 Codex 返回后继续**
 
-调用示例：
-```bash
-# 遍历后端模型生成原型
-for model in $(echo '{{BACKEND_MODELS}}' | jq -r '.[]'); do
-  codeagent-wrapper --backend $model - $PROJECT_DIR <<'EOF' &
-ROLE_FILE: ~/.claude/.ccg/prompts/$model/architect.md
-
-<TASK>
-生成后端原型: {{后端任务描述}}
-Context: {{相关代码和架构}}
-实现要点:
-- 遵循现有 API 设计模式
-- 实现完整的错误处理
-- 添加必要的参数验证
-- 考虑并发和性能
-</TASK>
-
-OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications.
-EOF
-done
-```
+Claude 综合规划，请求用户批准后存入 `.claude/plan/任务名.md`
 
-使用 `TaskOutput` 收集所有模型的原型结果。
+### ⚡ 阶段 4：执行
 
-### Step 4: 重构与实施
-1. 将所有模型的原型视为"脏原型" – 仅作参考
-2. **交叉验证所有模型结果，集各家所长**：
-   - 分析每个模型的优势和不足
-   - Codex 通常在算法和调试上更强
-   - Gemini 可能提供更现代的架构思路
-   - 选择最佳实现方案或综合创新点
-3. 重构为干净的生产级代码
-4. 确保正确的错误处理和安全性
-5. 验证变更不会引入副作用
+`[模式：执行]` - 代码开发
 
-### Step 5: 多模型审计交付
+- 严格按批准的计划实施
+- 遵循项目现有代码规范
+- 确保错误处理、安全性、性能优化
 
-**并行调用所有配置的后端模型进行审计**（使用 `run_in_background: true`）：
+### 🚀 阶段 5：优化
 
-遍历 {{BACKEND_MODELS}} 中的每个模型进行代码审查：
-- 每个模型使用对应的 `~/.claude/.ccg/prompts/<模型名>/reviewer.md`
-- 输出：`Review comments only`
+`[模式：优化]` - Codex 主导审查
 
-**总共并行调用次数**: {{BACKEND_MODELS}} 长度（例如：配置 codex + gemini = 2次）
+调用 Codex（`reviewer.md`）→ 安全性、性能、错误处理、API规范
 
-调用示例：
-```bash
-# 遍历后端模型列表进行审计
-for model in $(echo '{{BACKEND_MODELS}}' | jq -r '.[]'); do
-  codeagent-wrapper --backend $model - $PROJECT_DIR <<'EOF' &
-ROLE_FILE: ~/.claude/.ccg/prompts/$model/reviewer.md
-
-<TASK>
-审查后端代码: {{实施的代码变更}}
-关注点:
-- 安全性（SQL 注入、XSS、CSRF 等）
-- 性能（N+1 查询、缓存策略）
-- 错误处理（异常捕获、日志记录）
-- 代码质量（可读性、可维护性）
-- API 规范（RESTful 设计、HTTP 状态码）
-</TASK>
-
-OUTPUT: Review comments only. No code modifications.
-EOF
-done
-```
+**⚠️ 等待 Codex 返回后继续**
+
+整合审查意见，用户确认后执行优化。
 
-使用 `TaskOutput` 收集所有模型的审计结果，交叉验证后提供综合反馈。
+### ✅ 阶段 6：评审
 
-**最终交付**: 根据审计反馈进行必要的调整，确保代码达到生产级质量。
+`[模式：评审]` - 最终评估
+
+- 对照计划检查完成情况
+- 运行测试验证功能
+- 报告问题与建议
+
+---
 
-## 输出格式
-1. **Configuration** – 使用的模型和策略 ({{BACKEND_MODELS}})
-2. **Architecture Analysis** – 现有模式和依赖关系
-3. **Multi-Model Analysis** – 所有后端模型的分析报告（交叉验证）
-4. **Multi-Model Prototypes** – 所有后端模型的原型（交叉验证）
-5. **Refined Implementation** – 综合各模型优势的生产级代码
-6. **Multi-Model Audit** – 所有后端模型的审计反馈（交叉验证）
+## 关键规则
 
-## 注意事项
-- 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
+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. **定期运行** – 每月/季度一次保持清爽