chore: 删除历史遗留文件
- 删除已弃用的 install.py（已被 TypeScript 版本替代） - 删除旧的 commands/ccg/ 目录（已被 templates/commands/ 替代） - 清理项目结构，提升可读性
This commit is contained in:
li committed
1 parent
5c3e8b6e60
commit
d25b0ea4dd
18 files changed
-3296
No files matched your search
@@ -1,95 +0,0 @@
|
||||
---
|
||||
description: 多模型技术分析（根据配置并行），交叉验证后综合见解
|
||||
---
|
||||
|
||||
## Usage
|
||||
`/analyze <QUESTION_OR_TASK>`
|
||||
|
||||
## Context
|
||||
- Question or analysis task: $ARGUMENTS
|
||||
- This command triggers multi-model analysis without code changes.
|
||||
- Configured models provide perspectives for cross-validation.
|
||||
|
||||
## Configuration
|
||||
**首先读取 `~/.ccg/config.toml` 获取模型配置**:
|
||||
```toml
|
||||
[routing.frontend]
|
||||
models = ["gemini", "codex"]
|
||||
|
||||
[routing.backend]
|
||||
models = ["codex", "gemini"]
|
||||
```
|
||||
|
||||
分析任务使用 `routing.frontend.models` 和 `routing.backend.models` 的并集。
|
||||
|
||||
## Your Role
|
||||
You are the **Analysis Coordinator** orchestrating multi-model research. You direct:
|
||||
1. **MCP Tools** – for codebase context retrieval (ace-tool or auggie)
|
||||
2. **Configured Models** – for comprehensive multi-perspective analysis
|
||||
3. **Claude (Self)** – for synthesizing insights
|
||||
|
||||
## Process
|
||||
|
||||
### Step 1: Read Configuration + Context Retrieval
|
||||
|
||||
1. **读取 `~/.ccg/config.toml`** 获取 MCP 提供商和模型配置
|
||||
- 根据 `[mcp] provider` 字段确定使用的代码检索工具
|
||||
- 合并 `routing.frontend.models` 和 `routing.backend.models` 获取分析模型列表
|
||||
- 如果配置不存在，默认使用 provider=ace-tool, models=["codex", "gemini"]
|
||||
|
||||
2. **调用代码检索工具**:
|
||||
- 读取 `~/.ccg/config.toml` 获取 `[mcp] provider`（如 "ace-tool" 或 "auggie"）
|
||||
- 使用 `[mcp.tools] code_search_{provider}` 配置的工具名称
|
||||
- 参数：`project_root_path`，查询参数名使用 `query_param_{provider}` 的值
|
||||
|
||||
3. Identify key files, patterns, and architecture
|
||||
|
||||
### Step 2: Parallel Analysis
|
||||
|
||||
**并行调用所有配置的分析模型**（使用 `run_in_background: true` 非阻塞执行）：
|
||||
|
||||
**注意**：调用前先读取对应角色提示词文件，将内容注入到 `<ROLE>` 标签中。
|
||||
|
||||
遍历合并后的模型列表（去重），为每个模型发送调用：
|
||||
|
||||
```bash
|
||||
# 示例：调用配置的分析模型
|
||||
codeagent-wrapper --backend <MODEL_FROM_CONFIG> - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/<model>/analyzer.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Analyze: <question>
|
||||
|
||||
Context:
|
||||
<相关代码和架构信息>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Detailed analysis with recommendations.
|
||||
EOF
|
||||
```
|
||||
|
||||
### Step 3: Cross-Validate
|
||||
使用 `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: Synthesize
|
||||
Present unified analysis combining all perspectives.
|
||||
|
||||
## Output Format
|
||||
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
|
||||
|
||||
## Notes
|
||||
- **首先读取 `~/.ccg/config.toml` 获取模型配置**
|
||||
- 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,113 +0,0 @@
|
||||
---
|
||||
description: 后端/逻辑/算法任务，自动路由到配置的后端模型进行原型生成和审计
|
||||
---
|
||||
|
||||
## Usage
|
||||
`/backend <LOGIC_TASK_DESCRIPTION>`
|
||||
|
||||
## Context
|
||||
- Backend/logic task to implement: $ARGUMENTS
|
||||
- This command routes to your configured backend models.
|
||||
- Default authority for algorithms, APIs, and business logic.
|
||||
|
||||
## Configuration
|
||||
**首先读取 `~/.ccg/config.toml` 获取模型路由配置**:
|
||||
```
|
||||
[routing.backend]
|
||||
models = ["codex", "gemini"] # 用户配置的后端模型列表
|
||||
primary = "codex" # 主模型
|
||||
strategy = "parallel" # 路由策略: parallel | fallback | round-robin
|
||||
```
|
||||
|
||||
## Your Role
|
||||
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
|
||||
|
||||
## Process
|
||||
|
||||
### Step 1: Read Configuration
|
||||
1. Read `~/.ccg/config.toml` to get backend model configuration
|
||||
2. Identify which models to use based on `routing.backend.models`
|
||||
3. If config doesn't exist, default to `codex`
|
||||
|
||||
### Step 2: Context Retrieval
|
||||
1. **调用代码检索工具**:
|
||||
- 根据 `~/.ccg/config.toml` 中 `[mcp.tools] code_search_{provider}` 调用对应工具
|
||||
- 参数：`project_root_path`（项目根目录）, 查询内容为后端架构和相关代码
|
||||
- 查询参数名使用 `query_param_{provider}` 的值（"query" 或 "information_request"）
|
||||
2. Identify API patterns, data models, services, and dependencies
|
||||
|
||||
### Step 3: Model Prototype
|
||||
|
||||
**根据配置的 strategy 执行**:
|
||||
|
||||
- **parallel**: 同时调用所有配置的后端模型，综合结果
|
||||
- **fallback**: 调用主模型，失败则调用次模型
|
||||
- **round-robin**: 轮询调用
|
||||
|
||||
**注意**：调用前先读取对应角色提示词文件，将内容注入到 `<ROLE>` 标签中。
|
||||
|
||||
```bash
|
||||
# 示例：调用配置的后端模型 (根据 config.toml 选择)
|
||||
codeagent-wrapper --backend <MODEL_FROM_CONFIG> - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/<model>/architect.md 的内容并注入
|
||||
如果是 codex: prompts/codex/architect.md
|
||||
如果是 gemini: prompts/gemini/analyzer.md (Gemini 无专门后端角色)
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Implement backend logic for: <task>
|
||||
|
||||
Context:
|
||||
<相关代码>
|
||||
<API 规范/数据模型>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications.
|
||||
EOF
|
||||
```
|
||||
|
||||
**如果 strategy = parallel 且有多个模型**:
|
||||
使用 `run_in_background: true` 并行调用所有模型，然后用 `TaskOutput` 收集结果。
|
||||
|
||||
### Step 4: Refactor & Implement
|
||||
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: Audit
|
||||
|
||||
Call configured backend model(s) to review the final implementation:
|
||||
|
||||
```bash
|
||||
codeagent-wrapper --backend <MODEL_FROM_CONFIG> - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/<model>/reviewer.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Review this backend implementation for: security, performance, error handling.
|
||||
<provide diff>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Review comments only.
|
||||
EOF
|
||||
```
|
||||
|
||||
## Output Format
|
||||
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
|
||||
|
||||
## Notes
|
||||
- Codex excels at complex logic and debugging
|
||||
- Codex uses read-only sandbox by default
|
||||
- Read `~/.ccg/config.toml` at start of execution
|
||||
- Always request Unified Diff Patch format
|
||||
- Use HEREDOC syntax (`<<'EOF'`) to avoid shell escaping issues
|
||||
@@ -1,231 +0,0 @@
|
||||
---
|
||||
description: 质量门控修复（双模型交叉验证，90%+ 通过）
|
||||
---
|
||||
|
||||
# /ccg:bugfix - 质量门控修复
|
||||
|
||||
## Usage
|
||||
`/ccg:bugfix <bug描述>`
|
||||
|
||||
## Context
|
||||
- Bug 描述: $ARGUMENTS
|
||||
- 使用双模型交叉验证确保修复质量
|
||||
- 质量门控：90%+ 评分才能通过，最多 3 轮迭代
|
||||
|
||||
## 工作流程
|
||||
|
||||
**注意**: 本命令使用 MCP 代码检索工具。请先读取 `~/.ccg/config.toml` 确定 MCP 提供商（ace-tool 或 auggie），然后使用对应的工具。
|
||||
|
||||
### Phase 1: Bug 分析
|
||||
|
||||
1. **调用代码检索工具**:
|
||||
- 根据 `~/.ccg/config.toml` 中 `[mcp.tools] code_search_{provider}` 调用对应工具
|
||||
- 参数：`project_root_path`（项目根目录）, 查询参数使用配置中 `query_param_{provider}` 对应的名称
|
||||
- 查询参数名使用 `query_param_{provider}` 的值（"query" 或 "information_request"）
|
||||
2. 分析 bug 类型：前端/后端/全栈
|
||||
3. 收集复现步骤、错误日志、预期行为
|
||||
|
||||
### Phase 2: 双模型诊断
|
||||
|
||||
**并行启动（`run_in_background: true`）**：
|
||||
|
||||
**注意**：调用前先读取对应角色提示词文件，将内容注入到 `<ROLE>` 标签中。
|
||||
|
||||
#### Codex 分析
|
||||
```bash
|
||||
codeagent-wrapper --backend codex - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/codex/architect.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Bugfix: <bug描述>
|
||||
|
||||
Context:
|
||||
<相关代码>
|
||||
|
||||
Requirements:
|
||||
1. Identify root cause with evidence
|
||||
2. Propose fix with minimal code changes
|
||||
3. Assess potential side effects
|
||||
4. Recommend regression tests
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Unified Diff Patch for the fix.
|
||||
EOF
|
||||
```
|
||||
|
||||
#### Gemini 分析
|
||||
```bash
|
||||
codeagent-wrapper --backend gemini - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/gemini/frontend.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Bugfix: <bug描述>
|
||||
|
||||
Context:
|
||||
<相关代码>
|
||||
|
||||
Requirements:
|
||||
1. Identify root cause with evidence
|
||||
2. Propose fix with minimal code changes
|
||||
3. Check UI/UX impact
|
||||
4. Recommend user-facing tests
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Unified Diff Patch for the fix.
|
||||
EOF
|
||||
```
|
||||
|
||||
### Phase 3: 修复整合
|
||||
|
||||
1. 收集双模型的修复方案
|
||||
2. 综合分析：
|
||||
- 识别共同修复点
|
||||
- 合并互补的修复
|
||||
- 选择最优方案
|
||||
3. Claude 重构为生产级代码
|
||||
|
||||
### Phase 4: 实施修复
|
||||
|
||||
1. 应用修复代码
|
||||
2. 记录变更内容
|
||||
|
||||
### Phase 5: 质量门控验证
|
||||
|
||||
**并行启动双模型验证（`run_in_background: true`）**：
|
||||
|
||||
**注意**：调用前先读取对应角色提示词文件（reviewer），将内容注入到 `<ROLE>` 标签中。
|
||||
|
||||
#### Codex 验证
|
||||
```bash
|
||||
codeagent-wrapper --backend codex - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/codex/reviewer.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Validate bugfix for: <bug描述>
|
||||
|
||||
Original bug:
|
||||
<bug描述>
|
||||
|
||||
Applied fix:
|
||||
<修复的 diff>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Use the scoring format defined in the role.
|
||||
EOF
|
||||
```
|
||||
|
||||
#### Gemini 验证
|
||||
```bash
|
||||
codeagent-wrapper --backend gemini - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/gemini/reviewer.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Validate bugfix for: <bug描述>
|
||||
|
||||
Original bug:
|
||||
<bug描述>
|
||||
|
||||
Applied fix:
|
||||
<修复的 diff>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Use the scoring format defined in the role.
|
||||
EOF
|
||||
```
|
||||
|
||||
### Phase 6: 质量门控决策
|
||||
|
||||
```
|
||||
综合评分 = (Codex 评分 + Gemini 评分) / 2
|
||||
```
|
||||
|
||||
#### 评分 ≥ 90%: 通过
|
||||
```
|
||||
✅ 质量门控通过
|
||||
- Codex 评分: XX/100
|
||||
- Gemini 评分: XX/100
|
||||
- 综合评分: XX/100
|
||||
|
||||
修复已完成，可以提交。
|
||||
```
|
||||
|
||||
#### 评分 < 90%: 迭代修复
|
||||
```
|
||||
⚠️ 质量门控未通过 (第 N/3 轮)
|
||||
- Codex 评分: XX/100
|
||||
- Gemini 评分: XX/100
|
||||
- 综合评分: XX/100
|
||||
|
||||
需要改进的问题:
|
||||
1. <Codex 指出的问题>
|
||||
2. <Gemini 指出的问题>
|
||||
|
||||
正在进行第 N+1 轮修复...
|
||||
```
|
||||
|
||||
返回 Phase 3，携带反馈进行迭代（最多 3 轮）
|
||||
|
||||
#### 3 轮后仍未通过
|
||||
```
|
||||
❌ 质量门控失败（已达最大迭代次数）
|
||||
- 最终评分: XX/100
|
||||
- 未解决的问题: <问题列表>
|
||||
|
||||
建议: 需要人工介入审查
|
||||
```
|
||||
|
||||
## 输出格式
|
||||
|
||||
```
|
||||
## 🐛 Bugfix: <bug描述>
|
||||
|
||||
### Phase 1: 分析
|
||||
- Bug 类型: [前端/后端/全栈]
|
||||
- 影响范围: <影响的文件/模块>
|
||||
|
||||
### Phase 2: 诊断
|
||||
#### Codex 诊断
|
||||
- 根因: <分析结果>
|
||||
|
||||
#### Gemini 诊断
|
||||
- 根因: <分析结果>
|
||||
|
||||
### Phase 3-4: 修复
|
||||
<修复代码>
|
||||
|
||||
### Phase 5: 验证 (第 N 轮)
|
||||
| 检查项 | Codex | Gemini |
|
||||
|--------|-------|--------|
|
||||
| 项目1 | XX/20 | XX/20 |
|
||||
| ... | ... | ... |
|
||||
| **总分** | **XX/100** | **XX/100** |
|
||||
|
||||
**综合评分: XX/100**
|
||||
|
||||
### 结果
|
||||
[✅ 通过 / ⚠️ 迭代中 / ❌ 需人工介入]
|
||||
```
|
||||
|
||||
## 质量门控规则
|
||||
|
||||
| 综合评分 | 结果 | 动作 |
|
||||
|----------|------|------|
|
||||
| ≥ 90% | ✅ PASS | 完成修复，可提交 |
|
||||
| 70-89% | ⚠️ ITERATE | 返回修复，携带反馈 |
|
||||
| < 70% | ⚠️ ITERATE | 返回修复，重点关注问题 |
|
||||
| 3轮后 < 90% | ❌ FAIL | 需人工介入 |
|
||||
|
||||
## 关键原则
|
||||
|
||||
1. **双模型交叉验证** - 避免单一视角的盲区
|
||||
2. **量化质量评估** - 使用评分制而非主观判断
|
||||
3. **迭代改进** - 每轮携带具体反馈
|
||||
4. **止损机制** - 最多 3 轮，防止无限循环
|
||||
@@ -1,102 +0,0 @@
|
||||
---
|
||||
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
|
||||
---
|
||||
|
||||
# Claude Command: Clean Branches
|
||||
|
||||
该命令**安全地**识别并清理**已合并**或**长期未更新 (stale)** 的 Git 分支。
|
||||
默认以**只读预览 (`--dry-run`)** 模式运行，需明确指令才会执行删除操作。
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
# [最安全] 预览将要清理的分支，不执行任何删除
|
||||
/git-cleanBranches --dry-run
|
||||
|
||||
# 清理已合并到 main 且超过 90 天未动的本地分支 (需逐一确认)
|
||||
/git-cleanBranches --stale 90
|
||||
|
||||
# 清理已合并到 release/v2.1 的本地与远程分支 (自动确认)
|
||||
/git-cleanBranches --base release/v2.1 --remote --yes
|
||||
|
||||
# [危险] 强制删除一个未合并的本地分支
|
||||
/git-cleanBranches --force outdated-feature
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
- `--base <branch>`：指定清理的基准分支（默认为仓库的 `main`/`master`）。
|
||||
- `--stale <days>`：清理超过指定天数未提交的分支（默认不启用）。
|
||||
- `--remote`：同时清理远程已合并/过期的分支。
|
||||
- `--dry-run`：**默认行为**。仅列出将要删除的分支，不执行任何操作。
|
||||
- `--yes`：跳过逐一确认的步骤，直接删除所有已识别的分支（适合 CI/CD）。
|
||||
- `--force`：使用 `-D` 强制删除本地分支（即使未合并）。
|
||||
|
||||
---
|
||||
|
||||
## What This Command Does
|
||||
|
||||
1. **配置与安全预检**
|
||||
- **更新信息**：自动执行 `git fetch --all --prune`，确保分支状态最新。
|
||||
- **读取保护分支**：从 Git 配置读取不应被清理的分支列表（见下文“Configuration”）。
|
||||
- **确定基准**：使用 `--base` 参数或自动识别的 `main`/`master` 作为比较基准。
|
||||
|
||||
2. **分析识别（Find）**
|
||||
- **已合并分支**：找出已完全合并到 `--base` 的本地（及远程，如加 `--remote`）分支。
|
||||
- **过期分支**：如指定 `--stale <days>`，找出最后一次提交在 N 天前的分支。
|
||||
- **排除保护分支**：从待清理列表中移除所有已配置的保护分支。
|
||||
|
||||
3. **报告预览（Report）**
|
||||
- 清晰列出“将要删除的已合并分支”与“将要删除的过期分支”。
|
||||
- 若无 `--yes` 参数，**命令到此结束**，等待用户确认后再次执行（不带 `--dry-run`）。
|
||||
|
||||
4. **执行清理（Execute）**
|
||||
- **仅在不带 `--dry-run` 且用户确认后**（或带 `--yes`）执行。
|
||||
- 逐一删除已识别的分支，除非用户在交互式确认中选择跳过。
|
||||
- 本地用 `git branch -d <branch>`；远程用 `git push origin --delete <branch>`。
|
||||
- 若指定 `--force`，本地删除会改用 `git branch -D <branch>`。
|
||||
|
||||
---
|
||||
|
||||
## Configuration (一次配置，永久生效)
|
||||
|
||||
为防止误删重要分支（如 `develop`, `release/*`），请在仓库的 Git 配置中添加保护规则。命令会自动读取。
|
||||
|
||||
```bash
|
||||
# 保护 develop 分支
|
||||
git config --add branch.cleanup.protected develop
|
||||
|
||||
# 保护所有 release/ 开头的分支 (通配符)
|
||||
git config --add branch.cleanup.protected 'release/*'
|
||||
|
||||
# 查看所有已配置的保护分支
|
||||
git config --get-all branch.cleanup.protected
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices for Embedded Devs
|
||||
|
||||
- **优先 `--dry-run`**：养成先预览再执行的习惯。
|
||||
- **活用 `--base`**：维护长期 `release` 分支时，用它来清理已合并到该 release 的 `feature` 或 `hotfix` 分支。
|
||||
- **谨慎 `--force`**：除非你百分百确定某个未合并分支是无用功，否则不要强制删除。
|
||||
- **团队协作**：在清理共享的远程分支前，先在团队频道通知一声。
|
||||
- **定期运行**：每月或每季度运行一次，保持仓库清爽。
|
||||
|
||||
---
|
||||
|
||||
## Why This Version Is Better
|
||||
|
||||
- ✅ **更安全**：默认只读预览，且有可配置的保护分支列表。
|
||||
- ✅ **更灵活**：支持自定义基准分支，完美适配 `release` / `develop` 工作流。
|
||||
- ✅ **更兼容**：避免了在不同系统上行为不一的 `date -d` 等命令。
|
||||
- ✅ **更直观**：将复杂的 16 步清单，浓缩成一个带安全选项的、可直接执行的命令。
|
||||
- ✅ **风格一致**：与 `/commit` 命令共享相似的参数设计与文档结构。
|
||||
@@ -1,222 +0,0 @@
|
||||
---
|
||||
description: 多模型代码生成（智能路由：前端→Gemini，后端→Codex）
|
||||
---
|
||||
|
||||
# /ccg:code - 多模型代码生成
|
||||
|
||||
## Usage
|
||||
`/ccg:code <功能描述>`
|
||||
|
||||
## Context
|
||||
- 功能描述: $ARGUMENTS
|
||||
- 智能检测任务类型，自动路由到合适的模型
|
||||
- 生成的原型经 Claude 重构为生产级代码
|
||||
|
||||
## 工作流程
|
||||
|
||||
**注意**: 本命令使用 MCP 代码检索工具。请先读取 `~/.ccg/config.toml` 确定 MCP 提供商（ace-tool 或 auggie），然后使用对应的工具。
|
||||
|
||||
### Phase 1: 需求分析
|
||||
|
||||
1. **调用代码检索工具**:
|
||||
- 根据 `~/.ccg/config.toml` 中 `[mcp.tools] code_search_{provider}` 调用对应工具
|
||||
- 参数：`project_root_path`（项目根目录）, 查询内容为功能需求相关的代码
|
||||
- 查询参数名使用 `query_param_{provider}` 的值（"query" 或 "information_request"）
|
||||
|
||||
2. 分析检索结果：
|
||||
- 相关模块和文件结构
|
||||
- 现有代码模式和风格
|
||||
- 依赖和接口定义
|
||||
|
||||
3. 分析任务类型：
|
||||
- **前端**: UI 组件、样式、用户交互
|
||||
- **后端**: API、业务逻辑、数据库操作
|
||||
- **全栈**: 同时涉及前后端
|
||||
|
||||
### Phase 2: 智能路由
|
||||
|
||||
**注意**：调用前先读取对应角色提示词文件，将内容注入到 `<ROLE>` 标签中。
|
||||
|
||||
#### Route A: 前端任务 → Gemini
|
||||
```bash
|
||||
codeagent-wrapper --backend gemini - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/gemini/frontend.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Implement: <功能描述>
|
||||
|
||||
Context:
|
||||
<相关代码>
|
||||
<设计系统/组件库信息>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Unified Diff Patch ONLY.
|
||||
EOF
|
||||
```
|
||||
|
||||
#### Route B: 后端任务 → Codex
|
||||
```bash
|
||||
codeagent-wrapper --backend codex - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/codex/architect.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Implement: <功能描述>
|
||||
|
||||
Context:
|
||||
<相关代码>
|
||||
<API 规范/数据模型>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Unified Diff Patch ONLY.
|
||||
EOF
|
||||
```
|
||||
|
||||
#### Route C: 全栈任务 → 并行生成
|
||||
|
||||
**同时启动（`run_in_background: true`）**：
|
||||
|
||||
1. **Codex**: 使用 `prompts/codex/architect.md` 角色，生成后端 API + 数据层
|
||||
2. **Gemini**: 使用 `prompts/gemini/frontend.md` 角色，生成前端组件 + UI 交互
|
||||
|
||||
定义清晰的接口契约：
|
||||
```
|
||||
API Contract:
|
||||
- Endpoint: POST /api/xxx
|
||||
- Request: { field1: string, field2: number }
|
||||
- Response: { data: T, error?: string }
|
||||
```
|
||||
|
||||
### Phase 3: 原型整合
|
||||
|
||||
1. 收集模型输出（使用 `TaskOutput`）
|
||||
2. 将 Unified Diff 视为"脏原型"
|
||||
3. Claude 重构：
|
||||
- 统一代码风格
|
||||
- 确保前后端接口一致
|
||||
- 优化实现细节
|
||||
- 移除冗余代码
|
||||
|
||||
### Phase 4: 代码实施
|
||||
|
||||
1. 应用重构后的代码
|
||||
2. 确保不破坏现有功能
|
||||
3. 验证编译/类型检查通过
|
||||
|
||||
### Phase 5: 双模型审查
|
||||
|
||||
**并行启动审查（`run_in_background: true`）**：
|
||||
|
||||
**注意**：调用前先读取对应角色提示词文件（reviewer），将内容注入到 `<ROLE>` 标签中。
|
||||
|
||||
```bash
|
||||
# Codex 审查
|
||||
codeagent-wrapper --backend codex - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/codex/reviewer.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Review the implementation for: <功能描述>
|
||||
|
||||
Changes:
|
||||
<实施的代码变更>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Review comments with specific line references.
|
||||
EOF
|
||||
```
|
||||
|
||||
```bash
|
||||
# Gemini 审查
|
||||
codeagent-wrapper --backend gemini - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/gemini/reviewer.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Review the implementation for: <功能描述>
|
||||
|
||||
Changes:
|
||||
<实施的代码变更>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Review comments with specific line references.
|
||||
EOF
|
||||
```
|
||||
|
||||
### Phase 6: 修正与交付
|
||||
|
||||
1. 综合双模型审查意见
|
||||
2. 修正发现的问题
|
||||
3. 最终交付
|
||||
|
||||
## 输出格式
|
||||
|
||||
```
|
||||
## 🚀 Code: <功能描述>
|
||||
|
||||
### Phase 1: 需求分析
|
||||
- 任务类型: [前端/后端/全栈]
|
||||
- 相关文件: <文件列表>
|
||||
- 现有模式: <识别的模式>
|
||||
|
||||
### Phase 2: 代码生成
|
||||
#### [Codex/Gemini] 原型
|
||||
<Unified Diff 摘要>
|
||||
|
||||
### Phase 3: 整合重构
|
||||
<重构说明>
|
||||
|
||||
### Phase 4: 实施
|
||||
<变更文件列表>
|
||||
|
||||
### Phase 5: 审查
|
||||
#### Codex 审查
|
||||
- <审查意见 1>
|
||||
- <审查意见 2>
|
||||
|
||||
#### Gemini 审查
|
||||
- <审查意见 1>
|
||||
- <审查意见 2>
|
||||
|
||||
### Phase 6: 交付
|
||||
✅ 实施完成
|
||||
- 新增文件: X
|
||||
- 修改文件: Y
|
||||
- 代码行数: +N / -M
|
||||
```
|
||||
|
||||
## 任务类型检测
|
||||
|
||||
| 关键词 | 类型 | 路由 |
|
||||
|--------|------|------|
|
||||
| component, UI, style, CSS, React, Vue | 前端 | Gemini |
|
||||
| API, endpoint, database, auth, backend | 后端 | Codex |
|
||||
| full-stack, 全栈, 页面+接口 | 全栈 | 并行 |
|
||||
|
||||
## 代码质量标准
|
||||
|
||||
### 前端代码 (Gemini)
|
||||
- [ ] TypeScript 类型完整
|
||||
- [ ] 响应式设计
|
||||
- [ ] 无障碍属性
|
||||
- [ ] 加载/错误状态
|
||||
- [ ] 遵循设计系统
|
||||
|
||||
### 后端代码 (Codex)
|
||||
- [ ] 输入验证
|
||||
- [ ] 错误处理
|
||||
- [ ] 安全检查
|
||||
- [ ] 查询优化
|
||||
- [ ] API 一致性
|
||||
|
||||
## 关键原则
|
||||
|
||||
1. **智能路由** - 根据任务自动选择最合适的模型
|
||||
2. **接口优先** - 全栈任务先定义 API 契约
|
||||
3. **原型重构** - 外部模型输出需要 Claude 重构
|
||||
4. **双重审查** - 代码必须经过双模型审查
|
||||
@@ -1,158 +0,0 @@
|
||||
---
|
||||
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 # 修补上次提交并签名
|
||||
---
|
||||
|
||||
# Claude Command: Commit (Git-only)
|
||||
|
||||
该命令在**不依赖任何包管理器/构建工具**的前提下，仅通过 **Git**：
|
||||
|
||||
- 读取改动（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
|
||||
```
|
||||
|
||||
### 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` 以避免误操作。
|
||||
|
||||
---
|
||||
|
||||
## What This Command Does
|
||||
|
||||
1. **仓库/分支校验**
|
||||
- 通过 `git rev-parse --is-inside-work-tree` 判断是否位于 Git 仓库。
|
||||
- 读取当前分支/HEAD 状态；如处于 rebase/merge 冲突状态，先提示处理冲突后再继续。
|
||||
|
||||
2. **改动检测**
|
||||
- 用 `git status --porcelain` 与 `git diff` 获取已暂存与未暂存的改动。
|
||||
- 若已暂存文件为 0：
|
||||
- 若传入 `--all` → 执行 `git add -A`。
|
||||
- 否则提示你选择：继续仅分析未暂存改动并给出**建议**，或取消命令后手动分组暂存。
|
||||
|
||||
3. **拆分建议（Split Heuristics）**
|
||||
- 按**关注点**、**文件模式**、**改动类型**聚类（示例：源代码 vs 文档、测试；不同目录/包；新增 vs 删除）。
|
||||
- 若检测到**多组独立变更**或 diff 规模过大（如 > 300 行 / 跨多个顶级目录），建议拆分提交，并给出每一组的 pathspec（便于后续执行 `git add <paths>`）。
|
||||
|
||||
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`。
|
||||
|
||||
5. **执行提交**
|
||||
- 单提交场景：`git commit [-S] [--no-verify] [-s] -F .git/COMMIT_EDITMSG`
|
||||
- 多提交场景（如接受拆分建议）：按分组给出 `git add <paths> && git commit ...` 的明确指令；若允许执行则逐一完成。
|
||||
|
||||
6. **安全回滚**
|
||||
- 如误暂存，可用 `git restore --staged <paths>` 撤回暂存（命令会给出指令，不修改文件内容）。
|
||||
|
||||
---
|
||||
|
||||
## Best Practices for Commits
|
||||
|
||||
- **Atomic commits**：一次提交只做一件事，便于回溯与审阅。
|
||||
- **先分组再提交**：按目录/模块/功能点拆分。
|
||||
- **清晰主题**：首行 ≤ 72 字符，祈使语气（如 “add… / fix…”）。
|
||||
- **正文含上下文**：说明动机、方案、影响范围、风险与后续工作。
|
||||
- **遵循 Conventional Commits**：`<type>(<scope>): <subject>`。
|
||||
|
||||
---
|
||||
|
||||
## Type 与 Emoji 映射（使用 --emoji 时）
|
||||
|
||||
- ✨ `feat`：新增功能
|
||||
- 🐛 `fix`：缺陷修复（含 🔥 删除代码/文件、🚑️ 紧急修复、👽️ 适配外部 API 变更、🔒️ 安全修复、🚨 解决告警、💚 修复 CI）
|
||||
- 📝 `docs`：文档与注释
|
||||
- 🎨 `style`：风格/格式（不改语义）
|
||||
- ♻️ `refactor`：重构（不新增功能、不修缺陷）
|
||||
- ⚡️ `perf`：性能优化
|
||||
- ✅ `test`：新增/修复测试、快照
|
||||
- 🔧 `chore`：构建/工具/杂务（合并分支、更新配置、发布标记、依赖 pin、.gitignore 等）
|
||||
- 👷 `ci`：CI/CD 配置与脚本
|
||||
- ⏪️ `revert`：回滚提交
|
||||
- 💥 `feat`：破坏性变更（`BREAKING CHANGE:` 段落中说明）
|
||||
|
||||
> 若传入 `--type`/`--scope`，将**覆盖**自动推断。
|
||||
> 仅在指定 `--emoji` 标志时才会包含 emoji。
|
||||
|
||||
---
|
||||
|
||||
## Guidelines for Splitting Commits
|
||||
|
||||
1. **不同关注点**：互不相关的功能/模块改动应拆分。
|
||||
2. **不同类型**：不要将 `feat`、`fix`、`refactor` 混在同一提交。
|
||||
3. **文件模式**：源代码 vs 文档/测试/配置分组提交。
|
||||
4. **规模阈值**：超大 diff（示例：>300 行或跨多个顶级目录）建议拆分。
|
||||
5. **可回滚性**：确保每个提交可独立回退。
|
||||
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
**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)**
|
||||
|
||||
- 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"
|
||||
|
||||
**Split Example**
|
||||
|
||||
- `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` ←（如你的仓库有钩子报错）
|
||||
|
||||
---
|
||||
|
||||
## Important Notes
|
||||
|
||||
- **仅使用 Git**：不调用任何包管理器/构建命令（无 `pnpm`/`npm`/`yarn` 等）。
|
||||
- **尊重钩子**：默认执行本地 Git 钩子；使用 `--no-verify` 可跳过。
|
||||
- **不改源码内容**：命令只读写 `.git/COMMIT_EDITMSG` 与暂存区；不会直接编辑工作区文件。
|
||||
- **安全提示**：在 rebase/merge 冲突、detached HEAD 等状态下会先提示处理/确认再继续。
|
||||
- **可审可控**：如开启 `confirm: true`，每个实际 `git add`/`git commit` 步骤都会进行二次确认。
|
||||
@@ -1,143 +0,0 @@
|
||||
---
|
||||
description: UltraThink 多模型调试（Codex 后端诊断 + Gemini 前端诊断）
|
||||
---
|
||||
|
||||
# /ccg:debug - UltraThink 多模型调试
|
||||
|
||||
## Usage
|
||||
`/ccg:debug <问题描述>`
|
||||
|
||||
## Context
|
||||
- 问题描述: $ARGUMENTS
|
||||
- 使用 ace-tool 检索相关代码上下文
|
||||
- Codex 专注后端/逻辑问题，Gemini 专注前端/UI问题
|
||||
|
||||
## 工作流程
|
||||
|
||||
**注意**: 本命令使用 MCP 代码检索工具。请先读取 `~/.ccg/config.toml` 确定 MCP 提供商（ace-tool 或 auggie），然后使用对应的工具。
|
||||
|
||||
### Phase 1: 上下文检索
|
||||
|
||||
1. **调用代码检索工具**:
|
||||
- 根据 `~/.ccg/config.toml` 中 `[mcp.tools] code_search_{provider}` 调用对应工具
|
||||
- 参数：`project_root_path`（项目根目录）, 查询参数使用配置中 `query_param_{provider}` 对应的名称
|
||||
- 查询参数名使用 `query_param_{provider}` 的值（"query" 或 "information_request"）
|
||||
2. 收集错误日志、堆栈信息、复现步骤
|
||||
3. 识别问题涉及的模块（前端/后端/全栈）
|
||||
|
||||
### Phase 2: 并行诊断
|
||||
|
||||
**同时启动两个后台任务（`run_in_background: true`）**：
|
||||
|
||||
**注意**：调用前先读取对应角色提示词文件，将内容注入到 `<ROLE>` 标签中。
|
||||
|
||||
#### Codex 后端诊断
|
||||
```bash
|
||||
codeagent-wrapper --backend codex - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
{{读取 prompts/codex/debugger.md 的内容}}
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Debug: <问题描述>
|
||||
|
||||
Context:
|
||||
<相关代码>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Structured diagnostic report. No code modifications.
|
||||
EOF
|
||||
```
|
||||
|
||||
#### Gemini 前端诊断
|
||||
```bash
|
||||
codeagent-wrapper --backend gemini - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
{{读取 prompts/gemini/debugger.md 的内容}}
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Debug: <问题描述>
|
||||
|
||||
Context:
|
||||
<相关代码>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Structured diagnostic report. No code modifications.
|
||||
EOF
|
||||
```
|
||||
|
||||
### Phase 3: 假设整合
|
||||
|
||||
1. 收集两个模型的诊断报告（使用 `TaskOutput`）
|
||||
2. 交叉验证：识别重叠和互补的假设
|
||||
3. **UltraThink 综合**：
|
||||
- 整合所有假设，按可能性排序
|
||||
- 筛选出 **Top 1-2 最可能原因**
|
||||
- 设计验证策略
|
||||
|
||||
### Phase 4: 用户确认（Hard Stop）
|
||||
|
||||
输出格式：
|
||||
```
|
||||
## 🔍 诊断结果
|
||||
|
||||
### Codex 分析（后端视角）
|
||||
<Codex 诊断摘要>
|
||||
|
||||
### Gemini 分析（前端视角）
|
||||
<Gemini 诊断摘要>
|
||||
|
||||
### 综合诊断
|
||||
**最可能原因**：<具体诊断>
|
||||
**证据**：<支持证据>
|
||||
**验证方案**：<如何确认>
|
||||
|
||||
---
|
||||
**确认后我将执行修复。是否继续？(Y/N)**
|
||||
```
|
||||
|
||||
⚠️ **必须等待用户确认后才能进入 Phase 5**
|
||||
|
||||
### Phase 5: 修复与验证
|
||||
|
||||
1. 根据确认的诊断实施修复
|
||||
2. 修复完成后，**强制并行调用** Codex + Gemini 审查修复
|
||||
3. 综合审查意见，确认问题解决
|
||||
|
||||
## 输出格式
|
||||
|
||||
```
|
||||
## Phase 1: 上下文检索
|
||||
- 检索到 X 个相关文件
|
||||
- 问题类型: [前端/后端/全栈]
|
||||
|
||||
## Phase 2: 并行诊断
|
||||
### Codex 诊断
|
||||
<诊断内容>
|
||||
|
||||
### Gemini 诊断
|
||||
<诊断内容>
|
||||
|
||||
## Phase 3: 综合分析
|
||||
### Top 假设
|
||||
1. [最可能原因] - 可能性: High
|
||||
2. [次可能原因] - 可能性: Medium
|
||||
|
||||
### 验证策略
|
||||
- [具体验证步骤]
|
||||
|
||||
## Phase 4: 确认
|
||||
**是否按此诊断进行修复？(Y/N)**
|
||||
|
||||
## Phase 5: 修复验证（用户确认后）
|
||||
- 修复内容: <具体修改>
|
||||
- 双模型审查: <审查结果>
|
||||
```
|
||||
|
||||
## 关键原则
|
||||
|
||||
1. **不假设，先验证** - 所有假设需要证据支持
|
||||
2. **并行诊断** - 充分利用双模型的不同视角
|
||||
3. **用户确认** - 修复前必须获得确认
|
||||
4. **交叉审查** - 修复后双模型验证
|
||||
@@ -1,213 +0,0 @@
|
||||
---
|
||||
description: 完整6阶段多模型协作工作流（Prompt增强 → 上下文检索 → 多模型分析 → 原型生成 → 代码实施 → 审计交付）
|
||||
---
|
||||
|
||||
## 用法
|
||||
`/dev <功能描述>`
|
||||
|
||||
## 上下文
|
||||
- 要实现的功能: $ARGUMENTS
|
||||
- 此命令触发完整的 6 阶段多模型协作工作流
|
||||
- 根据 `~/.ccg/config.toml` 配置路由模型
|
||||
|
||||
## 配置
|
||||
**首先读取 `~/.ccg/config.toml` 获取模型路由配置**:
|
||||
```toml
|
||||
[routing]
|
||||
mode = "smart" # smart | parallel | sequential
|
||||
|
||||
[routing.frontend]
|
||||
models = ["gemini", "codex"]
|
||||
primary = "gemini"
|
||||
strategy = "parallel"
|
||||
|
||||
[routing.backend]
|
||||
models = ["codex", "gemini"]
|
||||
primary = "codex"
|
||||
strategy = "parallel"
|
||||
|
||||
[routing.review]
|
||||
models = ["codex", "gemini"]
|
||||
strategy = "parallel"
|
||||
```
|
||||
|
||||
## 你的角色
|
||||
你是**编排者**，协调多模型协作系统。你指挥:
|
||||
1. **ace-tool** – 用于 Prompt 增强和代码库上下文检索
|
||||
2. **配置的后端模型** – 用于后端逻辑、算法和调试
|
||||
3. **配置的前端模型** – 用于前端 UI/UX 和视觉设计
|
||||
4. **Claude (自己)** – 用于最终代码重构和交付
|
||||
|
||||
## 流程
|
||||
|
||||
### 阶段 0: 读取配置 + Prompt 增强
|
||||
1. **读取 `~/.ccg/config.toml`** 获取 MCP 提供商和模型路由配置
|
||||
- 如果配置不存在，使用默认值：provider=ace-tool, frontend=gemini, backend=codex
|
||||
- 根据 `[mcp] provider` 字段确定使用的 MCP 工具
|
||||
|
||||
2. **Prompt 增强**:
|
||||
- 读取 `~/.ccg/config.toml` 获取 `[mcp.tools] prompt_enhance_{provider}` 的工具名称
|
||||
- 如果工具名为空字符串（表示未配置 Prompt 增强功能），跳过增强，提示用户查看配置中的 setup_url 获取配置教程
|
||||
- 否则调用该工具，参数：`project_root_path`, `prompt`, `conversation_history`
|
||||
|
||||
3. 根据用户选择继续后续阶段
|
||||
|
||||
### 阶段 1: 上下文检索
|
||||
1. **调用代码检索工具**:
|
||||
- 读取 `~/.ccg/config.toml` 获取 `[mcp] provider` 值（如 "ace-tool" 或 "auggie"）
|
||||
- 使用 `[mcp.tools] code_search_{provider}` 配置的工具名称
|
||||
- 参数：`project_root_path`（项目根目录），查询参数名使用 `query_param_{provider}` 的值（"query" 或 "information_request"）
|
||||
|
||||
2. 识别所有相关文件、类、函数和依赖
|
||||
3. 如需求仍不清晰，提出澄清问题
|
||||
|
||||
### 阶段 2: 多模型分析
|
||||
|
||||
**根据配置并行调用模型进行分析**（使用 `run_in_background: true` 非阻塞执行）：
|
||||
|
||||
**注意**：调用前先读取对应角色提示词文件，将内容注入到 `<ROLE>` 标签中。
|
||||
|
||||
根据 `routing.backend.models` 和 `routing.frontend.models` 动态生成调用：
|
||||
|
||||
```bash
|
||||
# 后端模型分析 (遍历 routing.backend.models)
|
||||
codeagent-wrapper --backend <BACKEND_MODEL> - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/<model>/analyzer.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
分析此需求: <需求>
|
||||
|
||||
Context:
|
||||
<相关代码和架构信息>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: 提供后端/逻辑方面的实现方案。
|
||||
EOF
|
||||
```
|
||||
|
||||
```bash
|
||||
# 前端模型分析 (遍历 routing.frontend.models)
|
||||
codeagent-wrapper --backend <FRONTEND_MODEL> - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/<model>/analyzer.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
分析此需求: <需求>
|
||||
|
||||
Context:
|
||||
<相关代码和设计信息>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: 提供前端/UI方面的实现方案。
|
||||
EOF
|
||||
```
|
||||
|
||||
然后使用 `TaskOutput` 获取所有任务的结果，交叉验证后综合方案。
|
||||
|
||||
**强制停止**: 询问用户 **"是否继续执行此方案？(Y/N)"** 并等待确认
|
||||
|
||||
### 阶段 3: 原型生成
|
||||
|
||||
根据任务类型和配置选择路由：
|
||||
|
||||
**注意**：调用前先读取对应角色提示词文件，将内容注入到 `<ROLE>` 标签中。
|
||||
|
||||
**路由 A (前端/UI)** → 使用配置的前端模型:
|
||||
```bash
|
||||
# 遍历 routing.frontend.models，根据 strategy 执行
|
||||
codeagent-wrapper --backend <FRONTEND_MODEL> - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/<model>/frontend.md 的内容并注入
|
||||
如果是 codex: 使用 prompts/codex/architect.md
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
生成前端原型: <任务>
|
||||
|
||||
Context:
|
||||
<相关代码>
|
||||
<设计系统/组件库信息>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications.
|
||||
EOF
|
||||
```
|
||||
|
||||
**路由 B (后端/逻辑)** → 使用配置的后端模型:
|
||||
```bash
|
||||
# 遍历 routing.backend.models，根据 strategy 执行
|
||||
codeagent-wrapper --backend <BACKEND_MODEL> - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/<model>/architect.md 的内容并注入
|
||||
如果是 gemini: 使用 prompts/gemini/analyzer.md
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
实现后端逻辑: <任务>
|
||||
|
||||
Context:
|
||||
<相关代码>
|
||||
<API 规范/数据模型>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications.
|
||||
EOF
|
||||
```
|
||||
|
||||
**如果同时有前端和后端任务**，使用 `run_in_background: true` 并行执行。
|
||||
**如果 strategy = parallel 且有多个模型**，同时调用所有模型并交叉验证结果。
|
||||
|
||||
### 阶段 4: 代码实施
|
||||
1. 将原型视为"脏原型" – 仅作参考
|
||||
2. 如果有多个模型结果，交叉验证选择最佳方案
|
||||
3. 重构为干净的生产级代码
|
||||
4. 验证变更不会引入副作用
|
||||
|
||||
### 阶段 5: 审计与交付
|
||||
|
||||
**并行调用 `routing.review.models` 中的所有模型进行代码审查**：
|
||||
|
||||
**注意**：调用前先读取对应角色提示词文件（reviewer），将内容注入到 `<ROLE>` 标签中。
|
||||
|
||||
```bash
|
||||
# 遍历 routing.review.models 进行审查
|
||||
codeagent-wrapper --backend <REVIEW_MODEL> - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/<model>/reviewer.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
审查此实现:
|
||||
- 如果是后端: 安全性、性能、错误处理
|
||||
- 如果是前端: 可访问性、响应式设计、设计一致性
|
||||
<提供 diff>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Review comments only.
|
||||
EOF
|
||||
```
|
||||
|
||||
使用 `TaskOutput` 获取所有审查结果，整合反馈后修正并交付。
|
||||
|
||||
## 输出格式
|
||||
1. **配置信息** – 使用的模型和路由策略
|
||||
2. **增强后需求** – 优化后的 prompt (阶段 0)
|
||||
3. **上下文摘要** – 识别的相关代码元素
|
||||
4. **实施方案** – 含模型路由的逐步方案
|
||||
5. **代码变更** – 生产级实现
|
||||
6. **审计报告** – 审查反馈和修正
|
||||
7. **后续步骤** – 部署或跟进操作
|
||||
|
||||
## 关键规则
|
||||
- 未经用户批准不得跳过任何阶段
|
||||
- **首先读取 `~/.ccg/config.toml` 获取模型配置**
|
||||
- **阶段 0 的 prompt 增强是强制性的** – 必须先展示增强后的 prompt
|
||||
- 始终要求外部模型输出 Unified Diff Patch
|
||||
- 外部模型对文件系统**零写入权限**
|
||||
- 实时向用户报告当前阶段和下一阶段
|
||||
- 使用 HEREDOC 语法 (`<<'EOF'`) 避免 shell 转义问题
|
||||
- **并行模型调用使用 `run_in_background: true`** 避免阻塞
|
||||
- **多模型结果需交叉验证，取长补短**
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
description: 使用 ace-tool enhance_prompt 优化 Prompt，展示原始与增强版本供确认
|
||||
---
|
||||
|
||||
## Usage
|
||||
`/enhance <PROMPT>`
|
||||
|
||||
## Context
|
||||
- Original prompt: $ARGUMENTS
|
||||
- This command enhances prompts before execution using ace-tool's enhance_prompt.
|
||||
|
||||
## Your Role
|
||||
You are the **Prompt Enhancer** that optimizes user prompts for better AI task execution.
|
||||
|
||||
## Process
|
||||
|
||||
### Step 1: 读取 MCP 配置并调用 Prompt 增强工具
|
||||
1. 读取 `~/.ccg/config.toml`:
|
||||
- 获取 `[mcp] provider`（如 "ace-tool" 或 "auggie"）
|
||||
- 获取 `[mcp.tools] prompt_enhance_{provider}` 的工具名称
|
||||
2. 如果工具名不为空，调用该工具：
|
||||
- 参数：`project_root_path`, `prompt`, `conversation_history`
|
||||
3. 如果工具名为空字符串（表示未配置 Prompt 增强功能），提示用户：
|
||||
- 显示配置中 `[mcp] setup_url` 的链接，查看 Prompt 增强配置教程
|
||||
- 建议按教程配置或切换到 ace-tool（开箱即用）
|
||||
|
||||
### Step 2: 处理响应
|
||||
根据工具返回的结果：
|
||||
- **增强后的 prompt**: 使用该 prompt 继续执行任务
|
||||
- **原始 prompt**: 使用原始 prompt 继续
|
||||
- **`__END_CONVERSATION__`**: 停止对话，不执行任何任务
|
||||
- **工具不可用**: 直接使用原始 prompt
|
||||
|
||||
### Step 3: 执行任务
|
||||
根据用户选择或配置限制执行相应操作。
|
||||
|
||||
## Notes
|
||||
- 支持自动语言检测（中文输入 → 中文输出）
|
||||
- 8 分钟超时后自动回退到原始 prompt（仅部分 MCP 支持）
|
||||
- 也可通过在消息末尾添加 `-enhance` 或 `-Enhancer` 触发
|
||||
- 详细的 MCP 功能对比见配置文件 `~/.ccg/config.toml`
|
||||
@@ -1,112 +0,0 @@
|
||||
---
|
||||
description: 前端/UI/样式任务，自动路由到配置的前端模型进行原型生成和审计
|
||||
---
|
||||
|
||||
## Usage
|
||||
`/frontend <UI_TASK_DESCRIPTION>`
|
||||
|
||||
## Context
|
||||
- Frontend/UI task to implement: $ARGUMENTS
|
||||
- This command routes to your configured frontend models.
|
||||
- Default authority for CSS, React, Vue, and visual design.
|
||||
|
||||
## Configuration
|
||||
**首先读取 `~/.ccg/config.toml` 获取模型路由配置**:
|
||||
```
|
||||
[routing.frontend]
|
||||
models = ["gemini", "codex"] # 用户配置的前端模型列表
|
||||
primary = "gemini" # 主模型
|
||||
strategy = "parallel" # 路由策略: parallel | fallback | round-robin
|
||||
```
|
||||
|
||||
## Your Role
|
||||
You are the **Frontend Orchestrator** specializing in UI/UX implementation. You coordinate:
|
||||
1. **ace-tool** – for retrieving existing frontend code and components
|
||||
2. **Configured Frontend Models** – for generating CSS/React/Vue prototypes
|
||||
3. **Claude (Self)** – for refactoring prototypes into production code
|
||||
|
||||
## Process
|
||||
|
||||
### Step 1: Read Configuration
|
||||
1. Read `~/.ccg/config.toml` to get frontend model configuration
|
||||
2. Identify which models to use based on `routing.frontend.models`
|
||||
3. If config doesn't exist, default to `gemini`
|
||||
|
||||
### Step 2: Context Retrieval
|
||||
1. **调用代码检索工具**:
|
||||
- 根据 `~/.ccg/config.toml` 中 `[mcp.tools] code_search_{provider}` 调用对应工具
|
||||
- 参数：`project_root_path`（项目根目录）, 查询内容为前端组件和样式
|
||||
- 查询参数名使用 `query_param_{provider}` 的值（"query" 或 "information_request"）
|
||||
2. Identify the design system, component library, and styling conventions in use
|
||||
|
||||
### Step 3: Model Prototype
|
||||
|
||||
**根据配置的 strategy 执行**:
|
||||
|
||||
- **parallel**: 同时调用所有配置的前端模型，综合结果
|
||||
- **fallback**: 调用主模型，失败则调用次模型
|
||||
- **round-robin**: 轮询调用
|
||||
|
||||
**注意**：调用前先读取对应角色提示词文件，将内容注入到 `<ROLE>` 标签中。
|
||||
|
||||
```bash
|
||||
# 示例：调用配置的前端模型 (根据 config.toml 选择)
|
||||
codeagent-wrapper --backend <MODEL_FROM_CONFIG> - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/<model>/frontend.md 的内容并注入
|
||||
如果是 gemini: prompts/gemini/frontend.md
|
||||
如果是 codex: prompts/codex/architect.md (Codex 无专门前端角色)
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Generate frontend prototype for: <task>
|
||||
|
||||
Context:
|
||||
<相关代码>
|
||||
<设计系统/组件库信息>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications.
|
||||
EOF
|
||||
```
|
||||
|
||||
**如果 strategy = parallel 且有多个模型**:
|
||||
使用 `run_in_background: true` 并行调用所有模型，然后用 `TaskOutput` 收集结果。
|
||||
|
||||
### Step 4: Refactor & Implement
|
||||
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 consistency with existing components
|
||||
|
||||
### Step 5: Audit
|
||||
|
||||
Call configured frontend model(s) to review the final implementation:
|
||||
|
||||
```bash
|
||||
codeagent-wrapper --backend <MODEL_FROM_CONFIG> - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/<model>/reviewer.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Review this UI implementation for: accessibility, responsiveness, design consistency.
|
||||
<provide diff>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Review comments only.
|
||||
EOF
|
||||
```
|
||||
|
||||
## Output Format
|
||||
1. **Configuration** – models and strategy being used
|
||||
2. **Component Analysis** – existing patterns and design system
|
||||
3. **Model Prototype(s)** – raw prototypes from configured models
|
||||
4. **Refined Implementation** – production-ready UI code
|
||||
5. **Audit Feedback** – accessibility and design review
|
||||
|
||||
## Notes
|
||||
- Gemini context limit: < 32k tokens
|
||||
- Read `~/.ccg/config.toml` at start of execution
|
||||
- Always request Unified Diff Patch format
|
||||
- Use HEREDOC syntax (`<<'EOF'`) to avoid shell escaping issues
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
description: 初始化项目 AI 上下文，生成/更新根级与模块级 CLAUDE.md 索引
|
||||
allowed-tools: Read(**), Write(CLAUDE.md, **/CLAUDE.md)
|
||||
argument-hint: <项目摘要或名称>
|
||||
---
|
||||
|
||||
## 用法
|
||||
|
||||
`/init-project <项目摘要或名称>`
|
||||
|
||||
## 目标
|
||||
|
||||
以"根级简明 + 模块级详尽"的混合策略初始化项目 AI 上下文：
|
||||
|
||||
- 在仓库根生成/更新 `CLAUDE.md`（高层愿景、架构总览、模块索引、全局规范）。
|
||||
- 在识别的各模块目录生成/更新本地 `CLAUDE.md`（接口、依赖、入口、测试、关键文件等）。
|
||||
- ✨ **为了提升可读性，会在根 `CLAUDE.md` 中自动生成 Mermaid 结构图，并为每个模块 `CLAUDE.md` 添加导航面包屑**。
|
||||
|
||||
## 编排说明
|
||||
|
||||
**步骤 1**：调用 `get-current-datetime` 子智能体获取当前时间戳。
|
||||
|
||||
**步骤 2**：调用一次 `init-architect` 子智能体，输入：
|
||||
|
||||
- `project_summary`: $ARGUMENTS
|
||||
- `current_timestamp`: (来自步骤1的时间戳)
|
||||
|
||||
## 执行策略（由 Agent 自适应决定，不需要用户传参）
|
||||
|
||||
- **阶段 A：全仓清点（轻量）**
|
||||
快速统计文件与目录，识别模块根（package.json、pyproject.toml、go.mod、apps/_、packages/_、services/\* 等）。
|
||||
- **阶段 B：模块优先扫描（中等）**
|
||||
对每个模块做"入口/接口/依赖/测试/数据模型/质量工具"的定点读取与样本抽取。
|
||||
- **阶段 C：深度补捞（按需）**
|
||||
若仓库较小或模块规模较小，则扩大读取面；若较大，则对高风险/高价值路径分批追加扫描。
|
||||
- **覆盖率度量与可续跑**
|
||||
输出"已扫描文件数 / 估算总文件数、已覆盖模块占比、被忽略/跳过原因"，并列出"建议下一步深挖的子路径"。重复运行 `/init-project` 时按上次索引做**增量更新**与**断点续扫**。
|
||||
|
||||
## 安全与边界
|
||||
|
||||
- 只读/写文档与索引，不改源代码。
|
||||
- 默认忽略常见生成物与二进制大文件。
|
||||
- 结果在主对话打印"摘要"，全文写入仓库。
|
||||
|
||||
## 输出要求
|
||||
|
||||
- 在主对话中打印"初始化结果摘要"，包含：
|
||||
- 根级 `CLAUDE.md` 是否创建/更新、主要栏目概览。
|
||||
- 识别的模块数量及其路径列表。
|
||||
- 每个模块 `CLAUDE.md` 的生成/更新情况。
|
||||
- ✨ **明确提及"已生成 Mermaid 结构图"和"已为 N 个模块添加导航面包屑"**。
|
||||
- 覆盖率与主要缺口。
|
||||
- 若未读全：说明"为何到此为止"，并列出**推荐的下一步**（例如"建议优先补扫：packages/auth/src/controllers"）。
|
||||
@@ -1,186 +0,0 @@
|
||||
---
|
||||
description: 多模型性能优化（Codex 后端优化 + Gemini 前端优化）
|
||||
---
|
||||
|
||||
# /ccg:optimize - 性能优化
|
||||
|
||||
## Usage
|
||||
`/ccg:optimize <优化目标>`
|
||||
|
||||
## Context
|
||||
- 优化目标: $ARGUMENTS
|
||||
- Codex 专注后端性能（数据库、算法、缓存）
|
||||
- Gemini 专注前端性能（渲染、加载、交互）
|
||||
|
||||
## 工作流程
|
||||
|
||||
**注意**: 本命令使用 MCP 代码检索工具。请先读取 `~/.ccg/config.toml` 确定 MCP 提供商（ace-tool 或 auggie），然后使用对应的工具。
|
||||
|
||||
### Phase 1: 性能基线分析
|
||||
|
||||
1. **调用代码检索工具**:
|
||||
- 根据 `~/.ccg/config.toml` 中 `[mcp.tools] code_search_{provider}` 调用对应工具
|
||||
- 参数：`project_root_path`（项目根目录）, 查询参数使用配置中 `query_param_{provider}` 对应的名称
|
||||
- 查询参数名使用 `query_param_{provider}` 的值（"query" 或 "information_request"）
|
||||
2. 识别性能关键路径
|
||||
3. 收集现有指标（如有）：
|
||||
- 后端: 响应时间、查询耗时、内存占用
|
||||
- 前端: LCP、FID、CLS、Bundle Size
|
||||
|
||||
### Phase 2: 并行性能分析
|
||||
|
||||
**同时启动（`run_in_background: true`）**：
|
||||
|
||||
**注意**：调用前先读取对应角色提示词文件，将内容注入到 `<ROLE>` 标签中。
|
||||
|
||||
#### Codex 后端性能分析
|
||||
```bash
|
||||
codeagent-wrapper --backend codex - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/codex/optimizer.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Performance optimization for: <优化目标>
|
||||
|
||||
Context:
|
||||
<相关代码>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Analysis report + Unified Diff Patch for optimizations.
|
||||
EOF
|
||||
```
|
||||
|
||||
#### Gemini 前端性能分析
|
||||
```bash
|
||||
codeagent-wrapper --backend gemini - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/gemini/optimizer.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Performance optimization for: <优化目标>
|
||||
|
||||
Context:
|
||||
<相关代码>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Analysis report + Unified Diff Patch for optimizations.
|
||||
EOF
|
||||
```
|
||||
|
||||
### Phase 3: 优化整合
|
||||
|
||||
1. 收集双模型分析（使用 `TaskOutput`）
|
||||
2. **优先级排序**：
|
||||
- 按影响程度排序（High/Medium/Low）
|
||||
- 按实施难度评估
|
||||
- 综合性价比排序
|
||||
3. Claude 重构优化代码
|
||||
|
||||
### Phase 4: 实施优化
|
||||
|
||||
1. 按优先级实施优化
|
||||
2. 确保不破坏现有功能
|
||||
3. 添加必要的性能监控
|
||||
|
||||
### Phase 5: 验证
|
||||
|
||||
1. 运行性能测试（如有）
|
||||
2. 对比优化前后指标
|
||||
3. 双模型审查优化效果
|
||||
|
||||
## 输出格式
|
||||
|
||||
```
|
||||
## ⚡ 性能优化: <优化目标>
|
||||
|
||||
### Phase 1: 基线分析
|
||||
- 优化范围: <涉及的模块>
|
||||
- 当前指标: <现有性能数据>
|
||||
- 关键路径: <性能热点>
|
||||
|
||||
### Phase 2: 性能分析
|
||||
|
||||
#### Codex 分析（后端）
|
||||
| 问题 | 影响 | 难度 | 预期提升 |
|
||||
|------|------|------|----------|
|
||||
| <问题1> | High | Low | -200ms |
|
||||
| <问题2> | Medium | Medium | -50ms |
|
||||
|
||||
**优化建议**:
|
||||
1. <建议1>
|
||||
2. <建议2>
|
||||
|
||||
#### Gemini 分析（前端）
|
||||
| 问题 | 影响 | 难度 | 预期提升 |
|
||||
|------|------|------|----------|
|
||||
| <问题1> | High | Low | -1.5s LCP |
|
||||
| <问题2> | Medium | Low | -100KB |
|
||||
|
||||
**优化建议**:
|
||||
1. <建议1>
|
||||
2. <建议2>
|
||||
|
||||
### Phase 3: 优化计划
|
||||
|
||||
#### 优先级排序
|
||||
| 排序 | 优化项 | 来源 | 性价比 |
|
||||
|------|--------|------|--------|
|
||||
| 1 | <优化1> | Codex | ⭐⭐⭐ |
|
||||
| 2 | <优化2> | Gemini | ⭐⭐⭐ |
|
||||
| 3 | <优化3> | Codex | ⭐⭐ |
|
||||
|
||||
### Phase 4: 实施
|
||||
<优化代码变更>
|
||||
|
||||
### Phase 5: 验证
|
||||
| 指标 | 优化前 | 优化后 | 提升 |
|
||||
|------|--------|--------|------|
|
||||
| 响应时间 | 500ms | 200ms | 60% |
|
||||
| Bundle Size | 2MB | 1.2MB | 40% |
|
||||
| LCP | 3.5s | 1.8s | 49% |
|
||||
|
||||
### 结果
|
||||
✅ 优化完成
|
||||
- 后端优化: X 项
|
||||
- 前端优化: Y 项
|
||||
- 综合提升: Z%
|
||||
```
|
||||
|
||||
## 性能指标参考
|
||||
|
||||
### 后端指标
|
||||
| 指标 | 良好 | 需优化 | 严重 |
|
||||
|------|------|--------|------|
|
||||
| API 响应 | <100ms | 100-500ms | >500ms |
|
||||
| 数据库查询 | <50ms | 50-200ms | >200ms |
|
||||
| 内存占用 | 稳定 | 缓慢增长 | 快速增长 |
|
||||
|
||||
### 前端指标 (Core Web Vitals)
|
||||
| 指标 | 良好 | 需改进 | 差 |
|
||||
|------|------|--------|-----|
|
||||
| LCP | <2.5s | 2.5-4s | >4s |
|
||||
| FID | <100ms | 100-300ms | >300ms |
|
||||
| CLS | <0.1 | 0.1-0.25 | >0.25 |
|
||||
|
||||
## 常见优化模式
|
||||
|
||||
### 后端
|
||||
- **N+1 查询** → 批量加载 / JOIN
|
||||
- **缺少索引** → 添加复合索引
|
||||
- **重复计算** → 缓存 / Memoization
|
||||
- **同步阻塞** → 异步处理
|
||||
|
||||
### 前端
|
||||
- **大 Bundle** → 代码分割 / 懒加载
|
||||
- **频繁重渲染** → React.memo / useMemo
|
||||
- **大列表** → 虚拟滚动
|
||||
- **未优化图片** → WebP / 懒加载
|
||||
|
||||
## 关键原则
|
||||
|
||||
1. **先测量后优化** - 没有数据不盲目优化
|
||||
2. **性价比优先** - 高影响 + 低难度优先
|
||||
3. **不破坏功能** - 优化不能引入 bug
|
||||
4. **可观测性** - 添加监控便于持续优化
|
||||
@@ -1,102 +0,0 @@
|
||||
---
|
||||
description: 多模型代码审查（根据配置并行），无参数时自动审查 git diff
|
||||
---
|
||||
|
||||
## Usage
|
||||
`/review [CODE_OR_DESCRIPTION]`
|
||||
|
||||
## Context
|
||||
- Arguments: $ARGUMENTS
|
||||
- This command triggers multi-model code review based on your configuration.
|
||||
- Configured models review simultaneously for comprehensive feedback.
|
||||
|
||||
## Configuration
|
||||
**首先读取 `~/.ccg/config.toml` 获取审查模型配置**:
|
||||
```toml
|
||||
[routing.review]
|
||||
models = ["codex", "gemini"] # 用户配置的审查模型列表
|
||||
strategy = "parallel" # 始终并行执行
|
||||
```
|
||||
|
||||
## Behavior
|
||||
- **No arguments**: Automatically review current git changes (staged + unstaged)
|
||||
- **With arguments**: Review specified code or description
|
||||
|
||||
## Your Role
|
||||
You are the **Code Review Coordinator** orchestrating multi-model review. You direct:
|
||||
1. **ace-tool** – for retrieving code context
|
||||
2. **Configured Review Models** – for comprehensive code review
|
||||
3. **Claude (Self)** – for synthesizing feedback and recommendations
|
||||
|
||||
## Process
|
||||
|
||||
### Step 1: Read Configuration + Get Code to Review
|
||||
|
||||
1. **读取 `~/.ccg/config.toml`** 获取 `routing.review.models`
|
||||
2. 如果配置不存在，默认使用 `["codex", "gemini"]`
|
||||
|
||||
**If no arguments provided**, run git commands to get current changes:
|
||||
```bash
|
||||
# Get staged and unstaged changes
|
||||
git diff HEAD
|
||||
git status --short
|
||||
```
|
||||
|
||||
**If arguments provided**, use the specified code/description.
|
||||
|
||||
Then **调用代码检索工具**获取相关上下文:
|
||||
- 读取 `~/.ccg/config.toml` 获取 `[mcp] provider`
|
||||
- 使用 `[mcp.tools] code_search_{provider}` 配置的工具名称
|
||||
- 参数：`project_root_path`，查询参数名使用 `query_param_{provider}` 的值
|
||||
|
||||
### Step 2: Parallel Review
|
||||
|
||||
**并行调用所有配置的审查模型**（使用 `run_in_background: true` 非阻塞执行）：
|
||||
|
||||
**注意**：调用前先读取对应角色提示词文件，将内容注入到 `<ROLE>` 标签中。
|
||||
|
||||
遍历 `routing.review.models`，为每个模型发送调用：
|
||||
|
||||
```bash
|
||||
# 示例：调用配置的审查模型
|
||||
codeagent-wrapper --backend <MODEL_FROM_CONFIG> - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/<model>/reviewer.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Code changes to review:
|
||||
<git_diff_or_specified_code>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Review comments only. No code modifications.
|
||||
EOF
|
||||
```
|
||||
|
||||
### Step 3: Synthesize Feedback
|
||||
使用 `TaskOutput` 获取所有任务的结果，然后：
|
||||
1. Collect feedback from all configured models
|
||||
2. Categorize by severity (Critical, Major, Minor, Suggestion)
|
||||
3. Remove duplicate concerns
|
||||
4. Cross-validate findings across models
|
||||
5. Prioritize actionable items
|
||||
|
||||
### Step 4: Present Review
|
||||
Provide unified review report to user with recommendations.
|
||||
|
||||
## Output Format
|
||||
1. **Configuration** – models used for review
|
||||
2. **Review Summary** – overall assessment
|
||||
3. **Critical Issues** – must fix before merge
|
||||
4. **Major Issues** – should fix
|
||||
5. **Minor Issues** – nice to fix
|
||||
6. **Suggestions** – optional improvements
|
||||
7. **Recommended Actions** – prioritized fix list
|
||||
|
||||
## Notes
|
||||
- **首先读取 `~/.ccg/config.toml` 获取审查模型配置**
|
||||
- **No arguments** = auto-review git changes (`git diff HEAD`)
|
||||
- **With arguments** = review specified content
|
||||
- **Use `run_in_background: true` for parallel execution** to avoid blocking
|
||||
- 多模型结果交叉验证，综合反馈
|
||||
- Use HEREDOC syntax (`<<'EOF'`) to avoid shell escaping issues
|
||||
@@ -1,90 +0,0 @@
|
||||
---
|
||||
description: 交互式回滚 Git 分支到历史版本；列分支、列版本、二次确认后执行 reset / revert
|
||||
allowed-tools: Read(**), Exec(git fetch, git branch, git tag, git log, git reflog, git checkout, git reset, git revert, git switch), Write()
|
||||
argument-hint: [--branch <branch>] [--target <rev>] [--mode reset|revert] [--depth <n>] [--dry-run] [--yes]
|
||||
# examples:
|
||||
# - /git-rollback # 全交互模式，dry‑run
|
||||
# - /git-rollback --branch dev # 直接选 dev，其他交互
|
||||
# - /git-rollback --branch dev --target v1.2.0 --mode reset --yes
|
||||
---
|
||||
|
||||
# Claude Command: Git Rollback
|
||||
|
||||
**目的**：安全、可视地将指定分支回滚到旧版本。
|
||||
默认处于 **只读预览 (`--dry-run`)**；真正执行需加 `--yes` 或在交互中确认。
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
# 纯交互：列出分支 → 选分支 → 列最近 20 个版本 → 选目标 → 选择 reset 或 revert → 二次确认
|
||||
/git-rollback
|
||||
|
||||
# 指定分支，其他交互
|
||||
/git-rollback --branch feature/calculator
|
||||
|
||||
# 指定分支与目标 commit，并用 hard‑reset 一键执行（危险）
|
||||
/git-rollback --branch main --target 1a2b3c4d --mode reset --yes
|
||||
|
||||
# 只想生成 revert 提交（非破坏式回滚），预览即可
|
||||
/git-rollback --branch release/v2.1 --target v2.0.5 --mode revert --dry-run
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
| 选项 | 说明 |
|
||||
| ---------------------- | ---------------------------------------------------------------------------------- |
|
||||
| `--branch <branch>` | 要回滚的分支；缺省时交互选择。 |
|
||||
| `--target <rev>` | 目标版本（commit Hash、Tag、reflog 引用都行）；缺省时交互选择近 `--depth` 条记录。 |
|
||||
| `--mode reset\|revert` | `reset`：硬回滚历史；`revert`：生成反向提交保持历史完整。默认询问。 |
|
||||
| `--depth <n>` | 在交互模式下列出最近 n 个版本（默认 20）。 |
|
||||
| `--dry-run` | **默认开启**，只预览即将执行的命令。 |
|
||||
| `--yes` | 跳过所有确认直接执行，适合 CI/CD 脚本。 |
|
||||
|
||||
---
|
||||
|
||||
## 交互流程
|
||||
|
||||
1. **同步远端** → `git fetch --all --prune`
|
||||
2. **列分支** → `git branch -a`（本地＋远端，过滤受保护分支）
|
||||
3. **选分支** → 用户输入或传参
|
||||
4. **列版本** → `git log --oneline -n <depth>` + `git tag --merged` + `git reflog -n <depth>`
|
||||
5. **选目标** → 用户输入 commit hash / tag
|
||||
6. **选模式** → `reset` 或 `revert`
|
||||
7. **最终确认** （除非 `--yes`）
|
||||
8. **执行回滚**
|
||||
- `reset`：`git switch <branch> && git reset --hard <target>`
|
||||
- `revert`：`git switch <branch> && git revert --no-edit <target>..HEAD`
|
||||
9. **推送建议** → 提示是否 `git push --force-with-lease`（reset）或普通 `git push`（revert）
|
||||
|
||||
---
|
||||
|
||||
## 安全护栏
|
||||
|
||||
- **备份**：执行前自动在 reflog 中记录当前 HEAD，可用 `git switch -c backup/<timestamp>` 恢复。
|
||||
- **保护分支**：如检测到 `main` / `master` / `production` 等受保护分支且开启 `reset` 模式，将要求额外确认。
|
||||
- **--dry-run 默认开启**：防止误操作。
|
||||
- **--force 禁止**：不提供 `--force`；如需强推，请手动输入 `git push --force-with-lease`。
|
||||
|
||||
---
|
||||
|
||||
## 适用场景示例
|
||||
|
||||
| 场景 | 调用示例 |
|
||||
| ----------------------------------------------- | ---------------------------------------------------------------- |
|
||||
| 热修补丁上线后发现 bug，需要回到 Tag `v1.2.0` | `/git-rollback --branch release/v1 --target v1.2.0 --mode reset` |
|
||||
| 运维同事误推了 debug 日志提交，需要生成反向提交 | `/git-rollback --branch main --target 3f2e7c9 --mode revert` |
|
||||
| 调研历史 bug，引导新人浏览分支历史 | `/git-rollback` （全交互，dry‑run） |
|
||||
|
||||
---
|
||||
|
||||
## 注意
|
||||
|
||||
1. **reset vs revert**
|
||||
- **reset** 会改变历史，需要强推并可能影响其他协作者，谨慎使用。
|
||||
- **revert** 更安全，生成新提交保留历史，但会增加一次记录。
|
||||
2. **嵌入式仓库** 常有大体积二进制文件；回滚前请确保 LFS/子模块状态一致。
|
||||
3. 若仓库启用了 CI 强制校验，回滚后可能自动触发流水线；确认管控策略以免误部署旧版本。
|
||||
|
||||
---
|
||||
@@ -1,138 +0,0 @@
|
||||
---
|
||||
description: 多模型测试生成（Codex 后端测试 + Gemini 前端测试）
|
||||
---
|
||||
|
||||
# /ccg:test - 多模型测试生成
|
||||
|
||||
## Usage
|
||||
`/ccg:test <测试目标>`
|
||||
|
||||
## Context
|
||||
- 测试目标: $ARGUMENTS
|
||||
- 使用 ace-tool 检索目标代码和现有测试
|
||||
- Codex 生成后端测试，Gemini 生成前端测试
|
||||
|
||||
## 工作流程
|
||||
|
||||
**注意**: 本命令使用 MCP 代码检索工具。请先读取 `~/.ccg/config.toml` 确定 MCP 提供商（ace-tool 或 auggie），然后使用对应的工具。
|
||||
|
||||
### Phase 1: 测试分析
|
||||
|
||||
1. **调用代码检索工具**:
|
||||
- 根据 `~/.ccg/config.toml` 中 `[mcp.tools] code_search_{provider}` 调用对应工具
|
||||
- 参数：`project_root_path`（项目根目录）, 查询参数使用配置中 `query_param_{provider}` 对应的名称
|
||||
- 查询参数名使用 `query_param_{provider}` 的值（"query" 或 "information_request"）
|
||||
2. 识别代码类型：前端组件 / 后端逻辑 / 全栈
|
||||
3. 评估当前测试覆盖率和缺口
|
||||
|
||||
### Phase 2: 智能路由测试生成
|
||||
|
||||
根据代码类型选择路由：
|
||||
|
||||
**注意**：调用前先读取对应角色提示词文件，将内容注入到 `<ROLE>` 标签中。
|
||||
|
||||
#### Route A: 后端代码 → Codex
|
||||
```bash
|
||||
codeagent-wrapper --backend codex - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/codex/tester.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Generate tests for: <测试目标>
|
||||
|
||||
Context:
|
||||
<目标代码>
|
||||
<现有测试样例>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Unified Diff Patch for test files ONLY.
|
||||
EOF
|
||||
```
|
||||
|
||||
#### Route B: 前端代码 → Gemini
|
||||
```bash
|
||||
codeagent-wrapper --backend gemini - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/gemini/tester.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Generate tests for: <测试目标>
|
||||
|
||||
Context:
|
||||
<目标代码>
|
||||
<现有测试样例>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Unified Diff Patch for test files ONLY.
|
||||
EOF
|
||||
```
|
||||
|
||||
#### Route C: 全栈 → 并行生成
|
||||
同时启动 Codex (后端测试) + Gemini (前端测试)，使用 `run_in_background: true`
|
||||
|
||||
### Phase 3: 测试整合
|
||||
|
||||
1. 收集模型输出（使用 `TaskOutput`）
|
||||
2. 将 Unified Diff 视为"脏原型"
|
||||
3. Claude 重构：
|
||||
- 统一测试风格
|
||||
- 确保命名一致性
|
||||
- 优化测试结构
|
||||
- 移除冗余测试
|
||||
|
||||
### Phase 4: 测试验证
|
||||
|
||||
1. 运行生成的测试
|
||||
2. 检查测试通过率
|
||||
3. 如有失败，分析原因并修复
|
||||
|
||||
## 输出格式
|
||||
|
||||
```
|
||||
## Phase 1: 测试分析
|
||||
- 目标代码: <文件列表>
|
||||
- 代码类型: [前端/后端/全栈]
|
||||
- 现有测试: <测试文件列表>
|
||||
- 测试框架: [Jest/Pytest/Vitest/...]
|
||||
- 覆盖率缺口: <识别的缺口>
|
||||
|
||||
## Phase 2: 测试生成
|
||||
### [Codex/Gemini] 生成的测试
|
||||
<Unified Diff 摘要>
|
||||
|
||||
## Phase 3: 测试整合
|
||||
<重构后的测试代码>
|
||||
|
||||
## Phase 4: 验证
|
||||
- 测试运行结果: [PASS/FAIL]
|
||||
- 覆盖率变化: X% → Y%
|
||||
|
||||
## 生成的测试文件
|
||||
- <file1.test.ts>
|
||||
- <file2.spec.py>
|
||||
```
|
||||
|
||||
## 测试策略金字塔
|
||||
|
||||
```
|
||||
/\
|
||||
/ \ E2E Tests (少量)
|
||||
/----\
|
||||
/ \ Integration Tests (适量)
|
||||
/--------\
|
||||
/ \ Unit Tests (大量)
|
||||
--------------
|
||||
```
|
||||
|
||||
- **Unit Tests**: 70% - 快速、隔离、聚焦
|
||||
- **Integration Tests**: 20% - 组件交互、API 测试
|
||||
- **E2E Tests**: 10% - 关键用户流程
|
||||
|
||||
## 关键原则
|
||||
|
||||
1. **测试行为，不测试实现** - 关注输入输出，不关注内部细节
|
||||
2. **智能路由** - 后端测试用 Codex，前端测试用 Gemini
|
||||
3. **复用现有模式** - 遵循项目已有的测试风格
|
||||
4. **覆盖优先级** - 先覆盖关键路径和高风险代码
|
||||
@@ -1,180 +0,0 @@
|
||||
---
|
||||
description: UltraThink 深度分析（双模型并行分析 + 综合见解）
|
||||
---
|
||||
|
||||
# /ccg:think - 深度分析
|
||||
|
||||
## Usage
|
||||
`/ccg:think <分析主题>`
|
||||
|
||||
## Context
|
||||
- 分析主题: $ARGUMENTS
|
||||
- 使用双模型进行多角度深度分析
|
||||
- 适用于复杂架构决策、技术选型、问题探索
|
||||
|
||||
## 工作流程
|
||||
|
||||
**注意**: 本命令使用 MCP 代码检索工具。请先读取 `~/.ccg/config.toml` 确定 MCP 提供商（ace-tool 或 auggie），然后使用对应的工具。
|
||||
|
||||
### Phase 1: 上下文收集
|
||||
|
||||
1. **调用代码检索工具**:
|
||||
- 根据 `~/.ccg/config.toml` 中 `[mcp.tools] code_search_{provider}` 调用对应工具
|
||||
- 参数：`project_root_path`（项目根目录）, 查询参数使用配置中 `query_param_{provider}` 对应的名称
|
||||
- 查询参数名使用 `query_param_{provider}` 的值（"query" 或 "information_request"）
|
||||
2. 识别分析范围和关键组件
|
||||
3. 列出已知约束和假设
|
||||
|
||||
### Phase 2: 并行深度分析
|
||||
|
||||
**同时启动（`run_in_background: true`）**：
|
||||
|
||||
**注意**：调用前先读取对应角色提示词文件，将内容注入到 `<ROLE>` 标签中。
|
||||
|
||||
#### Codex 分析（后端/系统视角）
|
||||
```bash
|
||||
codeagent-wrapper --backend codex - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/codex/analyzer.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Deep analysis of: <分析主题>
|
||||
|
||||
Context:
|
||||
<相关代码和架构信息>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Structured analysis report with clear reasoning.
|
||||
EOF
|
||||
```
|
||||
|
||||
#### Gemini 分析（前端/用户视角）
|
||||
```bash
|
||||
codeagent-wrapper --backend gemini - $PROJECT_DIR <<'EOF'
|
||||
<ROLE>
|
||||
读取 prompts/gemini/analyzer.md 的内容并注入
|
||||
</ROLE>
|
||||
|
||||
<TASK>
|
||||
Deep analysis of: <分析主题>
|
||||
|
||||
Context:
|
||||
<相关代码和设计信息>
|
||||
</TASK>
|
||||
|
||||
OUTPUT: Structured analysis report with clear reasoning.
|
||||
EOF
|
||||
```
|
||||
|
||||
### Phase 3: UltraThink 综合
|
||||
|
||||
1. 收集双模型分析报告（使用 `TaskOutput`）
|
||||
2. **交叉验证**：
|
||||
- 识别一致的观点（强信号）
|
||||
- 分析分歧点（需要权衡）
|
||||
- 发现互补的见解
|
||||
3. **综合推理**：
|
||||
- 整合技术和用户视角
|
||||
- 形成统一的分析框架
|
||||
- 生成可行的建议
|
||||
|
||||
### Phase 4: 输出结论
|
||||
|
||||
生成结构化的分析报告，包含清晰的推理过程和可执行的建议。
|
||||
|
||||
## 输出格式
|
||||
|
||||
```
|
||||
## 🧠 深度分析: <分析主题>
|
||||
|
||||
### Phase 1: 上下文
|
||||
- 分析范围: <涉及的模块/文件>
|
||||
- 关键约束: <已知限制>
|
||||
- 假设前提: <假设列表>
|
||||
|
||||
### Phase 2: 双模型分析
|
||||
|
||||
#### Codex 视角（后端/系统）
|
||||
**问题分解**:
|
||||
<分解结果>
|
||||
|
||||
**技术评估**:
|
||||
<评估结果>
|
||||
|
||||
**方案探索**:
|
||||
| 方案 | 优点 | 缺点 | 可行性 |
|
||||
|------|------|------|--------|
|
||||
| A | ... | ... | High |
|
||||
| B | ... | ... | Medium |
|
||||
|
||||
#### Gemini 视角（前端/用户）
|
||||
**用户影响**:
|
||||
<影响分析>
|
||||
|
||||
**设计评估**:
|
||||
<评估结果>
|
||||
|
||||
**实现考量**:
|
||||
<考量点>
|
||||
|
||||
### Phase 3: 综合分析
|
||||
|
||||
#### 一致观点（强信号）
|
||||
1. <双方都认同的点>
|
||||
2. <双方都认同的点>
|
||||
|
||||
#### 分歧点（需权衡）
|
||||
| 议题 | Codex 观点 | Gemini 观点 | 建议 |
|
||||
|------|------------|-------------|------|
|
||||
| ... | ... | ... | ... |
|
||||
|
||||
#### 互补见解
|
||||
- Codex 补充: <技术深度>
|
||||
- Gemini 补充: <用户视角>
|
||||
|
||||
### Phase 4: 结论与建议
|
||||
|
||||
#### 核心结论
|
||||
<1-2 句话总结>
|
||||
|
||||
#### 推荐方案
|
||||
**首选**: <方案描述>
|
||||
- 理由: <为什么选择>
|
||||
- 风险: <潜在风险>
|
||||
- 缓解: <如何应对>
|
||||
|
||||
#### 行动计划
|
||||
1. [ ] <短期行动>
|
||||
2. [ ] <中期行动>
|
||||
3. [ ] <长期行动>
|
||||
|
||||
#### 待确认事项
|
||||
- <需要进一步调研的问题>
|
||||
- <需要用户决策的事项>
|
||||
```
|
||||
|
||||
## 适用场景
|
||||
|
||||
| 场景 | 示例 |
|
||||
|------|------|
|
||||
| 架构决策 | "评估微服务拆分方案" |
|
||||
| 技术选型 | "比较 Redux vs Zustand" |
|
||||
| 性能分析 | "分析页面加载慢的原因" |
|
||||
| 重构评估 | "评估重构遗留模块的风险" |
|
||||
| 问题探索 | "为什么用户流失率高" |
|
||||
|
||||
## 分析质量标准
|
||||
|
||||
- [ ] 问题被充分分解
|
||||
- [ ] 多角度视角覆盖
|
||||
- [ ] Trade-off 明确列出
|
||||
- [ ] 结论有证据支撑
|
||||
- [ ] 行动项可执行
|
||||
|
||||
## 关键原则
|
||||
|
||||
1. **不急于结论** - 充分收集和分析后再下结论
|
||||
2. **多视角思考** - 技术 + 用户 + 业务
|
||||
3. **量化权衡** - 尽可能用数据支撑判断
|
||||
4. **可执行导向** - 分析结果要能指导行动
|
||||
@@ -1,276 +0,0 @@
|
||||
---
|
||||
description: 管理 Git worktree，在项目平级的 ../.ccg/项目名/ 目录下创建，支持智能默认、IDE 集成和内容迁移
|
||||
allowed-tools: Read(**), Exec(git worktree add, git worktree list, git worktree remove, git worktree prune, git branch, git checkout, git rev-parse, git stash, git cp, detect-ide, open-ide, which, command, basename, dirname)
|
||||
argument-hint: <add|list|remove|prune|migrate> [path] [-b <branch>] [-o|--open] [--track] [--guess-remote] [--detach] [--checkout] [--lock] [--migrate-from <source-path>] [--migrate-stash]
|
||||
# examples:
|
||||
# - /git-worktree add feature-ui # 从 main/master 创建新分支 'feature-ui'
|
||||
# - /git-worktree add feature-ui -o # 创建 worktree 并直接用 IDE 打开
|
||||
# - /git-worktree add hotfix -b fix/login -o # 创建新分支 'fix/login'，路径为 'hotfix'
|
||||
# - /git-worktree migrate feature-ui --from main # 将主分支未提交内容迁移到 feature-ui
|
||||
# - /git-worktree migrate feature-ui --stash # 将当前 stash 迁移到 feature-ui
|
||||
---
|
||||
|
||||
# Claude Command: Git Worktree
|
||||
|
||||
管理 Git worktree，支持智能默认、IDE 集成和内容迁移，使用结构化的 `../.ccg/项目名/` 路径。
|
||||
|
||||
直接执行命令并提供简洁结果。
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
# 基本操作
|
||||
/git-worktree add <path> # 从 main/master 创建名为 <path> 的新分支
|
||||
/git-worktree add <path> -b <branch> # 创建指定名称的新分支
|
||||
/git-worktree add <path> -o # 创建并直接用 IDE 打开
|
||||
/git-worktree list # 显示所有 worktree 状态
|
||||
/git-worktree remove <path> # 删除指定的 worktree
|
||||
/git-worktree prune # 清理无效 worktree 记录
|
||||
|
||||
# 内容迁移
|
||||
/git-worktree migrate <target> --from <source> # 迁移未提交内容
|
||||
/git-worktree migrate <target> --stash # 迁移 stash 内容
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
| 选项 | 说明 |
|
||||
| ------------------ | -------------------------------------------- |
|
||||
| `add [<path>]` | 在 `../.ccg/项目名/<path>` 添加新的 worktree |
|
||||
| `migrate <target>` | 迁移内容到指定 worktree |
|
||||
| `list` | 列出所有 worktree 及其状态 |
|
||||
| `remove <path>` | 删除指定路径的 worktree |
|
||||
| `prune` | 清理无效的 worktree 引用 |
|
||||
| `-b <branch>` | 创建新分支并检出到 worktree |
|
||||
| `-o, --open` | 创建成功后直接用 IDE 打开（跳过询问） |
|
||||
| `--from <source>` | 指定迁移源路径（migrate 专用） |
|
||||
| `--stash` | 迁移当前 stash 内容（migrate 专用） |
|
||||
| `--track` | 设置新分支跟踪对应的远程分支 |
|
||||
| `--guess-remote` | 自动猜测远程分支进行跟踪 |
|
||||
| `--detach` | 创建分离 HEAD 的 worktree |
|
||||
| `--checkout` | 创建后立即检出（默认行为） |
|
||||
| `--lock` | 创建后锁定 worktree |
|
||||
|
||||
---
|
||||
|
||||
## What This Command Does
|
||||
|
||||
1. **环境检查**
|
||||
- 通过 `git rev-parse --is-inside-work-tree` 验证 Git 仓库
|
||||
- 检测是否在主仓库或现有 worktree 中，进行智能路径计算
|
||||
|
||||
2. **智能路径管理**
|
||||
- 使用 worktree 检测自动从主仓库路径计算项目名
|
||||
- 在结构化的 `../.ccg/项目名/<path>` 目录创建 worktree
|
||||
- 正确处理主仓库和 worktree 执行上下文
|
||||
|
||||
```bash
|
||||
# worktree 检测的核心路径计算逻辑
|
||||
get_main_repo_path() {
|
||||
local git_common_dir=$(git rev-parse --git-common-dir 2>/dev/null)
|
||||
local current_toplevel=$(git rev-parse --show-toplevel 2>/dev/null)
|
||||
|
||||
# 检测是否在 worktree 中
|
||||
if [[ "$git_common_dir" != "$current_toplevel/.git" ]]; then
|
||||
# 在 worktree 中，从 git-common-dir 推导主仓库路径
|
||||
dirname "$git_common_dir"
|
||||
else
|
||||
# 在主仓库中
|
||||
echo "$current_toplevel"
|
||||
fi
|
||||
}
|
||||
|
||||
MAIN_REPO_PATH=$(get_main_repo_path)
|
||||
PROJECT_NAME=$(basename "$MAIN_REPO_PATH")
|
||||
WORKTREE_BASE="$MAIN_REPO_PATH/../.ccg/$PROJECT_NAME"
|
||||
|
||||
# 始终使用绝对路径防止嵌套问题
|
||||
ABSOLUTE_WORKTREE_PATH="$WORKTREE_BASE/<path>"
|
||||
```
|
||||
|
||||
**关键修复**: 在现有 worktree 内创建新 worktree 时，始终使用绝对路径以防止出现类似 `../.ccg/project/.ccg/project/path` 的路径嵌套问题。
|
||||
|
||||
3. **Worktree 操作**
|
||||
- **add**: 使用智能分支/路径默认创建新 worktree
|
||||
- **list**: 显示所有 worktree 的分支和状态
|
||||
- **remove**: 安全删除 worktree 并清理引用
|
||||
- **prune**: 清理孤立的 worktree 记录
|
||||
|
||||
4. **智能默认**
|
||||
- **分支创建**: 未指定 `-b` 时，使用路径名创建新分支
|
||||
- **基础分支**: 新分支从 main/master 分支创建
|
||||
- **路径解析**: 未指定路径时使用分支名作为路径
|
||||
- **IDE 集成**: 自动检测并提示 IDE 打开
|
||||
|
||||
5. **内容迁移**
|
||||
- 在 worktree 之间迁移未提交改动
|
||||
- 将 stash 内容应用到目标 worktree
|
||||
- 安全检查防止冲突
|
||||
|
||||
6. **安全特性**
|
||||
- **路径冲突防护**: 创建前检查目录是否已存在
|
||||
- **分支检出验证**: 确保分支未被其他地方使用
|
||||
- **绝对路径强制**: 防止在 worktree 内创建嵌套的 `.ccg` 目录
|
||||
- **删除时自动清理**: 同时清理目录和 git 引用
|
||||
- **清晰的状态报告**: 显示 worktree 位置和分支状态
|
||||
|
||||
7. **环境文件处理**
|
||||
- **自动检测**: 扫描 `.gitignore` 文件中的环境变量文件模式
|
||||
- **智能复制**: 复制 `.gitignore` 中列出的 `.env` 和 `.env.*` 文件
|
||||
- **排除逻辑**: 跳过 `.env.example` 等模板文件
|
||||
- **权限保护**: 保持原始文件权限和时间戳
|
||||
- **用户反馈**: 提供已复制环境文件的清晰状态信息
|
||||
|
||||
```bash
|
||||
# 环境文件复制实现
|
||||
copy_environment_files() {
|
||||
local main_repo="$MAIN_REPO_PATH"
|
||||
local target_worktree="$ABSOLUTE_WORKTREE_PATH"
|
||||
local gitignore_file="$main_repo/.gitignore"
|
||||
|
||||
# 检查 .gitignore 是否存在
|
||||
if [[ ! -f "$gitignore_file" ]]; then
|
||||
return 0
|
||||
fi
|
||||
|
||||
local copied_count=0
|
||||
|
||||
# 检测 .env 文件
|
||||
if [[ -f "$main_repo/.env" ]] && grep -q "^\.env$" "$gitignore_file"; then
|
||||
cp "$main_repo/.env" "$target_worktree/.env"
|
||||
echo "✅ 已复制 .env"
|
||||
((copied_count++))
|
||||
fi
|
||||
|
||||
# 检测 .env.* 模式文件（排除 .env.example）
|
||||
for env_file in "$main_repo"/.env.*; do
|
||||
if [[ -f "$env_file" ]] && [[ "$(basename "$env_file")" != ".env.example" ]]; then
|
||||
local filename=$(basename "$env_file")
|
||||
if grep -q "^\.env\.\*$" "$gitignore_file"; then
|
||||
cp "$env_file" "$target_worktree/$filename"
|
||||
echo "✅ 已复制 $filename"
|
||||
((copied_count++))
|
||||
fi
|
||||
fi
|
||||
done
|
||||
|
||||
if [[ $copied_count -gt 0 ]]; then
|
||||
echo "📋 已从 .gitignore 复制 $copied_count 个环境文件"
|
||||
fi
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Enhanced Features
|
||||
|
||||
### IDE 集成
|
||||
|
||||
- **自动检测**: VS Code → Cursor → WebStorm → Sublime Text → Vim
|
||||
- **智能提示**: 创建 worktree 后询问是否在 IDE 中打开
|
||||
- **直接打开**: 使用 `-o` 标志跳过提示直接打开
|
||||
- **自定义配置**: 通过 git config 配置
|
||||
|
||||
### 内容迁移系统
|
||||
|
||||
```bash
|
||||
# 迁移未提交改动
|
||||
/git-worktree migrate feature-ui --from main
|
||||
/git-worktree migrate hotfix --from ../other-worktree
|
||||
|
||||
# 迁移 stash 内容
|
||||
/git-worktree migrate feature-ui --stash
|
||||
```
|
||||
|
||||
**迁移流程**:
|
||||
|
||||
1. 验证源有未提交内容
|
||||
2. 确保目标 worktree 干净
|
||||
3. 显示即将迁移的改动
|
||||
4. 使用 git 命令安全迁移
|
||||
5. 确认结果并建议后续步骤
|
||||
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
```bash
|
||||
# 基本用法
|
||||
/git-worktree add feature-ui # 从 main/master 创建新分支 'feature-ui'
|
||||
/git-worktree add feature-ui -b my-feature # 创建新分支 'my-feature'，路径为 'feature-ui'
|
||||
/git-worktree add feature-ui -o # 创建并直接用 IDE 打开
|
||||
|
||||
# 内容迁移场景
|
||||
/git-worktree add feature-ui -b feature/new-ui # 创建新功能 worktree
|
||||
/git-worktree migrate feature-ui --from main # 迁移未提交改动
|
||||
/git-worktree migrate hotfix --stash # 迁移 stash 内容
|
||||
|
||||
# 管理操作
|
||||
/git-worktree list # 查看所有 worktree
|
||||
/git-worktree remove feature-ui # 删除不需要的 worktree
|
||||
/git-worktree prune # 清理无效引用
|
||||
```
|
||||
|
||||
**示例输出**:
|
||||
|
||||
```
|
||||
✅ Worktree created at ../.ccg/项目名/feature-ui
|
||||
✅ 已复制 .env
|
||||
✅ 已复制 .env.local
|
||||
📋 已从 .gitignore 复制 2 个环境文件
|
||||
🖥️ 是否在 IDE 中打开 ../.ccg/项目名/feature-ui？[y/n]: y
|
||||
🚀 正在用 VS Code 打开 ../.ccg/项目名/feature-ui...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Directory Structure
|
||||
|
||||
```
|
||||
parent-directory/
|
||||
├── your-project/ # 主项目
|
||||
│ ├── .git/
|
||||
│ └── src/
|
||||
└── .ccg/ # worktree 管理
|
||||
└── your-project/ # 项目 worktree
|
||||
├── feature-ui/ # 功能分支
|
||||
├── hotfix/ # 修复分支
|
||||
└── debug/ # 调试 worktree
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Configuration
|
||||
|
||||
### IDE 配置
|
||||
|
||||
- 支持 VS Code、Cursor、WebStorm、Sublime Text、Vim
|
||||
- 通过 git config 配置自定义 IDE
|
||||
- 基于优先级的自动检测选择
|
||||
|
||||
### 自定义 IDE 设置
|
||||
|
||||
```bash
|
||||
# 配置自定义 IDE
|
||||
git config worktree.ide.custom.sublime "subl %s"
|
||||
git config worktree.ide.preferred "sublime"
|
||||
|
||||
# 控制自动检测
|
||||
git config worktree.ide.autodetect true # 默认
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- **性能**: worktree 共享 `.git` 目录，节省磁盘空间
|
||||
- **安全**: 路径冲突防护和分支检出验证
|
||||
- **迁移**: 仅限未提交改动；已提交内容需使用 `git cherry-pick`
|
||||
- **IDE 要求**: 命令行工具必须在 PATH 中
|
||||
- **跨平台**: 支持 Windows、macOS、Linux
|
||||
- **环境文件**: 自动复制 `.gitignore` 中列出的环境文件到新 worktree
|
||||
- **文件排除**: 模板文件如 `.env.example` 仅保留在主仓库中
|
||||
|
||||
---
|
||||
-841
@@ -1,841 +0,0 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
Skills-v2 安装器
|
||||
Claude Code 多模型协作系统
|
||||
|
||||
用法:
|
||||
python install.py # 安装核心模块（默认）
|
||||
python install.py --module core # 安装核心模块
|
||||
python install.py --module all # 安装所有启用的模块
|
||||
python install.py --list-modules # 列出可用模块
|
||||
python install.py --install-dir ~/.claude # 自定义安装目录
|
||||
"""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
import argparse
|
||||
import json
|
||||
import os
|
||||
import platform
|
||||
import shutil
|
||||
import subprocess
|
||||
import sys
|
||||
from pathlib import Path
|
||||
from typing import Any, Dict, List, Optional, Tuple
|
||||
|
||||
DEFAULT_INSTALL_DIR = "~/.claude"
|
||||
DEFAULT_CONFIG = "config.json"
|
||||
|
||||
# 检测操作系统
|
||||
IS_WINDOWS = platform.system() == "Windows"
|
||||
|
||||
|
||||
def parse_args() -> argparse.Namespace:
|
||||
parser = argparse.ArgumentParser(
|
||||
description="Skills-v2 安装器 - 多模型协作系统"
|
||||
)
|
||||
parser.add_argument(
|
||||
"--install-dir",
|
||||
default=DEFAULT_INSTALL_DIR,
|
||||
help=f"安装目录（默认: {DEFAULT_INSTALL_DIR}）",
|
||||
)
|
||||
parser.add_argument(
|
||||
"--module",
|
||||
default="core",
|
||||
help="要安装的模块: 'core', 'codex-only', 'gemini-only', 或 'all'",
|
||||
)
|
||||
parser.add_argument(
|
||||
"--config",
|
||||
default=DEFAULT_CONFIG,
|
||||
help="配置文件路径",
|
||||
)
|
||||
parser.add_argument(
|
||||
"--list-modules",
|
||||
action="store_true",
|
||||
help="列出可用模块并退出",
|
||||
)
|
||||
parser.add_argument(
|
||||
"--force",
|
||||
action="store_true",
|
||||
help="强制覆盖现有文件",
|
||||
)
|
||||
parser.add_argument(
|
||||
"--verbose", "-v",
|
||||
action="store_true",
|
||||
help="显示详细输出",
|
||||
)
|
||||
return parser.parse_args()
|
||||
|
||||
|
||||
def load_config(config_path: str) -> Dict[str, Any]:
|
||||
path = Path(config_path)
|
||||
if not path.exists():
|
||||
print(f"错误: 配置文件未找到: {config_path}", file=sys.stderr)
|
||||
sys.exit(1)
|
||||
|
||||
with path.open("r", encoding="utf-8") as f:
|
||||
return json.load(f)
|
||||
|
||||
|
||||
def list_modules(config: Dict[str, Any]) -> None:
|
||||
print("\n📦 可用模块:\n")
|
||||
modules = config.get("modules", {})
|
||||
for name, module in modules.items():
|
||||
status = "✅ 已启用" if module.get("enabled", False) else "⚪ 未启用"
|
||||
desc = module.get("description", "无描述")
|
||||
print(f" {name:15} {status:12} - {desc}")
|
||||
print()
|
||||
|
||||
|
||||
def ensure_dir(path: Path) -> None:
|
||||
path.mkdir(parents=True, exist_ok=True)
|
||||
|
||||
|
||||
def copy_file(src: Path, dst: Path, verbose: bool = False) -> None:
|
||||
ensure_dir(dst.parent)
|
||||
shutil.copy2(src, dst)
|
||||
if verbose:
|
||||
print(f" 📄 已复制: {src.name} -> {dst}")
|
||||
|
||||
|
||||
def copy_dir(src: Path, dst: Path, verbose: bool = False) -> None:
|
||||
if dst.exists():
|
||||
shutil.rmtree(dst)
|
||||
shutil.copytree(src, dst)
|
||||
if verbose:
|
||||
print(f" 📁 已复制目录: {src.name} -> {dst}")
|
||||
|
||||
|
||||
def merge_dir(src: Path, dst: Path, verbose: bool = False) -> None:
|
||||
ensure_dir(dst)
|
||||
for item in src.iterdir():
|
||||
dst_item = dst / item.name
|
||||
if item.is_file():
|
||||
shutil.copy2(item, dst_item)
|
||||
if verbose:
|
||||
print(f" 📄 已合并: {item.name}")
|
||||
elif item.is_dir():
|
||||
if dst_item.exists():
|
||||
merge_dir(item, dst_item, verbose)
|
||||
else:
|
||||
shutil.copytree(item, dst_item)
|
||||
if verbose:
|
||||
print(f" 📁 已合并目录: {item.name}")
|
||||
|
||||
|
||||
def check_go_installed() -> bool:
|
||||
try:
|
||||
result = subprocess.run(
|
||||
["go", "version"],
|
||||
capture_output=True,
|
||||
text=True
|
||||
)
|
||||
return result.returncode == 0
|
||||
except FileNotFoundError:
|
||||
return False
|
||||
|
||||
|
||||
def check_npm_installed() -> bool:
|
||||
"""检查 npm 是否已安装"""
|
||||
try:
|
||||
result = subprocess.run(
|
||||
["npm", "--version"],
|
||||
capture_output=True,
|
||||
text=True
|
||||
)
|
||||
return result.returncode == 0
|
||||
except FileNotFoundError:
|
||||
return False
|
||||
|
||||
|
||||
def choose_mcp_provider() -> Optional[str]:
|
||||
"""
|
||||
让用户选择 MCP 提供商
|
||||
返回: "ace-tool" | "auggie" | None (跳过)
|
||||
"""
|
||||
print("\n" + "=" * 60)
|
||||
print("🔧 MCP 代码检索工具选择")
|
||||
print("=" * 60)
|
||||
print("\n请选择要安装的 MCP 工具：\n")
|
||||
|
||||
print(" [1] ace-tool (推荐)")
|
||||
print(" • 第三方封装版本，使用更简单")
|
||||
print(" • ✅ 内置 Prompt 增强工具 (enhance_prompt)")
|
||||
print(" • ✅ 代码库上下文检索 (search_context)")
|
||||
print(" • 需要注册获取 API Token: https://augmentcode.com/")
|
||||
print()
|
||||
|
||||
print(" [2] auggie (官方原版)")
|
||||
print(" • Augment 官方 MCP (@augmentcode/auggie)")
|
||||
print(" • ⚠️ 不包含 Prompt 增强工具")
|
||||
print(" • ✅ 代码库上下文检索 (codebase-retrieval)")
|
||||
print(" • 📖 配置说明: https://linux.do/t/topic/1280612")
|
||||
print()
|
||||
|
||||
print(" [0] 跳过 MCP 安装 (稍后手动配置)")
|
||||
print()
|
||||
|
||||
while True:
|
||||
choice = input("请输入选项 [1/2/0]: ").strip()
|
||||
if choice == "1":
|
||||
return "ace-tool"
|
||||
elif choice == "2":
|
||||
return "auggie"
|
||||
elif choice == "0":
|
||||
print(" ℹ️ 跳过 MCP 安装，稍后可手动配置")
|
||||
return None
|
||||
else:
|
||||
print(" ❌ 无效选项，请输入 1、2 或 0")
|
||||
|
||||
|
||||
def install_ace_tool(verbose: bool = False) -> Tuple[bool, str]:
|
||||
"""
|
||||
安装并配置 ace-tool MCP
|
||||
返回 (成功, 消息)
|
||||
|
||||
重要: Claude Code CLI 从 ~/.claude.json 读取 MCP 配置
|
||||
NOT ~/.mcp.json (那是给 Claude Desktop 的)
|
||||
NOT ~/Library/Application Support/Claude/ (那也是 Claude Desktop)
|
||||
"""
|
||||
print("\n 🔧 配置 ace-tool MCP...")
|
||||
|
||||
# 检查 npm
|
||||
if not check_npm_installed():
|
||||
return False, "npm 未安装，请先安装 Node.js: https://nodejs.org/"
|
||||
|
||||
# 提示用户配置
|
||||
print("\n 📋 ace-tool 需要配置 API 访问信息:")
|
||||
print(" 获取方式: 访问 https://augmentcode.com/ 注册并获取 API Token")
|
||||
print()
|
||||
|
||||
# 获取 base-url
|
||||
default_base_url = "https://api.augmentcode.com"
|
||||
base_url = input(f" 请输入 Base URL (直接回车使用默认值 {default_base_url}): ").strip()
|
||||
if not base_url:
|
||||
base_url = default_base_url
|
||||
|
||||
# 获取 token
|
||||
token = input(" 请输入 API Token: ").strip()
|
||||
if not token:
|
||||
print(" ⚠️ Token 为空，稍后可手动配置")
|
||||
token = ""
|
||||
|
||||
# Claude Code CLI 的配置文件路径: ~/.claude.json
|
||||
config_file = Path.home() / ".claude.json"
|
||||
|
||||
# 读取现有配置（重要：保留所有其他字段！）
|
||||
existing_config = {}
|
||||
if config_file.exists():
|
||||
try:
|
||||
with config_file.open("r", encoding="utf-8") as f:
|
||||
existing_config = json.load(f)
|
||||
except json.JSONDecodeError as e:
|
||||
print(f" ⚠️ ~/.claude.json 解析失败: {e}")
|
||||
print(" ⚠️ 请检查文件格式，跳过 MCP 配置")
|
||||
return False, f"~/.claude.json 解析失败: {e}"
|
||||
except Exception as e:
|
||||
print(f" ⚠️ 读取 ~/.claude.json 失败: {e}")
|
||||
return False, f"读取配置失败: {e}"
|
||||
|
||||
# 确保 mcpServers 字段存在
|
||||
if "mcpServers" not in existing_config:
|
||||
existing_config["mcpServers"] = {}
|
||||
|
||||
# 添加或更新 ace-tool 配置（使用环境变量方式，更安全）
|
||||
existing_config["mcpServers"]["ace-tool"] = {
|
||||
"type": "stdio",
|
||||
"command": "npx",
|
||||
"args": ["-y", "ace-tool@latest"],
|
||||
"env": {
|
||||
"ACE_BASE_URL": base_url,
|
||||
"ACE_TOKEN": token
|
||||
}
|
||||
}
|
||||
|
||||
# 写入配置（保留所有其他字段）
|
||||
try:
|
||||
with config_file.open("w", encoding="utf-8") as f:
|
||||
json.dump(existing_config, f, indent=2, ensure_ascii=False)
|
||||
if verbose:
|
||||
print(f" 📄 已写入配置: {config_file}")
|
||||
except Exception as e:
|
||||
return False, f"写入配置失败: {e}"
|
||||
|
||||
# 测试安装
|
||||
print("\n 🚀 验证 ace-tool 安装...")
|
||||
try:
|
||||
result = subprocess.run(
|
||||
["npx", "-y", "ace-tool@latest", "--version"],
|
||||
capture_output=True,
|
||||
text=True,
|
||||
timeout=60
|
||||
)
|
||||
if result.returncode == 0:
|
||||
version = result.stdout.strip() or "unknown"
|
||||
if verbose:
|
||||
print(f" ✅ ace-tool 版本: {version}")
|
||||
else:
|
||||
if verbose:
|
||||
print(f" ⚠️ ace-tool 验证失败，但配置已保存")
|
||||
except subprocess.TimeoutExpired:
|
||||
print(" ⚠️ 验证超时，但配置已保存")
|
||||
except Exception as e:
|
||||
if verbose:
|
||||
print(f" ⚠️ 验证异常: {e}")
|
||||
|
||||
return True, f"ace-tool MCP 配置完成: {config_file}"
|
||||
|
||||
|
||||
def install_auggie(verbose: bool = False) -> Tuple[bool, str]:
|
||||
"""
|
||||
安装并配置 auggie MCP (Augment 官方版本)
|
||||
返回 (成功, 消息)
|
||||
"""
|
||||
print("\n 🔧 配置 auggie MCP...")
|
||||
|
||||
# 检查 npm
|
||||
if not check_npm_installed():
|
||||
return False, "npm 未安装，请先安装 Node.js: https://nodejs.org/"
|
||||
|
||||
# 提示用户配置说明
|
||||
print("\n 📖 auggie 配置说明:")
|
||||
print(" 详细配置教程: https://linux.do/t/topic/1280612")
|
||||
print(" 获取 API Token: 访问 https://augmentcode.com/ 注册")
|
||||
print()
|
||||
print(" ⚠️ 注意: auggie 不包含 Prompt 增强工具")
|
||||
print(" 如需使用 Prompt 增强，请查看上述教程手动配置")
|
||||
print()
|
||||
|
||||
# 安装 auggie
|
||||
print(" 🚀 安装 @augmentcode/auggie@prerelease...")
|
||||
try:
|
||||
result = subprocess.run(
|
||||
["npm", "install", "-g", "@augmentcode/auggie@prerelease"],
|
||||
capture_output=True,
|
||||
text=True,
|
||||
timeout=120
|
||||
)
|
||||
if result.returncode != 0:
|
||||
return False, f"npm 安装失败: {result.stderr}"
|
||||
if verbose:
|
||||
print(f" ✅ auggie 安装成功")
|
||||
except subprocess.TimeoutExpired:
|
||||
return False, "安装超时"
|
||||
except Exception as e:
|
||||
return False, f"安装异常: {e}"
|
||||
|
||||
# 获取 token
|
||||
print("\n 请输入 API Token (从 https://augmentcode.com/ 获取):")
|
||||
token = input(" Token: ").strip()
|
||||
if not token:
|
||||
print(" ⚠️ Token 为空，稍后可手动配置")
|
||||
token = ""
|
||||
|
||||
# Claude Code CLI 的配置文件路径: ~/.claude.json
|
||||
config_file = Path.home() / ".claude.json"
|
||||
|
||||
# 读取现有配置
|
||||
existing_config = {}
|
||||
if config_file.exists():
|
||||
try:
|
||||
with config_file.open("r", encoding="utf-8") as f:
|
||||
existing_config = json.load(f)
|
||||
except json.JSONDecodeError as e:
|
||||
print(f" ⚠️ ~/.claude.json 解析失败: {e}")
|
||||
return False, f"~/.claude.json 解析失败: {e}"
|
||||
except Exception as e:
|
||||
print(f" ⚠️ 读取 ~/.claude.json 失败: {e}")
|
||||
return False, f"读取配置失败: {e}"
|
||||
|
||||
# 确保 mcpServers 字段存在
|
||||
if "mcpServers" not in existing_config:
|
||||
existing_config["mcpServers"] = {}
|
||||
|
||||
# 添加或更新 auggie 配置
|
||||
existing_config["mcpServers"]["auggie-mcp"] = {
|
||||
"type": "stdio",
|
||||
"command": "auggie",
|
||||
"env": {
|
||||
"AUGMENT_API_KEY": token
|
||||
}
|
||||
}
|
||||
|
||||
# 写入配置
|
||||
try:
|
||||
with config_file.open("w", encoding="utf-8") as f:
|
||||
json.dump(existing_config, f, indent=2, ensure_ascii=False)
|
||||
if verbose:
|
||||
print(f" 📄 已写入配置: {config_file}")
|
||||
except Exception as e:
|
||||
return False, f"写入配置失败: {e}"
|
||||
|
||||
print("\n ✅ auggie MCP 配置完成")
|
||||
print(f" 📖 详细配置说明: https://linux.do/t/topic/1280612")
|
||||
|
||||
return True, f"auggie MCP 配置完成: {config_file}"
|
||||
|
||||
|
||||
def create_ccg_config(mcp_provider: str, install_dir: Path, verbose: bool = False) -> bool:
|
||||
"""
|
||||
创建 ~/.ccg/config.toml 配置文件
|
||||
|
||||
Args:
|
||||
mcp_provider: "ace-tool" | "auggie" | "none"
|
||||
install_dir: 安装目录 (通常是 ~/.claude)
|
||||
verbose: 详细输出
|
||||
|
||||
Returns:
|
||||
成功与否
|
||||
"""
|
||||
ccg_dir = Path.home() / ".ccg"
|
||||
config_file = ccg_dir / "config.toml"
|
||||
|
||||
# 确保目录存在
|
||||
ensure_dir(ccg_dir)
|
||||
|
||||
# 生成配置内容
|
||||
config_content = f"""# CCG (Claude + Codex + Gemini) 多模型协作系统配置
|
||||
# 生成时间: {subprocess.run(['date'], capture_output=True, text=True).stdout.strip()}
|
||||
|
||||
[mcp]
|
||||
# MCP 提供商: ace-tool | auggie | none
|
||||
provider = "{mcp_provider}"
|
||||
|
||||
[mcp.tools]
|
||||
# 工具名称映射（命令模板会自动读取此配置）
|
||||
# 代码检索工具
|
||||
code_search_ace = "mcp__ace-tool__search_context"
|
||||
code_search_auggie = "mcp__auggie-mcp__codebase-retrieval"
|
||||
|
||||
# Prompt 增强工具
|
||||
prompt_enhance_ace = "mcp__ace-tool__enhance_prompt"
|
||||
prompt_enhance_auggie = "" # auggie 不支持
|
||||
|
||||
# 参数名称映射
|
||||
query_param_ace = "query"
|
||||
query_param_auggie = "information_request"
|
||||
|
||||
[mcp.ace-tool]
|
||||
# ace-tool (第三方封装) 功能说明
|
||||
features = ["Prompt 增强", "代码检索"]
|
||||
setup_url = "https://augmentcode.com/"
|
||||
|
||||
[mcp.auggie]
|
||||
# auggie (官方原版) 功能说明
|
||||
features = ["代码检索"]
|
||||
setup_url = "https://linux.do/t/topic/1280612"
|
||||
note = "auggie 不包含 Prompt 增强工具，需手动配置"
|
||||
|
||||
[routing]
|
||||
# 路由模式: smart | parallel | sequential
|
||||
mode = "smart"
|
||||
|
||||
[routing.frontend]
|
||||
# 前端任务路由配置
|
||||
models = ["gemini", "codex"]
|
||||
primary = "gemini"
|
||||
strategy = "parallel"
|
||||
|
||||
[routing.backend]
|
||||
# 后端任务路由配置
|
||||
models = ["codex", "gemini"]
|
||||
primary = "codex"
|
||||
strategy = "parallel"
|
||||
|
||||
[routing.review]
|
||||
# 代码审查路由配置
|
||||
models = ["codex", "gemini"]
|
||||
strategy = "parallel"
|
||||
"""
|
||||
|
||||
try:
|
||||
with config_file.open("w", encoding="utf-8") as f:
|
||||
f.write(config_content)
|
||||
if verbose:
|
||||
print(f" 📄 已创建配置: {config_file}")
|
||||
return True
|
||||
except Exception as e:
|
||||
print(f" ⚠️ 创建配置失败: {e}", file=sys.stderr)
|
||||
return False
|
||||
|
||||
|
||||
def get_prebuilt_binary(source_dir: Path) -> Optional[Path]:
|
||||
"""查找预编译的二进制文件"""
|
||||
system = platform.system().lower()
|
||||
machine = platform.machine().lower()
|
||||
|
||||
# 映射架构名称
|
||||
arch_map = {
|
||||
"x86_64": "amd64",
|
||||
"amd64": "amd64",
|
||||
"arm64": "arm64",
|
||||
"aarch64": "arm64",
|
||||
}
|
||||
arch = arch_map.get(machine, machine)
|
||||
|
||||
# 映射系统名称
|
||||
if system == "darwin":
|
||||
binary_name = f"codeagent-wrapper-darwin-{arch}"
|
||||
elif system == "linux":
|
||||
binary_name = f"codeagent-wrapper-linux-{arch}"
|
||||
elif system == "windows":
|
||||
binary_name = f"codeagent-wrapper-windows-{arch}.exe"
|
||||
else:
|
||||
return None
|
||||
|
||||
binary_path = source_dir / "bin" / binary_name
|
||||
if binary_path.exists():
|
||||
return binary_path
|
||||
return None
|
||||
|
||||
|
||||
def build_go_binary(
|
||||
source_dir: Path,
|
||||
binary_name: str,
|
||||
verbose: bool = False
|
||||
) -> Tuple[bool, Optional[Path]]:
|
||||
if not check_go_installed():
|
||||
print(" ❌ Go 未安装，请先安装 Go:", file=sys.stderr)
|
||||
print(" https://go.dev/doc/install", file=sys.stderr)
|
||||
return False, None
|
||||
|
||||
# Windows 添加 .exe 扩展名
|
||||
if IS_WINDOWS and not binary_name.endswith(".exe"):
|
||||
output_name = binary_name + ".exe"
|
||||
else:
|
||||
output_name = binary_name
|
||||
|
||||
if verbose:
|
||||
print(f" 🔨 正在编译 {output_name}...")
|
||||
|
||||
try:
|
||||
result = subprocess.run(
|
||||
["go", "build", "-o", output_name, "."],
|
||||
cwd=source_dir,
|
||||
capture_output=True,
|
||||
text=True
|
||||
)
|
||||
|
||||
if result.returncode != 0:
|
||||
print(f" ❌ 编译失败: {result.stderr}", file=sys.stderr)
|
||||
return False, None
|
||||
|
||||
binary_path = source_dir / output_name
|
||||
if not binary_path.exists():
|
||||
print(f" ❌ 编译后未找到二进制文件", file=sys.stderr)
|
||||
return False, None
|
||||
|
||||
if verbose:
|
||||
print(f" ✅ 编译完成: {output_name}")
|
||||
|
||||
return True, binary_path
|
||||
|
||||
except Exception as e:
|
||||
print(f" ❌ 编译错误: {e}", file=sys.stderr)
|
||||
return False, None
|
||||
|
||||
|
||||
def install_binary_to_path(
|
||||
binary_path: Path,
|
||||
verbose: bool = False,
|
||||
target_name: Optional[str] = None
|
||||
) -> bool:
|
||||
# 确定目标文件名
|
||||
if target_name:
|
||||
if IS_WINDOWS and not target_name.endswith(".exe"):
|
||||
final_name = target_name + ".exe"
|
||||
else:
|
||||
final_name = target_name
|
||||
else:
|
||||
final_name = binary_path.name
|
||||
|
||||
# 根据系统选择安装目录
|
||||
if IS_WINDOWS:
|
||||
install_dirs = [
|
||||
Path.home() / ".local" / "bin",
|
||||
Path(os.environ.get("LOCALAPPDATA", "")) / "Programs" / "codeagent-wrapper",
|
||||
Path.home() / "bin",
|
||||
]
|
||||
else:
|
||||
install_dirs = [
|
||||
Path.home() / ".local" / "bin",
|
||||
Path("/usr/local/bin"),
|
||||
]
|
||||
|
||||
for install_dir in install_dirs:
|
||||
if install_dir.exists() or install_dir == install_dirs[0]:
|
||||
try:
|
||||
ensure_dir(install_dir)
|
||||
target = install_dir / final_name
|
||||
shutil.copy2(binary_path, target)
|
||||
|
||||
# 设置执行权限（仅 Unix）
|
||||
if not IS_WINDOWS:
|
||||
os.chmod(target, 0o755)
|
||||
|
||||
if verbose:
|
||||
print(f" 📦 已安装到: {target}")
|
||||
|
||||
# 检查安装目录是否在 PATH 中
|
||||
path_dirs = os.environ.get("PATH", "").split(os.pathsep)
|
||||
if str(install_dir) not in path_dirs:
|
||||
print(f" ⚠️ 注意: {install_dir} 可能不在 PATH 中")
|
||||
if IS_WINDOWS:
|
||||
print(f" 添加到 PATH: setx PATH \"%PATH%;{install_dir}\"")
|
||||
else:
|
||||
print(f" 添加到 PATH: export PATH=\"{install_dir}:$PATH\"")
|
||||
|
||||
return True
|
||||
except PermissionError:
|
||||
if verbose:
|
||||
print(f" ⚠️ {install_dir} 权限不足，尝试下一个...")
|
||||
continue
|
||||
except Exception as e:
|
||||
if verbose:
|
||||
print(f" ⚠️ 安装到 {install_dir} 失败: {e}")
|
||||
continue
|
||||
|
||||
print(" ❌ 无法安装二进制文件到 PATH", file=sys.stderr)
|
||||
if IS_WINDOWS:
|
||||
print(f" 手动安装: 复制 {binary_path} 到 PATH 中的目录", file=sys.stderr)
|
||||
else:
|
||||
print(f" 手动安装: sudo cp {binary_path} /usr/local/bin/", file=sys.stderr)
|
||||
return False
|
||||
|
||||
|
||||
def execute_operation(
|
||||
op: Dict[str, Any],
|
||||
source_dir: Path,
|
||||
install_dir: Path,
|
||||
verbose: bool = False
|
||||
) -> bool:
|
||||
op_type = op.get("type")
|
||||
source = op.get("source", "")
|
||||
target = op.get("target", source)
|
||||
desc = op.get("description", "")
|
||||
|
||||
src_path = source_dir / source
|
||||
dst_path = install_dir / target
|
||||
|
||||
if verbose:
|
||||
print(f"\n 🔧 {desc}")
|
||||
|
||||
try:
|
||||
if op_type == "copy_file":
|
||||
if not src_path.exists():
|
||||
print(f" ⚠️ 源文件未找到: {src_path}", file=sys.stderr)
|
||||
return False
|
||||
copy_file(src_path, dst_path, verbose)
|
||||
|
||||
elif op_type == "copy_dir":
|
||||
if not src_path.exists():
|
||||
print(f" ⚠️ 源目录未找到: {src_path}", file=sys.stderr)
|
||||
return False
|
||||
copy_dir(src_path, dst_path, verbose)
|
||||
|
||||
elif op_type == "merge_dir":
|
||||
if not src_path.exists():
|
||||
print(f" ⚠️ 源目录未找到: {src_path}", file=sys.stderr)
|
||||
return False
|
||||
merge_dir(src_path, dst_path, verbose)
|
||||
|
||||
elif op_type == "build_go":
|
||||
binary_name = op.get("binary", "")
|
||||
|
||||
# 优先使用预编译的二进制文件
|
||||
prebuilt = get_prebuilt_binary(source_dir)
|
||||
if prebuilt:
|
||||
if verbose:
|
||||
print(f" 📦 使用预编译二进制: {prebuilt.name}")
|
||||
# 重命名为目标名称
|
||||
target_name = binary_name
|
||||
if IS_WINDOWS and not target_name.endswith(".exe"):
|
||||
target_name += ".exe"
|
||||
binary_path = prebuilt
|
||||
else:
|
||||
# 没有预编译二进制，尝试编译
|
||||
if verbose:
|
||||
print(f" ℹ️ 未找到预编译二进制，尝试编译...")
|
||||
if not src_path.exists():
|
||||
print(f" ⚠️ 源目录未找到: {src_path}", file=sys.stderr)
|
||||
return False
|
||||
|
||||
success, binary_path = build_go_binary(src_path, binary_name, verbose)
|
||||
if not success:
|
||||
return False
|
||||
|
||||
# 安装到 PATH
|
||||
if not install_binary_to_path(binary_path, verbose, target_name=binary_name):
|
||||
return False
|
||||
|
||||
elif op_type == "install_ace_tool":
|
||||
# 兼容旧配置，直接安装 ace-tool
|
||||
success, message = install_ace_tool(verbose)
|
||||
if not success:
|
||||
print(f" ⚠️ {message}")
|
||||
print(f" ℹ️ 可稍后手动配置 ace-tool MCP")
|
||||
return True # 不阻止其他安装
|
||||
if verbose:
|
||||
print(f" ℹ️ {message}")
|
||||
# 创建配置文件
|
||||
create_ccg_config("ace-tool", install_dir, verbose)
|
||||
|
||||
elif op_type == "install_mcp":
|
||||
# 动态 MCP 选择
|
||||
mcp_provider = choose_mcp_provider()
|
||||
|
||||
if mcp_provider is None:
|
||||
print(" ⚠️ 跳过 MCP 安装")
|
||||
create_ccg_config("none", install_dir, verbose)
|
||||
return True # 不阻止其他安装
|
||||
|
||||
# 根据选择安装对应的 MCP
|
||||
if mcp_provider == "ace-tool":
|
||||
success, message = install_ace_tool(verbose)
|
||||
elif mcp_provider == "auggie":
|
||||
success, message = install_auggie(verbose)
|
||||
else:
|
||||
print(f" ❌ 未知的 MCP 提供商: {mcp_provider}", file=sys.stderr)
|
||||
return False
|
||||
|
||||
if not success:
|
||||
print(f" ⚠️ {message}")
|
||||
print(f" ℹ️ 可稍后手动配置 MCP")
|
||||
create_ccg_config("none", install_dir, verbose)
|
||||
return True # 不阻止其他安装
|
||||
|
||||
if verbose:
|
||||
print(f" ℹ️ {message}")
|
||||
|
||||
# 创建配置文件
|
||||
create_ccg_config(mcp_provider, install_dir, verbose)
|
||||
|
||||
else:
|
||||
print(f" ⚠️ 未知操作类型: {op_type}", file=sys.stderr)
|
||||
return False
|
||||
|
||||
return True
|
||||
|
||||
except Exception as e:
|
||||
print(f" ❌ 错误: {e}", file=sys.stderr)
|
||||
return False
|
||||
|
||||
|
||||
def install_module(
|
||||
name: str,
|
||||
module: Dict[str, Any],
|
||||
source_dir: Path,
|
||||
install_dir: Path,
|
||||
verbose: bool = False
|
||||
) -> bool:
|
||||
print(f"\n📦 正在安装模块: {name}")
|
||||
print(f" {module.get('description', '')}")
|
||||
|
||||
operations = module.get("operations", [])
|
||||
success_count = 0
|
||||
|
||||
for op in operations:
|
||||
if execute_operation(op, source_dir, install_dir, verbose):
|
||||
success_count += 1
|
||||
|
||||
if success_count == len(operations):
|
||||
print(f" ✅ 模块 '{name}' 安装成功!")
|
||||
return True
|
||||
else:
|
||||
print(f" ⚠️ 模块 '{name}' 安装完成，但有 {len(operations) - success_count} 个警告")
|
||||
return False
|
||||
|
||||
|
||||
def main() -> int:
|
||||
args = parse_args()
|
||||
|
||||
# 解析路径
|
||||
config_path = Path(args.config)
|
||||
if not config_path.is_absolute():
|
||||
config_path = Path(__file__).parent / args.config
|
||||
|
||||
source_dir = config_path.parent
|
||||
install_dir = Path(args.install_dir).expanduser().resolve()
|
||||
|
||||
# 加载配置
|
||||
config = load_config(str(config_path))
|
||||
|
||||
# 列出模块模式
|
||||
if args.list_modules:
|
||||
list_modules(config)
|
||||
return 0
|
||||
|
||||
# 打印标题
|
||||
print("\n" + "=" * 50)
|
||||
print("🚀 Skills-v2 安装器")
|
||||
print(" 多模型协作系统")
|
||||
print("=" * 50)
|
||||
print(f"\n📁 安装目录: {install_dir}")
|
||||
|
||||
# 确保安装目录存在
|
||||
ensure_dir(install_dir)
|
||||
|
||||
# 确定要安装的模块
|
||||
modules = config.get("modules", {})
|
||||
modules_to_install = []
|
||||
|
||||
if args.module == "all":
|
||||
modules_to_install = [
|
||||
(name, mod) for name, mod in modules.items()
|
||||
if mod.get("enabled", False)
|
||||
]
|
||||
elif args.module in modules:
|
||||
modules_to_install = [(args.module, modules[args.module])]
|
||||
else:
|
||||
print(f"\n❌ 未知模块: {args.module}", file=sys.stderr)
|
||||
print(" 使用 --list-modules 查看可用模块")
|
||||
return 1
|
||||
|
||||
if not modules_to_install:
|
||||
print("\n⚠️ 没有可安装的模块")
|
||||
return 0
|
||||
|
||||
# 安装模块
|
||||
success = True
|
||||
for name, module in modules_to_install:
|
||||
if not install_module(name, module, source_dir, install_dir, args.verbose):
|
||||
success = False
|
||||
|
||||
# 打印摘要
|
||||
print("\n" + "=" * 50)
|
||||
if success:
|
||||
print("✅ 安装完成!")
|
||||
print("\n📋 已安装命令 (/ccg:xxx):")
|
||||
print(" 开发工作流:")
|
||||
print(" /ccg:dev - 完整6阶段多模型工作流")
|
||||
print(" /ccg:code - 多模型代码生成（智能路由）")
|
||||
print(" /ccg:debug - UltraThink 多模型调试")
|
||||
print(" /ccg:test - 多模型测试生成")
|
||||
print(" /ccg:bugfix - 质量门控修复（90%+ 通过）")
|
||||
print(" /ccg:think - 深度分析")
|
||||
print(" /ccg:optimize - 性能优化")
|
||||
print(" /ccg:frontend - 前端任务 → Gemini")
|
||||
print(" /ccg:backend - 后端任务 → Codex")
|
||||
print(" /ccg:review - 双模型代码审查")
|
||||
print(" /ccg:analyze - 双模型分析")
|
||||
print(" /ccg:enhance - Prompt 增强")
|
||||
print(" Git 工具:")
|
||||
print(" /ccg:commit - 智能提交")
|
||||
print(" /ccg:rollback - 交互式回滚")
|
||||
print(" /ccg:clean-branches - 清理分支")
|
||||
print(" /ccg:worktree - Worktree 管理")
|
||||
print(" 项目初始化:")
|
||||
print(" /ccg:init - 初始化项目 AI 上下文")
|
||||
print("\n🎯 快速开始:")
|
||||
print(' /ccg:dev "实现用户认证功能"')
|
||||
print(' /ccg:debug "登录接口返回500错误"')
|
||||
print(' /ccg:bugfix "密码重置失败"')
|
||||
else:
|
||||
print("⚠️ 安装完成，但有警告")
|
||||
print("=" * 50 + "\n")
|
||||
|
||||
return 0 if success else 1
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
sys.exit(main())
|
||||
Reference in new issue
Block a user