mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-07 02:04:11 +08:00
Compare commits
56 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
4e66864cfd | ||
|
|
cac0566627 | ||
|
|
572c103fbf | ||
|
|
9d6bc92837 | ||
|
|
ffe9898fd3 | ||
|
|
a602a46985 | ||
|
|
f7dd3d23ff | ||
|
|
200812d204 | ||
|
|
261c98549d | ||
|
|
b85d9b9eb1 | ||
|
|
4610018193 | ||
|
|
9c9b1ad01c | ||
|
|
2f3a14e946 | ||
|
|
1376dc71d9 | ||
|
|
c1d12384c3 | ||
|
|
eea859dd6f | ||
|
|
3fe630f221 | ||
|
|
eeaefa7208 | ||
|
|
e58c33fb6e | ||
|
|
6716772e0a | ||
|
|
a8367bd4d7 | ||
|
|
ea13f9a575 | ||
|
|
7d152b7bf9 | ||
|
|
16c96229f9 | ||
|
|
40b003be68 | ||
|
|
46111b3987 | ||
|
|
f47726d43b | ||
|
|
502d088c98 | ||
|
|
f845e6e0ee | ||
|
|
e96eed817c | ||
|
|
6a6d1885d8 | ||
|
|
a34eeb63bf | ||
|
|
56acc4f19c | ||
|
|
fdf468ed99 | ||
|
|
680c2a0597 | ||
|
|
5b5dc85677 | ||
|
|
1e691fa751 | ||
|
|
1f87ca0be3 | ||
|
|
f14418603a | ||
|
|
1fae35c05d | ||
|
|
8523079a99 | ||
|
|
4daeb0eead | ||
|
|
86548af518 | ||
|
|
4e5eb6cd40 | ||
|
|
021ce619f0 | ||
|
|
63aaab596c | ||
|
|
bc52af540e | ||
|
|
8bbbdc61eb | ||
|
|
fd5f6c2c97 | ||
|
|
fd145c34cd | ||
|
|
10b3ace917 | ||
|
|
d6a2e0de59 | ||
|
|
35c6605681 | ||
|
|
ef2229b0bb | ||
|
|
b65977d8dc | ||
|
|
bc4176fda0 |
@@ -29,13 +29,18 @@ Available CLI endpoints are dynamically defined by the config file:
|
||||
```
|
||||
Bash({ command: "ccw cli -p '...' --tool gemini", run_in_background: true })
|
||||
```
|
||||
- **After CLI call**: Stop immediately - let CLI execute in background
|
||||
- **After CLI call**: Stop output immediately - let CLI execute in background. **DO NOT use TaskOutput polling** - wait for hook callback to receive results
|
||||
|
||||
### CLI Analysis Calls
|
||||
- **Wait for results**: MUST wait for CLI analysis to complete before taking any write action. Do NOT proceed with fixes while analysis is running
|
||||
- **Value every call**: Each CLI invocation is valuable and costly. NEVER waste analysis results:
|
||||
- Aggregate multiple analysis results before proposing solutions
|
||||
|
||||
### CLI Auto-Invoke Triggers
|
||||
- **Reference**: See `cli-tools-usage.md` → [Auto-Invoke Triggers](#auto-invoke-triggers) for full specification
|
||||
- **Key scenarios**: Self-repair fails, ambiguous requirements, architecture decisions, pattern uncertainty, critical code paths
|
||||
- **Principles**: Default `--mode analysis`, no confirmation needed, wait for completion, flexible rule selection
|
||||
|
||||
## Code Diagnostics
|
||||
|
||||
- **Prefer `mcp__ide__getDiagnostics`** for code error checking over shell-based TypeScript compilation
|
||||
|
||||
366
.claude/TYPESCRIPT_LSP_SETUP.md
Normal file
366
.claude/TYPESCRIPT_LSP_SETUP.md
Normal file
@@ -0,0 +1,366 @@
|
||||
# Claude Code TypeScript LSP 配置指南
|
||||
|
||||
> 更新日期: 2026-01-20
|
||||
> 适用版本: Claude Code v2.0.74+
|
||||
|
||||
---
|
||||
|
||||
## 目录
|
||||
|
||||
1. [方式一:插件市场(推荐)](#方式一插件市场推荐)
|
||||
2. [方式二:MCP Server (cclsp)](#方式二mcp-server-cclsp)
|
||||
3. [方式三:内置LSP工具](#方式三内置lsp工具)
|
||||
4. [配置验证](#配置验证)
|
||||
5. [故障排查](#故障排查)
|
||||
|
||||
---
|
||||
|
||||
## 方式一:插件市场(推荐)
|
||||
|
||||
### 步骤 1: 添加插件市场
|
||||
|
||||
在Claude Code中执行:
|
||||
|
||||
```bash
|
||||
/plugin marketplace add boostvolt/claude-code-lsps
|
||||
```
|
||||
|
||||
### 步骤 2: 安装TypeScript LSP插件
|
||||
|
||||
```bash
|
||||
# TypeScript/JavaScript支持(推荐vtsls)
|
||||
/plugin install vtsls@claude-code-lsps
|
||||
```
|
||||
|
||||
### 步骤 3: 验证安装
|
||||
|
||||
```bash
|
||||
/plugin list
|
||||
```
|
||||
|
||||
应该看到:
|
||||
```
|
||||
✓ vtsls@claude-code-lsps (enabled)
|
||||
✓ pyright-lsp@claude-plugins-official (enabled)
|
||||
```
|
||||
|
||||
### 配置文件自动更新
|
||||
|
||||
安装后,`~/.claude/settings.json` 会自动添加:
|
||||
|
||||
```json
|
||||
{
|
||||
"enabledPlugins": {
|
||||
"pyright-lsp@claude-plugins-official": true,
|
||||
"vtsls@claude-code-lsps": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 支持的操作
|
||||
|
||||
- `goToDefinition` - 跳转到定义
|
||||
- `findReferences` - 查找引用
|
||||
- `hover` - 显示类型信息
|
||||
- `documentSymbol` - 文档符号
|
||||
- `getDiagnostics` - 诊断信息
|
||||
|
||||
---
|
||||
|
||||
## 方式二:MCP Server (cclsp)
|
||||
|
||||
### 优势
|
||||
|
||||
- **位置容错**:自动修正AI生成的不精确行号
|
||||
- **更多功能**:支持重命名、完整诊断
|
||||
- **灵活配置**:完全自定义LSP服务器
|
||||
|
||||
### 安装步骤
|
||||
|
||||
#### 1. 安装TypeScript Language Server
|
||||
|
||||
```bash
|
||||
npm install -g typescript-language-server typescript
|
||||
```
|
||||
|
||||
验证安装:
|
||||
```bash
|
||||
typescript-language-server --version
|
||||
```
|
||||
|
||||
#### 2. 配置cclsp
|
||||
|
||||
运行自动配置:
|
||||
```bash
|
||||
npx cclsp@latest setup --user
|
||||
```
|
||||
|
||||
或手动创建配置文件:
|
||||
|
||||
**文件位置**: `~/.claude/cclsp.json` 或 `~/.config/claude/cclsp.json`
|
||||
|
||||
```json
|
||||
{
|
||||
"servers": [
|
||||
{
|
||||
"extensions": ["ts", "tsx", "js", "jsx"],
|
||||
"command": ["typescript-language-server", "--stdio"],
|
||||
"rootDir": ".",
|
||||
"restartInterval": 5,
|
||||
"initializationOptions": {
|
||||
"preferences": {
|
||||
"includeInlayParameterNameHints": "all",
|
||||
"includeInlayPropertyDeclarationTypeHints": true,
|
||||
"includeInlayFunctionParameterTypeHints": true,
|
||||
"includeInlayVariableTypeHints": true
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"extensions": ["py", "pyi"],
|
||||
"command": ["pylsp"],
|
||||
"rootDir": ".",
|
||||
"restartInterval": 5
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
#### 3. 在Claude Code中启用MCP Server
|
||||
|
||||
添加到Claude Code配置:
|
||||
|
||||
```bash
|
||||
# 查看当前MCP配置
|
||||
cat ~/.claude/.mcp.json
|
||||
|
||||
# 如果没有,创建新的
|
||||
```
|
||||
|
||||
**文件**: `~/.claude/.mcp.json`
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"cclsp": {
|
||||
"command": "npx",
|
||||
"args": ["cclsp@latest"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### cclsp可用的MCP工具
|
||||
|
||||
使用时,Claude Code会自动调用这些工具:
|
||||
|
||||
- `find_definition` - 按名称查找定义(支持模糊匹配)
|
||||
- `find_references` - 查找所有引用
|
||||
- `rename_symbol` - 重命名符号(带备份)
|
||||
- `get_diagnostics` - 获取诊断信息
|
||||
- `restart_server` - 重启LSP服务器
|
||||
|
||||
---
|
||||
|
||||
## 方式三:内置LSP工具
|
||||
|
||||
### 启用方式
|
||||
|
||||
设置环境变量:
|
||||
|
||||
**Linux/Mac**:
|
||||
```bash
|
||||
export ENABLE_LSP_TOOL=1
|
||||
claude
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**:
|
||||
```powershell
|
||||
$env:ENABLE_LSP_TOOL=1
|
||||
claude
|
||||
```
|
||||
|
||||
**永久启用** (添加到shell配置):
|
||||
```bash
|
||||
# Linux/Mac
|
||||
echo 'export ENABLE_LSP_TOOL=1' >> ~/.bashrc
|
||||
source ~/.bashrc
|
||||
|
||||
# Windows (PowerShell Profile)
|
||||
Add-Content $PROFILE '$env:ENABLE_LSP_TOOL=1'
|
||||
```
|
||||
|
||||
### 限制
|
||||
|
||||
- 需要先安装语言服务器插件(见方式一)
|
||||
- 不支持重命名等高级操作
|
||||
- 无位置容错功能
|
||||
|
||||
---
|
||||
|
||||
## 配置验证
|
||||
|
||||
### 1. 检查LSP服务器是否可用
|
||||
|
||||
```bash
|
||||
# 检查TypeScript Language Server
|
||||
which typescript-language-server # Linux/Mac
|
||||
where typescript-language-server # Windows
|
||||
|
||||
# 测试运行
|
||||
typescript-language-server --stdio
|
||||
```
|
||||
|
||||
### 2. 在Claude Code中测试
|
||||
|
||||
打开任意TypeScript文件,让Claude执行:
|
||||
|
||||
```typescript
|
||||
// 测试LSP功能
|
||||
LSP({
|
||||
operation: "hover",
|
||||
filePath: "path/to/your/file.ts",
|
||||
line: 10,
|
||||
character: 5
|
||||
})
|
||||
```
|
||||
|
||||
### 3. 检查插件状态
|
||||
|
||||
```bash
|
||||
/plugin list
|
||||
```
|
||||
|
||||
查看启用的插件:
|
||||
```bash
|
||||
cat ~/.claude/settings.json | grep enabledPlugins
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 故障排查
|
||||
|
||||
### 问题 1: "No LSP server available"
|
||||
|
||||
**原因**:TypeScript LSP插件未安装或未启用
|
||||
|
||||
**解决**:
|
||||
```bash
|
||||
# 重新安装插件
|
||||
/plugin install vtsls@claude-code-lsps
|
||||
|
||||
# 检查settings.json
|
||||
cat ~/.claude/settings.json
|
||||
```
|
||||
|
||||
### 问题 2: "typescript-language-server: command not found"
|
||||
|
||||
**原因**:未安装TypeScript Language Server
|
||||
|
||||
**解决**:
|
||||
```bash
|
||||
npm install -g typescript-language-server typescript
|
||||
|
||||
# 验证
|
||||
typescript-language-server --version
|
||||
```
|
||||
|
||||
### 问题 3: LSP响应慢或超时
|
||||
|
||||
**原因**:项目太大或配置不当
|
||||
|
||||
**解决**:
|
||||
```json
|
||||
// 在tsconfig.json中优化
|
||||
{
|
||||
"compilerOptions": {
|
||||
"incremental": true,
|
||||
"skipLibCheck": true
|
||||
},
|
||||
"exclude": ["node_modules", "dist"]
|
||||
}
|
||||
```
|
||||
|
||||
### 问题 4: 插件安装失败
|
||||
|
||||
**原因**:网络问题或插件市场未添加
|
||||
|
||||
**解决**:
|
||||
```bash
|
||||
# 确认插件市场已添加
|
||||
/plugin marketplace list
|
||||
|
||||
# 如果没有,重新添加
|
||||
/plugin marketplace add boostvolt/claude-code-lsps
|
||||
|
||||
# 重试安装
|
||||
/plugin install vtsls@claude-code-lsps
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 三种方式对比
|
||||
|
||||
| 特性 | 插件市场 | cclsp (MCP) | 内置LSP |
|
||||
|------|----------|-------------|---------|
|
||||
| 安装复杂度 | ⭐ 低 | ⭐⭐ 中 | ⭐ 低 |
|
||||
| 功能完整性 | ⭐⭐⭐ 完整 | ⭐⭐⭐ 完整+ | ⭐⭐ 基础 |
|
||||
| 位置容错 | ❌ 无 | ✅ 有 | ❌ 无 |
|
||||
| 重命名支持 | ✅ 有 | ✅ 有 | ❌ 无 |
|
||||
| 自定义配置 | ⚙️ 有限 | ⚙️ 完整 | ❌ 无 |
|
||||
| 生产稳定性 | ⭐⭐⭐ 高 | ⭐⭐ 中 | ⭐⭐⭐ 高 |
|
||||
|
||||
---
|
||||
|
||||
## 推荐配置
|
||||
|
||||
### 新手用户
|
||||
**推荐**: 方式一(插件市场)
|
||||
- 一条命令安装
|
||||
- 官方维护,稳定可靠
|
||||
- 满足日常使用需求
|
||||
|
||||
### 高级用户
|
||||
**推荐**: 方式二(cclsp)
|
||||
- 完整功能支持
|
||||
- 位置容错(AI友好)
|
||||
- 灵活配置
|
||||
- 支持重命名等高级操作
|
||||
|
||||
### 快速测试
|
||||
**推荐**: 方式三(内置LSP)+ 方式一(插件)
|
||||
- 设置环境变量
|
||||
- 安装插件
|
||||
- 立即可用
|
||||
|
||||
---
|
||||
|
||||
## 附录:支持的语言
|
||||
|
||||
通过插件市场可用的LSP:
|
||||
|
||||
| 语言 | 插件名 | 安装命令 |
|
||||
|------|--------|----------|
|
||||
| TypeScript/JavaScript | vtsls | `/plugin install vtsls@claude-code-lsps` |
|
||||
| Python | pyright | `/plugin install pyright@claude-code-lsps` |
|
||||
| Go | gopls | `/plugin install gopls@claude-code-lsps` |
|
||||
| Rust | rust-analyzer | `/plugin install rust-analyzer@claude-code-lsps` |
|
||||
| Java | jdtls | `/plugin install jdtls@claude-code-lsps` |
|
||||
| C/C++ | clangd | `/plugin install clangd@claude-code-lsps` |
|
||||
| C# | omnisharp | `/plugin install omnisharp@claude-code-lsps` |
|
||||
| PHP | intelephense | `/plugin install intelephense@claude-code-lsps` |
|
||||
| Kotlin | kotlin-ls | `/plugin install kotlin-language-server@claude-code-lsps` |
|
||||
| Ruby | solargraph | `/plugin install solargraph@claude-code-lsps` |
|
||||
|
||||
---
|
||||
|
||||
## 相关文档
|
||||
|
||||
- [Claude Code LSP 文档](https://docs.anthropic.com/claude-code/lsp)
|
||||
- [cclsp GitHub](https://github.com/ktnyt/cclsp)
|
||||
- [TypeScript Language Server](https://github.com/typescript-language-server/typescript-language-server)
|
||||
- [Plugin Marketplace](https://github.com/boostvolt/claude-code-lsps)
|
||||
|
||||
---
|
||||
|
||||
**配置完成后,重启Claude Code以应用更改**
|
||||
@@ -215,7 +215,7 @@ CONTEXT: @**/* | Memory: {ace_context_summary}
|
||||
|
||||
EXPECTED: JSON with feasibility_score, findings, implementation_approaches, technical_concerns, code_locations
|
||||
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/analysis-protocol.md) |
|
||||
CONSTRAINTS:
|
||||
- Specific file:line references
|
||||
- Quantify effort estimates
|
||||
- Concrete pros/cons
|
||||
|
||||
@@ -114,9 +114,10 @@ plan → planning/architecture-planning.txt | planning/task-breakdown.txt
|
||||
bug-fix → development/bug-diagnosis.txt
|
||||
```
|
||||
|
||||
**3. RULES Field**:
|
||||
- Use `$(cat ~/.claude/workflows/cli-templates/prompts/{path}.txt)` directly
|
||||
- NEVER escape: `\$`, `\"`, `\'` breaks command substitution
|
||||
**3. CONSTRAINTS Field**:
|
||||
- Use `--rule <template>` option to auto-load protocol + template (appended to prompt)
|
||||
- Template names: `category-function` format (e.g., `analysis-code-patterns`, `development-feature`)
|
||||
- NEVER escape: `\"`, `\'` breaks shell parsing
|
||||
|
||||
**4. Structured Prompt**:
|
||||
```bash
|
||||
@@ -125,7 +126,7 @@ TASK: {specific_task_with_details}
|
||||
MODE: {analysis|write|auto}
|
||||
CONTEXT: {structured_file_references}
|
||||
EXPECTED: {clear_output_expectations}
|
||||
RULES: $(cat {selected_template}) | {constraints}
|
||||
CONSTRAINTS: {constraints}
|
||||
```
|
||||
|
||||
---
|
||||
@@ -156,8 +157,8 @@ TASK: {task}
|
||||
MODE: analysis
|
||||
CONTEXT: @**/*
|
||||
EXPECTED: {output}
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/pattern.txt)
|
||||
" --tool gemini --mode analysis --cd {dir}
|
||||
CONSTRAINTS: {constraints}
|
||||
" --tool gemini --mode analysis --rule analysis-code-patterns --cd {dir}
|
||||
|
||||
# Qwen fallback: Replace '--tool gemini' with '--tool qwen'
|
||||
```
|
||||
|
||||
@@ -106,7 +106,7 @@ EXPECTED:
|
||||
## Time Estimate
|
||||
**Total**: [time]
|
||||
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/planning/02-breakdown-task-steps.txt) |
|
||||
CONSTRAINTS:
|
||||
- Follow schema structure from {schema_path}
|
||||
- Acceptance/verification must be quantified
|
||||
- Dependencies use task IDs
|
||||
|
||||
@@ -127,14 +127,14 @@ EXPECTED: Structured fix strategy with:
|
||||
- Fix approach ensuring business logic correctness (not just test passage)
|
||||
- Expected outcome and verification steps
|
||||
- Impact assessment: Will this fix potentially mask other issues?
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/{template}) |
|
||||
CONSTRAINTS:
|
||||
- For {test_type} tests: {layer_specific_guidance}
|
||||
- Avoid 'surgical fixes' that mask underlying issues
|
||||
- Provide specific line numbers for modifications
|
||||
- Consider previous iteration failures
|
||||
- Validate fix doesn't introduce new vulnerabilities
|
||||
- analysis=READ-ONLY
|
||||
" --tool {cli_tool} --mode analysis --cd {project_root} --timeout {timeout_value}
|
||||
" --tool {cli_tool} --mode analysis --rule {template} --cd {project_root} --timeout {timeout_value}
|
||||
```
|
||||
|
||||
**Layer-Specific Guidance Injection**:
|
||||
|
||||
@@ -385,8 +385,12 @@ Before completing any task, verify:
|
||||
- Make assumptions - verify with existing code
|
||||
- Create unnecessary complexity
|
||||
|
||||
**Bash Tool**:
|
||||
- Use `run_in_background=false` for all Bash/CLI calls to ensure foreground execution
|
||||
**Bash Tool (CLI Execution in Agent)**:
|
||||
- Use `run_in_background=false` for all Bash/CLI calls - agent cannot receive task hook callbacks
|
||||
- Set timeout ≥60 minutes for CLI commands (hooks don't propagate to subagents):
|
||||
```javascript
|
||||
Bash(command="ccw cli -p '...' --tool codex --mode write", timeout=3600000) // 60 min
|
||||
```
|
||||
|
||||
**ALWAYS:**
|
||||
- **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
|
||||
|
||||
@@ -105,7 +105,7 @@ TASK: • Analyze error pattern • Identify potential root causes • Suggest t
|
||||
MODE: analysis
|
||||
CONTEXT: @{affected_files}
|
||||
EXPECTED: Structured hypothesis list with priority ranking
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/01-diagnose-bug-root-cause.txt) | Focus on testable conditions
|
||||
CONSTRAINTS: Focus on testable conditions
|
||||
" --tool gemini --mode analysis --cd {project_root}
|
||||
```
|
||||
|
||||
@@ -213,7 +213,7 @@ EXPECTED:
|
||||
- Evidence summary
|
||||
- Root cause identification (if confirmed)
|
||||
- Next steps (if inconclusive)
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/01-diagnose-bug-root-cause.txt) | Evidence-based reasoning only
|
||||
CONSTRAINTS: Evidence-based reasoning only
|
||||
" --tool gemini --mode analysis
|
||||
```
|
||||
|
||||
@@ -271,7 +271,7 @@ TASK:
|
||||
MODE: write
|
||||
CONTEXT: @{affected_files}
|
||||
EXPECTED: Working fix that addresses root cause
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/development/02-implement-feature.txt) | Minimal changes only
|
||||
CONSTRAINTS: Minimal changes only
|
||||
" --tool codex --mode write --cd {project_root}
|
||||
```
|
||||
|
||||
|
||||
@@ -70,8 +70,8 @@ The agent supports **two execution modes** based on task JSON's `meta.cli_execut
|
||||
CONTEXT: @**/* ./src/modules/auth|code|code:5|dirs:2
|
||||
./src/modules/api|code|code:3|dirs:0
|
||||
EXPECTED: Documentation files in .workflow/docs/my_project/src/modules/
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/documentation/module-documentation.txt) | Mirror source structure
|
||||
" --tool gemini --mode write --cd src/modules
|
||||
CONSTRAINTS: Mirror source structure
|
||||
" --tool gemini --mode write --rule documentation-module --cd src/modules
|
||||
```
|
||||
|
||||
4. **CLI Execution** (Gemini CLI):
|
||||
@@ -216,7 +216,7 @@ Before completion, verify:
|
||||
{
|
||||
"step": "analyze_module_structure",
|
||||
"action": "Deep analysis of module structure and API",
|
||||
"command": "ccw cli -p \"PURPOSE: Document module comprehensively\nTASK: Extract module purpose, architecture, public API, dependencies\nMODE: analysis\nCONTEXT: @**/* System: [system_context]\nEXPECTED: Complete module analysis for documentation\nRULES: $(cat ~/.claude/workflows/cli-templates/prompts/documentation/module-documentation.txt)\" --tool gemini --mode analysis --cd src/auth",
|
||||
"command": "ccw cli -p \"PURPOSE: Document module comprehensively\nTASK: Extract module purpose, architecture, public API, dependencies\nMODE: analysis\nCONTEXT: @**/* System: [system_context]\nEXPECTED: Complete module analysis for documentation\nCONSTRAINTS: Mirror source structure\" --tool gemini --mode analysis --rule documentation-module --cd src/auth",
|
||||
"output_to": "module_analysis",
|
||||
"on_error": "fail"
|
||||
}
|
||||
|
||||
@@ -16,7 +16,7 @@ color: green
|
||||
- 5-phase task lifecycle (analyze → implement → test → optimize → commit)
|
||||
- Conflict-aware planning (isolate file modifications across issues)
|
||||
- Dependency DAG validation
|
||||
- Auto-bind for single solution, return for selection on multiple
|
||||
- Execute bind command for single solution, return for selection on multiple
|
||||
|
||||
**Key Principle**: Generate tasks conforming to schema with quantified acceptance criteria.
|
||||
|
||||
@@ -111,30 +111,30 @@ Generate multiple candidate solutions when:
|
||||
- Multiple valid implementation approaches exist
|
||||
- Trade-offs between approaches (performance vs simplicity, etc.)
|
||||
|
||||
| Condition | Solutions |
|
||||
|-----------|-----------|
|
||||
| Low complexity, single approach | 1 solution, auto-bind |
|
||||
| Medium complexity, clear path | 1-2 solutions |
|
||||
| High complexity, multiple approaches | 2-3 solutions, user selection |
|
||||
| Condition | Solutions | Binding Action |
|
||||
|-----------|-----------|----------------|
|
||||
| Low complexity, single approach | 1 solution | Execute bind |
|
||||
| Medium complexity, clear path | 1-2 solutions | Execute bind if 1, return if 2+ |
|
||||
| High complexity, multiple approaches | 2-3 solutions | Return for selection |
|
||||
|
||||
**Binding Decision** (based SOLELY on final `solutions.length`):
|
||||
```javascript
|
||||
// After generating all solutions
|
||||
if (solutions.length === 1) {
|
||||
exec(`ccw issue bind ${issueId} ${solutions[0].id}`); // MUST execute
|
||||
} else {
|
||||
return { pending_selection: solutions }; // Return for user choice
|
||||
}
|
||||
```
|
||||
|
||||
**Solution Evaluation** (for each candidate):
|
||||
```javascript
|
||||
{
|
||||
analysis: {
|
||||
risk: "low|medium|high", // Implementation risk
|
||||
impact: "low|medium|high", // Scope of changes
|
||||
complexity: "low|medium|high" // Technical complexity
|
||||
},
|
||||
score: 0.0-1.0 // Overall quality score (higher = recommended)
|
||||
analysis: { risk: "low|medium|high", impact: "low|medium|high", complexity: "low|medium|high" },
|
||||
score: 0.0-1.0 // Higher = recommended
|
||||
}
|
||||
```
|
||||
|
||||
**Selection Flow**:
|
||||
1. Generate all candidate solutions
|
||||
2. Evaluate and score each
|
||||
3. Single solution → auto-bind
|
||||
4. Multiple solutions → return `pending_selection` for user choice
|
||||
|
||||
**Task Decomposition** following schema:
|
||||
```javascript
|
||||
function decomposeTasks(issue, exploration) {
|
||||
@@ -248,8 +248,8 @@ Write({ file_path: filePath, content: newContent })
|
||||
```
|
||||
|
||||
**Step 2: Bind decision**
|
||||
- **Single solution** → Auto-bind: `ccw issue bind <issue-id> <solution-id>`
|
||||
- **Multiple solutions** → Return for user selection (no bind)
|
||||
- 1 solution → Execute `ccw issue bind <issue-id> <solution-id>`
|
||||
- 2+ solutions → Return `pending_selection` (no bind)
|
||||
|
||||
---
|
||||
|
||||
@@ -264,14 +264,7 @@ Write({ file_path: filePath, content: newContent })
|
||||
|
||||
Each line is a solution JSON containing tasks. Schema: `cat .claude/workflows/cli-templates/schemas/solution-schema.json`
|
||||
|
||||
### 2.2 Binding
|
||||
|
||||
| Scenario | Action |
|
||||
|----------|--------|
|
||||
| Single solution | `ccw issue bind <issue-id> <solution-id>` (auto) |
|
||||
| Multiple solutions | Register only, return for selection |
|
||||
|
||||
### 2.3 Return Summary
|
||||
### 2.2 Return Summary
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -332,9 +325,9 @@ Each line is a solution JSON containing tasks. Schema: `cat .claude/workflows/cl
|
||||
2. Use vague criteria ("works correctly", "good performance")
|
||||
3. Create circular dependencies
|
||||
4. Generate more than 10 tasks per issue
|
||||
5. **Bind when multiple solutions exist** - MUST check `solutions.length === 1` before calling `ccw issue bind`
|
||||
5. Skip bind when `solutions.length === 1` (MUST execute bind command)
|
||||
|
||||
**OUTPUT**:
|
||||
1. Write solutions to `.workflow/issues/solutions/{issue-id}.jsonl` (JSONL format)
|
||||
2. Single solution → `ccw issue bind <issue-id> <solution-id>`; Multiple → return only
|
||||
3. Return JSON with `bound`, `pending_selection`
|
||||
1. Write solutions to `.workflow/issues/solutions/{issue-id}.jsonl`
|
||||
2. Execute bind or return `pending_selection` based on solution count
|
||||
3. Return JSON: `{ bound: [...], pending_selection: [...] }`
|
||||
|
||||
@@ -87,7 +87,7 @@ TASK: • Detect file conflicts (same file modified by multiple solutions)
|
||||
MODE: analysis
|
||||
CONTEXT: @.workflow/issues/solutions/**/*.jsonl | Solution data: \${SOLUTIONS_JSON}
|
||||
EXPECTED: JSON array of conflicts with type, severity, solutions, recommended_order
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/analysis-protocol.md) | Severity: high (API/data) > medium (file/dependency) > low (architecture)
|
||||
CONSTRAINTS: Severity: high (API/data) > medium (file/dependency) > low (architecture)
|
||||
" --tool gemini --mode analysis --cd .workflow/issues
|
||||
```
|
||||
|
||||
|
||||
355
.claude/commands/cli/codex-review.md
Normal file
355
.claude/commands/cli/codex-review.md
Normal file
@@ -0,0 +1,355 @@
|
||||
---
|
||||
name: codex-review
|
||||
description: Interactive code review using Codex CLI via ccw endpoint with configurable review target, model, and custom instructions
|
||||
argument-hint: "[--uncommitted|--base <branch>|--commit <sha>] [--model <model>] [--title <title>] [prompt]"
|
||||
allowed-tools: Bash(*), AskUserQuestion(*), Read(*)
|
||||
---
|
||||
|
||||
# Codex Review Command (/cli:codex-review)
|
||||
|
||||
## Overview
|
||||
Interactive code review command that invokes `codex review` via ccw cli endpoint with guided parameter selection.
|
||||
|
||||
**Codex Review Parameters** (from `codex review --help`):
|
||||
| Parameter | Description |
|
||||
|-----------|-------------|
|
||||
| `[PROMPT]` | Custom review instructions (positional) |
|
||||
| `-c model=<model>` | Override model via config |
|
||||
| `--uncommitted` | Review staged, unstaged, and untracked changes |
|
||||
| `--base <BRANCH>` | Review changes against base branch |
|
||||
| `--commit <SHA>` | Review changes introduced by a commit |
|
||||
| `--title <TITLE>` | Optional commit title for review summary |
|
||||
|
||||
## Prompt Template Format
|
||||
|
||||
Follow the standard ccw cli prompt template:
|
||||
|
||||
```
|
||||
PURPOSE: [what] + [why] + [success criteria] + [constraints/scope]
|
||||
TASK: • [step 1] • [step 2] • [step 3]
|
||||
MODE: review
|
||||
CONTEXT: [review target description] | Memory: [relevant context]
|
||||
EXPECTED: [deliverable format] + [quality criteria]
|
||||
CONSTRAINTS: [focus constraints]
|
||||
```
|
||||
|
||||
## EXECUTION INSTRUCTIONS - START HERE
|
||||
|
||||
**When this command is triggered, follow these exact steps:**
|
||||
|
||||
### Step 1: Parse Arguments
|
||||
|
||||
Check if user provided arguments directly:
|
||||
- `--uncommitted` → Record target = uncommitted
|
||||
- `--base <branch>` → Record target = base, branch name
|
||||
- `--commit <sha>` → Record target = commit, sha value
|
||||
- `--model <model>` → Record model selection
|
||||
- `--title <title>` → Record title
|
||||
- Remaining text → Use as custom focus/prompt
|
||||
|
||||
If no target specified → Continue to Step 2 for interactive selection.
|
||||
|
||||
### Step 2: Interactive Parameter Selection
|
||||
|
||||
**2.1 Review Target Selection**
|
||||
|
||||
```javascript
|
||||
AskUserQuestion({
|
||||
questions: [{
|
||||
question: "What do you want to review?",
|
||||
header: "Review Target",
|
||||
options: [
|
||||
{ label: "Uncommitted changes (Recommended)", description: "Review staged, unstaged, and untracked changes" },
|
||||
{ label: "Compare to branch", description: "Review changes against a base branch (e.g., main)" },
|
||||
{ label: "Specific commit", description: "Review changes introduced by a specific commit" }
|
||||
],
|
||||
multiSelect: false
|
||||
}]
|
||||
})
|
||||
```
|
||||
|
||||
**2.2 Branch/Commit Input (if needed)**
|
||||
|
||||
If "Compare to branch" selected:
|
||||
```javascript
|
||||
AskUserQuestion({
|
||||
questions: [{
|
||||
question: "Which base branch to compare against?",
|
||||
header: "Base Branch",
|
||||
options: [
|
||||
{ label: "main", description: "Compare against main branch" },
|
||||
{ label: "master", description: "Compare against master branch" },
|
||||
{ label: "develop", description: "Compare against develop branch" }
|
||||
],
|
||||
multiSelect: false
|
||||
}]
|
||||
})
|
||||
```
|
||||
|
||||
If "Specific commit" selected:
|
||||
- Run `git log --oneline -10` to show recent commits
|
||||
- Ask user to provide commit SHA or select from list
|
||||
|
||||
**2.3 Model Selection (Optional)**
|
||||
|
||||
```javascript
|
||||
AskUserQuestion({
|
||||
questions: [{
|
||||
question: "Which model to use for review?",
|
||||
header: "Model",
|
||||
options: [
|
||||
{ label: "Default", description: "Use codex default model (gpt-5.2)" },
|
||||
{ label: "o3", description: "OpenAI o3 reasoning model" },
|
||||
{ label: "gpt-4.1", description: "GPT-4.1 model" },
|
||||
{ label: "o4-mini", description: "OpenAI o4-mini (faster)" }
|
||||
],
|
||||
multiSelect: false
|
||||
}]
|
||||
})
|
||||
```
|
||||
|
||||
**2.4 Review Focus Selection**
|
||||
|
||||
```javascript
|
||||
AskUserQuestion({
|
||||
questions: [{
|
||||
question: "What should the review focus on?",
|
||||
header: "Focus Area",
|
||||
options: [
|
||||
{ label: "General review (Recommended)", description: "Comprehensive review: correctness, style, bugs, docs" },
|
||||
{ label: "Security focus", description: "Security vulnerabilities, input validation, auth issues" },
|
||||
{ label: "Performance focus", description: "Performance bottlenecks, complexity, resource usage" },
|
||||
{ label: "Code quality", description: "Readability, maintainability, SOLID principles" }
|
||||
],
|
||||
multiSelect: false
|
||||
}]
|
||||
})
|
||||
```
|
||||
|
||||
### Step 3: Build Prompt and Command
|
||||
|
||||
**3.1 Construct Prompt Based on Focus**
|
||||
|
||||
**General Review Prompt:**
|
||||
```
|
||||
PURPOSE: Comprehensive code review to identify issues, improve quality, and ensure best practices; success = actionable feedback with clear priorities
|
||||
TASK: • Review code correctness and logic errors • Check coding standards and consistency • Identify potential bugs and edge cases • Evaluate documentation completeness
|
||||
MODE: review
|
||||
CONTEXT: {target_description} | Memory: Project conventions from CLAUDE.md
|
||||
EXPECTED: Structured review report with: severity levels (Critical/High/Medium/Low), file:line references, specific improvement suggestions, priority ranking
|
||||
CONSTRAINTS: Focus on actionable feedback
|
||||
```
|
||||
|
||||
**Security Focus Prompt:**
|
||||
```
|
||||
PURPOSE: Security-focused code review to identify vulnerabilities and security risks; success = all security issues documented with remediation
|
||||
TASK: • Scan for injection vulnerabilities (SQL, XSS, command) • Check authentication and authorization logic • Evaluate input validation and sanitization • Identify sensitive data exposure risks
|
||||
MODE: review
|
||||
CONTEXT: {target_description} | Memory: Security best practices, OWASP Top 10
|
||||
EXPECTED: Security report with: vulnerability classification, CVE references where applicable, remediation code snippets, risk severity matrix
|
||||
CONSTRAINTS: Security-first analysis | Flag all potential vulnerabilities
|
||||
```
|
||||
|
||||
**Performance Focus Prompt:**
|
||||
```
|
||||
PURPOSE: Performance-focused code review to identify bottlenecks and optimization opportunities; success = measurable improvement recommendations
|
||||
TASK: • Analyze algorithmic complexity (Big-O) • Identify memory allocation issues • Check for N+1 queries and blocking operations • Evaluate caching opportunities
|
||||
MODE: review
|
||||
CONTEXT: {target_description} | Memory: Performance patterns and anti-patterns
|
||||
EXPECTED: Performance report with: complexity analysis, bottleneck identification, optimization suggestions with expected impact, benchmark recommendations
|
||||
CONSTRAINTS: Performance optimization focus
|
||||
```
|
||||
|
||||
**Code Quality Focus Prompt:**
|
||||
```
|
||||
PURPOSE: Code quality review to improve maintainability and readability; success = cleaner, more maintainable code
|
||||
TASK: • Assess SOLID principles adherence • Identify code duplication and abstraction opportunities • Review naming conventions and clarity • Evaluate test coverage implications
|
||||
MODE: review
|
||||
CONTEXT: {target_description} | Memory: Project coding standards
|
||||
EXPECTED: Quality report with: principle violations, refactoring suggestions, naming improvements, maintainability score
|
||||
CONSTRAINTS: Code quality and maintainability focus
|
||||
```
|
||||
|
||||
**3.2 Build Target Description**
|
||||
|
||||
Based on selection, set `{target_description}`:
|
||||
- Uncommitted: `Reviewing uncommitted changes (staged + unstaged + untracked)`
|
||||
- Base branch: `Reviewing changes against {branch} branch`
|
||||
- Commit: `Reviewing changes introduced by commit {sha}`
|
||||
|
||||
### Step 4: Execute via CCW CLI
|
||||
|
||||
Build and execute the ccw cli command:
|
||||
|
||||
```bash
|
||||
# Base structure
|
||||
ccw cli -p "<PROMPT>" --tool codex --mode review [OPTIONS]
|
||||
```
|
||||
|
||||
**Command Construction:**
|
||||
|
||||
```bash
|
||||
# Variables from user selection
|
||||
TARGET_FLAG="" # --uncommitted | --base <branch> | --commit <sha>
|
||||
MODEL_FLAG="" # --model <model> (if not default)
|
||||
TITLE_FLAG="" # --title "<title>" (if provided)
|
||||
|
||||
# Build target flag
|
||||
if [ "$target" = "uncommitted" ]; then
|
||||
TARGET_FLAG="--uncommitted"
|
||||
elif [ "$target" = "base" ]; then
|
||||
TARGET_FLAG="--base $branch"
|
||||
elif [ "$target" = "commit" ]; then
|
||||
TARGET_FLAG="--commit $sha"
|
||||
fi
|
||||
|
||||
# Build model flag (only if not default)
|
||||
if [ "$model" != "default" ] && [ -n "$model" ]; then
|
||||
MODEL_FLAG="--model $model"
|
||||
fi
|
||||
|
||||
# Build title flag (if provided)
|
||||
if [ -n "$title" ]; then
|
||||
TITLE_FLAG="--title \"$title\""
|
||||
fi
|
||||
|
||||
# Execute
|
||||
ccw cli -p "$PROMPT" --tool codex --mode review $TARGET_FLAG $MODEL_FLAG $TITLE_FLAG
|
||||
```
|
||||
|
||||
**Full Example Command:**
|
||||
|
||||
```bash
|
||||
ccw cli -p "
|
||||
PURPOSE: Comprehensive code review to identify issues and improve quality; success = actionable feedback with priorities
|
||||
TASK: • Review correctness and logic • Check standards compliance • Identify bugs and edge cases • Evaluate documentation
|
||||
MODE: review
|
||||
CONTEXT: Reviewing uncommitted changes | Memory: Project conventions
|
||||
EXPECTED: Structured report with severity levels, file:line refs, improvement suggestions
|
||||
CONSTRAINTS: Actionable feedback
|
||||
" --tool codex --mode review --uncommitted --rule analysis-review-code-quality
|
||||
```
|
||||
|
||||
### Step 5: Execute and Display Results
|
||||
|
||||
```bash
|
||||
Bash({
|
||||
command: "ccw cli -p \"$PROMPT\" --tool codex --mode review $FLAGS",
|
||||
run_in_background: true
|
||||
})
|
||||
```
|
||||
|
||||
Wait for completion and display formatted results.
|
||||
|
||||
## Quick Usage Examples
|
||||
|
||||
### Direct Execution (No Interaction)
|
||||
|
||||
```bash
|
||||
# Review uncommitted changes with default settings
|
||||
/cli:codex-review --uncommitted
|
||||
|
||||
# Review against main branch
|
||||
/cli:codex-review --base main
|
||||
|
||||
# Review specific commit
|
||||
/cli:codex-review --commit abc123
|
||||
|
||||
# Review with custom model
|
||||
/cli:codex-review --uncommitted --model o3
|
||||
|
||||
# Review with security focus
|
||||
/cli:codex-review --uncommitted security
|
||||
|
||||
# Full options
|
||||
/cli:codex-review --base main --model o3 --title "Auth Feature" security
|
||||
```
|
||||
|
||||
### Interactive Mode
|
||||
|
||||
```bash
|
||||
# Start interactive selection (guided flow)
|
||||
/cli:codex-review
|
||||
```
|
||||
|
||||
## Focus Area Mapping
|
||||
|
||||
| User Selection | Prompt Focus | Key Checks |
|
||||
|----------------|--------------|------------|
|
||||
| General review | Comprehensive | Correctness, style, bugs, docs |
|
||||
| Security focus | Security-first | Injection, auth, validation, exposure |
|
||||
| Performance focus | Optimization | Complexity, memory, queries, caching |
|
||||
| Code quality | Maintainability | SOLID, duplication, naming, tests |
|
||||
|
||||
## Error Handling
|
||||
|
||||
### No Changes to Review
|
||||
```
|
||||
No changes found for review target. Suggestions:
|
||||
- For --uncommitted: Make some code changes first
|
||||
- For --base: Ensure branch exists and has diverged
|
||||
- For --commit: Verify commit SHA exists
|
||||
```
|
||||
|
||||
### Invalid Branch
|
||||
```bash
|
||||
# Show available branches
|
||||
git branch -a --list | head -20
|
||||
```
|
||||
|
||||
### Invalid Commit
|
||||
```bash
|
||||
# Show recent commits
|
||||
git log --oneline -10
|
||||
```
|
||||
|
||||
## Integration Notes
|
||||
|
||||
- Uses `ccw cli --tool codex --mode review` endpoint
|
||||
- Model passed via prompt (codex uses `-c model=` internally)
|
||||
- Target flags (`--uncommitted`, `--base`, `--commit`) passed through to codex
|
||||
- Prompt follows standard ccw cli template format for consistency
|
||||
|
||||
## Validation Constraints
|
||||
|
||||
**IMPORTANT: Target flags and prompt are mutually exclusive**
|
||||
|
||||
The codex CLI has a constraint where target flags (`--uncommitted`, `--base`, `--commit`) cannot be used with a positional `[PROMPT]` argument:
|
||||
|
||||
```
|
||||
error: the argument '--uncommitted' cannot be used with '[PROMPT]'
|
||||
error: the argument '--base <BRANCH>' cannot be used with '[PROMPT]'
|
||||
error: the argument '--commit <SHA>' cannot be used with '[PROMPT]'
|
||||
```
|
||||
|
||||
**Behavior:**
|
||||
- When ANY target flag is specified, ccw cli automatically skips template concatenation (systemRules/roles)
|
||||
- The review uses codex's default review behavior for the specified target
|
||||
- Custom prompts are only supported WITHOUT target flags (reviews uncommitted changes by default)
|
||||
|
||||
**Valid combinations:**
|
||||
| Command | Result |
|
||||
|---------|--------|
|
||||
| `codex review "Focus on security"` | ✓ Custom prompt, reviews uncommitted (default) |
|
||||
| `codex review --uncommitted` | ✓ No prompt, uses default review |
|
||||
| `codex review --base main` | ✓ No prompt, uses default review |
|
||||
| `codex review --commit abc123` | ✓ No prompt, uses default review |
|
||||
| `codex review --uncommitted "prompt"` | ✗ Invalid - mutually exclusive |
|
||||
| `codex review --base main "prompt"` | ✗ Invalid - mutually exclusive |
|
||||
| `codex review --commit abc123 "prompt"` | ✗ Invalid - mutually exclusive |
|
||||
|
||||
**Examples:**
|
||||
```bash
|
||||
# ✓ Valid: prompt only (reviews uncommitted by default)
|
||||
ccw cli -p "Focus on security" --tool codex --mode review
|
||||
|
||||
# ✓ Valid: target flag only (no prompt)
|
||||
ccw cli --tool codex --mode review --uncommitted
|
||||
ccw cli --tool codex --mode review --base main
|
||||
ccw cli --tool codex --mode review --commit abc123
|
||||
|
||||
# ✗ Invalid: target flag with prompt (will fail)
|
||||
ccw cli -p "Review this" --tool codex --mode review --uncommitted
|
||||
ccw cli -p "Review this" --tool codex --mode review --base main
|
||||
ccw cli -p "Review this" --tool codex --mode review --commit abc123
|
||||
```
|
||||
@@ -267,7 +267,7 @@ EXPECTED: JSON exploration plan following exploration-plan-schema.json:
|
||||
"estimated_iterations": N,
|
||||
"termination_conditions": [...]
|
||||
}
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/analysis-protocol.md) | Use ACE context to inform targets | Focus on actionable plan
|
||||
CONSTRAINTS: Use ACE context to inform targets | Focus on actionable plan
|
||||
`;
|
||||
|
||||
// Step 3: Execute Gemini planning
|
||||
|
||||
@@ -131,7 +131,7 @@ TASK: • Analyze issue titles/tags semantically • Identify functional/archite
|
||||
MODE: analysis
|
||||
CONTEXT: Issue metadata only
|
||||
EXPECTED: JSON with groups array, each containing max 4 issue_ids, theme, rationale
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/analysis-protocol.md) | Each issue in exactly one group | Max 4 issues per group | Balance group sizes
|
||||
CONSTRAINTS: Each issue in exactly one group | Max 4 issues per group | Balance group sizes
|
||||
|
||||
INPUT:
|
||||
${JSON.stringify(issueSummaries, null, 2)}
|
||||
|
||||
@@ -65,9 +65,13 @@ Queue formation command using **issue-queue-agent** that analyzes all bound solu
|
||||
--queues <n> Number of parallel queues (default: 1)
|
||||
--issue <id> Form queue for specific issue only
|
||||
--append <id> Append issue to active queue (don't create new)
|
||||
--force Skip active queue check, always create new queue
|
||||
|
||||
# CLI subcommands (ccw issue queue ...)
|
||||
ccw issue queue list List all queues with status
|
||||
ccw issue queue add <issue-id> Add issue to queue (interactive if active queue exists)
|
||||
ccw issue queue add <issue-id> -f Add to new queue without prompt (force)
|
||||
ccw issue queue merge <src> --queue <target> Merge source queue into target queue
|
||||
ccw issue queue switch <queue-id> Switch active queue
|
||||
ccw issue queue archive Archive current queue
|
||||
ccw issue queue delete <queue-id> Delete queue from history
|
||||
@@ -92,7 +96,7 @@ Phase 2-4: Agent-Driven Queue Formation (issue-queue-agent)
|
||||
│ ├─ Build dependency DAG from conflicts
|
||||
│ ├─ Calculate semantic priority per solution
|
||||
│ └─ Assign execution groups (parallel/sequential)
|
||||
└─ Each agent writes: queue JSON + index update
|
||||
└─ Each agent writes: queue JSON + index update (NOT active yet)
|
||||
|
||||
Phase 5: Conflict Clarification (if needed)
|
||||
├─ Collect `clarifications` arrays from all agents
|
||||
@@ -102,7 +106,24 @@ Phase 5: Conflict Clarification (if needed)
|
||||
|
||||
Phase 6: Status Update & Summary
|
||||
├─ Update issue statuses to 'queued'
|
||||
└─ Display queue summary (N queues), next step: /issue:execute
|
||||
└─ Display new queue summary (N queues)
|
||||
|
||||
Phase 7: Active Queue Check & Decision (REQUIRED)
|
||||
├─ Read queue index: ccw issue queue list --brief
|
||||
├─ Get generated queue ID from agent output
|
||||
├─ If NO active queue exists:
|
||||
│ ├─ Set generated queue as active_queue_id
|
||||
│ ├─ Update index.json
|
||||
│ └─ Display: "Queue created and activated"
|
||||
│
|
||||
└─ If active queue exists with items:
|
||||
├─ Display both queues to user
|
||||
├─ Use AskUserQuestion to prompt:
|
||||
│ ├─ "Use new queue (keep existing)" → Set new as active, keep old inactive
|
||||
│ ├─ "Merge: add new items to existing" → Merge new → existing, delete new
|
||||
│ ├─ "Merge: add existing items to new" → Merge existing → new, archive old
|
||||
│ └─ "Cancel" → Delete new queue, keep existing active
|
||||
└─ Execute chosen action
|
||||
```
|
||||
|
||||
## Implementation
|
||||
@@ -306,6 +327,41 @@ ccw issue update <issue-id> --status queued
|
||||
- Show unplanned issues (planned but NOT in queue)
|
||||
- Show next step: `/issue:execute`
|
||||
|
||||
### Phase 7: Active Queue Check & Decision
|
||||
|
||||
**After agent completes Phase 1-6, check for active queue:**
|
||||
|
||||
```bash
|
||||
ccw issue queue list --brief
|
||||
```
|
||||
|
||||
**Decision:**
|
||||
- If `active_queue_id` is null → `ccw issue queue switch <new-queue-id>` (activate new queue)
|
||||
- If active queue exists → Use **AskUserQuestion** to prompt user
|
||||
|
||||
**AskUserQuestion:**
|
||||
```javascript
|
||||
AskUserQuestion({
|
||||
questions: [{
|
||||
question: "Active queue exists. How would you like to proceed?",
|
||||
header: "Queue Action",
|
||||
options: [
|
||||
{ label: "Merge into existing queue", description: "Add new items to active queue, delete new queue" },
|
||||
{ label: "Use new queue", description: "Switch to new queue, keep existing in history" },
|
||||
{ label: "Cancel", description: "Delete new queue, keep existing active" }
|
||||
],
|
||||
multiSelect: false
|
||||
}]
|
||||
})
|
||||
```
|
||||
|
||||
**Action Commands:**
|
||||
|
||||
| User Choice | Commands |
|
||||
|-------------|----------|
|
||||
| **Merge into existing** | `ccw issue queue merge <new-queue-id> --queue <active-queue-id>` then `ccw issue queue delete <new-queue-id>` |
|
||||
| **Use new queue** | `ccw issue queue switch <new-queue-id>` |
|
||||
| **Cancel** | `ccw issue queue delete <new-queue-id>` |
|
||||
|
||||
## Storage Structure (Queue History)
|
||||
|
||||
@@ -360,6 +416,9 @@ ccw issue update <issue-id> --status queued
|
||||
| User cancels clarification | Abort queue formation |
|
||||
| **index.json not updated** | Auto-fix: Set active_queue_id to new queue |
|
||||
| **Queue file missing solutions** | Abort with error, agent must regenerate |
|
||||
| **User cancels queue add** | Display message, return without changes |
|
||||
| **Merge with empty source** | Skip merge, display warning |
|
||||
| **All items duplicate** | Skip merge, display "All items already exist" |
|
||||
|
||||
## Quality Checklist
|
||||
|
||||
|
||||
@@ -223,8 +223,8 @@ TASK:
|
||||
MODE: analysis
|
||||
CONTEXT: @src/**/*.controller.ts @src/**/*.routes.ts @src/**/*.dto.ts @src/**/middleware/**/*
|
||||
EXPECTED: JSON format API structure analysis report with modules, endpoints, security schemes, and error codes
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/analysis-protocol.md) | Strict RESTful standards | Identify all public endpoints | Document output language: {lang}
|
||||
" --tool gemini --mode analysis --cd {project_root}
|
||||
CONSTRAINTS: Strict RESTful standards | Identify all public endpoints | Document output language: {lang}
|
||||
" --tool gemini --mode analysis --rule analysis-code-patterns --cd {project_root}
|
||||
```
|
||||
|
||||
**Update swagger-planning-data.json** with analysis results:
|
||||
@@ -387,7 +387,7 @@ bash(cat ${session_dir}/.process/swagger-planning-data.json | jq -r '.api_struct
|
||||
"step": 1,
|
||||
"title": "Generate OpenAPI spec file",
|
||||
"description": "Create complete swagger.yaml specification file",
|
||||
"cli_prompt": "PURPOSE: Generate OpenAPI 3.0.3 specification file from analyzed API structure\nTASK:\n• Define openapi version: 3.0.3\n• Define info: title, description, version, contact, license\n• Define servers: development, staging, production environments\n• Define tags: organized by business modules\n• Define paths: all API endpoints with complete specifications\n• Define components: schemas, securitySchemes, parameters, responses\nMODE: write\nCONTEXT: @[api_analysis]\nEXPECTED: Complete swagger.yaml file following OpenAPI 3.0.3 specification\nRULES: $(cat ~/.claude/workflows/cli-templates/protocols/write-protocol.md) $(cat ~/.claude/workflows/cli-templates/prompts/documentation/swagger-api.txt) | Use {lang} for all descriptions | Strict RESTful standards",
|
||||
"cli_prompt": "PURPOSE: Generate OpenAPI 3.0.3 specification file from analyzed API structure\nTASK:\n• Define openapi version: 3.0.3\n• Define info: title, description, version, contact, license\n• Define servers: development, staging, production environments\n• Define tags: organized by business modules\n• Define paths: all API endpoints with complete specifications\n• Define components: schemas, securitySchemes, parameters, responses\nMODE: write\nCONTEXT: @[api_analysis]\nEXPECTED: Complete swagger.yaml file following OpenAPI 3.0.3 specification\nCONSTRAINTS: Use {lang} for all descriptions | Strict RESTful standards\n--rule documentation-swagger-api",
|
||||
"output": "swagger.yaml"
|
||||
}
|
||||
],
|
||||
@@ -429,7 +429,7 @@ bash(cat ${session_dir}/.process/swagger-planning-data.json | jq -r '.api_struct
|
||||
{
|
||||
"step": 1,
|
||||
"title": "Generate authentication documentation",
|
||||
"cli_prompt": "PURPOSE: Generate comprehensive authentication documentation for API security\nTASK:\n• Document authentication mechanism: JWT Bearer Token\n• Explain header format: Authorization: Bearer <token>\n• Describe token lifecycle: acquisition, refresh, expiration handling\n• Define permission levels: public, user, admin, super_admin\n• Document authentication failure responses: 401/403 error handling\nMODE: write\nCONTEXT: @[auth_patterns] @src/**/auth/**/* @src/**/guard/**/*\nEXPECTED: Complete authentication guide in {lang}\nRULES: $(cat ~/.claude/workflows/cli-templates/protocols/write-protocol.md) | Include code examples | Clear step-by-step instructions",
|
||||
"cli_prompt": "PURPOSE: Generate comprehensive authentication documentation for API security\nTASK:\n• Document authentication mechanism: JWT Bearer Token\n• Explain header format: Authorization: Bearer <token>\n• Describe token lifecycle: acquisition, refresh, expiration handling\n• Define permission levels: public, user, admin, super_admin\n• Document authentication failure responses: 401/403 error handling\nMODE: write\nCONTEXT: @[auth_patterns] @src/**/auth/**/* @src/**/guard/**/*\nEXPECTED: Complete authentication guide in {lang}\nCONSTRAINTS: Include code examples | Clear step-by-step instructions\n--rule development-feature",
|
||||
"output": "{auth_doc_name}"
|
||||
}
|
||||
],
|
||||
@@ -464,7 +464,7 @@ bash(cat ${session_dir}/.process/swagger-planning-data.json | jq -r '.api_struct
|
||||
{
|
||||
"step": 1,
|
||||
"title": "Generate error code specification document",
|
||||
"cli_prompt": "PURPOSE: Generate comprehensive error code specification for consistent API error handling\nTASK:\n• Define error response format: {code, message, details, timestamp}\n• Document authentication errors (AUTH_xxx): 401/403 series\n• Document parameter errors (PARAM_xxx): 400 series\n• Document business errors (BIZ_xxx): business logic errors\n• Document system errors (SYS_xxx): 500 series\n• For each error code: HTTP status, error message, possible causes, resolution suggestions\nMODE: write\nCONTEXT: @src/**/*.exception.ts @src/**/*.filter.ts\nEXPECTED: Complete error code specification in {lang} with tables and examples\nRULES: $(cat ~/.claude/workflows/cli-templates/protocols/write-protocol.md) | Include response examples | Clear categorization",
|
||||
"cli_prompt": "PURPOSE: Generate comprehensive error code specification for consistent API error handling\nTASK:\n• Define error response format: {code, message, details, timestamp}\n• Document authentication errors (AUTH_xxx): 401/403 series\n• Document parameter errors (PARAM_xxx): 400 series\n• Document business errors (BIZ_xxx): business logic errors\n• Document system errors (SYS_xxx): 500 series\n• For each error code: HTTP status, error message, possible causes, resolution suggestions\nMODE: write\nCONTEXT: @src/**/*.exception.ts @src/**/*.filter.ts\nEXPECTED: Complete error code specification in {lang} with tables and examples\nCONSTRAINTS: Include response examples | Clear categorization\n--rule development-feature",
|
||||
"output": "{error_doc_name}"
|
||||
}
|
||||
],
|
||||
@@ -523,7 +523,7 @@ bash(cat ${session_dir}/.process/swagger-planning-data.json | jq -r '.api_struct
|
||||
"step": 1,
|
||||
"title": "Generate module API documentation",
|
||||
"description": "Generate complete API documentation for ${module_name}",
|
||||
"cli_prompt": "PURPOSE: Generate complete RESTful API documentation for ${module_name} module\nTASK:\n• Create module overview: purpose, use cases, prerequisites\n• Generate endpoint index: grouped by functionality\n• For each endpoint document:\n - Functional description: purpose and business context\n - Request method: GET/POST/PUT/DELETE\n - URL path: complete API path\n - Request headers: Authorization and other required headers\n - Path parameters: {id} and other path variables\n - Query parameters: pagination, filters, etc.\n - Request body: JSON Schema format\n - Response body: success and error responses\n - Field description table: type, required, example, description\n• Add usage examples: cURL, JavaScript, Python\n• Add version info: v1.0.0, last updated date\nMODE: write\nCONTEXT: @[module_endpoints] @[source_code]\nEXPECTED: Complete module API documentation in {lang} with all endpoints fully documented\nRULES: $(cat ~/.claude/workflows/cli-templates/protocols/write-protocol.md) $(cat ~/.claude/workflows/cli-templates/prompts/documentation/swagger-api.txt) | RESTful standards | Include all response codes",
|
||||
"cli_prompt": "PURPOSE: Generate complete RESTful API documentation for ${module_name} module\nTASK:\n• Create module overview: purpose, use cases, prerequisites\n• Generate endpoint index: grouped by functionality\n• For each endpoint document:\n - Functional description: purpose and business context\n - Request method: GET/POST/PUT/DELETE\n - URL path: complete API path\n - Request headers: Authorization and other required headers\n - Path parameters: {id} and other path variables\n - Query parameters: pagination, filters, etc.\n - Request body: JSON Schema format\n - Response body: success and error responses\n - Field description table: type, required, example, description\n• Add usage examples: cURL, JavaScript, Python\n• Add version info: v1.0.0, last updated date\nMODE: write\nCONTEXT: @[module_endpoints] @[source_code]\nEXPECTED: Complete module API documentation in {lang} with all endpoints fully documented\nCONSTRAINTS: RESTful standards | Include all response codes\n--rule documentation-swagger-api",
|
||||
"output": "${module_doc_name}"
|
||||
}
|
||||
],
|
||||
@@ -559,7 +559,7 @@ bash(cat ${session_dir}/.process/swagger-planning-data.json | jq -r '.api_struct
|
||||
{
|
||||
"step": 1,
|
||||
"title": "Generate API overview",
|
||||
"cli_prompt": "PURPOSE: Generate API overview document with navigation and quick start guide\nTASK:\n• Create introduction: system features, tech stack, version\n• Write quick start guide: authentication, first request example\n• Build module navigation: categorized links to all modules\n• Document environment configuration: development, staging, production\n• List SDKs and tools: client libraries, Postman collection\nMODE: write\nCONTEXT: @[all_module_docs] @.workflow/docs/${project_name}/api/swagger.yaml\nEXPECTED: Complete API overview in {lang} with navigation links\nRULES: $(cat ~/.claude/workflows/cli-templates/protocols/write-protocol.md) | Clear structure | Quick start focus",
|
||||
"cli_prompt": "PURPOSE: Generate API overview document with navigation and quick start guide\nTASK:\n• Create introduction: system features, tech stack, version\n• Write quick start guide: authentication, first request example\n• Build module navigation: categorized links to all modules\n• Document environment configuration: development, staging, production\n• List SDKs and tools: client libraries, Postman collection\nMODE: write\nCONTEXT: @[all_module_docs] @.workflow/docs/${project_name}/api/swagger.yaml\nEXPECTED: Complete API overview in {lang} with navigation links\nCONSTRAINTS: Clear structure | Quick start focus\n--rule development-feature",
|
||||
"output": "README.md"
|
||||
}
|
||||
],
|
||||
@@ -602,7 +602,7 @@ bash(cat ${session_dir}/.process/swagger-planning-data.json | jq -r '.api_struct
|
||||
{
|
||||
"step": 1,
|
||||
"title": "Generate test report",
|
||||
"cli_prompt": "PURPOSE: Generate comprehensive API test validation report\nTASK:\n• Document test environment configuration\n• Calculate endpoint coverage statistics\n• Report test results: pass/fail counts\n• Document boundary tests: parameter limits, null values, special characters\n• Document exception tests: auth failures, permission denied, resource not found\n• List issues found with recommendations\nMODE: write\nCONTEXT: @[swagger_spec]\nEXPECTED: Complete test report in {lang} with detailed results\nRULES: $(cat ~/.claude/workflows/cli-templates/protocols/write-protocol.md) | Include test cases | Clear pass/fail status",
|
||||
"cli_prompt": "PURPOSE: Generate comprehensive API test validation report\nTASK:\n• Document test environment configuration\n• Calculate endpoint coverage statistics\n• Report test results: pass/fail counts\n• Document boundary tests: parameter limits, null values, special characters\n• Document exception tests: auth failures, permission denied, resource not found\n• List issues found with recommendations\nMODE: write\nCONTEXT: @[swagger_spec]\nEXPECTED: Complete test report in {lang} with detailed results\nCONSTRAINTS: Include test cases | Clear pass/fail status\n--rule development-tests",
|
||||
"output": "{test_doc_name}"
|
||||
}
|
||||
],
|
||||
|
||||
@@ -147,8 +147,8 @@ You are generating path-conditional rules for Claude Code.
|
||||
|
||||
## Instructions
|
||||
|
||||
Read the agent prompt template for detailed instructions:
|
||||
$(cat ~/.claude/workflows/cli-templates/prompts/rules/tech-rules-agent-prompt.txt)
|
||||
Read the agent prompt template for detailed instructions.
|
||||
Use --rule rules-tech-rules-agent-prompt to load the template automatically.
|
||||
|
||||
## Execution Steps
|
||||
|
||||
|
||||
666
.claude/commands/workflow/debug-with-file.md
Normal file
666
.claude/commands/workflow/debug-with-file.md
Normal file
@@ -0,0 +1,666 @@
|
||||
---
|
||||
name: debug-with-file
|
||||
description: Interactive hypothesis-driven debugging with documented exploration, understanding evolution, and Gemini-assisted correction
|
||||
argument-hint: "\"bug description or error message\""
|
||||
allowed-tools: TodoWrite(*), Task(*), AskUserQuestion(*), Read(*), Grep(*), Glob(*), Bash(*), Edit(*), Write(*)
|
||||
---
|
||||
|
||||
# Workflow Debug-With-File Command (/workflow:debug-with-file)
|
||||
|
||||
## Overview
|
||||
|
||||
Enhanced evidence-based debugging with **documented exploration process**. Records understanding evolution, consolidates insights, and uses Gemini to correct misunderstandings.
|
||||
|
||||
**Core workflow**: Explore → Document → Log → Analyze → Correct Understanding → Fix → Verify
|
||||
|
||||
**Key enhancements over /workflow:debug**:
|
||||
- **understanding.md**: Timeline of exploration and learning
|
||||
- **Gemini-assisted correction**: Validates and corrects hypotheses
|
||||
- **Consolidation**: Simplifies proven-wrong understanding to avoid clutter
|
||||
- **Learning retention**: Preserves what was learned, even from failed attempts
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
/workflow:debug-with-file <BUG_DESCRIPTION>
|
||||
|
||||
# Arguments
|
||||
<bug-description> Bug description, error message, or stack trace (required)
|
||||
```
|
||||
|
||||
## Execution Process
|
||||
|
||||
```
|
||||
Session Detection:
|
||||
├─ Check if debug session exists for this bug
|
||||
├─ EXISTS + understanding.md exists → Continue mode
|
||||
└─ NOT_FOUND → Explore mode
|
||||
|
||||
Explore Mode:
|
||||
├─ Locate error source in codebase
|
||||
├─ Document initial understanding in understanding.md
|
||||
├─ Generate testable hypotheses with Gemini validation
|
||||
├─ Add NDJSON logging instrumentation
|
||||
└─ Output: Hypothesis list + await user reproduction
|
||||
|
||||
Analyze Mode:
|
||||
├─ Parse debug.log, validate each hypothesis
|
||||
├─ Use Gemini to analyze evidence and correct understanding
|
||||
├─ Update understanding.md with:
|
||||
│ ├─ New evidence
|
||||
│ ├─ Corrected misunderstandings (strikethrough + correction)
|
||||
│ └─ Consolidated current understanding
|
||||
└─ Decision:
|
||||
├─ Confirmed → Fix root cause
|
||||
├─ Inconclusive → Add more logging, iterate
|
||||
└─ All rejected → Gemini-assisted new hypotheses
|
||||
|
||||
Fix & Cleanup:
|
||||
├─ Apply fix based on confirmed hypothesis
|
||||
├─ User verifies
|
||||
├─ Document final understanding + lessons learned
|
||||
├─ Remove debug instrumentation
|
||||
└─ If not fixed → Return to Analyze mode
|
||||
```
|
||||
|
||||
## Implementation
|
||||
|
||||
### Session Setup & Mode Detection
|
||||
|
||||
```javascript
|
||||
const getUtc8ISOString = () => new Date(Date.now() + 8 * 60 * 60 * 1000).toISOString()
|
||||
|
||||
const bugSlug = bug_description.toLowerCase().replace(/[^a-z0-9]+/g, '-').substring(0, 30)
|
||||
const dateStr = getUtc8ISOString().substring(0, 10)
|
||||
|
||||
const sessionId = `DBG-${bugSlug}-${dateStr}`
|
||||
const sessionFolder = `.workflow/.debug/${sessionId}`
|
||||
const debugLogPath = `${sessionFolder}/debug.log`
|
||||
const understandingPath = `${sessionFolder}/understanding.md`
|
||||
const hypothesesPath = `${sessionFolder}/hypotheses.json`
|
||||
|
||||
// Auto-detect mode
|
||||
const sessionExists = fs.existsSync(sessionFolder)
|
||||
const hasUnderstanding = sessionExists && fs.existsSync(understandingPath)
|
||||
const logHasContent = sessionExists && fs.existsSync(debugLogPath) && fs.statSync(debugLogPath).size > 0
|
||||
|
||||
const mode = logHasContent ? 'analyze' : (hasUnderstanding ? 'continue' : 'explore')
|
||||
|
||||
if (!sessionExists) {
|
||||
bash(`mkdir -p ${sessionFolder}`)
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Explore Mode
|
||||
|
||||
**Step 1.1: Locate Error Source**
|
||||
|
||||
```javascript
|
||||
// Extract keywords from bug description
|
||||
const keywords = extractErrorKeywords(bug_description)
|
||||
|
||||
// Search codebase for error locations
|
||||
const searchResults = []
|
||||
for (const keyword of keywords) {
|
||||
const results = Grep({ pattern: keyword, path: ".", output_mode: "content", "-C": 3 })
|
||||
searchResults.push({ keyword, results })
|
||||
}
|
||||
|
||||
// Identify affected files and functions
|
||||
const affectedLocations = analyzeSearchResults(searchResults)
|
||||
```
|
||||
|
||||
**Step 1.2: Document Initial Understanding**
|
||||
|
||||
Create `understanding.md` with exploration timeline:
|
||||
|
||||
```markdown
|
||||
# Understanding Document
|
||||
|
||||
**Session ID**: ${sessionId}
|
||||
**Bug Description**: ${bug_description}
|
||||
**Started**: ${getUtc8ISOString()}
|
||||
|
||||
---
|
||||
|
||||
## Exploration Timeline
|
||||
|
||||
### Iteration 1 - Initial Exploration (${timestamp})
|
||||
|
||||
#### Current Understanding
|
||||
|
||||
Based on bug description and initial code search:
|
||||
|
||||
- Error pattern: ${errorPattern}
|
||||
- Affected areas: ${affectedLocations.map(l => l.file).join(', ')}
|
||||
- Initial hypothesis: ${initialThoughts}
|
||||
|
||||
#### Evidence from Code Search
|
||||
|
||||
${searchResults.map(r => `
|
||||
**Keyword: "${r.keyword}"**
|
||||
- Found in: ${r.results.files.join(', ')}
|
||||
- Key findings: ${r.insights}
|
||||
`).join('\n')}
|
||||
|
||||
#### Next Steps
|
||||
|
||||
- Generate testable hypotheses
|
||||
- Add instrumentation
|
||||
- Await reproduction
|
||||
|
||||
---
|
||||
|
||||
## Current Consolidated Understanding
|
||||
|
||||
${initialConsolidatedUnderstanding}
|
||||
```
|
||||
|
||||
**Step 1.3: Gemini-Assisted Hypothesis Generation**
|
||||
|
||||
```bash
|
||||
ccw cli -p "
|
||||
PURPOSE: Generate debugging hypotheses for: ${bug_description}
|
||||
Success criteria: Testable hypotheses with clear evidence criteria
|
||||
|
||||
TASK:
|
||||
• Analyze error pattern and code search results
|
||||
• Identify 3-5 most likely root causes
|
||||
• For each hypothesis, specify:
|
||||
- What might be wrong
|
||||
- What evidence would confirm/reject it
|
||||
- Where to add instrumentation
|
||||
• Rank by likelihood
|
||||
|
||||
MODE: analysis
|
||||
|
||||
CONTEXT: @${sessionFolder}/understanding.md | Search results in understanding.md
|
||||
|
||||
EXPECTED:
|
||||
- Structured hypothesis list (JSON format)
|
||||
- Each hypothesis with: id, description, testable_condition, logging_point, evidence_criteria
|
||||
- Likelihood ranking (1=most likely)
|
||||
|
||||
CONSTRAINTS: Focus on testable conditions
|
||||
" --tool gemini --mode analysis --rule analysis-diagnose-bug-root-cause
|
||||
```
|
||||
|
||||
Save Gemini output to `hypotheses.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"iteration": 1,
|
||||
"timestamp": "2025-01-21T10:00:00+08:00",
|
||||
"hypotheses": [
|
||||
{
|
||||
"id": "H1",
|
||||
"description": "Data structure mismatch - expected key not present",
|
||||
"testable_condition": "Check if target key exists in dict",
|
||||
"logging_point": "file.py:func:42",
|
||||
"evidence_criteria": {
|
||||
"confirm": "data shows missing key",
|
||||
"reject": "key exists with valid value"
|
||||
},
|
||||
"likelihood": 1,
|
||||
"status": "pending"
|
||||
}
|
||||
],
|
||||
"gemini_insights": "...",
|
||||
"corrected_assumptions": []
|
||||
}
|
||||
```
|
||||
|
||||
**Step 1.4: Add NDJSON Instrumentation**
|
||||
|
||||
For each hypothesis, add logging (same as original debug command).
|
||||
|
||||
**Step 1.5: Update understanding.md**
|
||||
|
||||
Append hypothesis section:
|
||||
|
||||
```markdown
|
||||
#### Hypotheses Generated (Gemini-Assisted)
|
||||
|
||||
${hypotheses.map(h => `
|
||||
**${h.id}** (Likelihood: ${h.likelihood}): ${h.description}
|
||||
- Logging at: ${h.logging_point}
|
||||
- Testing: ${h.testable_condition}
|
||||
- Evidence to confirm: ${h.evidence_criteria.confirm}
|
||||
- Evidence to reject: ${h.evidence_criteria.reject}
|
||||
`).join('\n')}
|
||||
|
||||
**Gemini Insights**: ${geminiInsights}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Analyze Mode
|
||||
|
||||
**Step 2.1: Parse Debug Log**
|
||||
|
||||
```javascript
|
||||
// Parse NDJSON log
|
||||
const entries = Read(debugLogPath).split('\n')
|
||||
.filter(l => l.trim())
|
||||
.map(l => JSON.parse(l))
|
||||
|
||||
// Group by hypothesis
|
||||
const byHypothesis = groupBy(entries, 'hid')
|
||||
```
|
||||
|
||||
**Step 2.2: Gemini-Assisted Evidence Analysis**
|
||||
|
||||
```bash
|
||||
ccw cli -p "
|
||||
PURPOSE: Analyze debug log evidence to validate/correct hypotheses for: ${bug_description}
|
||||
Success criteria: Clear verdict per hypothesis + corrected understanding
|
||||
|
||||
TASK:
|
||||
• Parse log entries by hypothesis
|
||||
• Evaluate evidence against expected criteria
|
||||
• Determine verdict: confirmed | rejected | inconclusive
|
||||
• Identify incorrect assumptions from previous understanding
|
||||
• Suggest corrections to understanding
|
||||
|
||||
MODE: analysis
|
||||
|
||||
CONTEXT:
|
||||
@${debugLogPath}
|
||||
@${understandingPath}
|
||||
@${hypothesesPath}
|
||||
|
||||
EXPECTED:
|
||||
- Per-hypothesis verdict with reasoning
|
||||
- Evidence summary
|
||||
- List of incorrect assumptions with corrections
|
||||
- Updated consolidated understanding
|
||||
- Root cause if confirmed, or next investigation steps
|
||||
|
||||
CONSTRAINTS: Evidence-based reasoning only, no speculation
|
||||
" --tool gemini --mode analysis --rule analysis-diagnose-bug-root-cause
|
||||
```
|
||||
|
||||
**Step 2.3: Update Understanding with Corrections**
|
||||
|
||||
Append new iteration to `understanding.md`:
|
||||
|
||||
```markdown
|
||||
### Iteration ${n} - Evidence Analysis (${timestamp})
|
||||
|
||||
#### Log Analysis Results
|
||||
|
||||
${results.map(r => `
|
||||
**${r.id}**: ${r.verdict.toUpperCase()}
|
||||
- Evidence: ${JSON.stringify(r.evidence)}
|
||||
- Reasoning: ${r.reason}
|
||||
`).join('\n')}
|
||||
|
||||
#### Corrected Understanding
|
||||
|
||||
Previous misunderstandings identified and corrected:
|
||||
|
||||
${corrections.map(c => `
|
||||
- ~~${c.wrong}~~ → ${c.corrected}
|
||||
- Why wrong: ${c.reason}
|
||||
- Evidence: ${c.evidence}
|
||||
`).join('\n')}
|
||||
|
||||
#### New Insights
|
||||
|
||||
${newInsights.join('\n- ')}
|
||||
|
||||
#### Gemini Analysis
|
||||
|
||||
${geminiAnalysis}
|
||||
|
||||
${confirmedHypothesis ? `
|
||||
#### Root Cause Identified
|
||||
|
||||
**${confirmedHypothesis.id}**: ${confirmedHypothesis.description}
|
||||
|
||||
Evidence supporting this conclusion:
|
||||
${confirmedHypothesis.supportingEvidence}
|
||||
` : `
|
||||
#### Next Steps
|
||||
|
||||
${nextSteps}
|
||||
`}
|
||||
|
||||
---
|
||||
|
||||
## Current Consolidated Understanding (Updated)
|
||||
|
||||
${consolidatedUnderstanding}
|
||||
```
|
||||
|
||||
**Step 2.4: Consolidate Understanding**
|
||||
|
||||
At the bottom of `understanding.md`, update the consolidated section:
|
||||
|
||||
- Remove or simplify proven-wrong assumptions
|
||||
- Keep them in strikethrough for reference
|
||||
- Focus on current valid understanding
|
||||
- Avoid repeating details from timeline
|
||||
|
||||
```markdown
|
||||
## Current Consolidated Understanding
|
||||
|
||||
### What We Know
|
||||
|
||||
- ${validUnderstanding1}
|
||||
- ${validUnderstanding2}
|
||||
|
||||
### What Was Disproven
|
||||
|
||||
- ~~Initial assumption: ${wrongAssumption}~~ (Evidence: ${disproofEvidence})
|
||||
|
||||
### Current Investigation Focus
|
||||
|
||||
${currentFocus}
|
||||
|
||||
### Remaining Questions
|
||||
|
||||
- ${openQuestion1}
|
||||
- ${openQuestion2}
|
||||
```
|
||||
|
||||
**Step 2.5: Update hypotheses.json**
|
||||
|
||||
```json
|
||||
{
|
||||
"iteration": 2,
|
||||
"timestamp": "2025-01-21T10:15:00+08:00",
|
||||
"hypotheses": [
|
||||
{
|
||||
"id": "H1",
|
||||
"status": "rejected",
|
||||
"verdict_reason": "Evidence shows key exists with valid value",
|
||||
"evidence": {...}
|
||||
},
|
||||
{
|
||||
"id": "H2",
|
||||
"status": "confirmed",
|
||||
"verdict_reason": "Log data confirms timing issue",
|
||||
"evidence": {...}
|
||||
}
|
||||
],
|
||||
"gemini_corrections": [
|
||||
{
|
||||
"wrong_assumption": "...",
|
||||
"corrected_to": "...",
|
||||
"reason": "..."
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Fix & Verification
|
||||
|
||||
**Step 3.1: Apply Fix**
|
||||
|
||||
(Same as original debug command)
|
||||
|
||||
**Step 3.2: Document Resolution**
|
||||
|
||||
Append to `understanding.md`:
|
||||
|
||||
```markdown
|
||||
### Iteration ${n} - Resolution (${timestamp})
|
||||
|
||||
#### Fix Applied
|
||||
|
||||
- Modified files: ${modifiedFiles.join(', ')}
|
||||
- Fix description: ${fixDescription}
|
||||
- Root cause addressed: ${rootCause}
|
||||
|
||||
#### Verification Results
|
||||
|
||||
${verificationResults}
|
||||
|
||||
#### Lessons Learned
|
||||
|
||||
What we learned from this debugging session:
|
||||
|
||||
1. ${lesson1}
|
||||
2. ${lesson2}
|
||||
3. ${lesson3}
|
||||
|
||||
#### Key Insights for Future
|
||||
|
||||
- ${insight1}
|
||||
- ${insight2}
|
||||
```
|
||||
|
||||
**Step 3.3: Cleanup**
|
||||
|
||||
Remove debug instrumentation (same as original command).
|
||||
|
||||
---
|
||||
|
||||
## Session Folder Structure
|
||||
|
||||
```
|
||||
.workflow/.debug/DBG-{slug}-{date}/
|
||||
├── debug.log # NDJSON log (execution evidence)
|
||||
├── understanding.md # NEW: Exploration timeline + consolidated understanding
|
||||
├── hypotheses.json # NEW: Hypothesis history with verdicts
|
||||
└── resolution.md # Optional: Final summary
|
||||
```
|
||||
|
||||
## Understanding Document Template
|
||||
|
||||
```markdown
|
||||
# Understanding Document
|
||||
|
||||
**Session ID**: DBG-xxx-2025-01-21
|
||||
**Bug Description**: [original description]
|
||||
**Started**: 2025-01-21T10:00:00+08:00
|
||||
|
||||
---
|
||||
|
||||
## Exploration Timeline
|
||||
|
||||
### Iteration 1 - Initial Exploration (2025-01-21 10:00)
|
||||
|
||||
#### Current Understanding
|
||||
...
|
||||
|
||||
#### Evidence from Code Search
|
||||
...
|
||||
|
||||
#### Hypotheses Generated (Gemini-Assisted)
|
||||
...
|
||||
|
||||
### Iteration 2 - Evidence Analysis (2025-01-21 10:15)
|
||||
|
||||
#### Log Analysis Results
|
||||
...
|
||||
|
||||
#### Corrected Understanding
|
||||
- ~~[wrong]~~ → [corrected]
|
||||
|
||||
#### Gemini Analysis
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
## Current Consolidated Understanding
|
||||
|
||||
### What We Know
|
||||
- [valid understanding points]
|
||||
|
||||
### What Was Disproven
|
||||
- ~~[disproven assumptions]~~
|
||||
|
||||
### Current Investigation Focus
|
||||
[current focus]
|
||||
|
||||
### Remaining Questions
|
||||
- [open questions]
|
||||
```
|
||||
|
||||
## Iteration Flow
|
||||
|
||||
```
|
||||
First Call (/workflow:debug-with-file "error"):
|
||||
├─ No session exists → Explore mode
|
||||
├─ Extract error keywords, search codebase
|
||||
├─ Document initial understanding in understanding.md
|
||||
├─ Use Gemini to generate hypotheses
|
||||
├─ Add logging instrumentation
|
||||
└─ Await user reproduction
|
||||
|
||||
After Reproduction (/workflow:debug-with-file "error"):
|
||||
├─ Session exists + debug.log has content → Analyze mode
|
||||
├─ Parse log, use Gemini to evaluate hypotheses
|
||||
├─ Update understanding.md with:
|
||||
│ ├─ Evidence analysis results
|
||||
│ ├─ Corrected misunderstandings (strikethrough)
|
||||
│ ├─ New insights
|
||||
│ └─ Updated consolidated understanding
|
||||
├─ Update hypotheses.json with verdicts
|
||||
└─ Decision:
|
||||
├─ Confirmed → Fix → Document resolution
|
||||
├─ Inconclusive → Add logging, document next steps
|
||||
└─ All rejected → Gemini-assisted new hypotheses
|
||||
|
||||
Output:
|
||||
├─ .workflow/.debug/DBG-{slug}-{date}/debug.log
|
||||
├─ .workflow/.debug/DBG-{slug}-{date}/understanding.md (evolving document)
|
||||
└─ .workflow/.debug/DBG-{slug}-{date}/hypotheses.json (history)
|
||||
```
|
||||
|
||||
## Gemini Integration Points
|
||||
|
||||
### 1. Hypothesis Generation (Explore Mode)
|
||||
|
||||
**Purpose**: Generate evidence-based, testable hypotheses
|
||||
|
||||
**Prompt Pattern**:
|
||||
```
|
||||
PURPOSE: Generate debugging hypotheses + evidence criteria
|
||||
TASK: Analyze error + code → testable hypotheses with clear pass/fail criteria
|
||||
CONTEXT: @understanding.md (search results)
|
||||
EXPECTED: JSON with hypotheses, likelihood ranking, evidence criteria
|
||||
```
|
||||
|
||||
### 2. Evidence Analysis (Analyze Mode)
|
||||
|
||||
**Purpose**: Validate hypotheses and correct misunderstandings
|
||||
|
||||
**Prompt Pattern**:
|
||||
```
|
||||
PURPOSE: Analyze debug log evidence + correct understanding
|
||||
TASK: Evaluate each hypothesis → identify wrong assumptions → suggest corrections
|
||||
CONTEXT: @debug.log @understanding.md @hypotheses.json
|
||||
EXPECTED: Verdicts + corrections + updated consolidated understanding
|
||||
```
|
||||
|
||||
### 3. New Hypothesis Generation (After All Rejected)
|
||||
|
||||
**Purpose**: Generate new hypotheses based on what was disproven
|
||||
|
||||
**Prompt Pattern**:
|
||||
```
|
||||
PURPOSE: Generate new hypotheses given disproven assumptions
|
||||
TASK: Review rejected hypotheses → identify knowledge gaps → new investigation angles
|
||||
CONTEXT: @understanding.md (with disproven section) @hypotheses.json
|
||||
EXPECTED: New hypotheses avoiding previously rejected paths
|
||||
```
|
||||
|
||||
## Error Correction Mechanism
|
||||
|
||||
### Correction Format in understanding.md
|
||||
|
||||
```markdown
|
||||
#### Corrected Understanding
|
||||
|
||||
- ~~Assumed dict key "config" was missing~~ → Key exists, but value is None
|
||||
- Why wrong: Only checked existence, not value validity
|
||||
- Evidence: H1 log shows {"config": null, "exists": true}
|
||||
|
||||
- ~~Thought error occurred in initialization~~ → Error happens during runtime update
|
||||
- Why wrong: Stack trace misread as init code
|
||||
- Evidence: H2 timestamp shows 30s after startup
|
||||
```
|
||||
|
||||
### Consolidation Rules
|
||||
|
||||
When updating "Current Consolidated Understanding":
|
||||
|
||||
1. **Simplify disproven items**: Move to "What Was Disproven" with single-line summary
|
||||
2. **Keep valid insights**: Promote confirmed findings to "What We Know"
|
||||
3. **Avoid duplication**: Don't repeat timeline details in consolidated section
|
||||
4. **Focus on current state**: What do we know NOW, not the journey
|
||||
5. **Preserve key corrections**: Keep important wrong→right transformations for learning
|
||||
|
||||
**Bad (cluttered)**:
|
||||
```markdown
|
||||
## Current Consolidated Understanding
|
||||
|
||||
In iteration 1 we thought X, but in iteration 2 we found Y, then in iteration 3...
|
||||
Also we checked A and found B, and then we checked C...
|
||||
```
|
||||
|
||||
**Good (consolidated)**:
|
||||
```markdown
|
||||
## Current Consolidated Understanding
|
||||
|
||||
### What We Know
|
||||
- Error occurs during runtime update, not initialization
|
||||
- Config value is None (not missing key)
|
||||
|
||||
### What Was Disproven
|
||||
- ~~Initialization error~~ (Timing evidence)
|
||||
- ~~Missing key hypothesis~~ (Key exists)
|
||||
|
||||
### Current Investigation Focus
|
||||
Why is config value None during update?
|
||||
```
|
||||
|
||||
## Post-Completion Expansion
|
||||
|
||||
完成后询问用户是否扩展为issue(test/enhance/refactor/doc),选中项调用 `/issue:new "{summary} - {dimension}"`
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Situation | Action |
|
||||
|-----------|--------|
|
||||
| Empty debug.log | Verify reproduction triggered the code path |
|
||||
| All hypotheses rejected | Use Gemini to generate new hypotheses based on disproven assumptions |
|
||||
| Fix doesn't work | Document failed fix attempt, iterate with refined understanding |
|
||||
| >5 iterations | Review consolidated understanding, escalate to `/workflow:lite-fix` with full context |
|
||||
| Gemini unavailable | Fallback to manual hypothesis generation, document without Gemini insights |
|
||||
| Understanding too long | Consolidate aggressively, archive old iterations to separate file |
|
||||
|
||||
## Comparison with /workflow:debug
|
||||
|
||||
| Feature | /workflow:debug | /workflow:debug-with-file |
|
||||
|---------|-----------------|---------------------------|
|
||||
| NDJSON logging | ✅ | ✅ |
|
||||
| Hypothesis generation | Manual | Gemini-assisted |
|
||||
| Exploration documentation | ❌ | ✅ understanding.md |
|
||||
| Understanding evolution | ❌ | ✅ Timeline + corrections |
|
||||
| Error correction | ❌ | ✅ Strikethrough + reasoning |
|
||||
| Consolidated learning | ❌ | ✅ Current understanding section |
|
||||
| Hypothesis history | ❌ | ✅ hypotheses.json |
|
||||
| Gemini validation | ❌ | ✅ At key decision points |
|
||||
|
||||
## Usage Recommendations
|
||||
|
||||
Use `/workflow:debug-with-file` when:
|
||||
- Complex bugs requiring multiple investigation rounds
|
||||
- Learning from debugging process is valuable
|
||||
- Team needs to understand debugging rationale
|
||||
- Bug might recur, documentation helps prevention
|
||||
|
||||
Use `/workflow:debug` when:
|
||||
- Simple, quick bugs
|
||||
- One-off issues
|
||||
- Documentation overhead not needed
|
||||
@@ -81,6 +81,7 @@ AskUserQuestion({
|
||||
options: [
|
||||
{ label: "Skip", description: "No review" },
|
||||
{ label: "Gemini Review", description: "Gemini CLI tool" },
|
||||
{ label: "Codex Review", description: "codex review --uncommitted" },
|
||||
{ label: "Agent Review", description: "Current agent review" }
|
||||
]
|
||||
}
|
||||
@@ -171,10 +172,23 @@ Output:
|
||||
**Operations**:
|
||||
- Initialize result tracking for multi-execution scenarios
|
||||
- Set up `previousExecutionResults` array for context continuity
|
||||
- **In-Memory Mode**: Echo execution strategy from lite-plan for transparency
|
||||
|
||||
```javascript
|
||||
// Initialize result tracking
|
||||
previousExecutionResults = []
|
||||
|
||||
// In-Memory Mode: Echo execution strategy (transparency before execution)
|
||||
if (executionContext) {
|
||||
console.log(`
|
||||
📋 Execution Strategy (from lite-plan):
|
||||
Method: ${executionContext.executionMethod}
|
||||
Review: ${executionContext.codeReviewTool}
|
||||
Tasks: ${executionContext.planObject.tasks.length}
|
||||
Complexity: ${executionContext.planObject.complexity}
|
||||
${executionContext.executorAssignments ? ` Assignments: ${JSON.stringify(executionContext.executorAssignments)}` : ''}
|
||||
`)
|
||||
}
|
||||
```
|
||||
|
||||
### Step 2: Task Grouping & Batch Creation
|
||||
@@ -392,16 +406,8 @@ ccw cli -p "${buildExecutionPrompt(batch)}" --tool codex --mode write
|
||||
|
||||
**Execution with fixed IDs** (predictable ID pattern):
|
||||
```javascript
|
||||
// Launch CLI in foreground (NOT background)
|
||||
// Timeout based on complexity: Low=40min, Medium=60min, High=100min
|
||||
const timeoutByComplexity = {
|
||||
"Low": 2400000, // 40 minutes
|
||||
"Medium": 3600000, // 60 minutes
|
||||
"High": 6000000 // 100 minutes
|
||||
}
|
||||
|
||||
// Launch CLI in background, wait for task hook callback
|
||||
// Generate fixed execution ID: ${sessionId}-${groupId}
|
||||
// This enables predictable ID lookup without relying on resume context chains
|
||||
const sessionId = executionContext?.session?.id || 'standalone'
|
||||
const fixedExecutionId = `${sessionId}-${batch.groupId}` // e.g., "implement-auth-2025-12-13-P1"
|
||||
|
||||
@@ -413,16 +419,12 @@ const cli_command = previousCliId
|
||||
? `ccw cli -p "${buildExecutionPrompt(batch)}" --tool codex --mode write --id ${fixedExecutionId} --resume ${previousCliId}`
|
||||
: `ccw cli -p "${buildExecutionPrompt(batch)}" --tool codex --mode write --id ${fixedExecutionId}`
|
||||
|
||||
bash_result = Bash(
|
||||
// Execute in background, stop output and wait for task hook callback
|
||||
Bash(
|
||||
command=cli_command,
|
||||
timeout=timeoutByComplexity[planObject.complexity] || 3600000
|
||||
run_in_background=true
|
||||
)
|
||||
|
||||
// Execution ID is now predictable: ${fixedExecutionId}
|
||||
// Can also extract from output: "ID: implement-auth-2025-12-13-P1"
|
||||
const cliExecutionId = fixedExecutionId
|
||||
|
||||
// Update TodoWrite when execution completes
|
||||
// STOP HERE - CLI executes in background, task hook will notify on completion
|
||||
```
|
||||
|
||||
**Resume on Failure** (with fixed ID):
|
||||
@@ -485,7 +487,7 @@ TASK: • Verify plan acceptance criteria fulfillment • Analyze code quality
|
||||
MODE: analysis
|
||||
CONTEXT: @**/* @{plan.json} [@{exploration.json}] | Memory: Review lite-execute changes against plan requirements
|
||||
EXPECTED: Quality assessment with acceptance criteria verification, issue identification, and recommendations. Explicitly check each acceptance criterion from plan.json tasks.
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/02-review-code-quality.txt) | Focus on plan acceptance criteria and plan adherence | analysis=READ-ONLY
|
||||
CONSTRAINTS: Focus on plan acceptance criteria and plan adherence | analysis=READ-ONLY
|
||||
```
|
||||
|
||||
**Tool-Specific Execution** (Apply shared prompt template above):
|
||||
@@ -504,8 +506,9 @@ ccw cli -p "[Shared Prompt Template with artifacts]" --tool gemini --mode analys
|
||||
ccw cli -p "[Shared Prompt Template with artifacts]" --tool qwen --mode analysis
|
||||
# Same prompt as Gemini, different execution engine
|
||||
|
||||
# Method 4: Codex Review (autonomous)
|
||||
ccw cli -p "[Verify plan acceptance criteria at ${plan.json}]" --tool codex --mode write
|
||||
# Method 4: Codex Review (git-aware)
|
||||
ccw cli -p "[Shared Prompt Template with artifacts]" --tool codex --mode review --uncommitted
|
||||
# Reviews uncommitted changes against plan acceptance criteria
|
||||
```
|
||||
|
||||
**Multi-Round Review with Fixed IDs**:
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
name: workflow:lite-lite-lite
|
||||
description: Ultra-lightweight multi-tool analysis and direct execution. No artifacts, auto tool selection based on task analysis, user-driven iteration via AskUser.
|
||||
description: Ultra-lightweight multi-tool analysis and direct execution. No artifacts for simple tasks; auto-creates planning docs in .workflow/.scratchpad/ for complex tasks. Auto tool selection based on task analysis, user-driven iteration via AskUser.
|
||||
argument-hint: "<task description>"
|
||||
allowed-tools: TodoWrite(*), Task(*), AskUserQuestion(*), Read(*), Bash(*), mcp__ace-tool__search_context(*)
|
||||
allowed-tools: TodoWrite(*), Task(*), AskUserQuestion(*), Read(*), Bash(*), Write(*), mcp__ace-tool__search_context(*), mcp__ccw-tools__write_file(*)
|
||||
---
|
||||
|
||||
# Ultra-Lite Multi-Tool Workflow
|
||||
@@ -14,22 +14,23 @@ allowed-tools: TodoWrite(*), Task(*), AskUserQuestion(*), Read(*), Bash(*), mcp_
|
||||
/workflow:lite-lite-lite "Refactor payment module for multi-gateway support"
|
||||
```
|
||||
|
||||
**Core Philosophy**: Minimal friction, maximum velocity. No files, no artifacts - just analyze and execute.
|
||||
**Core Philosophy**: Minimal friction, maximum velocity. Simple tasks = no artifacts. Complex tasks = lightweight planning doc in `.workflow/.scratchpad/`.
|
||||
|
||||
## Overview
|
||||
|
||||
**Zero-artifact workflow**: Clarify → Select Tools → Multi-Mode Analysis → Decision → Direct Execution
|
||||
**Complexity-aware workflow**: Clarify → Assess Complexity → Select Tools → Multi-Mode Analysis → Decision → Direct Execution
|
||||
|
||||
**vs multi-cli-plan**: No IMPL_PLAN.md, plan.json, synthesis.json - all state in memory.
|
||||
**vs multi-cli-plan**: No IMPL_PLAN.md, plan.json, synthesis.json - state in memory or lightweight scratchpad doc for complex tasks.
|
||||
|
||||
## Execution Flow
|
||||
|
||||
```
|
||||
Phase 1: Clarify Requirements → AskUser for missing details
|
||||
Phase 1.5: Assess Complexity → Determine if planning doc needed
|
||||
Phase 2: Select Tools (CLI → Mode → Agent) → 3-step selection
|
||||
Phase 3: Multi-Mode Analysis → Execute with --resume chaining
|
||||
Phase 4: User Decision → Execute / Refine / Change / Cancel
|
||||
Phase 5: Direct Execution → No plan files, immediate implementation
|
||||
Phase 5: Direct Execution → No plan files (simple) or scratchpad doc (complex)
|
||||
```
|
||||
|
||||
## Phase 1: Clarify Requirements
|
||||
@@ -58,6 +59,25 @@ mcp__ace-tool__search_context({
|
||||
})
|
||||
```
|
||||
|
||||
## Phase 1.5: Assess Complexity
|
||||
|
||||
| Level | Creates Plan Doc | Trigger Keywords |
|
||||
|-------|------------------|------------------|
|
||||
| **simple** | ❌ | (default) |
|
||||
| **moderate** | ✅ | module, system, service, integration, multiple |
|
||||
| **complex** | ✅ | refactor, migrate, security, auth, payment, database |
|
||||
|
||||
```javascript
|
||||
// Complexity detection (after ACE query)
|
||||
const isComplex = /refactor|migrate|security|auth|payment|database/i.test(taskDescription)
|
||||
const isModerate = /module|system|service|integration|multiple/i.test(taskDescription) || aceContext?.relevant_files?.length > 2
|
||||
|
||||
if (isComplex || isModerate) {
|
||||
const planPath = `.workflow/.scratchpad/lite3-${taskSlug}-${dateStr}.md`
|
||||
// Create planning doc with: Task, Status, Complexity, Analysis Summary, Execution Plan, Progress Log
|
||||
}
|
||||
```
|
||||
|
||||
## Phase 2: Select Tools
|
||||
|
||||
### Tool Definitions
|
||||
@@ -167,7 +187,7 @@ TASK: ${tasks.map(t => `• ${t}`).join(' ')}
|
||||
MODE: analysis
|
||||
CONTEXT: @**/*
|
||||
EXPECTED: ${expected}
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/analysis-protocol.md) | ${rules}
|
||||
CONSTRAINTS: ${rules}
|
||||
`
|
||||
}
|
||||
|
||||
@@ -308,6 +328,8 @@ function aggregateResults(mode, results) {
|
||||
critiques: parseCritiques(results.find(r => r.phase === 'challenge')?.result), riskScore: calculateRiskScore(results) }
|
||||
}
|
||||
}
|
||||
|
||||
// If planPath exists: update Analysis Summary & Execution Plan sections
|
||||
```
|
||||
|
||||
## Phase 4: User Decision
|
||||
@@ -348,13 +370,14 @@ AskUserQuestion({
|
||||
multiSelect: false
|
||||
}]
|
||||
})
|
||||
// If planPath exists: record decision to Decisions Made table
|
||||
// Routing: Execute → Phase 5 | Refine → Phase 3 | Change → Phase 2 | Cancel → End
|
||||
```
|
||||
|
||||
## Phase 5: Direct Execution
|
||||
|
||||
```javascript
|
||||
// No IMPL_PLAN.md, no plan.json - direct implementation
|
||||
// Simple tasks: No artifacts | Complex tasks: Update scratchpad doc
|
||||
const executionAgents = agents.filter(a => a.canExecute)
|
||||
const executionTool = selectedAgent.canExecute ? selectedAgent : selectedCLIs[0]
|
||||
|
||||
@@ -373,11 +396,12 @@ TASK: ${extractedTasks.join(' • ')}
|
||||
MODE: write
|
||||
CONTEXT: @${affectedFiles.join(' @')}
|
||||
EXPECTED: Working implementation with all changes applied
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/write-protocol.md)
|
||||
CONSTRAINTS: Follow existing patterns
|
||||
" --tool ${executionTool.name} --mode write`,
|
||||
run_in_background: false
|
||||
})
|
||||
}
|
||||
// If planPath exists: update Status to completed/failed, append to Progress Log
|
||||
```
|
||||
|
||||
## TodoWrite Structure
|
||||
@@ -385,6 +409,7 @@ RULES: $(cat ~/.claude/workflows/cli-templates/protocols/write-protocol.md)
|
||||
```javascript
|
||||
TodoWrite({ todos: [
|
||||
{ content: "Phase 1: Clarify requirements", status: "in_progress", activeForm: "Clarifying requirements" },
|
||||
{ content: "Phase 1.5: Assess complexity", status: "pending", activeForm: "Assessing complexity" },
|
||||
{ content: "Phase 2: Select tools", status: "pending", activeForm: "Selecting tools" },
|
||||
{ content: "Phase 3: Multi-mode analysis", status: "pending", activeForm: "Running analysis" },
|
||||
{ content: "Phase 4: User decision", status: "pending", activeForm: "Awaiting decision" },
|
||||
@@ -409,16 +434,19 @@ TodoWrite({ todos: [
|
||||
| Task unclear | Default to first CLI + code-developer |
|
||||
| Ambiguous task | Force clarification via AskUser |
|
||||
| Execution fails | Present error, ask user for direction |
|
||||
| Plan doc write fails | Continue without doc (degrade to zero-artifact mode) |
|
||||
| Scratchpad dir missing | Auto-create `.workflow/.scratchpad/` |
|
||||
|
||||
## Comparison with multi-cli-plan
|
||||
|
||||
| Aspect | lite-lite-lite | multi-cli-plan |
|
||||
|--------|----------------|----------------|
|
||||
| **Artifacts** | None | IMPL_PLAN.md, plan.json, synthesis.json |
|
||||
| **Artifacts** | Conditional (scratchpad doc for complex tasks) | Always (IMPL_PLAN.md, plan.json, synthesis.json) |
|
||||
| **Session** | Stateless (--resume chaining) | Persistent session folder |
|
||||
| **Tool Selection** | 3-step (CLI → Mode → Agent) | Config-driven fixed tools |
|
||||
| **Analysis Modes** | 5 modes with --resume | Fixed synthesis rounds |
|
||||
| **Best For** | Quick analysis, adversarial validation | Complex multi-step implementations |
|
||||
| **Complexity** | Auto-detected (simple/moderate/complex) | Assumed complex |
|
||||
| **Best For** | Quick analysis, simple-to-moderate tasks | Complex multi-step implementations |
|
||||
|
||||
## Post-Completion Expansion
|
||||
|
||||
|
||||
@@ -497,6 +497,7 @@ ${plan.tasks.map((t, i) => `${i+1}. ${t.title} (${t.file})`).join('\n')}
|
||||
|
||||
**Step 4.2: Collect Confirmation**
|
||||
```javascript
|
||||
// Note: Execution "Other" option allows specifying CLI tools from ~/.claude/cli-tools.json
|
||||
AskUserQuestion({
|
||||
questions: [
|
||||
{
|
||||
@@ -524,8 +525,9 @@ AskUserQuestion({
|
||||
header: "Review",
|
||||
multiSelect: false,
|
||||
options: [
|
||||
{ label: "Gemini Review", description: "Gemini CLI" },
|
||||
{ label: "Agent Review", description: "@code-reviewer" },
|
||||
{ label: "Gemini Review", description: "Gemini CLI review" },
|
||||
{ label: "Codex Review", description: "codex review --uncommitted" },
|
||||
{ label: "Agent Review", description: "@code-reviewer agent" },
|
||||
{ label: "Skip", description: "No review" }
|
||||
]
|
||||
}
|
||||
|
||||
@@ -17,15 +17,13 @@ allowed-tools: TodoWrite(*), Task(*), AskUserQuestion(*), Read(*), Bash(*), Writ
|
||||
/workflow:multi-cli-plan "Add dark mode support" --max-rounds=3
|
||||
/workflow:multi-cli-plan "Refactor payment module" --tools=gemini,codex,claude
|
||||
/workflow:multi-cli-plan "Fix memory leak" --mode=serial
|
||||
|
||||
# Resume session
|
||||
/workflow:lite-execute --session=MCP-xxx
|
||||
```
|
||||
|
||||
**Context Source**: ACE semantic search + Multi-CLI analysis
|
||||
**Output Directory**: `.workflow/.multi-cli-plan/{session-id}/`
|
||||
**Default Max Rounds**: 3 (convergence may complete earlier)
|
||||
**CLI Tools**: @cli-discuss-agent (analysis), @cli-lite-planning-agent (plan generation)
|
||||
**Execution**: Auto-hands off to `/workflow:lite-execute --in-memory` after plan approval
|
||||
|
||||
## What & Why
|
||||
|
||||
@@ -71,22 +69,27 @@ Phase 3: Present Options
|
||||
└─ Display solutions with trade-offs from agent output
|
||||
|
||||
Phase 4: User Decision
|
||||
├─ Approve solution → Phase 5
|
||||
├─ Need clarification → Return to Phase 2
|
||||
└─ Change direction → Reset with feedback
|
||||
├─ Select solution approach
|
||||
├─ Select execution method (Agent/Codex/Auto)
|
||||
├─ Select code review tool (Skip/Gemini/Codex/Agent)
|
||||
└─ Route:
|
||||
├─ Approve → Phase 5
|
||||
├─ Need More Analysis → Return to Phase 2
|
||||
└─ Cancel → Save session
|
||||
|
||||
Phase 5: Plan Generation (via @cli-lite-planning-agent)
|
||||
├─ Generate IMPL_PLAN.md + plan.json
|
||||
└─ Hand off to /workflow:lite-execute
|
||||
Phase 5: Plan Generation & Execution Handoff
|
||||
├─ Generate plan.json (via @cli-lite-planning-agent)
|
||||
├─ Build executionContext with user selections
|
||||
└─ Execute to /workflow:lite-execute --in-memory
|
||||
```
|
||||
|
||||
### Agent Roles
|
||||
|
||||
| Agent | Responsibility |
|
||||
|-------|---------------|
|
||||
| **Orchestrator** | Session management, ACE context, user decisions, phase transitions |
|
||||
| **Orchestrator** | Session management, ACE context, user decisions, phase transitions, executionContext assembly |
|
||||
| **@cli-discuss-agent** | Multi-CLI execution (Gemini/Codex/Claude), cross-verification, solution synthesis, synthesis.json output |
|
||||
| **@cli-lite-planning-agent** | Task decomposition, IMPL_PLAN.md + plan.json generation |
|
||||
| **@cli-lite-planning-agent** | Task decomposition, plan.json generation following schema |
|
||||
|
||||
## Core Responsibilities
|
||||
|
||||
@@ -205,25 +208,49 @@ Disagreements: ${synthesis.cross_verification.disagreements.length}
|
||||
**Decision Options**:
|
||||
```javascript
|
||||
AskUserQuestion({
|
||||
questions: [{
|
||||
question: "Which solution approach?",
|
||||
header: "Solution",
|
||||
options: solutions.map((s, i) => ({
|
||||
label: `Option ${i+1}: ${s.name}`,
|
||||
description: `${s.effort} effort, ${s.risk} risk`
|
||||
})).concat([
|
||||
{ label: "Need More Analysis", description: "Return to Phase 2" }
|
||||
])
|
||||
}]
|
||||
questions: [
|
||||
{
|
||||
question: "Which solution approach?",
|
||||
header: "Solution",
|
||||
multiSelect: false,
|
||||
options: solutions.map((s, i) => ({
|
||||
label: `Option ${i+1}: ${s.name}`,
|
||||
description: `${s.effort} effort, ${s.risk} risk`
|
||||
})).concat([
|
||||
{ label: "Need More Analysis", description: "Return to Phase 2" }
|
||||
])
|
||||
},
|
||||
{
|
||||
question: "Execution method:",
|
||||
header: "Execution",
|
||||
multiSelect: false,
|
||||
options: [
|
||||
{ label: "Agent", description: "@code-developer agent" },
|
||||
{ label: "Codex", description: "codex CLI tool" },
|
||||
{ label: "Auto", description: "Auto-select based on complexity" }
|
||||
]
|
||||
},
|
||||
{
|
||||
question: "Code review after execution?",
|
||||
header: "Review",
|
||||
multiSelect: false,
|
||||
options: [
|
||||
{ label: "Skip", description: "No review" },
|
||||
{ label: "Gemini Review", description: "Gemini CLI tool" },
|
||||
{ label: "Codex Review", description: "codex review --uncommitted" },
|
||||
{ label: "Agent Review", description: "Current agent review" }
|
||||
]
|
||||
}
|
||||
]
|
||||
})
|
||||
```
|
||||
|
||||
**Routing**:
|
||||
- Approve → Phase 5
|
||||
- Approve + execution method → Phase 5
|
||||
- Need More Analysis → Phase 2 with feedback
|
||||
- Add constraints → Collect details, then Phase 5
|
||||
- Cancel → Save session for resumption
|
||||
|
||||
### Phase 5: Plan Generation
|
||||
### Phase 5: Plan Generation & Execution Handoff
|
||||
|
||||
**Step 1: Build Context-Package** (Orchestrator responsibility):
|
||||
```javascript
|
||||
@@ -340,31 +367,63 @@ ${JSON.stringify(contextPackage, null, 2)}
|
||||
4. Use implementation_plan.tasks[] as task foundation
|
||||
5. Preserve task dependencies (depends_on) and execution_flow
|
||||
6. Expand tasks with detailed acceptance criteria
|
||||
7. Generate IMPL_PLAN.md documenting milestones and key_points
|
||||
8. Generate plan.json following schema exactly
|
||||
7. Generate plan.json following schema exactly
|
||||
|
||||
## Output
|
||||
- ${sessionFolder}/IMPL_PLAN.md
|
||||
- ${sessionFolder}/plan.json
|
||||
|
||||
## Completion Checklist
|
||||
- [ ] IMPL_PLAN.md documents approach, milestones, technical_concerns
|
||||
- [ ] plan.json preserves task dependencies from implementation_plan
|
||||
- [ ] Task execution order follows execution_flow
|
||||
- [ ] Key_points reflected in task descriptions
|
||||
- [ ] User constraints applied to implementation
|
||||
- [ ] Acceptance criteria are testable
|
||||
- [ ] Schema fields match plan-json-schema.json exactly
|
||||
`
|
||||
})
|
||||
```
|
||||
|
||||
**Hand off to Execution**:
|
||||
**Step 3: Build executionContext**:
|
||||
```javascript
|
||||
if (userConfirms) {
|
||||
SlashCommand("/workflow:lite-execute --in-memory")
|
||||
// After plan.json is generated by cli-lite-planning-agent
|
||||
const plan = JSON.parse(Read(`${sessionFolder}/plan.json`))
|
||||
|
||||
// Build executionContext (same structure as lite-plan)
|
||||
executionContext = {
|
||||
planObject: plan,
|
||||
explorationsContext: null, // Multi-CLI doesn't use exploration files
|
||||
explorationAngles: [], // No exploration angles
|
||||
explorationManifest: null, // No manifest
|
||||
clarificationContext: null, // Store user feedback from Phase 2 if exists
|
||||
executionMethod: userSelection.execution_method, // From Phase 4
|
||||
codeReviewTool: userSelection.code_review_tool, // From Phase 4
|
||||
originalUserInput: taskDescription,
|
||||
|
||||
// Optional: Task-level executor assignments
|
||||
executorAssignments: null, // Could be enhanced in future
|
||||
|
||||
session: {
|
||||
id: sessionId,
|
||||
folder: sessionFolder,
|
||||
artifacts: {
|
||||
explorations: [], // No explorations in multi-CLI workflow
|
||||
explorations_manifest: null,
|
||||
plan: `${sessionFolder}/plan.json`,
|
||||
synthesis_rounds: Array.from({length: currentRound}, (_, i) =>
|
||||
`${sessionFolder}/rounds/${i+1}/synthesis.json`
|
||||
),
|
||||
context_package: `${sessionFolder}/context-package.json`
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Step 4: Hand off to Execution**:
|
||||
```javascript
|
||||
// Execute to lite-execute with in-memory context
|
||||
SlashCommand("/workflow:lite-execute --in-memory")
|
||||
```
|
||||
|
||||
## Output File Structure
|
||||
|
||||
```
|
||||
@@ -375,7 +434,6 @@ if (userConfirms) {
|
||||
│ ├── 2/synthesis.json # Round 2 analysis (cli-discuss-agent)
|
||||
│ └── .../
|
||||
├── context-package.json # Extracted context for planning (orchestrator)
|
||||
├── IMPL_PLAN.md # Documentation (cli-lite-planning-agent)
|
||||
└── plan.json # Structured plan (cli-lite-planning-agent)
|
||||
```
|
||||
|
||||
@@ -386,8 +444,7 @@ if (userConfirms) {
|
||||
| `session-state.json` | Orchestrator | Session metadata, rounds, decisions |
|
||||
| `rounds/*/synthesis.json` | cli-discuss-agent | Solutions, convergence, cross-verification |
|
||||
| `context-package.json` | Orchestrator | Extracted solution, dependencies, consensus for planning |
|
||||
| `IMPL_PLAN.md` | cli-lite-planning-agent | Human-readable plan |
|
||||
| `plan.json` | cli-lite-planning-agent | Structured tasks for execution |
|
||||
| `plan.json` | cli-lite-planning-agent | Structured tasks for lite-execute |
|
||||
|
||||
## synthesis.json Schema
|
||||
|
||||
@@ -495,9 +552,6 @@ TodoWrite({ todos: [
|
||||
## Related Commands
|
||||
|
||||
```bash
|
||||
# Resume saved session
|
||||
/workflow:lite-execute --session=MCP-xxx
|
||||
|
||||
# Simpler single-round planning
|
||||
/workflow:lite-plan "task description"
|
||||
|
||||
@@ -505,6 +559,10 @@ TodoWrite({ todos: [
|
||||
/issue:discover-by-prompt "find issues"
|
||||
|
||||
# View session files
|
||||
cat .workflow/.multi-cli-plan/{session-id}/IMPL_PLAN.md
|
||||
cat .workflow/.multi-cli-plan/{session-id}/plan.json
|
||||
cat .workflow/.multi-cli-plan/{session-id}/rounds/1/synthesis.json
|
||||
cat .workflow/.multi-cli-plan/{session-id}/context-package.json
|
||||
|
||||
# Direct execution (if you have plan.json)
|
||||
/workflow:lite-execute plan.json
|
||||
```
|
||||
|
||||
@@ -37,6 +37,44 @@ allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*)
|
||||
7. **Task Attachment Model**: SlashCommand execute **attaches** sub-tasks to current workflow. Orchestrator **executes** these attached tasks itself, then **collapses** them after completion
|
||||
8. **⚠️ CRITICAL: DO NOT STOP**: Continuous multi-phase workflow. After executing all attached tasks, immediately collapse them and execute next phase
|
||||
|
||||
## TDD Compliance Requirements
|
||||
|
||||
### The Iron Law
|
||||
|
||||
```
|
||||
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
|
||||
```
|
||||
|
||||
**Enforcement Method**:
|
||||
- Phase 5: `implementation_approach` includes test-first steps (Red → Green → Refactor)
|
||||
- Green phase: Includes test-fix-cycle configuration (max 3 iterations)
|
||||
- Auto-revert: Triggered when max iterations reached without passing tests
|
||||
|
||||
**Verification**: Phase 6 validates Red-Green-Refactor structure in all generated tasks
|
||||
|
||||
### TDD Compliance Checkpoint
|
||||
|
||||
| Checkpoint | Validation Phase | Evidence Required |
|
||||
|------------|------------------|-------------------|
|
||||
| Test-first structure | Phase 5 | `implementation_approach` has 3 steps |
|
||||
| Red phase exists | Phase 6 | Step 1: `tdd_phase: "red"` |
|
||||
| Green phase with test-fix | Phase 6 | Step 2: `tdd_phase: "green"` + test-fix-cycle |
|
||||
| Refactor phase exists | Phase 6 | Step 3: `tdd_phase: "refactor"` |
|
||||
|
||||
### Core TDD Principles (from ref skills)
|
||||
|
||||
**Red Flags - STOP and Reassess**:
|
||||
- Code written before test
|
||||
- Test passes immediately (no Red phase witnessed)
|
||||
- Cannot explain why test should fail
|
||||
- "Just this once" rationalization
|
||||
- "Tests after achieve same goals" thinking
|
||||
|
||||
**Why Order Matters**:
|
||||
- Tests written after code pass immediately → proves nothing
|
||||
- Test-first forces edge case discovery before implementation
|
||||
- Tests-after verify what was built, not what's required
|
||||
|
||||
## 6-Phase Execution (with Conflict Resolution)
|
||||
|
||||
### Phase 1: Session Discovery
|
||||
@@ -183,7 +221,7 @@ SlashCommand(command="/workflow:tools:conflict-resolution --session [sessionId]
|
||||
{"content": "Phase 3: Test Coverage Analysis", "status": "completed", "activeForm": "Executing test coverage analysis"},
|
||||
{"content": "Phase 4: Conflict Resolution", "status": "in_progress", "activeForm": "Executing conflict resolution"},
|
||||
{"content": " → Detect conflicts with CLI analysis", "status": "in_progress", "activeForm": "Detecting conflicts"},
|
||||
{"content": " → Present conflicts to user", "status": "pending", "activeForm": "Presenting conflicts"},
|
||||
{"content": " → Log and analyze detected conflicts", "status": "pending", "activeForm": "Analyzing conflicts"},
|
||||
{"content": " → Apply resolution strategies", "status": "pending", "activeForm": "Applying resolution strategies"},
|
||||
{"content": "Phase 5: TDD Task Generation", "status": "pending", "activeForm": "Executing TDD task generation"},
|
||||
{"content": "Phase 6: TDD Structure Validation", "status": "pending", "activeForm": "Validating TDD structure"}
|
||||
@@ -251,6 +289,13 @@ SlashCommand(command="/workflow:tools:task-generate-tdd --session [sessionId]")
|
||||
- IMPL_PLAN.md contains workflow_type: "tdd" in frontmatter
|
||||
- Task count ≤10 (compliance with task limit)
|
||||
|
||||
**Red Flag Detection** (Non-Blocking Warnings):
|
||||
- Task count >10: `⚠️ High task count may indicate insufficient decomposition`
|
||||
- Missing test-fix-cycle: `⚠️ Green phase lacks auto-revert configuration`
|
||||
- Generic task names: `⚠️ Vague task names suggest unclear TDD cycles`
|
||||
|
||||
**Action**: Log warnings to `.workflow/active/[sessionId]/.process/tdd-warnings.log` (non-blocking)
|
||||
|
||||
<!-- TodoWrite: When task-generate-tdd executed, INSERT 3 task-generate-tdd tasks -->
|
||||
|
||||
**TodoWrite Update (Phase 5 SlashCommand executed - tasks attached)**:
|
||||
@@ -302,6 +347,42 @@ SlashCommand(command="/workflow:tools:task-generate-tdd --session [sessionId]")
|
||||
5. Test-fix cycle: Green phase step includes test-fix-cycle logic with max_iterations
|
||||
6. Task count: Total tasks ≤10 (simple + subtasks)
|
||||
|
||||
**Red Flag Checklist** (from TDD best practices):
|
||||
- [ ] No tasks skip Red phase (`tdd_phase: "red"` exists in step 1)
|
||||
- [ ] Test files referenced in Red phase (explicit paths, not placeholders)
|
||||
- [ ] Green phase has test-fix-cycle with `max_iterations` configured
|
||||
- [ ] Refactor phase has clear completion criteria
|
||||
|
||||
**Non-Compliance Warning Format**:
|
||||
```
|
||||
⚠️ TDD Red Flag: [issue description]
|
||||
Task: [IMPL-N]
|
||||
Recommendation: [action to fix]
|
||||
```
|
||||
|
||||
**Evidence Gathering** (Before Completion Claims):
|
||||
|
||||
```bash
|
||||
# Verify session artifacts exist
|
||||
ls -la .workflow/active/[sessionId]/{IMPL_PLAN.md,TODO_LIST.md}
|
||||
ls -la .workflow/active/[sessionId]/.task/IMPL-*.json
|
||||
|
||||
# Count generated artifacts
|
||||
echo "IMPL tasks: $(ls .workflow/active/[sessionId]/.task/IMPL-*.json 2>/dev/null | wc -l)"
|
||||
|
||||
# Sample task structure verification (first task)
|
||||
jq '{id, tdd: .meta.tdd_workflow, phases: [.flow_control.implementation_approach[].tdd_phase]}' \
|
||||
"$(ls .workflow/active/[sessionId]/.task/IMPL-*.json | head -1)"
|
||||
```
|
||||
|
||||
**Evidence Required Before Summary**:
|
||||
| Evidence Type | Verification Method | Pass Criteria |
|
||||
|---------------|---------------------|---------------|
|
||||
| File existence | `ls -la` artifacts | All files present |
|
||||
| Task count | Count IMPL-*.json | Count matches claims |
|
||||
| TDD structure | jq sample extraction | Shows red/green/refactor |
|
||||
| Warning log | Check tdd-warnings.log | Logged (may be empty) |
|
||||
|
||||
**Return Summary**:
|
||||
```
|
||||
TDD Planning complete for session: [sessionId]
|
||||
@@ -333,6 +414,9 @@ TDD Configuration:
|
||||
- Green phase includes test-fix cycle (max 3 iterations)
|
||||
- Auto-revert on max iterations reached
|
||||
|
||||
⚠️ ACTION REQUIRED: Before execution, ensure you understand WHY each Red phase test is expected to fail.
|
||||
This is crucial for valid TDD - if you don't know why the test fails, you can't verify it tests the right thing.
|
||||
|
||||
Recommended Next Steps:
|
||||
1. /workflow:action-plan-verify --session [sessionId] # Verify TDD plan quality and dependencies
|
||||
2. /workflow:execute --session [sessionId] # Start TDD execution
|
||||
@@ -400,7 +484,7 @@ TDD Workflow Orchestrator
|
||||
│ IF conflict_risk ≥ medium:
|
||||
│ └─ /workflow:tools:conflict-resolution ← ATTACHED (3 tasks)
|
||||
│ ├─ Phase 4.1: Detect conflicts with CLI
|
||||
│ ├─ Phase 4.2: Present conflicts to user
|
||||
│ ├─ Phase 4.2: Log and analyze detected conflicts
|
||||
│ └─ Phase 4.3: Apply resolution strategies
|
||||
│ └─ Returns: conflict-resolution.json ← COLLAPSED
|
||||
│ ELSE:
|
||||
@@ -439,6 +523,34 @@ Convert user input to TDD-structured format:
|
||||
- **Command failure**: Keep phase in_progress, report error
|
||||
- **TDD validation failure**: Report incomplete chains or wrong dependencies
|
||||
|
||||
### TDD Warning Patterns
|
||||
|
||||
| Pattern | Warning Message | Recommended Action |
|
||||
|---------|----------------|-------------------|
|
||||
| Task count >10 | High task count detected | Consider splitting into multiple sessions |
|
||||
| Missing test-fix-cycle | Green phase lacks auto-revert | Add `max_iterations: 3` to task config |
|
||||
| Red phase missing test path | Test file path not specified | Add explicit test file paths |
|
||||
| Generic task names | Vague names like "Add feature" | Use specific behavior descriptions |
|
||||
| No refactor criteria | Refactor phase lacks completion criteria | Define clear refactor scope |
|
||||
|
||||
### Non-Blocking Warning Policy
|
||||
|
||||
**All warnings are advisory** - they do not halt execution:
|
||||
1. Warnings logged to `.process/tdd-warnings.log`
|
||||
2. Summary displayed in Phase 6 output
|
||||
3. User decides whether to address before `/workflow:execute`
|
||||
|
||||
### Error Handling Quick Reference
|
||||
|
||||
| Error Type | Detection | Recovery Action |
|
||||
|------------|-----------|-----------------|
|
||||
| Parsing failure | Empty/malformed output | Retry once, then report |
|
||||
| Missing context-package | File read error | Re-run `/workflow:tools:context-gather` |
|
||||
| Invalid task JSON | jq parse error | Report malformed file path |
|
||||
| High task count (>10) | Count validation | Log warning, continue (non-blocking) |
|
||||
| Test-context missing | File not found | Re-run `/workflow:tools:test-context-gather` |
|
||||
| Phase timeout | No response | Retry phase, check CLI connectivity |
|
||||
|
||||
## Related Commands
|
||||
|
||||
**Prerequisite Commands**:
|
||||
@@ -458,3 +570,28 @@ Convert user input to TDD-structured format:
|
||||
- `/workflow:execute` - Begin TDD implementation
|
||||
- `/workflow:tdd-verify` - Post-execution: Verify TDD compliance and generate quality report
|
||||
|
||||
## Next Steps Decision Table
|
||||
|
||||
| Situation | Recommended Command | Purpose |
|
||||
|-----------|---------------------|---------|
|
||||
| First time planning | `/workflow:action-plan-verify` | Validate task structure before execution |
|
||||
| Warnings in tdd-warnings.log | Review log, refine tasks | Address Red Flags before proceeding |
|
||||
| High task count warning | Consider `/workflow:session:start` | Split into focused sub-sessions |
|
||||
| Ready to implement | `/workflow:execute` | Begin TDD Red-Green-Refactor cycles |
|
||||
| After implementation | `/workflow:tdd-verify` | Generate TDD compliance report |
|
||||
| Need to review tasks | `/workflow:status --session [id]` | Inspect current task breakdown |
|
||||
| Plan needs changes | `/task:replan` | Update task JSON with new requirements |
|
||||
|
||||
### TDD Workflow State Transitions
|
||||
|
||||
```
|
||||
/workflow:tdd-plan
|
||||
↓
|
||||
[Planning Complete] ──→ /workflow:action-plan-verify (recommended)
|
||||
↓
|
||||
[Verified/Ready] ─────→ /workflow:execute
|
||||
↓
|
||||
[Implementation] ─────→ /workflow:tdd-verify (post-execution)
|
||||
↓
|
||||
[Quality Report] ─────→ Done or iterate
|
||||
```
|
||||
|
||||
@@ -154,8 +154,8 @@ Task(subagent_type="cli-execution-agent", run_in_background=false, prompt=`
|
||||
- Validation of exploration conflict_indicators
|
||||
- ModuleOverlap conflicts with overlap_analysis
|
||||
- Targeted clarification questions
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/02-analyze-code-patterns.txt) | Focus on breaking changes, migration needs, and functional overlaps | Prioritize exploration-identified conflicts | analysis=READ-ONLY
|
||||
" --tool gemini --mode analysis --cd {project_root}
|
||||
CONSTRAINTS: Focus on breaking changes, migration needs, and functional overlaps | Prioritize exploration-identified conflicts | analysis=READ-ONLY
|
||||
" --tool gemini --mode analysis --rule analysis-code-patterns --cd {project_root}
|
||||
|
||||
Fallback: Qwen (same prompt) → Claude (manual analysis)
|
||||
|
||||
|
||||
@@ -90,7 +90,7 @@ Template: ~/.claude/workflows/cli-templates/prompts/test/test-concept-analysis.t
|
||||
|
||||
## EXECUTION STEPS
|
||||
1. Execute Gemini analysis:
|
||||
ccw cli -p "$(cat ~/.claude/workflows/cli-templates/prompts/test/test-concept-analysis.txt)" --tool gemini --mode write --cd .workflow/active/{test_session_id}/.process
|
||||
ccw cli -p "..." --tool gemini --mode write --rule test-test-concept-analysis --cd .workflow/active/{test_session_id}/.process
|
||||
|
||||
2. Generate TEST_ANALYSIS_RESULTS.md:
|
||||
Synthesize gemini-test-analysis.md into standardized format for task generation
|
||||
|
||||
@@ -8,6 +8,44 @@ allowed-tools: Task(*), SlashCommand(*), AskUserQuestion(*), Read(*), Bash(*), G
|
||||
|
||||
无状态工作流协调器,根据任务意图自动选择最优工作流。
|
||||
|
||||
## Workflow System Overview
|
||||
|
||||
CCW 提供两个工作流系统:**Main Workflow** 和 **Issue Workflow**,协同覆盖完整的软件开发生命周期。
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Main Workflow │
|
||||
│ │
|
||||
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
|
||||
│ │ Level 1 │ → │ Level 2 │ → │ Level 3 │ → │ Level 4 │ │
|
||||
│ │ Rapid │ │ Lightweight │ │ Standard │ │ Brainstorm │ │
|
||||
│ │ │ │ │ │ │ │ │ │
|
||||
│ │ lite-lite- │ │ lite-plan │ │ plan │ │ brainstorm │ │
|
||||
│ │ lite │ │ lite-fix │ │ tdd-plan │ │ :auto- │ │
|
||||
│ │ │ │ multi-cli- │ │ test-fix- │ │ parallel │ │
|
||||
│ │ │ │ plan │ │ gen │ │ ↓ │ │
|
||||
│ │ │ │ │ │ │ │ plan │ │
|
||||
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
|
||||
│ │
|
||||
│ Complexity: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━▶ │
|
||||
│ Low High │
|
||||
└─────────────────────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
│ After development
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Issue Workflow │
|
||||
│ │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ Accumulate │ → │ Plan │ → │ Execute │ │
|
||||
│ │ Discover & │ │ Batch │ │ Parallel │ │
|
||||
│ │ Collect │ │ Planning │ │ Execution │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
│ │
|
||||
│ Supplementary role: Maintain main branch stability, worktree isolation │
|
||||
└─────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
@@ -17,7 +55,7 @@ allowed-tools: Task(*), SlashCommand(*), AskUserQuestion(*), Read(*), Bash(*), G
|
||||
│ Phase 1 │ Input Analysis (rule-based, fast path) │
|
||||
│ Phase 1.5 │ CLI Classification (semantic, smart path) │
|
||||
│ Phase 1.75 │ Requirement Clarification (clarity < 2) │
|
||||
│ Phase 2 │ Chain Selection (intent → workflow) │
|
||||
│ Phase 2 │ Level Selection (intent → level → workflow) │
|
||||
│ Phase 2.5 │ CLI Action Planning (high complexity) │
|
||||
│ Phase 3 │ User Confirmation (optional) │
|
||||
│ Phase 4 │ TODO Tracking Setup │
|
||||
@@ -25,23 +63,79 @@ allowed-tools: Task(*), SlashCommand(*), AskUserQuestion(*), Read(*), Bash(*), G
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Level Quick Reference
|
||||
|
||||
| Level | Name | Workflows | Artifacts | Execution |
|
||||
|-------|------|-----------|-----------|-----------|
|
||||
| **1** | Rapid | `lite-lite-lite` | None | Direct execute |
|
||||
| **2** | Lightweight | `lite-plan`, `lite-fix`, `multi-cli-plan` | Memory/Lightweight files | → `lite-execute` |
|
||||
| **3** | Standard | `plan`, `tdd-plan`, `test-fix-gen` | Session persistence | → `execute` / `test-cycle-execute` |
|
||||
| **4** | Brainstorm | `brainstorm:auto-parallel` → `plan` | Multi-role analysis + Session | → `execute` |
|
||||
| **-** | Issue | `discover` → `plan` → `queue` → `execute` | Issue records | Worktree isolation (optional) |
|
||||
|
||||
## Workflow Selection Decision Tree
|
||||
|
||||
```
|
||||
Start
|
||||
│
|
||||
├─ Is it post-development maintenance?
|
||||
│ ├─ Yes → Issue Workflow
|
||||
│ └─ No ↓
|
||||
│
|
||||
├─ Are requirements clear?
|
||||
│ ├─ Uncertain → Level 4 (brainstorm:auto-parallel)
|
||||
│ └─ Clear ↓
|
||||
│
|
||||
├─ Need persistent Session?
|
||||
│ ├─ Yes → Level 3 (plan / tdd-plan / test-fix-gen)
|
||||
│ └─ No ↓
|
||||
│
|
||||
├─ Need multi-perspective / solution comparison?
|
||||
│ ├─ Yes → Level 2 (multi-cli-plan)
|
||||
│ └─ No ↓
|
||||
│
|
||||
├─ Is it a bug fix?
|
||||
│ ├─ Yes → Level 2 (lite-fix)
|
||||
│ └─ No ↓
|
||||
│
|
||||
├─ Need planning?
|
||||
│ ├─ Yes → Level 2 (lite-plan)
|
||||
│ └─ No → Level 1 (lite-lite-lite)
|
||||
```
|
||||
|
||||
## Intent Classification
|
||||
|
||||
### Priority Order
|
||||
### Priority Order (with Level Mapping)
|
||||
|
||||
| Priority | Intent | Patterns | Flow |
|
||||
|----------|--------|----------|------|
|
||||
| 1 | bugfix/hotfix | `urgent,production,critical` + bug | `bugfix.hotfix` |
|
||||
| 1 | bugfix | `fix,bug,error,crash,fail` | `bugfix.standard` |
|
||||
| 2 | issue batch | `issues,batch` + `fix,resolve` | `issue` |
|
||||
| 3 | exploration | `不确定,explore,研究,what if` | `full` |
|
||||
| 3 | multi-perspective | `多视角,权衡,比较方案,cross-verify` | `multi-cli-plan` |
|
||||
| 4 | quick-task | `快速,简单,small,quick` + feature | `lite-lite-lite` |
|
||||
| 5 | ui design | `ui,design,component,style` | `ui` |
|
||||
| 6 | tdd | `tdd,test-driven,先写测试` | `tdd` |
|
||||
| 7 | review | `review,审查,code review` | `review-fix` |
|
||||
| 8 | documentation | `文档,docs,readme` | `docs` |
|
||||
| 99 | feature | complexity-based | `rapid`/`coupled` |
|
||||
| Priority | Intent | Patterns | Level | Flow |
|
||||
|----------|--------|----------|-------|------|
|
||||
| 1 | bugfix/hotfix | `urgent,production,critical` + bug | L2 | `bugfix.hotfix` |
|
||||
| 1 | bugfix | `fix,bug,error,crash,fail` | L2 | `bugfix.standard` |
|
||||
| 2 | issue batch | `issues,batch` + `fix,resolve` | Issue | `issue` |
|
||||
| 3 | exploration | `不确定,explore,研究,what if` | L4 | `full` |
|
||||
| 3 | multi-perspective | `多视角,权衡,比较方案,cross-verify` | L2 | `multi-cli-plan` |
|
||||
| 4 | quick-task | `快速,简单,small,quick` + feature | L1 | `lite-lite-lite` |
|
||||
| 5 | ui design | `ui,design,component,style` | L3/L4 | `ui` |
|
||||
| 6 | tdd | `tdd,test-driven,先写测试` | L3 | `tdd` |
|
||||
| 7 | test-fix | `测试失败,test fail,fix test` | L3 | `test-fix-gen` |
|
||||
| 8 | review | `review,审查,code review` | L3 | `review-fix` |
|
||||
| 9 | documentation | `文档,docs,readme` | L2 | `docs` |
|
||||
| 99 | feature | complexity-based | L2/L3 | `rapid`/`coupled` |
|
||||
|
||||
### Quick Selection Guide
|
||||
|
||||
| Scenario | Recommended Workflow | Level |
|
||||
|----------|---------------------|-------|
|
||||
| Quick fixes, config adjustments | `lite-lite-lite` | 1 |
|
||||
| Clear single-module features | `lite-plan → lite-execute` | 2 |
|
||||
| Bug diagnosis and fix | `lite-fix` | 2 |
|
||||
| Production emergencies | `lite-fix --hotfix` | 2 |
|
||||
| Technology selection, solution comparison | `multi-cli-plan → lite-execute` | 2 |
|
||||
| Multi-module changes, refactoring | `plan → verify → execute` | 3 |
|
||||
| Test-driven development | `tdd-plan → execute → tdd-verify` | 3 |
|
||||
| Test failure fixes | `test-fix-gen → test-cycle-execute` | 3 |
|
||||
| New features, architecture design | `brainstorm:auto-parallel → plan → execute` | 4 |
|
||||
| Post-development issue fixes | Issue Workflow | - |
|
||||
|
||||
### Complexity Assessment
|
||||
|
||||
@@ -214,24 +308,100 @@ CLI 可返回建议:`use_default` | `modify` (调整步骤) | `upgrade` (升
|
||||
|
||||
## Workflow Flow Details
|
||||
|
||||
### Issue Workflow (两阶段生命周期)
|
||||
### Issue Workflow (Main Workflow 补充机制)
|
||||
|
||||
Issue 工作流设计为两阶段生命周期,支持在项目迭代过程中积累问题并集中解决。
|
||||
Issue Workflow 是 Main Workflow 的**补充机制**,专注于开发后的持续维护。
|
||||
|
||||
**Phase 1: Accumulation (积累阶段)**
|
||||
- 触发:任务完成后的 review、代码审查发现、测试失败
|
||||
- 活动:需求扩展、bug 分析、测试覆盖、安全审查
|
||||
- 命令:`/issue:discover`, `/issue:discover-by-prompt`, `/issue:new`
|
||||
#### 设计理念
|
||||
|
||||
**Phase 2: Batch Resolution (批量解决阶段)**
|
||||
- 触发:积累足够 issue 后的集中处理
|
||||
- 流程:plan → queue → execute
|
||||
- 命令:`/issue:plan --all-pending` → `/issue:queue` → `/issue:execute`
|
||||
| 方面 | Main Workflow | Issue Workflow |
|
||||
|------|---------------|----------------|
|
||||
| **用途** | 主要开发周期 | 开发后维护 |
|
||||
| **时机** | 功能开发阶段 | 主工作流完成后 |
|
||||
| **范围** | 完整功能实现 | 针对性修复/增强 |
|
||||
| **并行性** | 依赖分析 → Agent 并行 | Worktree 隔离 (可选) |
|
||||
| **分支模型** | 当前分支工作 | 可使用隔离的 worktree |
|
||||
|
||||
#### 为什么 Main Workflow 不自动使用 Worktree?
|
||||
|
||||
**依赖分析已解决并行性问题**:
|
||||
1. 规划阶段 (`/workflow:plan`) 执行依赖分析
|
||||
2. 自动识别任务依赖和关键路径
|
||||
3. 划分为**并行组**(独立任务)和**串行链**(依赖任务)
|
||||
4. Agent 并行执行独立任务,无需文件系统隔离
|
||||
|
||||
#### 两阶段生命周期
|
||||
|
||||
```
|
||||
任务完成 → discover → 积累 issue → ... → plan all → queue → parallel execute
|
||||
↑ ↓
|
||||
└────── 迭代循环 ───────┘
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ Phase 1: Accumulation (积累阶段) │
|
||||
│ │
|
||||
│ Triggers: 任务完成后的 review、代码审查发现、测试失败 │
|
||||
│ │
|
||||
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
|
||||
│ │ discover │ │ discover- │ │ new │ │
|
||||
│ │ Auto-find │ │ by-prompt │ │ Manual │ │
|
||||
│ └────────────┘ └────────────┘ └────────────┘ │
|
||||
│ │
|
||||
│ 持续积累 issues 到待处理队列 │
|
||||
└─────────────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
│ 积累足够后
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ Phase 2: Batch Resolution (批量解决阶段) │
|
||||
│ │
|
||||
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
|
||||
│ │ plan │ ──→ │ queue │ ──→ │ execute │ │
|
||||
│ │ --all- │ │ Optimize │ │ Parallel │ │
|
||||
│ │ pending │ │ order │ │ execution │ │
|
||||
│ └────────────┘ └────────────┘ └────────────┘ │
|
||||
│ │
|
||||
│ 支持 worktree 隔离,保持主分支稳定 │
|
||||
└─────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
#### 与 Main Workflow 的协作
|
||||
|
||||
```
|
||||
开发迭代循环
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ │
|
||||
│ ┌─────────┐ ┌─────────┐ │
|
||||
│ │ Feature │ ──→ Main Workflow ──→ Done ──→│ Review │ │
|
||||
│ │ Request │ (Level 1-4) └────┬────┘ │
|
||||
│ └─────────┘ │ │
|
||||
│ ▲ │ 发现 Issues │
|
||||
│ │ ▼ │
|
||||
│ │ ┌─────────┐ │
|
||||
│ 继续 │ │ Issue │ │
|
||||
│ 新功能│ │ Workflow│ │
|
||||
│ │ └────┬────┘ │
|
||||
│ │ ┌──────────────────────────────┘ │
|
||||
│ │ │ 修复完成 │
|
||||
│ │ ▼ │
|
||||
│ ┌────┴────┐◀────── │
|
||||
│ │ Main │ Merge │
|
||||
│ │ Branch │ back │
|
||||
│ └─────────┘ │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
#### 命令列表
|
||||
|
||||
**积累阶段:**
|
||||
```bash
|
||||
/issue:discover # 多视角自动发现
|
||||
/issue:discover-by-prompt # 基于提示发现
|
||||
/issue:new # 手动创建
|
||||
```
|
||||
|
||||
**批量解决阶段:**
|
||||
```bash
|
||||
/issue:plan --all-pending # 批量规划所有待处理
|
||||
/issue:queue # 生成优化执行队列
|
||||
/issue:execute # 并行执行
|
||||
```
|
||||
|
||||
### lite-lite-lite vs multi-cli-plan
|
||||
|
||||
@@ -73,10 +73,37 @@
|
||||
},
|
||||
|
||||
"flows": {
|
||||
"_level_guide": {
|
||||
"L1": "Rapid - No artifacts, direct execution",
|
||||
"L2": "Lightweight - Memory/lightweight files, → lite-execute",
|
||||
"L3": "Standard - Session persistence, → execute/test-cycle-execute",
|
||||
"L4": "Brainstorm - Multi-role analysis + Session, → execute"
|
||||
},
|
||||
"lite-lite-lite": {
|
||||
"name": "Ultra-Rapid Execution",
|
||||
"level": "L1",
|
||||
"description": "零文件 + 自动CLI选择 + 语义描述 + 直接执行",
|
||||
"complexity": ["low"],
|
||||
"artifacts": "none",
|
||||
"steps": [
|
||||
{ "phase": "clarify", "description": "需求澄清 (AskUser if needed)" },
|
||||
{ "phase": "auto-select", "description": "任务分析 → 自动选择CLI组合" },
|
||||
{ "phase": "multi-cli", "description": "并行多CLI分析" },
|
||||
{ "phase": "decision", "description": "展示结果 → AskUser决策" },
|
||||
{ "phase": "execute", "description": "直接执行 (无中间文件)" }
|
||||
],
|
||||
"cli_hints": {
|
||||
"analysis": { "tool": "auto", "mode": "analysis", "parallel": true },
|
||||
"execution": { "tool": "auto", "mode": "write" }
|
||||
},
|
||||
"estimated_time": "10-30 min"
|
||||
},
|
||||
"rapid": {
|
||||
"name": "Rapid Iteration",
|
||||
"description": "多模型协作分析 + 直接执行",
|
||||
"level": "L2",
|
||||
"description": "内存规划 + 直接执行",
|
||||
"complexity": ["low", "medium"],
|
||||
"artifacts": "memory://plan",
|
||||
"steps": [
|
||||
{ "command": "/workflow:lite-plan", "optional": false, "auto_continue": true },
|
||||
{ "command": "/workflow:lite-execute", "optional": false }
|
||||
@@ -87,107 +114,12 @@
|
||||
},
|
||||
"estimated_time": "15-45 min"
|
||||
},
|
||||
"full": {
|
||||
"name": "Full Exploration",
|
||||
"description": "头脑风暴 + 规划 + 执行",
|
||||
"complexity": ["medium", "high"],
|
||||
"steps": [
|
||||
{ "command": "/workflow:brainstorm:auto-parallel", "optional": false, "confirm_before": true },
|
||||
{ "command": "/workflow:plan", "optional": false },
|
||||
{ "command": "/workflow:action-plan-verify", "optional": true, "auto_continue": true },
|
||||
{ "command": "/workflow:execute", "optional": false }
|
||||
],
|
||||
"cli_hints": {
|
||||
"role_analysis": { "tool": "gemini", "mode": "analysis", "trigger": "always", "parallel": true },
|
||||
"execution": { "tool": "codex", "mode": "write", "trigger": "task_count >= 3" }
|
||||
},
|
||||
"estimated_time": "1-3 hours"
|
||||
},
|
||||
"coupled": {
|
||||
"name": "Coupled Planning",
|
||||
"description": "完整规划 + 验证 + 执行",
|
||||
"complexity": ["high"],
|
||||
"steps": [
|
||||
{ "command": "/workflow:plan", "optional": false },
|
||||
{ "command": "/workflow:action-plan-verify", "optional": false, "auto_continue": true },
|
||||
{ "command": "/workflow:execute", "optional": false },
|
||||
{ "command": "/workflow:review", "optional": true }
|
||||
],
|
||||
"cli_hints": {
|
||||
"pre_analysis": { "tool": "gemini", "mode": "analysis", "trigger": "always" },
|
||||
"execution": { "tool": "codex", "mode": "write", "trigger": "always" }
|
||||
},
|
||||
"estimated_time": "2-4 hours"
|
||||
},
|
||||
"bugfix": {
|
||||
"name": "Bug Fix",
|
||||
"description": "智能诊断 + 修复",
|
||||
"complexity": ["low", "medium"],
|
||||
"variants": {
|
||||
"standard": [{ "command": "/workflow:lite-fix", "optional": false }],
|
||||
"hotfix": [{ "command": "/workflow:lite-fix --hotfix", "optional": false }]
|
||||
},
|
||||
"cli_hints": {
|
||||
"diagnosis": { "tool": "gemini", "mode": "analysis", "trigger": "always" },
|
||||
"fix": { "tool": "codex", "mode": "write", "trigger": "severity >= medium" }
|
||||
},
|
||||
"estimated_time": "10-30 min"
|
||||
},
|
||||
"issue": {
|
||||
"name": "Issue Lifecycle",
|
||||
"description": "发现积累 → 批量规划 → 队列优化 → 并行执行",
|
||||
"complexity": ["medium", "high"],
|
||||
"phases": {
|
||||
"accumulation": {
|
||||
"description": "项目迭代中持续发现和积累issue",
|
||||
"commands": ["/issue:discover", "/issue:new"],
|
||||
"trigger": "post-task, code-review, test-failure"
|
||||
},
|
||||
"resolution": {
|
||||
"description": "集中规划和执行积累的issue",
|
||||
"steps": [
|
||||
{ "command": "/issue:plan --all-pending", "optional": false },
|
||||
{ "command": "/issue:queue", "optional": false },
|
||||
{ "command": "/issue:execute", "optional": false }
|
||||
]
|
||||
}
|
||||
},
|
||||
"cli_hints": {
|
||||
"discovery": { "tool": "gemini", "mode": "analysis", "trigger": "perspective_analysis", "parallel": true },
|
||||
"solution_generation": { "tool": "gemini", "mode": "analysis", "trigger": "always", "parallel": true },
|
||||
"batch_execution": { "tool": "codex", "mode": "write", "trigger": "always" }
|
||||
},
|
||||
"estimated_time": "1-4 hours"
|
||||
},
|
||||
"lite-lite-lite": {
|
||||
"name": "Ultra-Lite Multi-CLI",
|
||||
"description": "零文件 + 自动CLI选择 + 语义描述 + 直接执行",
|
||||
"complexity": ["low", "medium"],
|
||||
"steps": [
|
||||
{ "phase": "clarify", "description": "需求澄清 (AskUser if needed)" },
|
||||
{ "phase": "auto-select", "description": "任务分析 → 自动选择CLI组合" },
|
||||
{ "phase": "multi-cli", "description": "并行多CLI分析" },
|
||||
{ "phase": "decision", "description": "展示结果 → AskUser决策" },
|
||||
{ "phase": "execute", "description": "直接执行 (无中间文件)" }
|
||||
],
|
||||
"vs_multi_cli_plan": {
|
||||
"artifacts": "None vs IMPL_PLAN.md + plan.json + synthesis.json",
|
||||
"session": "Stateless vs Persistent",
|
||||
"cli_selection": "Auto-select based on task analysis vs Config-driven",
|
||||
"iteration": "Via AskUser vs Via rounds/synthesis",
|
||||
"execution": "Direct vs Via lite-execute",
|
||||
"best_for": "Quick fixes, simple features vs Complex multi-step implementations"
|
||||
},
|
||||
"cli_hints": {
|
||||
"analysis": { "tool": "auto", "mode": "analysis", "parallel": true },
|
||||
"execution": { "tool": "auto", "mode": "write" }
|
||||
},
|
||||
"estimated_time": "10-30 min"
|
||||
},
|
||||
"multi-cli-plan": {
|
||||
"name": "Multi-CLI Collaborative Planning",
|
||||
"level": "L2",
|
||||
"description": "ACE上下文 + 多CLI协作分析 + 迭代收敛 + 计划生成",
|
||||
"complexity": ["medium", "high"],
|
||||
"artifacts": ".workflow/.multi-cli-plan/{session}/",
|
||||
"steps": [
|
||||
{ "command": "/workflow:multi-cli-plan", "optional": false, "phases": [
|
||||
"context_gathering: ACE语义搜索",
|
||||
@@ -210,28 +142,154 @@
|
||||
"discussion": { "tools": ["gemini", "codex", "claude"], "mode": "analysis", "parallel": true },
|
||||
"planning": { "tool": "gemini", "mode": "analysis" }
|
||||
},
|
||||
"output": ".workflow/.multi-cli-plan/{session-id}/",
|
||||
"estimated_time": "30-90 min"
|
||||
},
|
||||
"coupled": {
|
||||
"name": "Standard Planning",
|
||||
"level": "L3",
|
||||
"description": "完整规划 + 验证 + 执行",
|
||||
"complexity": ["medium", "high"],
|
||||
"artifacts": ".workflow/active/{session}/",
|
||||
"steps": [
|
||||
{ "command": "/workflow:plan", "optional": false },
|
||||
{ "command": "/workflow:action-plan-verify", "optional": false, "auto_continue": true },
|
||||
{ "command": "/workflow:execute", "optional": false },
|
||||
{ "command": "/workflow:review", "optional": true }
|
||||
],
|
||||
"cli_hints": {
|
||||
"pre_analysis": { "tool": "gemini", "mode": "analysis", "trigger": "always" },
|
||||
"execution": { "tool": "codex", "mode": "write", "trigger": "always" }
|
||||
},
|
||||
"estimated_time": "2-4 hours"
|
||||
},
|
||||
"full": {
|
||||
"name": "Full Exploration (Brainstorm)",
|
||||
"level": "L4",
|
||||
"description": "头脑风暴 + 规划 + 执行",
|
||||
"complexity": ["high"],
|
||||
"artifacts": ".workflow/active/{session}/.brainstorming/",
|
||||
"steps": [
|
||||
{ "command": "/workflow:brainstorm:auto-parallel", "optional": false, "confirm_before": true },
|
||||
{ "command": "/workflow:plan", "optional": false },
|
||||
{ "command": "/workflow:action-plan-verify", "optional": true, "auto_continue": true },
|
||||
{ "command": "/workflow:execute", "optional": false }
|
||||
],
|
||||
"cli_hints": {
|
||||
"role_analysis": { "tool": "gemini", "mode": "analysis", "trigger": "always", "parallel": true },
|
||||
"execution": { "tool": "codex", "mode": "write", "trigger": "task_count >= 3" }
|
||||
},
|
||||
"estimated_time": "1-3 hours"
|
||||
},
|
||||
"bugfix": {
|
||||
"name": "Bug Fix",
|
||||
"level": "L2",
|
||||
"description": "智能诊断 + 修复 (5 phases)",
|
||||
"complexity": ["low", "medium"],
|
||||
"artifacts": ".workflow/.lite-fix/{bug-slug}-{date}/",
|
||||
"variants": {
|
||||
"standard": [{ "command": "/workflow:lite-fix", "optional": false }],
|
||||
"hotfix": [{ "command": "/workflow:lite-fix --hotfix", "optional": false }]
|
||||
},
|
||||
"phases": [
|
||||
"Phase 1: Bug Analysis & Diagnosis (severity pre-assessment)",
|
||||
"Phase 2: Clarification (optional, AskUserQuestion)",
|
||||
"Phase 3: Fix Planning (Low/Medium → Claude, High/Critical → cli-lite-planning-agent)",
|
||||
"Phase 4: Confirmation & Selection",
|
||||
"Phase 5: Execute (→ lite-execute --mode bugfix)"
|
||||
],
|
||||
"cli_hints": {
|
||||
"diagnosis": { "tool": "gemini", "mode": "analysis", "trigger": "always" },
|
||||
"fix": { "tool": "codex", "mode": "write", "trigger": "severity >= medium" }
|
||||
},
|
||||
"estimated_time": "10-30 min"
|
||||
},
|
||||
"issue": {
|
||||
"name": "Issue Lifecycle",
|
||||
"level": "Supplementary",
|
||||
"description": "发现积累 → 批量规划 → 队列优化 → 并行执行 (Main Workflow 补充机制)",
|
||||
"complexity": ["medium", "high"],
|
||||
"artifacts": ".workflow/.issues/",
|
||||
"purpose": "Post-development continuous maintenance, maintain main branch stability",
|
||||
"phases": {
|
||||
"accumulation": {
|
||||
"description": "项目迭代中持续发现和积累issue",
|
||||
"commands": ["/issue:discover", "/issue:discover-by-prompt", "/issue:new"],
|
||||
"trigger": "post-task, code-review, test-failure"
|
||||
},
|
||||
"resolution": {
|
||||
"description": "集中规划和执行积累的issue",
|
||||
"steps": [
|
||||
{ "command": "/issue:plan --all-pending", "optional": false },
|
||||
{ "command": "/issue:queue", "optional": false },
|
||||
{ "command": "/issue:execute", "optional": false }
|
||||
]
|
||||
}
|
||||
},
|
||||
"worktree_support": {
|
||||
"description": "可选的 worktree 隔离,保持主分支稳定",
|
||||
"use_case": "主开发完成后的 issue 修复"
|
||||
},
|
||||
"cli_hints": {
|
||||
"discovery": { "tool": "gemini", "mode": "analysis", "trigger": "perspective_analysis", "parallel": true },
|
||||
"solution_generation": { "tool": "gemini", "mode": "analysis", "trigger": "always", "parallel": true },
|
||||
"batch_execution": { "tool": "codex", "mode": "write", "trigger": "always" }
|
||||
},
|
||||
"estimated_time": "1-4 hours"
|
||||
},
|
||||
"tdd": {
|
||||
"name": "Test-Driven Development",
|
||||
"description": "TDD规划 + 执行 + 验证",
|
||||
"level": "L3",
|
||||
"description": "TDD规划 + 执行 + 验证 (6 phases)",
|
||||
"complexity": ["medium", "high"],
|
||||
"artifacts": ".workflow/active/{session}/",
|
||||
"steps": [
|
||||
{ "command": "/workflow:tdd-plan", "optional": false },
|
||||
{ "command": "/workflow:action-plan-verify", "optional": true, "auto_continue": true },
|
||||
{ "command": "/workflow:execute", "optional": false },
|
||||
{ "command": "/workflow:tdd-verify", "optional": false }
|
||||
],
|
||||
"tdd_structure": {
|
||||
"description": "Each IMPL task contains complete internal Red-Green-Refactor cycle",
|
||||
"meta": "tdd_workflow: true",
|
||||
"flow_control": "implementation_approach contains 3 steps (red/green/refactor)"
|
||||
},
|
||||
"cli_hints": {
|
||||
"test_strategy": { "tool": "gemini", "mode": "analysis", "trigger": "always" },
|
||||
"red_green_refactor": { "tool": "codex", "mode": "write", "trigger": "always" }
|
||||
},
|
||||
"estimated_time": "1-3 hours"
|
||||
},
|
||||
"test-fix": {
|
||||
"name": "Test Fix Generation",
|
||||
"level": "L3",
|
||||
"description": "测试修复生成 + 执行循环 (5 phases)",
|
||||
"complexity": ["medium", "high"],
|
||||
"artifacts": ".workflow/active/WFS-test-{session}/",
|
||||
"dual_mode": {
|
||||
"session_mode": { "input": "WFS-xxx", "context_source": "Source session summaries" },
|
||||
"prompt_mode": { "input": "Text/file path", "context_source": "Direct codebase analysis" }
|
||||
},
|
||||
"steps": [
|
||||
{ "command": "/workflow:test-fix-gen", "optional": false },
|
||||
{ "command": "/workflow:test-cycle-execute", "optional": false }
|
||||
],
|
||||
"task_structure": [
|
||||
"IMPL-001.json (test understanding & generation)",
|
||||
"IMPL-001.5-review.json (quality gate)",
|
||||
"IMPL-002.json (test execution & fix cycle)"
|
||||
],
|
||||
"cli_hints": {
|
||||
"analysis": { "tool": "gemini", "mode": "analysis", "trigger": "always" },
|
||||
"fix_cycle": { "tool": "codex", "mode": "write", "trigger": "pass_rate < 0.95" }
|
||||
},
|
||||
"estimated_time": "1-2 hours"
|
||||
},
|
||||
"ui": {
|
||||
"name": "UI-First Development",
|
||||
"level": "L3/L4",
|
||||
"description": "UI设计 + 规划 + 执行",
|
||||
"complexity": ["medium", "high"],
|
||||
"artifacts": ".workflow/active/{session}/",
|
||||
"variants": {
|
||||
"explore": [
|
||||
{ "command": "/workflow:ui-design:explore-auto", "optional": false },
|
||||
@@ -250,8 +308,10 @@
|
||||
},
|
||||
"review-fix": {
|
||||
"name": "Review and Fix",
|
||||
"level": "L3",
|
||||
"description": "多维审查 + 自动修复",
|
||||
"complexity": ["medium"],
|
||||
"artifacts": ".workflow/active/{session}/review_report.md",
|
||||
"steps": [
|
||||
{ "command": "/workflow:review-session-cycle", "optional": false },
|
||||
{ "command": "/workflow:review-fix", "optional": true }
|
||||
@@ -264,6 +324,7 @@
|
||||
},
|
||||
"docs": {
|
||||
"name": "Documentation",
|
||||
"level": "L2",
|
||||
"description": "批量文档生成",
|
||||
"complexity": ["low", "medium"],
|
||||
"variants": {
|
||||
@@ -278,8 +339,17 @@
|
||||
},
|
||||
|
||||
"intent_rules": {
|
||||
"_level_mapping": {
|
||||
"description": "Intent → Level → Flow mapping guide",
|
||||
"L1": ["lite-lite-lite"],
|
||||
"L2": ["rapid", "bugfix", "multi-cli-plan", "docs"],
|
||||
"L3": ["coupled", "tdd", "test-fix", "review-fix", "ui"],
|
||||
"L4": ["full"],
|
||||
"Supplementary": ["issue"]
|
||||
},
|
||||
"bugfix": {
|
||||
"priority": 1,
|
||||
"level": "L2",
|
||||
"variants": {
|
||||
"hotfix": {
|
||||
"patterns": ["hotfix", "urgent", "production", "critical", "emergency", "紧急", "生产环境", "线上"],
|
||||
@@ -293,6 +363,7 @@
|
||||
},
|
||||
"issue_batch": {
|
||||
"priority": 2,
|
||||
"level": "Supplementary",
|
||||
"patterns": {
|
||||
"batch": ["issues", "batch", "queue", "多个", "批量"],
|
||||
"action": ["fix", "resolve", "处理", "解决"]
|
||||
@@ -302,11 +373,25 @@
|
||||
},
|
||||
"exploration": {
|
||||
"priority": 3,
|
||||
"level": "L4",
|
||||
"patterns": ["不确定", "不知道", "explore", "研究", "分析一下", "怎么做", "what if", "探索"],
|
||||
"flow": "full"
|
||||
},
|
||||
"ui_design": {
|
||||
"multi_perspective": {
|
||||
"priority": 3,
|
||||
"level": "L2",
|
||||
"patterns": ["多视角", "权衡", "比较方案", "cross-verify", "多CLI", "协作分析"],
|
||||
"flow": "multi-cli-plan"
|
||||
},
|
||||
"quick_task": {
|
||||
"priority": 4,
|
||||
"level": "L1",
|
||||
"patterns": ["快速", "简单", "small", "quick", "simple", "trivial", "小改动"],
|
||||
"flow": "lite-lite-lite"
|
||||
},
|
||||
"ui_design": {
|
||||
"priority": 5,
|
||||
"level": "L3/L4",
|
||||
"patterns": ["ui", "界面", "design", "设计", "component", "组件", "style", "样式", "layout", "布局"],
|
||||
"variants": {
|
||||
"imitate": { "triggers": ["参考", "模仿", "像", "类似"], "flow": "ui.imitate" },
|
||||
@@ -314,17 +399,26 @@
|
||||
}
|
||||
},
|
||||
"tdd": {
|
||||
"priority": 5,
|
||||
"priority": 6,
|
||||
"level": "L3",
|
||||
"patterns": ["tdd", "test-driven", "测试驱动", "先写测试", "test first"],
|
||||
"flow": "tdd"
|
||||
},
|
||||
"test_fix": {
|
||||
"priority": 7,
|
||||
"level": "L3",
|
||||
"patterns": ["测试失败", "test fail", "fix test", "test error", "pass rate", "coverage gap"],
|
||||
"flow": "test-fix"
|
||||
},
|
||||
"review": {
|
||||
"priority": 6,
|
||||
"priority": 8,
|
||||
"level": "L3",
|
||||
"patterns": ["review", "审查", "检查代码", "code review", "质量检查"],
|
||||
"flow": "review-fix"
|
||||
},
|
||||
"documentation": {
|
||||
"priority": 7,
|
||||
"priority": 9,
|
||||
"level": "L2",
|
||||
"patterns": ["文档", "documentation", "docs", "readme"],
|
||||
"variants": {
|
||||
"incremental": { "triggers": ["更新", "增量"], "flow": "docs.incremental" },
|
||||
@@ -334,9 +428,9 @@
|
||||
"feature": {
|
||||
"priority": 99,
|
||||
"complexity_map": {
|
||||
"high": "coupled",
|
||||
"medium": "rapid",
|
||||
"low": "rapid"
|
||||
"high": { "level": "L3", "flow": "coupled" },
|
||||
"medium": { "level": "L2", "flow": "rapid" },
|
||||
"low": { "level": "L1", "flow": "lite-lite-lite" }
|
||||
}
|
||||
}
|
||||
},
|
||||
|
||||
@@ -304,28 +304,22 @@ async function runWithTool(tool, context) {
|
||||
### 引用协议模板
|
||||
|
||||
```bash
|
||||
# 分析模式 - 必须引用 analysis-protocol.md
|
||||
# Analysis mode - use --rule to auto-load protocol and template (appended to prompt)
|
||||
ccw cli -p "
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/analysis-protocol.md)
|
||||
$(cat ~/.claude/workflows/cli-templates/prompts/analysis/02-analyze-code-patterns.txt)
|
||||
..." --tool gemini --mode analysis
|
||||
CONSTRAINTS: ...
|
||||
..." --tool gemini --mode analysis --rule analysis-code-patterns
|
||||
|
||||
# 写入模式 - 必须引用 write-protocol.md
|
||||
# Write mode - use --rule to auto-load protocol and template (appended to prompt)
|
||||
ccw cli -p "
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/write-protocol.md)
|
||||
$(cat ~/.claude/workflows/cli-templates/prompts/development/02-implement-feature.txt)
|
||||
..." --tool codex --mode write
|
||||
CONSTRAINTS: ...
|
||||
..." --tool codex --mode write --rule development-feature
|
||||
```
|
||||
|
||||
### 动态模板构建
|
||||
|
||||
```javascript
|
||||
function buildPrompt(config) {
|
||||
const { purpose, task, mode, context, expected, template } = config;
|
||||
|
||||
const protocolPath = mode === 'write'
|
||||
? '~/.claude/workflows/cli-templates/protocols/write-protocol.md'
|
||||
: '~/.claude/workflows/cli-templates/protocols/analysis-protocol.md';
|
||||
const { purpose, task, mode, context, expected, constraints } = config;
|
||||
|
||||
return `
|
||||
PURPOSE: ${purpose}
|
||||
@@ -333,8 +327,8 @@ TASK: ${task.map(t => `• ${t}`).join('\n')}
|
||||
MODE: ${mode}
|
||||
CONTEXT: ${context}
|
||||
EXPECTED: ${expected}
|
||||
RULES: $(cat ${protocolPath}) $(cat ${template})
|
||||
`;
|
||||
CONSTRAINTS: ${constraints || ''}
|
||||
`; // Use --rule option to auto-append protocol + template
|
||||
}
|
||||
```
|
||||
|
||||
@@ -435,11 +429,11 @@ CLI 调用 (Bash + ccw cli):
|
||||
- 相关任务使用 `--resume` 保持上下文
|
||||
- 独立任务不使用 `--resume`
|
||||
|
||||
### 4. 提示词规范
|
||||
### 4. Prompt Specification
|
||||
|
||||
- 始终使用 PURPOSE/TASK/MODE/CONTEXT/EXPECTED/RULES 结构
|
||||
- 必须引用协议模板(analysis-protocol 或 write-protocol)
|
||||
- 使用 `$(cat ...)` 动态加载模板
|
||||
- Always use PURPOSE/TASK/MODE/CONTEXT/EXPECTED/CONSTRAINTS structure
|
||||
- Use `--rule <template>` to auto-append protocol + template to prompt
|
||||
- Template name format: `category-function` (e.g., `analysis-code-patterns`)
|
||||
|
||||
### 5. 结果处理
|
||||
|
||||
|
||||
@@ -76,8 +76,8 @@ TASK: • Extract conflicts from IMPL_PLAN and lessons • Group by type (archit
|
||||
MODE: analysis
|
||||
CONTEXT: @.workflow/.archives/*/IMPL_PLAN.md @.workflow/.archives/manifest.json
|
||||
EXPECTED: Conflict patterns with frequency and resolution
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/workflow/skill-aggregation.txt) | analysis=READ-ONLY
|
||||
" --tool gemini --cd .workflow/.archives
|
||||
CONSTRAINTS: analysis=READ-ONLY
|
||||
" --tool gemini --mode analysis --rule workflow-skill-aggregation --cd .workflow/.archives
|
||||
```
|
||||
|
||||
**Pattern Grouping**:
|
||||
@@ -72,8 +72,8 @@ TASK: • Group successes by functional domain • Categorize challenges by seve
|
||||
MODE: analysis
|
||||
CONTEXT: @.workflow/.archives/manifest.json
|
||||
EXPECTED: Aggregated lessons with frequency counts
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/workflow/skill-aggregation.txt) | analysis=READ-ONLY
|
||||
" --tool gemini --cd .workflow/.archives
|
||||
CONSTRAINTS: analysis=READ-ONLY
|
||||
" --tool gemini --mode analysis --rule workflow-skill-aggregation --cd .workflow/.archives
|
||||
```
|
||||
|
||||
**Severity Classification**:
|
||||
@@ -5,7 +5,7 @@
|
||||
2. [Tool Selection](#tool-selection)
|
||||
3. [Prompt Template](#prompt-template)
|
||||
4. [CLI Execution](#cli-execution)
|
||||
5. [Execution Configuration](#execution-configuration)
|
||||
5. [Auto-Invoke Triggers](#auto-invoke-triggers)
|
||||
6. [Best Practices](#best-practices)
|
||||
|
||||
---
|
||||
@@ -110,13 +110,13 @@ When primary tool fails or is unavailable:
|
||||
|
||||
### Universal Prompt Template
|
||||
|
||||
```
|
||||
PURPOSE: [what] + [why] + [success criteria] + [constraints/scope]
|
||||
```bash
|
||||
ccw cli -p "PURPOSE: [what] + [why] + [success criteria] + [constraints/scope]
|
||||
TASK: • [step 1: specific action] • [step 2: specific action] • [step 3: specific action]
|
||||
MODE: [analysis|write]
|
||||
CONTEXT: @[file patterns] | Memory: [session/tech/module context]
|
||||
EXPECTED: [deliverable format] + [quality criteria] + [structure requirements]
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/[mode]-protocol.md) $(cat ~/.claude/workflows/cli-templates/prompts/[category]/[template].txt) | [domain constraints]
|
||||
CONSTRAINTS: [domain constraints]" --tool <tool-id> --mode <analysis|write> --rule <category-template>
|
||||
```
|
||||
|
||||
### Intent Capture Checklist (Before CLI Execution)
|
||||
@@ -165,11 +165,11 @@ Every command MUST include these fields:
|
||||
- Bad Example: "Report"
|
||||
- Good Example: "Markdown report with: severity levels (Critical/High/Medium/Low), file:line references, remediation code snippets, priority ranking"
|
||||
|
||||
- **RULES**
|
||||
- Purpose: Protocol + template + constraints
|
||||
- Components: $(cat protocol) + $(cat template) + domain rules
|
||||
- Bad Example: (missing)
|
||||
- Good Example: "$(cat ~/.claude/workflows/cli-templates/protocols/analysis-protocol.md) $(cat ~/.claude/workflows/cli-templates/prompts/analysis/03-assess-security-risks.txt) \| Focus on authentication \| Ignore test files"
|
||||
- **CONSTRAINTS**
|
||||
- Purpose: Domain-specific constraints
|
||||
- Components: Scope limits, special requirements, focus areas
|
||||
- Bad Example: (missing or too vague)
|
||||
- Good Example: "Focus on authentication | Ignore test files | No breaking changes"
|
||||
|
||||
### CONTEXT Configuration
|
||||
|
||||
@@ -204,7 +204,11 @@ Memory: Integration with auth module, using shared error patterns from @shared/u
|
||||
For complex requirements, discover files BEFORE CLI execution:
|
||||
|
||||
```bash
|
||||
# Step 1: Discover files
|
||||
# Step 1: Discover files (choose one method)
|
||||
# Method A: ACE semantic search (recommended)
|
||||
mcp__ace-tool__search_context(project_root_path="/path", query="React components with export")
|
||||
|
||||
# Method B: Ripgrep pattern search
|
||||
rg "export.*Component" --files-with-matches --type ts
|
||||
|
||||
# Step 2: Build CONTEXT
|
||||
@@ -214,108 +218,60 @@ CONTEXT: @components/Auth.tsx @types/auth.d.ts | Memory: Previous type refactori
|
||||
ccw cli -p "..." --tool <tool-id> --mode analysis --cd src
|
||||
```
|
||||
|
||||
### RULES Configuration
|
||||
### --rule Configuration
|
||||
|
||||
**Format**: `RULES: $(cat ~/.claude/workflows/cli-templates/prompts/[category]/[template].txt) | [constraints]`
|
||||
**Use `--rule` option to auto-load templates**:
|
||||
|
||||
**⚠️ MANDATORY**: Exactly ONE template reference is REQUIRED. Select from Task-Template Matrix or use universal fallback:
|
||||
- `universal/00-universal-rigorous-style.txt` - For precision-critical tasks (default fallback)
|
||||
- `universal/00-universal-creative-style.txt` - For exploratory tasks
|
||||
|
||||
**Command Substitution Rules**:
|
||||
- Use `$(cat ...)` directly in **double quotes** - command substitution executes in your local shell BEFORE passing to ccw
|
||||
- Shell expands `$(cat ...)` into file content automatically - do NOT read template content first
|
||||
- NEVER use escape characters (`\$`, `\"`, `\'`) or single quotes - these prevent shell expansion
|
||||
- Tilde (`~`) expands correctly in prompt context
|
||||
|
||||
**Critical**: Use double quotes `"..."` around the entire prompt to enable `$(cat ...)` expansion:
|
||||
```bash
|
||||
# ✓ CORRECT - double quotes allow shell expansion
|
||||
ccw cli -p "RULES: $(cat ~/.claude/workflows/cli-templates/protocols/analysis-protocol.md) ..." --tool <tool-id>
|
||||
|
||||
# ✗ WRONG - single quotes prevent expansion
|
||||
ccw cli -p 'RULES: $(cat ~/.claude/workflows/cli-templates/protocols/analysis-protocol.md) ...' --tool <tool-id>
|
||||
|
||||
# ✗ WRONG - escaped $ prevents expansion
|
||||
ccw cli -p "RULES: \$(cat ~/.claude/workflows/cli-templates/protocols/analysis-protocol.md) ..." --tool <tool-id>
|
||||
ccw cli -p "..." --tool gemini --mode analysis --rule analysis-review-architecture
|
||||
```
|
||||
|
||||
### Mode Protocol References (MANDATORY)
|
||||
### Mode Protocol References
|
||||
|
||||
**⚠️ REQUIRED**: Every CLI execution MUST include the corresponding mode protocol in RULES:
|
||||
|
||||
#### Mode Rule Templates
|
||||
|
||||
**Purpose**: Mode protocols define permission boundaries and operational constraints for each execution mode.
|
||||
**`--rule` auto-loads Protocol based on mode**:
|
||||
- `--mode analysis` → analysis-protocol.md
|
||||
- `--mode write` → write-protocol.md
|
||||
|
||||
**Protocol Mapping**:
|
||||
|
||||
- **`analysis`** mode
|
||||
- Protocol: `$(cat ~/.claude/workflows/cli-templates/protocols/analysis-protocol.md)`
|
||||
- Permission: Read-only operations
|
||||
- Enforces: No file creation/modification/deletion
|
||||
- Permission: Read-only
|
||||
- Constraint: No file create/modify/delete
|
||||
|
||||
- **`write`** mode
|
||||
- Protocol: `$(cat ~/.claude/workflows/cli-templates/protocols/write-protocol.md)`
|
||||
- Permission: Create/Modify/Delete files
|
||||
- Enforces: Explicit write authorization and full workflow execution capability
|
||||
|
||||
**RULES Format** (protocol MUST be included):
|
||||
```bash
|
||||
# Analysis mode - MUST include analysis-protocol.md
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/analysis-protocol.md) $(cat ~/.claude/workflows/cli-templates/prompts/analysis/...) | constraints
|
||||
|
||||
# Write mode - MUST include write-protocol.md
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/write-protocol.md) $(cat ~/.claude/workflows/cli-templates/prompts/development/...) | constraints
|
||||
```
|
||||
|
||||
**Validation**: CLI execution without mode protocol reference is INVALID
|
||||
|
||||
**Why Mode Rules Are Required**:
|
||||
- Ensures consistent permission enforcement across all tools
|
||||
- Prevents accidental file modifications during analysis tasks
|
||||
- Provides explicit authorization trail for write operations
|
||||
- Enables safe automation with clear boundaries
|
||||
- Constraint: Full workflow execution
|
||||
|
||||
### Template System
|
||||
|
||||
**Base Path**: `~/.claude/workflows/cli-templates/prompts/`
|
||||
**Available `--rule` template names**:
|
||||
|
||||
**Naming Convention**:
|
||||
- `00-*` - Universal fallbacks (when no specific match)
|
||||
- `01-*` - Universal, high-frequency
|
||||
- `02-*` - Common specialized
|
||||
- `03-*` - Domain-specific
|
||||
|
||||
**Universal Templates**:
|
||||
|
||||
- **`universal/00-universal-rigorous-style.txt`**: Precision-critical, systematic methodology
|
||||
- **`universal/00-universal-creative-style.txt`**: Exploratory, innovative solutions
|
||||
|
||||
**Task-Template Matrix**:
|
||||
**Universal**:
|
||||
- `universal-rigorous-style` - Precise tasks
|
||||
- `universal-creative-style` - Exploratory tasks
|
||||
|
||||
**Analysis**:
|
||||
- Execution Tracing: `analysis/01-trace-code-execution.txt`
|
||||
- Bug Diagnosis: `analysis/01-diagnose-bug-root-cause.txt`
|
||||
- Code Patterns: `analysis/02-analyze-code-patterns.txt`
|
||||
- Document Analysis: `analysis/02-analyze-technical-document.txt`
|
||||
- Architecture Review: `analysis/02-review-architecture.txt`
|
||||
- Code Review: `analysis/02-review-code-quality.txt`
|
||||
- Performance: `analysis/03-analyze-performance.txt`
|
||||
- Security: `analysis/03-assess-security-risks.txt`
|
||||
- `analysis-trace-code-execution` - Execution tracing
|
||||
- `analysis-diagnose-bug-root-cause` - Bug diagnosis
|
||||
- `analysis-analyze-code-patterns` - Code patterns
|
||||
- `analysis-analyze-technical-document` - Document analysis
|
||||
- `analysis-review-architecture` - Architecture review
|
||||
- `analysis-review-code-quality` - Code review
|
||||
- `analysis-analyze-performance` - Performance analysis
|
||||
- `analysis-assess-security-risks` - Security assessment
|
||||
|
||||
**Planning**:
|
||||
- Architecture: `planning/01-plan-architecture-design.txt`
|
||||
- Task Breakdown: `planning/02-breakdown-task-steps.txt`
|
||||
- Component Design: `planning/02-design-component-spec.txt`
|
||||
- Migration: `planning/03-plan-migration-strategy.txt`
|
||||
- `planning-plan-architecture-design` - Architecture design
|
||||
- `planning-breakdown-task-steps` - Task breakdown
|
||||
- `planning-design-component-spec` - Component design
|
||||
- `planning-plan-migration-strategy` - Migration strategy
|
||||
|
||||
**Development**:
|
||||
- Feature: `development/02-implement-feature.txt`
|
||||
- Refactoring: `development/02-refactor-codebase.txt`
|
||||
- Tests: `development/02-generate-tests.txt`
|
||||
- UI Component: `development/02-implement-component-ui.txt`
|
||||
- Debugging: `development/03-debug-runtime-issues.txt`
|
||||
- `development-implement-feature` - Feature implementation
|
||||
- `development-refactor-codebase` - Code refactoring
|
||||
- `development-generate-tests` - Test generation
|
||||
- `development-implement-component-ui` - UI component
|
||||
- `development-debug-runtime-issues` - Runtime debugging
|
||||
|
||||
---
|
||||
|
||||
@@ -336,10 +292,13 @@ RULES: $(cat ~/.claude/workflows/cli-templates/protocols/write-protocol.md) $(ca
|
||||
- **`review`**
|
||||
- Permission: Read-only (code review output)
|
||||
- Use For: Git-aware code review of uncommitted changes, branch diffs, specific commits
|
||||
- Specification: **codex only** - uses `codex review` subcommand with `--uncommitted` by default
|
||||
- Specification: **codex only** - uses `codex review` subcommand
|
||||
- Tool Behavior:
|
||||
- `codex`: Executes `codex review --uncommitted [prompt]` for structured code review
|
||||
- `codex`: Executes `codex review` for structured code review
|
||||
- Other tools (gemini/qwen/claude): Accept mode but no operation change (treated as analysis)
|
||||
- **Constraint**: Target flags (`--uncommitted`, `--base`, `--commit`) and prompt are mutually exclusive
|
||||
- With prompt only: `ccw cli -p "Focus on security" --tool codex --mode review` (reviews uncommitted by default)
|
||||
- With target flag only: `ccw cli --tool codex --mode review --commit abc123` (no prompt allowed)
|
||||
|
||||
### Command Options
|
||||
|
||||
@@ -368,6 +327,11 @@ RULES: $(cat ~/.claude/workflows/cli-templates/protocols/write-protocol.md) $(ca
|
||||
- Description: Resume previous session
|
||||
- Default: -
|
||||
|
||||
- **`--rule <template>`**
|
||||
- Description: Template name, auto-loads protocol + template appended to prompt
|
||||
- Default: universal-rigorous-style
|
||||
- Auto-selects protocol based on --mode
|
||||
|
||||
### Directory Configuration
|
||||
|
||||
#### Working Directory (`--cd`)
|
||||
@@ -429,62 +393,60 @@ ASSISTANT RESPONSE: [Previous output]
|
||||
|
||||
**Analysis Task** (Security Audit):
|
||||
```bash
|
||||
ccw cli -p "
|
||||
PURPOSE: Identify OWASP Top 10 vulnerabilities in authentication module to pass security audit; success = all critical/high issues documented with remediation
|
||||
ccw cli -p "PURPOSE: Identify OWASP Top 10 vulnerabilities in authentication module to pass security audit; success = all critical/high issues documented with remediation
|
||||
TASK: • Scan for injection flaws (SQL, command, LDAP) • Check authentication bypass vectors • Evaluate session management • Assess sensitive data exposure
|
||||
MODE: analysis
|
||||
CONTEXT: @src/auth/**/* @src/middleware/auth.ts | Memory: Using bcrypt for passwords, JWT for sessions
|
||||
EXPECTED: Security report with: severity matrix, file:line references, CVE mappings where applicable, remediation code snippets prioritized by risk
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/analysis-protocol.md) $(cat ~/.claude/workflows/cli-templates/prompts/analysis/03-assess-security-risks.txt) | Focus on authentication | Ignore test files
|
||||
" --tool <tool-id> --mode analysis --cd src/auth
|
||||
CONSTRAINTS: Focus on authentication | Ignore test files
|
||||
" --tool gemini --mode analysis --rule analysis-assess-security-risks --cd src/auth
|
||||
```
|
||||
|
||||
**Implementation Task** (New Feature):
|
||||
```bash
|
||||
ccw cli -p "
|
||||
PURPOSE: Implement rate limiting for API endpoints to prevent abuse; must be configurable per-endpoint; backward compatible with existing clients
|
||||
ccw cli -p "PURPOSE: Implement rate limiting for API endpoints to prevent abuse; must be configurable per-endpoint; backward compatible with existing clients
|
||||
TASK: • Create rate limiter middleware with sliding window • Implement per-route configuration • Add Redis backend for distributed state • Include bypass for internal services
|
||||
MODE: write
|
||||
CONTEXT: @src/middleware/**/* @src/config/**/* | Memory: Using Express.js, Redis already configured, existing middleware pattern in auth.ts
|
||||
EXPECTED: Production-ready code with: TypeScript types, unit tests, integration test, configuration example, migration guide
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/write-protocol.md) $(cat ~/.claude/workflows/cli-templates/prompts/development/02-implement-feature.txt) | Follow existing middleware patterns | No breaking changes
|
||||
" --tool <tool-id> --mode write
|
||||
CONSTRAINTS: Follow existing middleware patterns | No breaking changes
|
||||
" --tool gemini --mode write --rule development-implement-feature
|
||||
```
|
||||
|
||||
**Bug Fix Task**:
|
||||
```bash
|
||||
ccw cli -p "
|
||||
PURPOSE: Fix memory leak in WebSocket connection handler causing server OOM after 24h; root cause must be identified before any fix
|
||||
ccw cli -p "PURPOSE: Fix memory leak in WebSocket connection handler causing server OOM after 24h; root cause must be identified before any fix
|
||||
TASK: • Trace connection lifecycle from open to close • Identify event listener accumulation • Check cleanup on disconnect • Verify garbage collection eligibility
|
||||
MODE: analysis
|
||||
CONTEXT: @src/websocket/**/* @src/services/connection-manager.ts | Memory: Using ws library, ~5000 concurrent connections in production
|
||||
EXPECTED: Root cause analysis with: memory profile, leak source (file:line), fix recommendation with code, verification steps
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/analysis-protocol.md) $(cat ~/.claude/workflows/cli-templates/prompts/analysis/01-diagnose-bug-root-cause.txt) | Focus on resource cleanup
|
||||
" --tool <tool-id> --mode analysis --cd src
|
||||
CONSTRAINTS: Focus on resource cleanup
|
||||
" --tool gemini --mode analysis --rule analysis-diagnose-bug-root-cause --cd src
|
||||
```
|
||||
|
||||
**Refactoring Task**:
|
||||
```bash
|
||||
ccw cli -p "
|
||||
PURPOSE: Refactor payment processing to use strategy pattern for multi-gateway support; no functional changes; all existing tests must pass
|
||||
ccw cli -p "PURPOSE: Refactor payment processing to use strategy pattern for multi-gateway support; no functional changes; all existing tests must pass
|
||||
TASK: • Extract gateway interface from current implementation • Create strategy classes for Stripe, PayPal • Implement factory for gateway selection • Migrate existing code to use strategies
|
||||
MODE: write
|
||||
CONTEXT: @src/payments/**/* @src/types/payment.ts | Memory: Currently only Stripe, adding PayPal next sprint, must support future gateways
|
||||
EXPECTED: Refactored code with: strategy interface, concrete implementations, factory class, updated tests, migration checklist
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/protocols/write-protocol.md) $(cat ~/.claude/workflows/cli-templates/prompts/development/02-refactor-codebase.txt) | Preserve all existing behavior | Tests must pass
|
||||
" --tool <tool-id> --mode write
|
||||
CONSTRAINTS: Preserve all existing behavior | Tests must pass
|
||||
" --tool gemini --mode write --rule development-refactor-codebase
|
||||
```
|
||||
|
||||
**Code Review Task** (codex review mode):
|
||||
```bash
|
||||
# Review uncommitted changes (default)
|
||||
# Option 1: Custom prompt (reviews uncommitted changes by default)
|
||||
ccw cli -p "Focus on security vulnerabilities and error handling" --tool codex --mode review
|
||||
|
||||
# Review with custom instructions
|
||||
ccw cli -p "Check for breaking changes in API contracts and backward compatibility" --tool codex --mode review
|
||||
# Option 2: Target flag only (no prompt allowed with target flags)
|
||||
ccw cli --tool codex --mode review --uncommitted
|
||||
ccw cli --tool codex --mode review --base main
|
||||
ccw cli --tool codex --mode review --commit abc123
|
||||
```
|
||||
|
||||
> **Note**: `--mode review` only triggers special behavior for `codex` tool (uses `codex review --uncommitted`). Other tools accept the mode but execute as standard analysis.
|
||||
> **Note**: `--mode review` only triggers special behavior for `codex` tool. Target flags (`--uncommitted`, `--base`, `--commit`) and prompt are **mutually exclusive** - use one or the other, not both.
|
||||
|
||||
---
|
||||
|
||||
@@ -500,6 +462,41 @@ ccw cli -p "Check for breaking changes in API contracts and backward compatibili
|
||||
|
||||
---
|
||||
|
||||
## Auto-Invoke Triggers
|
||||
|
||||
**Proactive CLI invocation** - Auto-invoke `ccw cli` when encountering these scenarios:
|
||||
|
||||
| Trigger Condition | Suggested Rule | When to Use |
|
||||
|-------------------|----------------|-------------|
|
||||
| **Self-repair fails** | `analysis-diagnose-bug-root-cause` | After 1+ failed fix attempts |
|
||||
| **Ambiguous requirements** | `planning-breakdown-task-steps` | Task description lacks clarity |
|
||||
| **Architecture decisions** | `planning-plan-architecture-design` | Complex feature needs design |
|
||||
| **Pattern uncertainty** | `analysis-analyze-code-patterns` | Unsure of existing conventions |
|
||||
| **Critical code paths** | `analysis-assess-security-risks` | Security/performance sensitive |
|
||||
|
||||
### Execution Principles
|
||||
|
||||
- **Default mode**: `--mode analysis` (read-only, safe for auto-execution)
|
||||
- **No confirmation needed**: Invoke proactively when triggers match
|
||||
- **Wait for results**: Complete analysis before next action
|
||||
- **Tool selection**: Use context-appropriate tool or fallback chain (`gemini` → `qwen` → `codex`)
|
||||
- **Rule flexibility**: Suggested rules are guidelines, not requirements - choose the most appropriate template for the situation
|
||||
|
||||
### Example: Bug Fix with Auto-Invoke
|
||||
|
||||
```bash
|
||||
# After 1+ failed fix attempts, auto-invoke root cause analysis
|
||||
ccw cli -p "PURPOSE: Identify root cause of [bug description]; success = actionable fix strategy
|
||||
TASK: • Trace execution flow • Identify failure point • Analyze state at failure • Determine fix approach
|
||||
MODE: analysis
|
||||
CONTEXT: @src/module/**/* | Memory: Previous fix attempts failed at [location]
|
||||
EXPECTED: Root cause analysis with: failure mechanism, stack trace interpretation, fix recommendation with code
|
||||
CONSTRAINTS: Focus on [specific area]
|
||||
" --tool gemini --mode analysis --rule analysis-diagnose-bug-root-cause
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Core Principles
|
||||
@@ -509,16 +506,15 @@ ccw cli -p "Check for breaking changes in API contracts and backward compatibili
|
||||
- **Use tools early and often** - Tools are faster and more thorough
|
||||
- **Unified CLI** - Always use `ccw cli -p` for consistent parameter handling
|
||||
- **Default mode is analysis** - Omit `--mode` for read-only operations, explicitly use `--mode write` for file modifications
|
||||
- **One template required** - ALWAYS reference exactly ONE template in RULES (use universal fallback if no specific match)
|
||||
- **Use `--rule` for templates** - Auto-loads protocol + template appended to prompt
|
||||
- **Write protection** - Require EXPLICIT `--mode write` for file operations
|
||||
- **Use double quotes for shell expansion** - Always wrap prompts in double quotes `"..."` to enable `$(cat ...)` command substitution; NEVER use single quotes or escape characters (`\$`, `\"`, `\'`)
|
||||
|
||||
### Workflow Principles
|
||||
|
||||
- **Use CCW unified interface** for all executions
|
||||
- **Always include template** - Use Task-Template Matrix or universal fallback
|
||||
- **Always include template** - Use `--rule <template-name>` to load templates
|
||||
- **Be specific** - Clear PURPOSE, TASK, EXPECTED fields
|
||||
- **Include constraints** - File patterns, scope in RULES
|
||||
- **Include constraints** - File patterns, scope in CONSTRAINTS
|
||||
- **Leverage memory context** when building on previous work
|
||||
- **Discover patterns first** - Use rg/MCP before CLI execution
|
||||
- **Default to full context** - Use `@**/*` unless specific files needed
|
||||
@@ -530,8 +526,8 @@ ccw cli -p "Check for breaking changes in API contracts and backward compatibili
|
||||
- [ ] **Context gathered** - File references + memory (default `@**/*`)
|
||||
- [ ] **Directory navigation** - `--cd` and/or `--includeDirs`
|
||||
- [ ] **Tool selected** - Explicit `--tool` or tag-based auto-selection
|
||||
- [ ] **Template applied (REQUIRED)** - Use specific or universal fallback template
|
||||
- [ ] **Constraints specified** - Scope, requirements
|
||||
- [ ] **Rule template** - `--rule <template-name>` loads template
|
||||
- [ ] **Constraints** - Domain constraints in CONSTRAINTS field
|
||||
|
||||
### Execution Workflow
|
||||
|
||||
|
||||
@@ -1,196 +0,0 @@
|
||||
# API Settings 页面实现完成
|
||||
|
||||
## 创建的文件
|
||||
|
||||
### 1. JavaScript 文件
|
||||
**位置**: `ccw/src/templates/dashboard-js/views/api-settings.js` (28KB)
|
||||
|
||||
**主要功能**:
|
||||
- ✅ Provider Management (提供商管理)
|
||||
- 添加/编辑/删除提供商
|
||||
- 支持 OpenAI, Anthropic, Google, Ollama, Azure, Mistral, DeepSeek, Custom
|
||||
- API Key 管理(支持环境变量)
|
||||
- 连接测试功能
|
||||
|
||||
- ✅ Endpoint Management (端点管理)
|
||||
- 创建自定义端点
|
||||
- 关联提供商和模型
|
||||
- 缓存策略配置
|
||||
- 显示 CLI 使用示例
|
||||
|
||||
- ✅ Cache Management (缓存管理)
|
||||
- 全局缓存开关
|
||||
- 缓存统计显示
|
||||
- 清除缓存功能
|
||||
|
||||
### 2. CSS 样式文件
|
||||
**位置**: `ccw/src/templates/dashboard-css/31-api-settings.css` (6.8KB)
|
||||
|
||||
**样式包括**:
|
||||
- 卡片式布局
|
||||
- 表单样式
|
||||
- 进度条
|
||||
- 响应式设计
|
||||
- 空状态显示
|
||||
|
||||
### 3. 国际化支持
|
||||
**位置**: `ccw/src/templates/dashboard-js/i18n.js`
|
||||
|
||||
**添加的翻译**:
|
||||
- 英文:54 个翻译键
|
||||
- 中文:54 个翻译键
|
||||
- 包含所有 UI 文本、提示信息、错误消息
|
||||
|
||||
### 4. 配置更新
|
||||
|
||||
#### dashboard-generator.ts
|
||||
- ✅ 添加 `31-api-settings.css` 到 CSS 模块列表
|
||||
- ✅ 添加 `views/api-settings.js` 到 JS 模块列表
|
||||
|
||||
#### navigation.js
|
||||
- ✅ 添加 `api-settings` 路由处理
|
||||
- ✅ 添加标题更新逻辑
|
||||
|
||||
#### dashboard.html
|
||||
- ✅ 添加导航菜单项 (Settings 图标)
|
||||
|
||||
## API 端点使用
|
||||
|
||||
该页面使用以下后端 API(已存在):
|
||||
|
||||
### Provider APIs
|
||||
- `GET /api/litellm-api/providers` - 获取所有提供商
|
||||
- `POST /api/litellm-api/providers` - 创建提供商
|
||||
- `PUT /api/litellm-api/providers/:id` - 更新提供商
|
||||
- `DELETE /api/litellm-api/providers/:id` - 删除提供商
|
||||
- `POST /api/litellm-api/providers/:id/test` - 测试连接
|
||||
|
||||
### Endpoint APIs
|
||||
- `GET /api/litellm-api/endpoints` - 获取所有端点
|
||||
- `POST /api/litellm-api/endpoints` - 创建端点
|
||||
- `PUT /api/litellm-api/endpoints/:id` - 更新端点
|
||||
- `DELETE /api/litellm-api/endpoints/:id` - 删除端点
|
||||
|
||||
### Model Discovery
|
||||
- `GET /api/litellm-api/models/:providerType` - 获取提供商支持的模型列表
|
||||
|
||||
### Cache APIs
|
||||
- `GET /api/litellm-api/cache/stats` - 获取缓存统计
|
||||
- `POST /api/litellm-api/cache/clear` - 清除缓存
|
||||
|
||||
### Config APIs
|
||||
- `GET /api/litellm-api/config` - 获取完整配置
|
||||
- `PUT /api/litellm-api/config/cache` - 更新全局缓存设置
|
||||
|
||||
## 页面特性
|
||||
|
||||
### Provider 管理
|
||||
```
|
||||
+-- Provider Card ------------------------+
|
||||
| OpenAI Production [Edit] [Del] |
|
||||
| Type: openai |
|
||||
| Key: sk-...abc |
|
||||
| URL: https://api.openai.com/v1 |
|
||||
| Status: ✓ Enabled |
|
||||
+-----------------------------------------+
|
||||
```
|
||||
|
||||
### Endpoint 管理
|
||||
```
|
||||
+-- Endpoint Card ------------------------+
|
||||
| GPT-4o Code Review [Edit] [Del]|
|
||||
| ID: my-gpt4o |
|
||||
| Provider: OpenAI Production |
|
||||
| Model: gpt-4-turbo |
|
||||
| Cache: Enabled (60 min) |
|
||||
| Usage: ccw cli -p "..." --model my-gpt4o|
|
||||
+-----------------------------------------+
|
||||
```
|
||||
|
||||
### 表单功能
|
||||
- **Provider Form**:
|
||||
- 类型选择(8 种提供商)
|
||||
- API Key 输入(支持显示/隐藏)
|
||||
- 环境变量支持
|
||||
- Base URL 自定义
|
||||
- 启用/禁用开关
|
||||
|
||||
- **Endpoint Form**:
|
||||
- 端点 ID(CLI 使用)
|
||||
- 显示名称
|
||||
- 提供商选择(动态加载)
|
||||
- 模型选择(根据提供商动态加载)
|
||||
- 缓存策略配置
|
||||
- TTL(分钟)
|
||||
- 最大大小(KB)
|
||||
- 自动缓存文件模式
|
||||
|
||||
## 使用流程
|
||||
|
||||
### 1. 添加提供商
|
||||
1. 点击 "Add Provider"
|
||||
2. 选择提供商类型(如 OpenAI)
|
||||
3. 输入显示名称
|
||||
4. 输入 API Key(或使用环境变量)
|
||||
5. 可选:输入自定义 API Base URL
|
||||
6. 保存
|
||||
|
||||
### 2. 创建自定义端点
|
||||
1. 点击 "Add Endpoint"
|
||||
2. 输入端点 ID(用于 CLI)
|
||||
3. 输入显示名称
|
||||
4. 选择提供商
|
||||
5. 选择模型(自动加载该提供商支持的模型)
|
||||
6. 可选:配置缓存策略
|
||||
7. 保存
|
||||
|
||||
### 3. 使用端点
|
||||
```bash
|
||||
ccw cli -p "Analyze this code..." --model my-gpt4o
|
||||
```
|
||||
|
||||
## 代码质量
|
||||
|
||||
- ✅ 遵循现有代码风格
|
||||
- ✅ 使用 i18n 函数支持国际化
|
||||
- ✅ 响应式设计(移动端友好)
|
||||
- ✅ 完整的表单验证
|
||||
- ✅ 用户友好的错误提示
|
||||
- ✅ 使用 Lucide 图标
|
||||
- ✅ 模态框复用现有样式
|
||||
- ✅ 与后端 API 完全集成
|
||||
|
||||
## 测试建议
|
||||
|
||||
1. **基础功能测试**:
|
||||
- 添加/编辑/删除提供商
|
||||
- 添加/编辑/删除端点
|
||||
- 清除缓存
|
||||
|
||||
2. **表单验证测试**:
|
||||
- 必填字段验证
|
||||
- API Key 显示/隐藏
|
||||
- 环境变量切换
|
||||
|
||||
3. **数据加载测试**:
|
||||
- 模型列表动态加载
|
||||
- 缓存统计显示
|
||||
- 空状态显示
|
||||
|
||||
4. **国际化测试**:
|
||||
- 切换语言(英文/中文)
|
||||
- 验证所有文本正确显示
|
||||
|
||||
## 下一步
|
||||
|
||||
页面已完成并集成到项目中。启动 CCW Dashboard 后:
|
||||
1. 导航栏会显示 "API Settings" 菜单项(Settings 图标)
|
||||
2. 点击进入即可使用所有功能
|
||||
3. 所有操作会实时同步到配置文件
|
||||
|
||||
## 注意事项
|
||||
|
||||
- 页面使用现有的 LiteLLM API 路由(`litellm-api-routes.ts`)
|
||||
- 配置保存在项目的 LiteLLM 配置文件中
|
||||
- 支持环境变量引用格式:`${VARIABLE_NAME}`
|
||||
- API Key 在显示时会自动脱敏(显示前 4 位和后 4 位)
|
||||
@@ -1,508 +0,0 @@
|
||||
# CCW Dashboard 操作指南
|
||||
|
||||
**版本**: 6.2.0
|
||||
**更新日期**: 2025-12-20
|
||||
|
||||
本文档提供 CCW Dashboard 各功能视图的详细操作步骤说明。
|
||||
|
||||
---
|
||||
|
||||
## 目录
|
||||
|
||||
1. [首页概览操作](#1-首页概览操作)
|
||||
2. [会话详情操作](#2-会话详情操作)
|
||||
3. [CLI 管理器操作](#3-cli-管理器操作)
|
||||
4. [核心记忆操作](#4-核心记忆操作)
|
||||
5. [MCP 服务器管理操作](#5-mcp-服务器管理操作)
|
||||
6. [Hook 管理器操作](#6-hook-管理器操作)
|
||||
7. [技能管理器操作](#7-技能管理器操作)
|
||||
8. [CodexLens 索引管理操作](#8-codexlens-索引管理操作)
|
||||
|
||||
---
|
||||
|
||||
## 1. 首页概览操作
|
||||
|
||||
### 1.1 进入方式
|
||||
- 启动 Dashboard 后自动显示
|
||||
- 点击侧边栏 **"概览"** 导航项
|
||||
|
||||
### 1.2 项目切换
|
||||
1. 点击顶部操作栏的 **项目路径选择器**
|
||||
2. 从下拉列表选择最近项目,或点击 **"浏览..."** 选择新项目
|
||||
3. 系统自动加载新项目数据
|
||||
|
||||
### 1.3 数据刷新
|
||||
- 点击顶部操作栏的 **刷新按钮** (🔄)
|
||||
- 或等待 WebSocket 自动推送更新
|
||||
|
||||
### 1.4 活跃会话轮播
|
||||
- 自动轮播显示当前活跃的工作流会话
|
||||
- 点击会话卡片进入会话详情
|
||||
|
||||
### 1.5 统计卡片
|
||||
显示以下统计信息:
|
||||
- 会话总数
|
||||
- 活跃会话数
|
||||
- 已归档会话数
|
||||
- 任务完成率
|
||||
|
||||
---
|
||||
|
||||
## 2. 会话详情操作
|
||||
|
||||
### 2.1 进入方式
|
||||
- 从首页点击会话卡片
|
||||
- 从侧边栏 **"会话"** > **"全部/活跃/已归档"** 列表点击
|
||||
|
||||
### 2.2 会话列表操作
|
||||
|
||||
| 操作 | 步骤 |
|
||||
|------|------|
|
||||
| 筛选会话 | 点击 **"全部/活跃/已归档"** 标签切换 |
|
||||
| 搜索会话 | 在搜索框输入会话 ID 或描述 |
|
||||
| 查看详情 | 点击会话行展开详情 |
|
||||
|
||||
### 2.3 会话详情面板
|
||||
|
||||
#### 基本信息区
|
||||
- 会话 ID、创建时间、状态
|
||||
- 会话描述和目标
|
||||
|
||||
#### 任务列表区
|
||||
| 操作 | 说明 |
|
||||
|------|------|
|
||||
| 查看任务 | 任务以列表形式显示,包含状态图标 |
|
||||
| 展开任务 | 点击任务行查看详细信息 |
|
||||
| 任务状态 | 🔵 待处理 / 🟡 进行中 / 🟢 完成 / 🔴 失败 |
|
||||
|
||||
#### 操作按钮
|
||||
| 按钮 | 功能 |
|
||||
|------|------|
|
||||
| **归档** | 将会话标记为已归档 |
|
||||
| **删除** | 删除会话(需确认) |
|
||||
| **导出** | 导出会话数据为 JSON |
|
||||
|
||||
### 2.4 任务抽屉
|
||||
|
||||
点击任务后打开的详情抽屉:
|
||||
|
||||
| 区域 | 内容 |
|
||||
|------|------|
|
||||
| 头部 | 任务标题、状态徽章 |
|
||||
| 上下文 | 相关文件列表、依赖项 |
|
||||
| 执行日志 | 实时执行输出(WebSocket 推送) |
|
||||
| 操作区 | 重试、跳过、标记完成 |
|
||||
|
||||
---
|
||||
|
||||
## 3. CLI 管理器操作
|
||||
|
||||
### 3.1 进入方式
|
||||
侧边栏 **"项目"** > **"状态"**
|
||||
|
||||
### 3.2 CLI 工具状态面板
|
||||
|
||||
#### 工具状态卡片
|
||||
每个工具(Gemini/Qwen/Codex)显示:
|
||||
- 安装状态:✅ 已安装 / ❌ 未安装
|
||||
- 版本信息
|
||||
- 默认模型配置
|
||||
|
||||
#### 设置默认工具
|
||||
1. 点击工具卡片上的 **"设为默认"** 按钮
|
||||
2. 确认选择
|
||||
|
||||
#### 模型配置
|
||||
1. 点击 **"配置"** 按钮
|
||||
2. 在弹出的模态框中设置:
|
||||
- 主模型 (Primary Model)
|
||||
- 备用模型 (Fallback Model)
|
||||
3. 点击 **"保存"**
|
||||
|
||||
### 3.3 安装/卸载向导
|
||||
|
||||
#### 安装工具
|
||||
1. 点击未安装工具的 **"安装"** 按钮
|
||||
2. 按向导步骤操作:
|
||||
- 确认系统要求
|
||||
- 输入 API 密钥(如需要)
|
||||
- 选择安装选项
|
||||
3. 等待安装完成
|
||||
|
||||
#### 卸载工具
|
||||
1. 点击已安装工具的 **"卸载"** 按钮
|
||||
2. 确认卸载操作
|
||||
3. 等待卸载完成
|
||||
|
||||
### 3.4 执行历史
|
||||
|
||||
侧边栏 **"项目"** > **"历史"**
|
||||
|
||||
| 操作 | 说明 |
|
||||
|------|------|
|
||||
| 查看记录 | 列表显示执行时间、工具、提示词摘要 |
|
||||
| 展开详情 | 点击记录查看完整输入/输出 |
|
||||
| 恢复会话 | 点击 **"继续"** 按钮使用 `--resume` 恢复 |
|
||||
| 复制命令 | 点击 **"复制"** 图标复制执行命令 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 核心记忆操作
|
||||
|
||||
### 4.1 进入方式
|
||||
侧边栏 **"记忆"** > **"核心记忆"**
|
||||
|
||||
### 4.2 记忆列表视图
|
||||
|
||||
#### 查看记忆
|
||||
- 记忆条目以卡片形式显示
|
||||
- 包含:标题、摘要、标签、创建时间
|
||||
|
||||
#### 创建记忆
|
||||
1. 点击 **"+ 新建记忆"** 按钮
|
||||
2. 填写表单:
|
||||
| 字段 | 说明 |
|
||||
|------|------|
|
||||
| 标题 | 记忆标题(必填) |
|
||||
| 内容 | 记忆正文(Markdown 支持) |
|
||||
| 标签 | 分类标签(逗号分隔) |
|
||||
| 优先级 | 高/中/低 |
|
||||
3. 点击 **"保存"**
|
||||
|
||||
#### 编辑记忆
|
||||
1. 点击记忆卡片的 **"编辑"** 图标
|
||||
2. 修改内容
|
||||
3. 点击 **"保存"**
|
||||
|
||||
#### 归档/删除
|
||||
- **归档**: 点击 **"归档"** 图标,记忆移至归档列表
|
||||
- **删除**: 点击 **"删除"** 图标,确认后永久删除
|
||||
|
||||
### 4.3 集群视图
|
||||
|
||||
切换到 **"集群"** 标签页
|
||||
|
||||
#### 查看集群
|
||||
- 自动聚类的会话分组显示
|
||||
- 每个集群显示:名称、成员数、创建时间
|
||||
|
||||
#### 自动聚类
|
||||
1. 点击 **"自动聚类"** 按钮
|
||||
2. 设置参数:
|
||||
| 参数 | 说明 |
|
||||
|------|------|
|
||||
| 相似度阈值 | 0.0-1.0,默认 0.7 |
|
||||
| 最小成员数 | 集群最小会话数 |
|
||||
3. 点击 **"执行"**
|
||||
4. 等待聚类完成
|
||||
|
||||
#### 集群管理
|
||||
| 操作 | 步骤 |
|
||||
|------|------|
|
||||
| 查看成员 | 点击集群卡片展开成员列表 |
|
||||
| 重命名 | 点击集群名称编辑 |
|
||||
| 合并集群 | 选中多个集群,点击 **"合并"** |
|
||||
| 删除集群 | 点击 **"删除"** 图标(成员不会删除) |
|
||||
|
||||
### 4.4 嵌入管理
|
||||
|
||||
#### 查看嵌入状态
|
||||
- 显示已生成嵌入的记忆数量
|
||||
- 显示待生成嵌入的记忆数量
|
||||
|
||||
#### 生成嵌入
|
||||
1. 点击 **"生成嵌入"** 按钮
|
||||
2. 选择范围:
|
||||
- 全部未嵌入
|
||||
- 选中的记忆
|
||||
3. 等待生成完成(进度条显示)
|
||||
|
||||
---
|
||||
|
||||
## 5. MCP 服务器管理操作
|
||||
|
||||
### 5.1 进入方式
|
||||
侧边栏 **"配置"** > **"MCP 服务器"**
|
||||
|
||||
### 5.2 服务器列表
|
||||
|
||||
#### 查看服务器
|
||||
- 列表显示已配置的服务器
|
||||
- 每行显示:名称、类型、状态、配置来源
|
||||
|
||||
#### 状态指示
|
||||
- 🟢 运行中
|
||||
- 🔴 已停止
|
||||
- 🟡 启动中
|
||||
|
||||
### 5.3 创建服务器
|
||||
|
||||
#### 手动创建
|
||||
1. 点击 **"+ 添加服务器"** 按钮
|
||||
2. 填写表单:
|
||||
| 字段 | 说明 |
|
||||
|------|------|
|
||||
| 名称 | 服务器标识名(必填) |
|
||||
| 命令 | 启动命令(如 `node`) |
|
||||
| 参数 | 命令参数数组 |
|
||||
| 环境变量 | KEY=VALUE 格式 |
|
||||
| 配置范围 | 项目级 / 全局 |
|
||||
3. 点击 **"保存"**
|
||||
|
||||
#### 从模板安装
|
||||
1. 点击 **"模板"** 标签
|
||||
2. 浏览可用模板
|
||||
3. 点击模板的 **"安装"** 按钮
|
||||
4. 确认或修改配置
|
||||
5. 点击 **"确认安装"**
|
||||
|
||||
### 5.4 编辑/删除
|
||||
|
||||
| 操作 | 步骤 |
|
||||
|------|------|
|
||||
| 编辑 | 点击 **"编辑"** 图标 → 修改配置 → 保存 |
|
||||
| 删除 | 点击 **"删除"** 图标 → 确认删除 |
|
||||
| 启用/禁用 | 切换状态开关 |
|
||||
|
||||
### 5.5 配置文件位置
|
||||
|
||||
| 范围 | 文件路径 |
|
||||
|------|----------|
|
||||
| 项目级 | `.mcp.json` |
|
||||
| 全局 | `~/.claude/settings.json` |
|
||||
|
||||
---
|
||||
|
||||
## 6. Hook 管理器操作
|
||||
|
||||
### 6.1 进入方式
|
||||
侧边栏 **"配置"** > **"Hooks"**
|
||||
|
||||
### 6.2 Hook 列表
|
||||
|
||||
#### 按类型查看
|
||||
- **PreToolUse**: 工具使用前触发
|
||||
- **PostToolUse**: 工具使用后触发
|
||||
- **Notification**: 通知类钩子
|
||||
|
||||
#### 列表信息
|
||||
每个 Hook 显示:名称、类型、匹配工具、命令摘要
|
||||
|
||||
### 6.3 创建 Hook
|
||||
|
||||
#### 向导模式
|
||||
1. 点击 **"+ 添加 Hook"** 按钮
|
||||
2. 选择 Hook 类型
|
||||
3. 填写配置:
|
||||
| 字段 | 说明 |
|
||||
|------|------|
|
||||
| 名称 | Hook 标识名 |
|
||||
| 匹配器 | 匹配的工具名称(支持通配符 `*`) |
|
||||
| 命令 | 执行的 Shell 命令 |
|
||||
| 超时 | 命令超时时间(毫秒) |
|
||||
| 范围 | 项目级 / 全局 |
|
||||
4. 点击 **"保存"**
|
||||
|
||||
#### 从模板创建
|
||||
1. 点击 **"模板"** 标签
|
||||
2. 选择预设模板(如:格式化检查、安全扫描)
|
||||
3. 点击 **"使用模板"**
|
||||
4. 根据需要修改配置
|
||||
5. 点击 **"保存"**
|
||||
|
||||
### 6.4 编辑/删除
|
||||
|
||||
| 操作 | 步骤 |
|
||||
|------|------|
|
||||
| 编辑 | 点击 Hook 行 → 修改配置 → 保存 |
|
||||
| 删除 | 点击 **"删除"** 图标 → 确认 |
|
||||
| 启用/禁用 | 切换状态开关 |
|
||||
|
||||
### 6.5 配置文件位置
|
||||
|
||||
| 范围 | 文件路径 |
|
||||
|------|----------|
|
||||
| 项目级 | `.claude/settings.local.json` |
|
||||
| 全局 | `~/.claude/settings.json` |
|
||||
|
||||
---
|
||||
|
||||
## 7. 技能管理器操作
|
||||
|
||||
### 7.1 进入方式
|
||||
侧边栏 **"记忆"** > **"技能"**
|
||||
|
||||
### 7.2 技能列表
|
||||
|
||||
#### 分类视图
|
||||
- **项目技能**: `./.claude/skills/` 目录下的技能
|
||||
- **用户技能**: `~/.claude/skills/` 目录下的技能
|
||||
|
||||
#### 技能卡片信息
|
||||
- 技能名称
|
||||
- 描述
|
||||
- 版本号
|
||||
- 工具数量
|
||||
- 支持文件数量
|
||||
|
||||
### 7.3 查看技能详情
|
||||
|
||||
1. 点击技能卡片
|
||||
2. 详情面板显示:
|
||||
- 完整描述
|
||||
- 包含的工具列表
|
||||
- 支持文件列表
|
||||
- 依赖信息
|
||||
|
||||
### 7.4 创建技能
|
||||
|
||||
#### 从文件夹导入
|
||||
1. 点击 **"+ 导入技能"** 按钮
|
||||
2. 选择包含技能文件的目录
|
||||
3. 确认技能信息
|
||||
4. 点击 **"导入"**
|
||||
|
||||
#### 通过 CLI 生成
|
||||
1. 点击 **"+ 生成技能"** 按钮
|
||||
2. 输入技能描述
|
||||
3. 选择生成选项:
|
||||
- 目标目录(项目/用户)
|
||||
- 包含的能力
|
||||
4. 点击 **"生成"**
|
||||
5. 等待 AI 生成完成
|
||||
|
||||
### 7.5 删除技能
|
||||
|
||||
1. 点击技能卡片的 **"删除"** 图标
|
||||
2. 确认删除操作
|
||||
3. 技能文件将被移除
|
||||
|
||||
---
|
||||
|
||||
## 8. CodexLens 索引管理操作
|
||||
|
||||
### 8.1 进入方式
|
||||
侧边栏 **"项目"** > **"状态"** → CodexLens 面板
|
||||
|
||||
### 8.2 索引状态
|
||||
|
||||
#### 状态指示
|
||||
| 状态 | 说明 |
|
||||
|------|------|
|
||||
| ✅ 已索引 | 项目已建立索引 |
|
||||
| ⚠️ 过期 | 索引需要更新 |
|
||||
| ❌ 未索引 | 项目未建立索引 |
|
||||
|
||||
#### 索引统计
|
||||
- 总索引大小
|
||||
- 项目数量
|
||||
- 向量索引数
|
||||
- FTS 索引数
|
||||
|
||||
### 8.3 初始化索引
|
||||
|
||||
1. 点击 **"初始化索引"** 按钮
|
||||
2. 选择索引模式:
|
||||
| 模式 | 说明 |
|
||||
|------|------|
|
||||
| FTS | 全文搜索,速度快 |
|
||||
| 向量 | 语义搜索,需要嵌入模型 |
|
||||
| 混合 | FTS + 向量,功能最全 |
|
||||
3. 选择要索引的语言/文件类型
|
||||
4. 点击 **"开始索引"**
|
||||
5. 查看进度条和实时日志
|
||||
|
||||
### 8.4 清理索引
|
||||
|
||||
#### 清理当前项目
|
||||
1. 点击 **"清理项目索引"** 按钮
|
||||
2. 确认操作
|
||||
3. 当前项目索引被删除
|
||||
|
||||
#### 清理所有索引
|
||||
1. 点击 **"清理所有索引"** 按钮
|
||||
2. 输入确认文字
|
||||
3. 所有索引被删除
|
||||
|
||||
### 8.5 语义依赖管理
|
||||
|
||||
#### 检查状态
|
||||
- 显示 Python 环境状态
|
||||
- 显示已安装的依赖包
|
||||
|
||||
#### 安装依赖
|
||||
1. 点击 **"安装语义依赖"** 按钮
|
||||
2. 等待安装完成
|
||||
3. 查看安装日志
|
||||
|
||||
### 8.6 嵌入模型管理
|
||||
|
||||
#### 查看模型
|
||||
- 列出可用的嵌入模型
|
||||
- 显示已下载/未下载状态
|
||||
|
||||
#### 下载模型
|
||||
1. 点击未下载模型的 **"下载"** 按钮
|
||||
2. 等待下载完成
|
||||
3. 模型可用于向量索引
|
||||
|
||||
#### 删除模型
|
||||
1. 点击已下载模型的 **"删除"** 按钮
|
||||
2. 确认删除
|
||||
3. 模型文件被移除
|
||||
|
||||
### 8.7 测试搜索
|
||||
|
||||
1. 在测试区输入搜索查询
|
||||
2. 选择搜索模式:
|
||||
- `auto`: 自动选择
|
||||
- `hybrid`: 混合搜索
|
||||
- `exact`: 精确匹配
|
||||
- `ripgrep`: 文本搜索
|
||||
3. 点击 **"搜索"**
|
||||
4. 查看搜索结果
|
||||
|
||||
---
|
||||
|
||||
## 通用操作说明
|
||||
|
||||
### 键盘快捷键
|
||||
|
||||
| 快捷键 | 功能 |
|
||||
|--------|------|
|
||||
| `Escape` | 关闭模态框/侧边栏 |
|
||||
| `Ctrl+R` / `Cmd+R` | 刷新数据 |
|
||||
|
||||
### 主题与语言切换
|
||||
|
||||
| 操作 | 位置 |
|
||||
|------|------|
|
||||
| 切换主题 | 顶部操作栏太阳/月亮图标 |
|
||||
| 切换语言 | 顶部操作栏 EN/ZH 按钮 |
|
||||
|
||||
### 错误处理
|
||||
|
||||
| 错误类型 | 处理方式 |
|
||||
|----------|----------|
|
||||
| 网络错误 | 检查连接,点击刷新重试 |
|
||||
| 权限错误 | 检查文件/目录权限 |
|
||||
| 验证错误 | 检查表单必填字段 |
|
||||
| 超时错误 | 增加超时设置或分批操作 |
|
||||
|
||||
### WebSocket 连接
|
||||
|
||||
- **自动重连**: 断开后自动尝试重连
|
||||
- **心跳保活**: 定期发送心跳保持连接
|
||||
- **状态指示**: 页脚显示连接状态
|
||||
|
||||
---
|
||||
|
||||
## 相关文档
|
||||
|
||||
- [DASHBOARD_GUIDE.md](DASHBOARD_GUIDE.md) - Dashboard 用户指南
|
||||
- [COMMAND_REFERENCE.md](COMMAND_REFERENCE.md) - 命令参考
|
||||
- [GETTING_STARTED_CN.md](GETTING_STARTED_CN.md) - 快速入门
|
||||
|
||||
---
|
||||
|
||||
**CCW Dashboard** - Claude Code Workflow 可视化控制中心操作手册
|
||||
@@ -1,508 +0,0 @@
|
||||
# CCW Dashboard Operations Guide
|
||||
|
||||
**Version**: 6.2.0
|
||||
**Updated**: 2025-12-20
|
||||
|
||||
This document provides detailed step-by-step operation instructions for each CCW Dashboard view.
|
||||
|
||||
---
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Home Overview Operations](#1-home-overview-operations)
|
||||
2. [Session Detail Operations](#2-session-detail-operations)
|
||||
3. [CLI Manager Operations](#3-cli-manager-operations)
|
||||
4. [Core Memory Operations](#4-core-memory-operations)
|
||||
5. [MCP Server Management Operations](#5-mcp-server-management-operations)
|
||||
6. [Hook Manager Operations](#6-hook-manager-operations)
|
||||
7. [Skills Manager Operations](#7-skills-manager-operations)
|
||||
8. [CodexLens Index Management Operations](#8-codexlens-index-management-operations)
|
||||
|
||||
---
|
||||
|
||||
## 1. Home Overview Operations
|
||||
|
||||
### 1.1 Entry Point
|
||||
- Displayed automatically after Dashboard launch
|
||||
- Click **"Overview"** in the sidebar navigation
|
||||
|
||||
### 1.2 Project Switching
|
||||
1. Click the **Project Path Selector** in the top action bar
|
||||
2. Select from recent projects dropdown, or click **"Browse..."** to select a new project
|
||||
3. System automatically loads the new project data
|
||||
|
||||
### 1.3 Data Refresh
|
||||
- Click the **Refresh Button** (🔄) in the top action bar
|
||||
- Or wait for WebSocket automatic push updates
|
||||
|
||||
### 1.4 Active Session Carousel
|
||||
- Auto-rotates through currently active workflow sessions
|
||||
- Click a session card to enter session details
|
||||
|
||||
### 1.5 Statistics Cards
|
||||
Displays the following statistics:
|
||||
- Total sessions
|
||||
- Active sessions
|
||||
- Archived sessions
|
||||
- Task completion rate
|
||||
|
||||
---
|
||||
|
||||
## 2. Session Detail Operations
|
||||
|
||||
### 2.1 Entry Point
|
||||
- Click a session card from the home page
|
||||
- Click from sidebar **"Sessions"** > **"All/Active/Archived"** list
|
||||
|
||||
### 2.2 Session List Operations
|
||||
|
||||
| Operation | Steps |
|
||||
|-----------|-------|
|
||||
| Filter sessions | Click **"All/Active/Archived"** tabs to switch |
|
||||
| Search sessions | Enter session ID or description in search box |
|
||||
| View details | Click session row to expand details |
|
||||
|
||||
### 2.3 Session Detail Panel
|
||||
|
||||
#### Basic Information Area
|
||||
- Session ID, creation time, status
|
||||
- Session description and objectives
|
||||
|
||||
#### Task List Area
|
||||
| Operation | Description |
|
||||
|-----------|-------------|
|
||||
| View tasks | Tasks displayed as list with status icons |
|
||||
| Expand task | Click task row to view detailed information |
|
||||
| Task status | 🔵 Pending / 🟡 In Progress / 🟢 Completed / 🔴 Failed |
|
||||
|
||||
#### Action Buttons
|
||||
| Button | Function |
|
||||
|--------|----------|
|
||||
| **Archive** | Mark session as archived |
|
||||
| **Delete** | Delete session (requires confirmation) |
|
||||
| **Export** | Export session data as JSON |
|
||||
|
||||
### 2.4 Task Drawer
|
||||
|
||||
Detail drawer opened after clicking a task:
|
||||
|
||||
| Area | Content |
|
||||
|------|---------|
|
||||
| Header | Task title, status badge |
|
||||
| Context | Related files list, dependencies |
|
||||
| Execution log | Real-time execution output (WebSocket push) |
|
||||
| Actions | Retry, Skip, Mark complete |
|
||||
|
||||
---
|
||||
|
||||
## 3. CLI Manager Operations
|
||||
|
||||
### 3.1 Entry Point
|
||||
Sidebar **"Project"** > **"Status"**
|
||||
|
||||
### 3.2 CLI Tool Status Panel
|
||||
|
||||
#### Tool Status Cards
|
||||
Each tool (Gemini/Qwen/Codex) displays:
|
||||
- Installation status: ✅ Installed / ❌ Not installed
|
||||
- Version information
|
||||
- Default model configuration
|
||||
|
||||
#### Set Default Tool
|
||||
1. Click **"Set as Default"** button on tool card
|
||||
2. Confirm selection
|
||||
|
||||
#### Model Configuration
|
||||
1. Click **"Configure"** button
|
||||
2. In the modal dialog, set:
|
||||
- Primary Model
|
||||
- Fallback Model
|
||||
3. Click **"Save"**
|
||||
|
||||
### 3.3 Install/Uninstall Wizard
|
||||
|
||||
#### Install Tool
|
||||
1. Click **"Install"** button on uninstalled tool
|
||||
2. Follow wizard steps:
|
||||
- Confirm system requirements
|
||||
- Enter API key (if required)
|
||||
- Select installation options
|
||||
3. Wait for installation to complete
|
||||
|
||||
#### Uninstall Tool
|
||||
1. Click **"Uninstall"** button on installed tool
|
||||
2. Confirm uninstall operation
|
||||
3. Wait for uninstall to complete
|
||||
|
||||
### 3.4 Execution History
|
||||
|
||||
Sidebar **"Project"** > **"History"**
|
||||
|
||||
| Operation | Description |
|
||||
|-----------|-------------|
|
||||
| View records | List displays execution time, tool, prompt summary |
|
||||
| Expand details | Click record to view full input/output |
|
||||
| Resume session | Click **"Continue"** button to resume with `--resume` |
|
||||
| Copy command | Click **"Copy"** icon to copy execution command |
|
||||
|
||||
---
|
||||
|
||||
## 4. Core Memory Operations
|
||||
|
||||
### 4.1 Entry Point
|
||||
Sidebar **"Memory"** > **"Core Memory"**
|
||||
|
||||
### 4.2 Memory List View
|
||||
|
||||
#### View Memories
|
||||
- Memory entries displayed as cards
|
||||
- Includes: title, summary, tags, creation time
|
||||
|
||||
#### Create Memory
|
||||
1. Click **"+ New Memory"** button
|
||||
2. Fill in the form:
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| Title | Memory title (required) |
|
||||
| Content | Memory body (Markdown supported) |
|
||||
| Tags | Category tags (comma-separated) |
|
||||
| Priority | High/Medium/Low |
|
||||
3. Click **"Save"**
|
||||
|
||||
#### Edit Memory
|
||||
1. Click **"Edit"** icon on memory card
|
||||
2. Modify content
|
||||
3. Click **"Save"**
|
||||
|
||||
#### Archive/Delete
|
||||
- **Archive**: Click **"Archive"** icon, memory moves to archive list
|
||||
- **Delete**: Click **"Delete"** icon, confirm for permanent deletion
|
||||
|
||||
### 4.3 Cluster View
|
||||
|
||||
Switch to **"Clusters"** tab
|
||||
|
||||
#### View Clusters
|
||||
- Auto-clustered session groups displayed
|
||||
- Each cluster shows: name, member count, creation time
|
||||
|
||||
#### Auto Clustering
|
||||
1. Click **"Auto Cluster"** button
|
||||
2. Set parameters:
|
||||
| Parameter | Description |
|
||||
|-----------|-------------|
|
||||
| Similarity Threshold | 0.0-1.0, default 0.7 |
|
||||
| Minimum Members | Minimum sessions per cluster |
|
||||
3. Click **"Execute"**
|
||||
4. Wait for clustering to complete
|
||||
|
||||
#### Cluster Management
|
||||
| Operation | Steps |
|
||||
|-----------|-------|
|
||||
| View members | Click cluster card to expand member list |
|
||||
| Rename | Click cluster name to edit |
|
||||
| Merge clusters | Select multiple clusters, click **"Merge"** |
|
||||
| Delete cluster | Click **"Delete"** icon (members not deleted) |
|
||||
|
||||
### 4.4 Embedding Management
|
||||
|
||||
#### View Embedding Status
|
||||
- Shows count of memories with generated embeddings
|
||||
- Shows count of memories pending embedding
|
||||
|
||||
#### Generate Embeddings
|
||||
1. Click **"Generate Embeddings"** button
|
||||
2. Select scope:
|
||||
- All unembedded
|
||||
- Selected memories
|
||||
3. Wait for generation to complete (progress bar displayed)
|
||||
|
||||
---
|
||||
|
||||
## 5. MCP Server Management Operations
|
||||
|
||||
### 5.1 Entry Point
|
||||
Sidebar **"Config"** > **"MCP Servers"**
|
||||
|
||||
### 5.2 Server List
|
||||
|
||||
#### View Servers
|
||||
- List displays configured servers
|
||||
- Each row shows: name, type, status, config source
|
||||
|
||||
#### Status Indicators
|
||||
- 🟢 Running
|
||||
- 🔴 Stopped
|
||||
- 🟡 Starting
|
||||
|
||||
### 5.3 Create Server
|
||||
|
||||
#### Manual Creation
|
||||
1. Click **"+ Add Server"** button
|
||||
2. Fill in the form:
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| Name | Server identifier (required) |
|
||||
| Command | Start command (e.g., `node`) |
|
||||
| Arguments | Command arguments array |
|
||||
| Environment Variables | KEY=VALUE format |
|
||||
| Config Scope | Project / Global |
|
||||
3. Click **"Save"**
|
||||
|
||||
#### Install from Template
|
||||
1. Click **"Templates"** tab
|
||||
2. Browse available templates
|
||||
3. Click template's **"Install"** button
|
||||
4. Confirm or modify configuration
|
||||
5. Click **"Confirm Install"**
|
||||
|
||||
### 5.4 Edit/Delete
|
||||
|
||||
| Operation | Steps |
|
||||
|-----------|-------|
|
||||
| Edit | Click **"Edit"** icon → Modify config → Save |
|
||||
| Delete | Click **"Delete"** icon → Confirm deletion |
|
||||
| Enable/Disable | Toggle status switch |
|
||||
|
||||
### 5.5 Configuration File Locations
|
||||
|
||||
| Scope | File Path |
|
||||
|-------|-----------|
|
||||
| Project | `.mcp.json` |
|
||||
| Global | `~/.claude/settings.json` |
|
||||
|
||||
---
|
||||
|
||||
## 6. Hook Manager Operations
|
||||
|
||||
### 6.1 Entry Point
|
||||
Sidebar **"Config"** > **"Hooks"**
|
||||
|
||||
### 6.2 Hook List
|
||||
|
||||
#### View by Type
|
||||
- **PreToolUse**: Triggered before tool use
|
||||
- **PostToolUse**: Triggered after tool use
|
||||
- **Notification**: Notification hooks
|
||||
|
||||
#### List Information
|
||||
Each hook displays: name, type, matching tool, command summary
|
||||
|
||||
### 6.3 Create Hook
|
||||
|
||||
#### Wizard Mode
|
||||
1. Click **"+ Add Hook"** button
|
||||
2. Select hook type
|
||||
3. Fill in configuration:
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| Name | Hook identifier |
|
||||
| Matcher | Tool name to match (supports wildcard `*`) |
|
||||
| Command | Shell command to execute |
|
||||
| Timeout | Command timeout (milliseconds) |
|
||||
| Scope | Project / Global |
|
||||
4. Click **"Save"**
|
||||
|
||||
#### Create from Template
|
||||
1. Click **"Templates"** tab
|
||||
2. Select preset template (e.g., format check, security scan)
|
||||
3. Click **"Use Template"**
|
||||
4. Modify configuration as needed
|
||||
5. Click **"Save"**
|
||||
|
||||
### 6.4 Edit/Delete
|
||||
|
||||
| Operation | Steps |
|
||||
|-----------|-------|
|
||||
| Edit | Click hook row → Modify config → Save |
|
||||
| Delete | Click **"Delete"** icon → Confirm |
|
||||
| Enable/Disable | Toggle status switch |
|
||||
|
||||
### 6.5 Configuration File Locations
|
||||
|
||||
| Scope | File Path |
|
||||
|-------|-----------|
|
||||
| Project | `.claude/settings.local.json` |
|
||||
| Global | `~/.claude/settings.json` |
|
||||
|
||||
---
|
||||
|
||||
## 7. Skills Manager Operations
|
||||
|
||||
### 7.1 Entry Point
|
||||
Sidebar **"Memory"** > **"Skills"**
|
||||
|
||||
### 7.2 Skills List
|
||||
|
||||
#### Category View
|
||||
- **Project Skills**: Skills in `./.claude/skills/` directory
|
||||
- **User Skills**: Skills in `~/.claude/skills/` directory
|
||||
|
||||
#### Skill Card Information
|
||||
- Skill name
|
||||
- Description
|
||||
- Version number
|
||||
- Tool count
|
||||
- Support file count
|
||||
|
||||
### 7.3 View Skill Details
|
||||
|
||||
1. Click skill card
|
||||
2. Detail panel displays:
|
||||
- Full description
|
||||
- Included tools list
|
||||
- Support files list
|
||||
- Dependency information
|
||||
|
||||
### 7.4 Create Skill
|
||||
|
||||
#### Import from Folder
|
||||
1. Click **"+ Import Skill"** button
|
||||
2. Select directory containing skill files
|
||||
3. Confirm skill information
|
||||
4. Click **"Import"**
|
||||
|
||||
#### Generate via CLI
|
||||
1. Click **"+ Generate Skill"** button
|
||||
2. Enter skill description
|
||||
3. Select generation options:
|
||||
- Target directory (Project/User)
|
||||
- Included capabilities
|
||||
4. Click **"Generate"**
|
||||
5. Wait for AI generation to complete
|
||||
|
||||
### 7.5 Delete Skill
|
||||
|
||||
1. Click **"Delete"** icon on skill card
|
||||
2. Confirm delete operation
|
||||
3. Skill files will be removed
|
||||
|
||||
---
|
||||
|
||||
## 8. CodexLens Index Management Operations
|
||||
|
||||
### 8.1 Entry Point
|
||||
Sidebar **"Project"** > **"Status"** → CodexLens panel
|
||||
|
||||
### 8.2 Index Status
|
||||
|
||||
#### Status Indicators
|
||||
| Status | Description |
|
||||
|--------|-------------|
|
||||
| ✅ Indexed | Project has established index |
|
||||
| ⚠️ Outdated | Index needs update |
|
||||
| ❌ Not indexed | Project has no index |
|
||||
|
||||
#### Index Statistics
|
||||
- Total index size
|
||||
- Project count
|
||||
- Vector index count
|
||||
- FTS index count
|
||||
|
||||
### 8.3 Initialize Index
|
||||
|
||||
1. Click **"Initialize Index"** button
|
||||
2. Select index mode:
|
||||
| Mode | Description |
|
||||
|------|-------------|
|
||||
| FTS | Full-text search, fast |
|
||||
| Vector | Semantic search, requires embedding model |
|
||||
| Hybrid | FTS + Vector, full features |
|
||||
3. Select languages/file types to index
|
||||
4. Click **"Start Indexing"**
|
||||
5. View progress bar and real-time logs
|
||||
|
||||
### 8.4 Clean Index
|
||||
|
||||
#### Clean Current Project
|
||||
1. Click **"Clean Project Index"** button
|
||||
2. Confirm operation
|
||||
3. Current project index is deleted
|
||||
|
||||
#### Clean All Indexes
|
||||
1. Click **"Clean All Indexes"** button
|
||||
2. Enter confirmation text
|
||||
3. All indexes are deleted
|
||||
|
||||
### 8.5 Semantic Dependency Management
|
||||
|
||||
#### Check Status
|
||||
- Shows Python environment status
|
||||
- Shows installed dependency packages
|
||||
|
||||
#### Install Dependencies
|
||||
1. Click **"Install Semantic Dependencies"** button
|
||||
2. Wait for installation to complete
|
||||
3. View installation logs
|
||||
|
||||
### 8.6 Embedding Model Management
|
||||
|
||||
#### View Models
|
||||
- Lists available embedding models
|
||||
- Shows downloaded/not downloaded status
|
||||
|
||||
#### Download Model
|
||||
1. Click **"Download"** button on undownloaded model
|
||||
2. Wait for download to complete
|
||||
3. Model available for vector indexing
|
||||
|
||||
#### Delete Model
|
||||
1. Click **"Delete"** button on downloaded model
|
||||
2. Confirm deletion
|
||||
3. Model files are removed
|
||||
|
||||
### 8.7 Test Search
|
||||
|
||||
1. Enter search query in test area
|
||||
2. Select search mode:
|
||||
- `auto`: Auto select
|
||||
- `hybrid`: Hybrid search
|
||||
- `exact`: Exact match
|
||||
- `ripgrep`: Text search
|
||||
3. Click **"Search"**
|
||||
4. View search results
|
||||
|
||||
---
|
||||
|
||||
## Common Operations
|
||||
|
||||
### Keyboard Shortcuts
|
||||
|
||||
| Shortcut | Function |
|
||||
|----------|----------|
|
||||
| `Escape` | Close modal/sidebar |
|
||||
| `Ctrl+R` / `Cmd+R` | Refresh data |
|
||||
|
||||
### Theme & Language Switching
|
||||
|
||||
| Operation | Location |
|
||||
|-----------|----------|
|
||||
| Switch theme | Sun/moon icon in top action bar |
|
||||
| Switch language | EN/ZH button in top action bar |
|
||||
|
||||
### Error Handling
|
||||
|
||||
| Error Type | Resolution |
|
||||
|------------|------------|
|
||||
| Network error | Check connection, click refresh to retry |
|
||||
| Permission error | Check file/directory permissions |
|
||||
| Validation error | Check required form fields |
|
||||
| Timeout error | Increase timeout settings or batch operations |
|
||||
|
||||
### WebSocket Connection
|
||||
|
||||
- **Auto reconnect**: Automatically attempts reconnection after disconnect
|
||||
- **Heartbeat keepalive**: Periodic heartbeat to maintain connection
|
||||
- **Status indicator**: Connection status shown in footer
|
||||
|
||||
---
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- [DASHBOARD_GUIDE.md](DASHBOARD_GUIDE.md) - Dashboard User Guide
|
||||
- [COMMAND_REFERENCE.md](COMMAND_REFERENCE.md) - Command Reference
|
||||
- [GETTING_STARTED.md](GETTING_STARTED.md) - Getting Started Guide
|
||||
|
||||
---
|
||||
|
||||
**CCW Dashboard** - Claude Code Workflow Visual Control Center Operations Manual
|
||||
@@ -1,167 +0,0 @@
|
||||
# CodexLens Embeddings Statistics Improvements
|
||||
|
||||
## Summary
|
||||
|
||||
Improved the CodexLens `init` and `status` commands to return comprehensive embeddings statistics, making it easy for users to understand embeddings coverage.
|
||||
|
||||
## Changes Made
|
||||
|
||||
### 1. Updated `init` command (Task 1)
|
||||
|
||||
**File**: `codex-lens/src/codexlens/cli/commands.py` (lines 142-219)
|
||||
|
||||
**Key Changes**:
|
||||
- Changed from `generate_embeddings()` to `generate_embeddings_recursive()`
|
||||
- Now processes all `_index.db` files recursively in the index tree
|
||||
- Passes `index_root` (directory) instead of `index_path` (file)
|
||||
- Returns comprehensive coverage statistics after generation
|
||||
|
||||
**Imports Added**:
|
||||
```python
|
||||
from codexlens.cli.embedding_manager import generate_embeddings_recursive, get_embeddings_status
|
||||
```
|
||||
|
||||
**Result Structure**:
|
||||
```json
|
||||
{
|
||||
"embeddings": {
|
||||
"generated": true,
|
||||
"total_indexes": 26,
|
||||
"total_files": 303,
|
||||
"files_with_embeddings": 303,
|
||||
"coverage_percent": 100.0,
|
||||
"total_chunks": 500
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Console Output**:
|
||||
- Shows files processed count
|
||||
- Shows total chunks created
|
||||
- Shows indexes processed (successful/total)
|
||||
|
||||
### 2. Updated `status` command (Task 2)
|
||||
|
||||
**File**: `codex-lens/src/codexlens/cli/commands.py` (lines 642-713)
|
||||
|
||||
**Key Changes**:
|
||||
- Added embeddings coverage check using `get_embeddings_status()`
|
||||
- Updates `vector_search` feature flag based on coverage (>= 50%)
|
||||
- Includes embeddings data in JSON output
|
||||
- Displays embeddings statistics in console output
|
||||
|
||||
**Imports Added**:
|
||||
```python
|
||||
from codexlens.cli.embedding_manager import get_embeddings_status
|
||||
```
|
||||
|
||||
**Result Structure**:
|
||||
```json
|
||||
{
|
||||
"embeddings": {
|
||||
"total_indexes": 26,
|
||||
"total_files": 303,
|
||||
"files_with_embeddings": 303,
|
||||
"files_without_embeddings": 0,
|
||||
"coverage_percent": 100.0,
|
||||
"total_chunks": 500,
|
||||
"indexes_with_embeddings": 26,
|
||||
"indexes_without_embeddings": 0
|
||||
},
|
||||
"features": {
|
||||
"exact_fts": true,
|
||||
"fuzzy_fts": true,
|
||||
"hybrid_search": true,
|
||||
"vector_search": true // true when coverage >= 50%
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Console Output**:
|
||||
```
|
||||
Search Backends:
|
||||
Exact FTS: ✓ (unicode61)
|
||||
Fuzzy FTS: ✓ (trigram)
|
||||
Hybrid Search: ✓ (RRF fusion)
|
||||
Vector Search: ✓ (embeddings available)
|
||||
|
||||
Embeddings Coverage:
|
||||
Total Indexes: 26
|
||||
Total Files: 303
|
||||
Files with Embeddings: 303
|
||||
Coverage: 100.0%
|
||||
Total Chunks: 500
|
||||
```
|
||||
|
||||
## Benefits
|
||||
|
||||
1. **Transparency**: Users can now see exactly what embeddings were generated
|
||||
2. **Coverage Visibility**: Clear percentage showing embeddings coverage across all files
|
||||
3. **Recursive Processing**: All index databases in the tree are processed, not just the root
|
||||
4. **Feature Detection**: Vector search is automatically enabled when coverage is sufficient (>= 50%)
|
||||
5. **Comprehensive Stats**: Shows total indexes, files, chunks, and coverage percentage
|
||||
|
||||
## Backward Compatibility
|
||||
|
||||
- All changes are backward compatible
|
||||
- Gracefully handles cases where embeddings are not available
|
||||
- ImportError handling for when embedding_manager is not available
|
||||
- Existing JSON output structure is extended, not changed
|
||||
|
||||
## Testing
|
||||
|
||||
Created test script: `test_embeddings_improvements.py`
|
||||
|
||||
Tests verify:
|
||||
- Init command reports embeddings statistics correctly
|
||||
- Status command shows embeddings coverage
|
||||
- JSON output includes all required fields
|
||||
- Console output displays statistics properly
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### Init with embeddings
|
||||
```bash
|
||||
codexlens init /path/to/project --json
|
||||
# Returns comprehensive embeddings statistics
|
||||
```
|
||||
|
||||
### Check status
|
||||
```bash
|
||||
codexlens status --json
|
||||
# Shows embeddings coverage and feature availability
|
||||
```
|
||||
|
||||
### Init without embeddings
|
||||
```bash
|
||||
codexlens init /path/to/project --no-embeddings --json
|
||||
# Returns embeddings: {"generated": false, "error": "Skipped (--no-embeddings)"}
|
||||
```
|
||||
|
||||
## Files Modified
|
||||
|
||||
1. `codex-lens/src/codexlens/cli/commands.py` - Updated init and status commands
|
||||
|
||||
## Implementation Details
|
||||
|
||||
### Init Command Flow
|
||||
1. Build index tree as before
|
||||
2. If `--no-embeddings` not set:
|
||||
- Call `generate_embeddings_recursive(index_root)` instead of `generate_embeddings(index_path)`
|
||||
- After generation, call `get_embeddings_status(index_root)` to get coverage stats
|
||||
- Include comprehensive statistics in result
|
||||
3. Return result with embeddings coverage data
|
||||
|
||||
### Status Command Flow
|
||||
1. Collect index statistics as before
|
||||
2. Call `get_embeddings_status(index_root)` to check embeddings
|
||||
3. Set `vector_search` feature flag based on coverage >= 50%
|
||||
4. Include embeddings info in JSON output
|
||||
5. Display embeddings statistics in console output
|
||||
|
||||
## Error Handling
|
||||
|
||||
- Handles ImportError when embedding_manager not available
|
||||
- Handles cases where embeddings don't exist (returns 0% coverage)
|
||||
- Graceful fallback if get_embeddings_status fails
|
||||
- Debug logging for failed operations
|
||||
167
IMPLEMENTATION_COMPLETION_REPORT.md
Normal file
167
IMPLEMENTATION_COMPLETION_REPORT.md
Normal file
@@ -0,0 +1,167 @@
|
||||
# CLI History Store 数据库迁移优化 - 完成报告
|
||||
|
||||
## 📋 任务概况
|
||||
|
||||
优化 CLI History Store 的数据库迁移逻辑,解决每次 CLI 执行都输出重复迁移日志的问题。
|
||||
|
||||
## ✅ 实现清单
|
||||
|
||||
### 1. 完善 turns 表结构 - COMPLETED
|
||||
**文件**: `ccw/src/tools/cli-history-store.ts:149-169`
|
||||
|
||||
在 `initSchema()` 的 CREATE TABLE 语句中添加了 5 个缺失的列:
|
||||
- ✅ `cached INTEGER DEFAULT 0` (行 162)
|
||||
- ✅ `stdout_full TEXT` (行 163)
|
||||
- ✅ `stderr_full TEXT` (行 164)
|
||||
- ✅ `parsed_output TEXT` (行 165)
|
||||
- ✅ `final_output TEXT` (行 166)
|
||||
|
||||
**验证**:
|
||||
```bash
|
||||
sed -n '162,166p' ccw/src/tools/cli-history-store.ts
|
||||
# 输出: 所有 5 列定义已确认
|
||||
```
|
||||
|
||||
### 2. 重构迁移逻辑 - COMPLETED
|
||||
**文件**: `ccw/src/tools/cli-history-store.ts:331-361`
|
||||
|
||||
将逐个迁移(每列一条日志)改为批量迁移(单条汇总日志):
|
||||
|
||||
```typescript
|
||||
// 改进前: 5 条独立的 console.log 调用
|
||||
if (!hasCached) {
|
||||
console.log('[CLI History] Migrating database: adding cached column...');
|
||||
// ...
|
||||
}
|
||||
if (!hasStdoutFull) {
|
||||
console.log('[CLI History] Migrating database: adding stdout_full column...');
|
||||
// ...
|
||||
}
|
||||
// ... 重复 3 次
|
||||
|
||||
// 改进后: 1 条汇总日志
|
||||
const missingTurnsColumns: string[] = [];
|
||||
for (const [col, def] of Object.entries(turnsColumnDefs)) {
|
||||
if (!turnsColumns.has(col)) {
|
||||
missingTurnsColumns.push(col);
|
||||
}
|
||||
}
|
||||
if (missingTurnsColumns.length > 0) {
|
||||
console.log(`[CLI History] Migrating turns table: adding ${missingTurnsColumns.length} columns...`);
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
**关键改进**:
|
||||
- 使用 Set 高效查询列名
|
||||
- 集中定义列配置 (`turnsColumnDefs`)
|
||||
- 条件输出:仅在有迁移时显示一条汇总日志
|
||||
|
||||
**验证**:
|
||||
```bash
|
||||
sed -n '353,361p' ccw/src/tools/cli-history-store.ts
|
||||
# 输出: 批量迁移逻辑已确认
|
||||
```
|
||||
|
||||
### 3. memory-store.ts 评估 - COMPLETED
|
||||
**文件**: `ccw/src/core/memory-store.ts`
|
||||
|
||||
**结论**: **无需修复** ✅
|
||||
|
||||
原因:
|
||||
- 表结构完整,所有列在 `initDatabase()` 中已定义
|
||||
- 迁移逻辑清晰,仅处理 2 个后续添加的列
|
||||
- 无类似的批量列缺失问题
|
||||
|
||||
## 📊 效果对比
|
||||
|
||||
| 指标 | 修复前 | 修复后 | 改进 |
|
||||
|------|--------|--------|------|
|
||||
| **新安装日志数** | 5 条 | 0 条 | -100% |
|
||||
| **旧库升级日志数** | 每次 5 条 | 首次 1 条 | -80% |
|
||||
| **后续启动日志** | 每次 5 条 | 静默 | -100% |
|
||||
| **表结构完整性** | 运行时创建 | 创建时完整 | ✓ |
|
||||
|
||||
## 🧪 测试验证
|
||||
|
||||
### 测试脚本执行
|
||||
```bash
|
||||
node test-cli-history-migration.js
|
||||
```
|
||||
|
||||
### 测试结果
|
||||
```
|
||||
✓ Test 1: New database creation - 所有列已在创建时定义
|
||||
✓ Test 2: Subsequent initialization - 后续初始化静默
|
||||
✓ Test 3: Column verification - 所有 16 列已验证
|
||||
|
||||
✓ All required columns present: id, conversation_id, turn_number,
|
||||
timestamp, prompt, duration_ms, status, exit_code, stdout, stderr,
|
||||
truncated, cached, stdout_full, stderr_full, parsed_output, final_output
|
||||
```
|
||||
|
||||
## 📁 文件变更
|
||||
|
||||
### 修改的文件
|
||||
```
|
||||
ccw/src/tools/cli-history-store.ts
|
||||
├── 149-169: 添加 5 列到 CREATE TABLE turns
|
||||
└── 331-361: 重构迁移逻辑为批量处理
|
||||
```
|
||||
|
||||
### 无需修改的文件
|
||||
```
|
||||
ccw/src/core/memory-store.ts (表结构完整)
|
||||
```
|
||||
|
||||
## 🔍 根本原因分析
|
||||
|
||||
**原问题根源**:
|
||||
1. `turns` 表在 `initSchema()` 中缺少 5 个列定义
|
||||
2. 新数据库创建时表结构不完整
|
||||
3. 每次实例化都执行 `migrateSchema()` 检查
|
||||
4. CLI 每次作为新进程运行,单例缓存失效
|
||||
5. 逐个迁移导致 5 条重复日志
|
||||
|
||||
**修复策略**:
|
||||
1. ✅ 在 initSchema() 中添加完整列定义
|
||||
2. ✅ 实现批量迁移逻辑
|
||||
3. ✅ 条件输出:仅在必要时显示汇总日志
|
||||
|
||||
## 🎯 后续行动
|
||||
|
||||
### 即时验证
|
||||
```bash
|
||||
# 1. 编译验证
|
||||
npm run build
|
||||
|
||||
# 2. 集成测试
|
||||
npm test -- --grep "cli-history"
|
||||
|
||||
# 3. 手动测试
|
||||
rm -rf ~/.ccw/test-project
|
||||
ccw cli -p "test query" --tool gemini --mode analysis
|
||||
# 预期: 无迁移日志输出
|
||||
```
|
||||
|
||||
### 长期监控
|
||||
- 监控 CLI 执行日志输出,确认无重复迁移日志
|
||||
- 定期审查新增列的使用情况
|
||||
- 保持迁移逻辑与表结构定义同步
|
||||
|
||||
## 📚 相关文档
|
||||
|
||||
- `MIGRATION_FIX_SUMMARY.md` - 详细实现总结
|
||||
- `ccw/src/tools/cli-history-store.ts` - 源代码实现
|
||||
|
||||
## ✨ 总结
|
||||
|
||||
✅ **所有计划项目已完成**
|
||||
|
||||
- 新数据库创建时表结构完整
|
||||
- 旧数据库升级时日志输出优化
|
||||
- 批量迁移策略有效降低日志噪声
|
||||
- 向后兼容性保持完好
|
||||
- 代码质量和可维护性得到提升
|
||||
|
||||
**预期影响**: CLI 执行时将不再输出重复的数据库迁移日志,提升用户体验。
|
||||
310
IMPLEMENTATION_SUMMARY.md
Normal file
310
IMPLEMENTATION_SUMMARY.md
Normal file
@@ -0,0 +1,310 @@
|
||||
# CodexLens MCP Integration - Implementation Summary
|
||||
|
||||
> Implementation Date: 2026-01-19
|
||||
> Project: CCW Dashboard + CodexLens MCP
|
||||
|
||||
## 实现概览
|
||||
|
||||
成功完成 codex-lens LSP 功能分析及其 MCP 端点设计,并在 CCW view 中实现工具选择功能。
|
||||
|
||||
---
|
||||
|
||||
## ✅ 已完成任务
|
||||
|
||||
### 1. **Gemini 分析 - CodexLens LSP 功能** ✓
|
||||
|
||||
**输出文件**:`D:\Claude_dms3\codex-lens\docs\MCP_ENDPOINT_DESIGN.md`
|
||||
|
||||
**分析结果**:
|
||||
- **4 个核心 MCP 工具**已规划:
|
||||
1. `code.symbol.search` - 符号搜索(对应 `workspace/symbol` 和 `textDocument/completion`)
|
||||
2. `code.symbol.findDefinition` - 查找定义(对应 `textDocument/definition`)
|
||||
3. `code.symbol.findReferences` - 查找引用(对应 `textDocument/references`)
|
||||
4. `code.symbol.getHoverInfo` - 悬停信息(对应 `textDocument/hover`)
|
||||
|
||||
**技术细节**:
|
||||
- 后端实现基于 `GlobalSymbolIndex` 和 `ChainSearchEngine`
|
||||
- 完整的 MCP schema 定义(参数、返回值、使用场景)
|
||||
- 命名规范:`code.symbol.<operation>`
|
||||
|
||||
---
|
||||
|
||||
### 2. **实现 Multi-Select 字段类型** ✓
|
||||
|
||||
**修改文件**:`ccw/src/templates/dashboard-js/components/mcp-manager.js`
|
||||
|
||||
**核心实现**:
|
||||
|
||||
#### 字段渲染(line 1506-1529)
|
||||
```javascript
|
||||
${field.type === 'multi-select' ? `
|
||||
<div id="wizard-field-${field.key}" class="space-y-2 p-2 bg-muted/30 border border-border rounded-lg max-h-48 overflow-y-auto">
|
||||
${(field.options || []).map(opt => {
|
||||
const isChecked = (field.default || []).includes(opt.value);
|
||||
return `
|
||||
<label class="flex items-center gap-2 p-2 rounded-md hover:bg-accent cursor-pointer transition-colors">
|
||||
<input type="checkbox"
|
||||
class="wizard-multi-select-${field.key} rounded border-border text-primary focus:ring-primary"
|
||||
value="${escapeHtml(opt.value)}"
|
||||
${isChecked ? 'checked' : ''}>
|
||||
<span class="text-sm text-foreground">${escapeHtml(opt.label)}</span>
|
||||
${opt.desc ? `<span class="text-xs text-muted-foreground ml-auto">${escapeHtml(opt.desc)}</span>` : ''}
|
||||
</label>
|
||||
`;
|
||||
}).join('')}
|
||||
</div>
|
||||
` : `
|
||||
<input type="${field.type || 'text'}" ...>
|
||||
`}
|
||||
```
|
||||
|
||||
#### 值收集(line 1637-1661)
|
||||
```javascript
|
||||
if (field.type === 'multi-select') {
|
||||
const checkboxes = document.querySelectorAll(`.wizard-multi-select-${field.key}:checked`);
|
||||
const selectedValues = Array.from(checkboxes).map(cb => cb.value);
|
||||
|
||||
if (field.required && selectedValues.length === 0) {
|
||||
showRefreshToast(`${t(field.labelKey)} - ${t('mcp.wizard.selectAtLeastOne')}`, 'error');
|
||||
hasError = true;
|
||||
break;
|
||||
}
|
||||
|
||||
values[field.key] = selectedValues;
|
||||
}
|
||||
```
|
||||
|
||||
**特性**:
|
||||
- ✅ 复选框列表 UI
|
||||
- ✅ 默认值预选
|
||||
- ✅ 必填验证
|
||||
- ✅ 悬停高亮效果
|
||||
- ✅ 滚动容器(max-height: 48)
|
||||
|
||||
---
|
||||
|
||||
### 3. **添加 CodexLens 到推荐 MCP 列表** ✓
|
||||
|
||||
**修改位置**:`ccw/src/templates/dashboard-js/components/mcp-manager.js` (line 1430-1457)
|
||||
|
||||
**MCP 定义**:
|
||||
```javascript
|
||||
{
|
||||
id: 'codex-lens-tools',
|
||||
nameKey: 'mcp.codexLens.name',
|
||||
descKey: 'mcp.codexLens.desc',
|
||||
icon: 'code-2',
|
||||
category: 'code-intelligence',
|
||||
fields: [
|
||||
{
|
||||
key: 'tools',
|
||||
labelKey: 'mcp.codexLens.field.tools',
|
||||
type: 'multi-select', // 使用新的 multi-select 类型
|
||||
options: [
|
||||
{ value: 'symbol.search', label: 'Symbol Search', desc: 'Workspace symbol search' },
|
||||
{ value: 'symbol.findDefinition', label: 'Find Definition', desc: 'Go to definition' },
|
||||
{ value: 'symbol.findReferences', label: 'Find References', desc: 'Find all references' },
|
||||
{ value: 'symbol.getHoverInfo', label: 'Hover Information', desc: 'Rich symbol info' }
|
||||
],
|
||||
default: ['symbol.search', 'symbol.findDefinition', 'symbol.findReferences'],
|
||||
required: true,
|
||||
descKey: 'mcp.codexLens.field.tools.desc'
|
||||
}
|
||||
],
|
||||
buildConfig: (values) => {
|
||||
const tools = values.tools || [];
|
||||
const env = { CODEXLENS_ENABLED_TOOLS: tools.join(',') };
|
||||
return buildCrossPlatformMcpConfig('npx', ['-y', 'codex-lens-mcp'], { env });
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**配置生成**:
|
||||
```javascript
|
||||
// 示例输出
|
||||
{
|
||||
command: "cmd", // Windows 自动包装
|
||||
args: ["/c", "npx", "-y", "codex-lens-mcp"],
|
||||
env: {
|
||||
CODEXLENS_ENABLED_TOOLS: "symbol.search,symbol.findDefinition,symbol.findReferences"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4. **添加 i18n 翻译支持** ✓
|
||||
|
||||
**修改文件**:`ccw/src/templates/dashboard-js/i18n.js`
|
||||
|
||||
#### 英文翻译(line 959-963)
|
||||
```javascript
|
||||
'mcp.codexLens.name': 'CodexLens Tools',
|
||||
'mcp.codexLens.desc': 'Code intelligence tools for symbol search, navigation, and reference finding',
|
||||
'mcp.codexLens.field.tools': 'Enabled Tools',
|
||||
'mcp.codexLens.field.tools.desc': 'Select the code intelligence tools to enable for this MCP server',
|
||||
'mcp.wizard.selectAtLeastOne': 'Please select at least one option',
|
||||
```
|
||||
|
||||
#### 中文翻译(line 3286-3290)
|
||||
```javascript
|
||||
'mcp.codexLens.name': 'CodexLens 工具',
|
||||
'mcp.codexLens.desc': '代码智能工具,提供符号搜索、代码导航和引用查找功能',
|
||||
'mcp.codexLens.field.tools': '启用的工具',
|
||||
'mcp.codexLens.field.tools.desc': '选择要启用的代码智能工具',
|
||||
'mcp.wizard.selectAtLeastOne': '请至少选择一个选项',
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📋 使用流程
|
||||
|
||||
### 用户操作步骤
|
||||
|
||||
1. **打开 CCW Dashboard**
|
||||
```bash
|
||||
ccw view
|
||||
```
|
||||
|
||||
2. **导航到 MCP Manager**
|
||||
- 点击侧边栏 "MCP Servers" → "Manage"
|
||||
|
||||
3. **安装 CodexLens MCP**
|
||||
- 滚动到 "Recommended MCP" 部分
|
||||
- 找到 "CodexLens Tools" 卡片
|
||||
- 点击 "Install" 按钮
|
||||
|
||||
4. **配置工具**
|
||||
- 在弹出的安装向导中,看到 **4 个工具选项**(带复选框)
|
||||
- 默认已选中 3 个:
|
||||
- ☑ Symbol Search
|
||||
- ☑ Find Definition
|
||||
- ☑ Find References
|
||||
- ☐ Hover Information
|
||||
- 可以勾选/取消勾选任意工具
|
||||
|
||||
5. **选择安装目标**
|
||||
- **Project**:项目级(`.mcp.json`)
|
||||
- **Global**:全局级(`~/.claude.json`)默认选中
|
||||
- **Codex**:Codex 全局(`~/.codex/config.toml`)
|
||||
|
||||
6. **确认安装**
|
||||
- 点击 "Install" 按钮
|
||||
- 等待安装完成提示
|
||||
|
||||
### 生成的配置示例
|
||||
|
||||
**Claude 配置(`.claude.json` 或 `.mcp.json`)**:
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"codex-lens-tools": {
|
||||
"command": "cmd",
|
||||
"args": ["/c", "npx", "-y", "codex-lens-mcp"],
|
||||
"env": {
|
||||
"CODEXLENS_ENABLED_TOOLS": "symbol.search,symbol.findDefinition,symbol.findReferences"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Codex 配置(`~/.codex/config.toml`)**:
|
||||
```toml
|
||||
[mcp_servers.codex-lens-tools]
|
||||
command = "npx"
|
||||
args = ["-y", "codex-lens-mcp"]
|
||||
env = { CODEXLENS_ENABLED_TOOLS = "symbol.search,symbol.findDefinition,symbol.findReferences" }
|
||||
enabled = true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 技术亮点
|
||||
|
||||
### 1. **跨平台兼容性**
|
||||
- 使用 `buildCrossPlatformMcpConfig` 自动处理 Windows `cmd /c` 包装
|
||||
- 支持 Claude、Codex 两种配置格式
|
||||
|
||||
### 2. **动态工具控制**
|
||||
- 通过环境变量 `CODEXLENS_ENABLED_TOOLS` 控制启用的工具
|
||||
- 前端 UI 实时更新配置
|
||||
|
||||
### 3. **可扩展字段类型**
|
||||
- 新增 `multi-select` 字段类型
|
||||
- 保持向后兼容(`text`, `password` 等)
|
||||
|
||||
### 4. **国际化支持**
|
||||
- 完整的中英文翻译
|
||||
- UI 文本动态切换
|
||||
|
||||
---
|
||||
|
||||
## 📁 修改文件清单
|
||||
|
||||
| 文件路径 | 修改内容 | 行数 |
|
||||
|---------|---------|------|
|
||||
| `codex-lens/docs/MCP_ENDPOINT_DESIGN.md` | **新增** - MCP 端点设计文档 | 262 |
|
||||
| `ccw/src/templates/dashboard-js/components/mcp-manager.js` | 字段渲染 multi-select 支持 | 1506-1529 |
|
||||
| `ccw/src/templates/dashboard-js/components/mcp-manager.js` | 值收集 multi-select 处理 | 1637-1661 |
|
||||
| `ccw/src/templates/dashboard-js/components/mcp-manager.js` | 添加 codex-lens-tools MCP 定义 | 1430-1457 |
|
||||
| `ccw/src/templates/dashboard-js/i18n.js` | 添加英文翻译(5 个键) | 959-963 |
|
||||
| `ccw/src/templates/dashboard-js/i18n.js` | 添加中文翻译(5 个键) | 3286-3290 |
|
||||
|
||||
---
|
||||
|
||||
## 🚀 后续工作
|
||||
|
||||
### 待实现功能(CodexLens MCP Server)
|
||||
|
||||
1. **实现 MCP Server**
|
||||
- 创建 `codex-lens-mcp` npm 包
|
||||
- 实现 4 个 MCP 工具的 handler
|
||||
- 环境变量解析:`CODEXLENS_ENABLED_TOOLS`
|
||||
|
||||
2. **测试**
|
||||
- 单元测试:MCP 工具实现
|
||||
- 集成测试:与 CCW Dashboard 集成
|
||||
- E2E 测试:完整安装流程
|
||||
|
||||
3. **文档**
|
||||
- 用户手册:如何使用 CodexLens MCP
|
||||
- API 文档:MCP 工具详细说明
|
||||
- 故障排除指南
|
||||
|
||||
### 可选增强
|
||||
|
||||
- **实时索引进度**:显示代码索引状态
|
||||
- **更多工具**:`code.symbol.getDocumentSymbols`
|
||||
- **过滤器**:按文件类型/语言过滤符号
|
||||
- **性能监控**:工具调用延迟统计
|
||||
|
||||
---
|
||||
|
||||
## 📊 性能指标
|
||||
|
||||
| 指标 | 值 |
|
||||
|------|-----|
|
||||
| Gemini 分析时间 | 67.6s |
|
||||
| 新增代码行数 | ~150 lines |
|
||||
| 支持的工具数 | 4 tools |
|
||||
| i18n 翻译键 | 10 keys (5 en + 5 zh) |
|
||||
| 修改文件数 | 3 files |
|
||||
|
||||
---
|
||||
|
||||
## 🎉 总结
|
||||
|
||||
成功完成 codex-lens LSP 到 MCP 的完整设计和 CCW Dashboard 集成:
|
||||
|
||||
1. ✅ **完整的 MCP 端点设计**(4 个工具,详细 schema)
|
||||
2. ✅ **可复用的 multi-select 字段类型**
|
||||
3. ✅ **CodexLens MCP 集成到推荐列表**
|
||||
4. ✅ **完整的中英文国际化支持**
|
||||
|
||||
用户现在可以在 CCW Dashboard 中一键安装 CodexLens MCP 服务,并通过可视化界面选择启用的代码智能工具。
|
||||
|
||||
---
|
||||
|
||||
Generated: 2026-01-19
|
||||
Status: ✅ Ready for Testing
|
||||
248
MCP_FINAL_FIX.md
248
MCP_FINAL_FIX.md
@@ -1,248 +0,0 @@
|
||||
# CCW MCP 工具安装问题 - 最终修复报告
|
||||
|
||||
## 🎯 通过 Gemini AI 发现的关键问题
|
||||
|
||||
### 问题 4: 事件监听器注册失败 ⚠️ **根本原因** ✅ 已修复
|
||||
**文件**: `views/mcp-manager.js` Line 1407
|
||||
**严重性**: Critical - 导致所有按钮完全无响应
|
||||
**原因**: 使用 `querySelector` 只返回第一个匹配元素,如果 DOM 中有多个元素或选择器匹配错误,事件监听器会附加到错误的元素上
|
||||
**症状**: 按钮点击无任何反应,控制台无错误,调试困难
|
||||
|
||||
**修复前**:
|
||||
```javascript
|
||||
const btn = document.querySelector(`button[data-action="${action}"]`);
|
||||
if (btn) {
|
||||
btn.addEventListener('click', async (e) => {
|
||||
e.preventDefault();
|
||||
await handler();
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
**修复后**:
|
||||
```javascript
|
||||
const btns = document.querySelectorAll(`button[data-action="${action}"]`);
|
||||
|
||||
if (btns.length > 0) {
|
||||
console.log(`[MCP] Attaching listener to ${action} (${btns.length} button(s) found)`);
|
||||
btns.forEach(btn => {
|
||||
btn.addEventListener('click', async (e) => {
|
||||
e.preventDefault();
|
||||
console.log(`[MCP] Button clicked: ${action}`);
|
||||
try {
|
||||
await handler();
|
||||
} catch (err) {
|
||||
console.error(`[MCP] Error executing handler for ${action}:`, err);
|
||||
if (typeof showRefreshToast === 'function') {
|
||||
showRefreshToast(`Action failed: ${err.message}`, 'error');
|
||||
}
|
||||
}
|
||||
});
|
||||
});
|
||||
} else {
|
||||
console.warn(`[MCP] No buttons found for action: ${action}`);
|
||||
}
|
||||
```
|
||||
|
||||
**修复优势**:
|
||||
1. ✅ 使用 `querySelectorAll` 确保所有匹配按钮都绑定事件
|
||||
2. ✅ 添加详细的控制台日志,便于调试
|
||||
3. ✅ 添加错误捕获和用户友好的错误提示
|
||||
4. ✅ 添加警告日志,发现选择器不匹配问题
|
||||
|
||||
---
|
||||
|
||||
### 问题 5: MCP 计数显示错误 ✅ 已修复
|
||||
**文件**: `components/mcp-manager.js` Line 398
|
||||
**严重性**: Medium - 显示 2/2 但实际只有 1 个服务器
|
||||
**原因**: 路径格式不一致 - `loadMcpConfig` 使用 `\\`,`updateMcpBadge` 使用 `/`
|
||||
|
||||
**修复前**:
|
||||
```javascript
|
||||
function updateMcpBadge() {
|
||||
const badge = document.getElementById('badgeMcpServers');
|
||||
if (badge) {
|
||||
const currentPath = projectPath; // Keep original format (forward slash)
|
||||
const projectData = mcpAllProjects[currentPath];
|
||||
// ...
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**修复后**:
|
||||
```javascript
|
||||
function updateMcpBadge() {
|
||||
const badge = document.getElementById('badgeMcpServers');
|
||||
if (badge) {
|
||||
// IMPORTANT: Use same path normalization as loadMcpConfig
|
||||
const currentPath = projectPath.replace(/\//g, '\\');
|
||||
const projectData = mcpAllProjects[currentPath];
|
||||
// ...
|
||||
console.log('[MCP Badge]', { currentPath, totalServers, enabledServers, disabledServers });
|
||||
badge.textContent = `${enabledServers}/${totalServers}`;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📊 完整问题清单
|
||||
|
||||
| # | 问题 | 文件 | 严重性 | 状态 |
|
||||
|---|------|------|--------|------|
|
||||
| 1 | API 端点不匹配 | components/mcp-manager.js | Critical | ✅ 已修复 |
|
||||
| 2 | 未定义函数引用 | views/mcp-manager.js | High | ✅ 已修复 |
|
||||
| 3 | 全局作用域污染 | views/mcp-manager.js | Medium | ✅ 已修复 |
|
||||
| 4 | **querySelector 单选器失效** | views/mcp-manager.js | **Critical** | ✅ 已修复 |
|
||||
| 5 | MCP 计数路径不一致 | components/mcp-manager.js | Medium | ✅ 已修复 |
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Gemini AI 分析价值
|
||||
|
||||
Gemini AI 深度分析提供了关键洞察:
|
||||
|
||||
1. **执行流程追踪**: 确认 `attachMcpEventListeners()` 在 DOM 更新后立即调用
|
||||
2. **选择器匹配验证**: 发现 `data-action` 属性完全匹配
|
||||
3. **根本原因识别**: 定位到 `querySelector` vs `querySelectorAll` 的关键差异
|
||||
4. **静默失败诊断**: 指出缺少日志导致调试困难
|
||||
5. **修复建议**: 提供完整的代码修复方案,包括错误处理
|
||||
|
||||
---
|
||||
|
||||
## 🧪 测试验证步骤
|
||||
|
||||
### 1. 重启服务
|
||||
```bash
|
||||
cd D:\Claude_dms3\ccw
|
||||
npm run dev
|
||||
```
|
||||
|
||||
### 2. 打开浏览器控制台
|
||||
- 访问 `http://localhost:3456`
|
||||
- 按 `F12` 打开控制台
|
||||
- **现在应该能看到调试日志**:
|
||||
```
|
||||
[MCP] Attaching listener to install-ccw-workspace (1 button(s) found)
|
||||
[MCP] Attaching listener to install-ccw-global (1 button(s) found)
|
||||
[MCP] Attaching listener to update-ccw-workspace (1 button(s) found)
|
||||
[MCP] Attaching listener to update-ccw-global (1 button(s) found)
|
||||
[MCP] Attaching listener to install-ccw-codex (1 button(s) found)
|
||||
```
|
||||
|
||||
### 3. 点击按钮测试
|
||||
点击任何 CCW Tools 按钮,应该看到:
|
||||
```
|
||||
[MCP] Button clicked: install-ccw-workspace
|
||||
Installing CCW Tools MCP to workspace...
|
||||
```
|
||||
|
||||
如果失败,会看到:
|
||||
```
|
||||
[MCP] Error executing handler for install-ccw-workspace: <错误详情>
|
||||
```
|
||||
|
||||
### 4. 验证 MCP 计数
|
||||
- 导航到 MCP Manager
|
||||
- 检查左侧导航栏的 MCP 徽章
|
||||
- **现在应该显示正确的计数** (1/1 而不是 2/2)
|
||||
- 控制台会显示:
|
||||
```
|
||||
[MCP Badge] { currentPath: 'D:\\dongdiankaifa9', totalServers: 1, enabledServers: 1, disabledServers: [] }
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ✅ 预期结果
|
||||
|
||||
### 所有按钮现在应该正常工作
|
||||
|
||||
#### 1. 工作空间安装/更新
|
||||
- **位置**: CCW Tools MCP 卡片
|
||||
- **按钮**: "安装到工作空间" / "在工作空间更新"
|
||||
- **预期**: 点击后显示加载提示,成功后显示成功消息
|
||||
|
||||
#### 2. 全局安装/更新
|
||||
- **位置**: CCW Tools MCP 卡片
|
||||
- **按钮**: "Install to global" / "Update Globally"
|
||||
- **预期**: 更新 `~/.claude.json`
|
||||
|
||||
#### 3. Codex 安装
|
||||
- **位置**: Codex 模式的 CCW Tools MCP 卡片
|
||||
- **按钮**: "Install" / "Update"
|
||||
- **预期**: 更新 `~/.codex/config.toml`
|
||||
|
||||
#### 4. 从其他项目安装
|
||||
- **位置**: "Available from Other Projects" 部分
|
||||
- **预期**: 弹出配置类型选择对话框
|
||||
|
||||
#### 5. MCP 计数显示
|
||||
- **位置**: 左侧导航栏 MCP Manager 徽章
|
||||
- **预期**: 显示正确的启用/总计数量 (例如 1/1)
|
||||
|
||||
---
|
||||
|
||||
## 🐛 调试指南
|
||||
|
||||
### 如果按钮仍然无响应
|
||||
|
||||
#### 检查控制台日志
|
||||
如果看不到 `[MCP] Attaching listener` 日志:
|
||||
- ❌ `attachMcpEventListeners()` 函数没有被调用
|
||||
- 解决方法: 检查 `renderMcpManager()` 是否正确调用了该函数
|
||||
|
||||
#### 如果看到 "No buttons found"
|
||||
```
|
||||
[MCP] No buttons found for action: install-ccw-workspace
|
||||
```
|
||||
- ❌ `data-action` 属性不匹配或按钮未渲染
|
||||
- 解决方法: 检查 HTML 生成逻辑,确保 `data-action` 属性正确设置
|
||||
|
||||
#### 如果看到点击日志但无反应
|
||||
```
|
||||
[MCP] Button clicked: install-ccw-workspace
|
||||
```
|
||||
但之后无进一步输出:
|
||||
- ❌ 函数执行被阻塞或抛出未捕获的错误
|
||||
- 解决方法: 检查 `installCcwToolsMcp()` 函数实现
|
||||
|
||||
#### 如果 MCP 计数仍然错误
|
||||
控制台应该显示:
|
||||
```
|
||||
[MCP Badge] { currentPath: '...', totalServers: 1, enabledServers: 1, disabledServers: [] }
|
||||
```
|
||||
- 如果 `currentPath` 格式错误 (例如包含 `/` 而不是 `\\`),说明路径规范化失败
|
||||
- 如果 `totalServers` 不正确,检查 `mcpAllProjects` 数据结构
|
||||
|
||||
---
|
||||
|
||||
## 📋 修复文件清单
|
||||
|
||||
```
|
||||
D:\Claude_dms3\ccw\src\templates\dashboard-js\components\mcp-manager.js
|
||||
- Line 398: updateMcpBadge 路径规范化修复
|
||||
- Line 404: 添加调试日志
|
||||
|
||||
D:\Claude_dms3\ccw\src\templates\dashboard-js\views\mcp-manager.js
|
||||
- Line 1407-1420: querySelector → querySelectorAll + 完整错误处理
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 关键收获
|
||||
|
||||
1. **工具链选择**: Gemini AI 在执行流程追踪和根本原因分析上表现出色
|
||||
2. **调试友好**: 添加详细日志是诊断"静默失败"的关键
|
||||
3. **健壮性设计**: `querySelectorAll` + 错误捕获 > 简单的 `querySelector`
|
||||
4. **路径规范化**: 在 Windows 系统上,路径格式必须一致(统一使用 `\\`)
|
||||
|
||||
---
|
||||
|
||||
## 🚀 下一步
|
||||
|
||||
重启服务后测试所有按钮功能。如果仍有问题,请提供:
|
||||
1. 完整的浏览器控制台输出(包括 `[MCP]` 前缀的所有日志)
|
||||
2. Network 标签中的 API 请求详情
|
||||
3. 具体点击的按钮和操作步骤
|
||||
|
||||
所有修复已合并到代码库,重新编译完成。
|
||||
@@ -1,227 +0,0 @@
|
||||
# CCW MCP 工具安装问题修复总结
|
||||
|
||||
## 📊 问题发现
|
||||
|
||||
通过 Gemini AI 深度分析,发现了 3 个导致 MCP 安装按钮无响应的关键问题:
|
||||
|
||||
### 🔴 问题 1: API 端点不匹配(Critical)
|
||||
- **文件**: `ccw/src/templates/dashboard-js/components/mcp-manager.js`
|
||||
- **影响**: 全局安装/更新按钮完全无响应
|
||||
- **根本原因**: 前端调用 `/api/mcp-add-global`,后端定义 `/api/mcp-add-global-server`
|
||||
- **修复位置**:
|
||||
- Line 960: `installCcwToolsMcp()` 全局安装
|
||||
- Line 1024: `updateCcwToolsMcp()` 全局更新
|
||||
|
||||
### 🔴 问题 2: 未定义的函数引用(High)
|
||||
- **文件**: `ccw/src/templates/dashboard-js/views/mcp-manager.js`
|
||||
- **影响**: "从其他项目安装" 按钮抛出 ReferenceError
|
||||
- **根本原因**: 调用不存在的 `installMcpToProject`,正确名称是 `copyMcpServerToProject`
|
||||
- **修复位置**:
|
||||
- Line 1352: Install to project 按钮事件处理
|
||||
- Line 1847: 模板安装逻辑
|
||||
|
||||
### 🟡 问题 3: 全局作用域污染(Medium)
|
||||
- **文件**: `ccw/src/templates/dashboard-js/views/mcp-manager.js`
|
||||
- **影响**: CCW Tools 工作空间/全局更新按钮可能无响应
|
||||
- **根本原因**: 使用内联 `onclick` 属性,函数不在全局作用域
|
||||
- **修复位置**:
|
||||
- Line 239: Codex 安装按钮
|
||||
- Lines 424, 430: 工作空间/全局更新按钮
|
||||
- Lines 437, 443: 工作空间/全局安装按钮
|
||||
- Lines 1397-1413: 新增健壮的事件监听器
|
||||
|
||||
## ✅ 已修复的文件
|
||||
|
||||
```
|
||||
D:\Claude_dms3\ccw\src\templates\dashboard-js\components\mcp-manager.js
|
||||
- Line 960: API 端点修正 (/api/mcp-add-global-server)
|
||||
- Line 1024: API 端点修正 (/api/mcp-add-global-server)
|
||||
|
||||
D:\Claude_dms3\ccw\src\templates\dashboard-js\views\mcp-manager.js
|
||||
- Line 239: onclick → data-action (Codex)
|
||||
- Line 424: onclick → data-action (update workspace)
|
||||
- Line 430: onclick → data-action (update global)
|
||||
- Line 437: onclick → data-action (install workspace)
|
||||
- Line 443: onclick → data-action (install global)
|
||||
- Line 1352: installMcpToProject → copyMcpServerToProject
|
||||
- Line 1397-1413: 新增 CCW Tools 事件监听器
|
||||
- Line 1847: installMcpToProject → copyMcpServerToProject
|
||||
```
|
||||
|
||||
## 🔧 修复方案详解
|
||||
|
||||
### 方案 1: API 端点统一
|
||||
```javascript
|
||||
// 修复前
|
||||
fetch('/api/mcp-add-global', { ... }) // ❌ 404 Not Found
|
||||
|
||||
// 修复后
|
||||
fetch('/api/mcp-add-global-server', { ... }) // ✅ 匹配后端路由
|
||||
```
|
||||
|
||||
### 方案 2: 函数名称修正
|
||||
```javascript
|
||||
// 修复前
|
||||
await installMcpToProject(serverName, serverConfig); // ❌ ReferenceError
|
||||
|
||||
// 修复后
|
||||
await copyMcpServerToProject(serverName, serverConfig); // ✅ 正确函数
|
||||
```
|
||||
|
||||
### 方案 3: 事件处理重构
|
||||
```html
|
||||
<!-- 修复前: 内联 onclick,依赖全局作用域 -->
|
||||
<button onclick="updateCcwToolsMcp('workspace')">Update</button> <!-- ❌ -->
|
||||
|
||||
<!-- 修复后: data-action 属性,健壮的事件监听 -->
|
||||
<button data-action="update-ccw-workspace">Update</button> <!-- ✅ -->
|
||||
```
|
||||
|
||||
```javascript
|
||||
// 新增事件监听器
|
||||
const ccwActions = {
|
||||
'update-ccw-workspace': () => updateCcwToolsMcp('workspace'),
|
||||
'update-ccw-global': () => updateCcwToolsMcp('global'),
|
||||
'install-ccw-workspace': () => installCcwToolsMcp('workspace'),
|
||||
'install-ccw-global': () => installCcwToolsMcp('global'),
|
||||
'install-ccw-codex': () => installCcwToolsMcpToCodex()
|
||||
};
|
||||
|
||||
Object.entries(ccwActions).forEach(([action, handler]) => {
|
||||
const btn = document.querySelector(`button[data-action="${action}"]`);
|
||||
if (btn) {
|
||||
btn.addEventListener('click', async (e) => {
|
||||
e.preventDefault();
|
||||
await handler();
|
||||
});
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
## 🧪 测试场景
|
||||
|
||||
### ✅ 现在应该正常工作的按钮
|
||||
|
||||
#### 1. CCW Tools 工作空间安装/更新
|
||||
- **位置**: MCP Manager → CCW Tools MCP 卡片
|
||||
- **按钮**: "Install to Workspace" / "Update in Workspace"
|
||||
- **测试步骤**:
|
||||
1. 选择至少一个工具(勾选复选框)
|
||||
2. 点击按钮
|
||||
3. **预期结果**: 提示 "Installing/Updating CCW Tools MCP to workspace..."
|
||||
4. 成功后显示: "CCW Tools installed/updated to workspace (N tools)"
|
||||
|
||||
#### 2. CCW Tools 全局安装/更新
|
||||
- **位置**: MCP Manager → CCW Tools MCP 卡片
|
||||
- **按钮**: "Install Globally" / "Update Globally"
|
||||
- **测试步骤**:
|
||||
1. 选择至少一个工具
|
||||
2. 点击按钮
|
||||
3. **预期结果**: 提示 "Installing/Updating CCW Tools MCP globally..."
|
||||
4. 成功后显示: "CCW Tools installed/updated globally (N tools)"
|
||||
|
||||
#### 3. Codex 安装/更新
|
||||
- **位置**: MCP Manager → Codex 模式 → CCW Tools MCP 卡片
|
||||
- **按钮**: "Install" / "Update"
|
||||
- **测试步骤**:
|
||||
1. 切换到 Codex 模式
|
||||
2. 选择工具
|
||||
3. 点击按钮
|
||||
4. **预期结果**: 成功提示
|
||||
|
||||
#### 4. 从其他项目安装
|
||||
- **位置**: MCP Manager → Available from Other Projects 部分
|
||||
- **按钮**: 服务器卡片上的文本按钮或图标按钮
|
||||
- **测试步骤**:
|
||||
1. 找到其他项目的 MCP 服务器
|
||||
2. 点击 "Install to Project" 或文件夹图标
|
||||
3. **预期结果**: 弹出配置类型选择对话框
|
||||
4. 选择后成功安装
|
||||
|
||||
## 📋 验证清单
|
||||
|
||||
在重启服务后,请逐项验证:
|
||||
|
||||
- [ ] **CCW Tools 工作空间安装** - 点击按钮有反应,控制台无错误
|
||||
- [ ] **CCW Tools 工作空间更新** - 修改工具选择后可更新
|
||||
- [ ] **CCW Tools 全局安装** - 安装到 ~/.claude.json
|
||||
- [ ] **CCW Tools 全局更新** - 可更新全局配置
|
||||
- [ ] **Codex 模式安装** - 安装到 ~/.codex/config.toml
|
||||
- [ ] **从其他项目安装** - 文本按钮工作正常
|
||||
- [ ] **从其他项目安装** - 图标按钮工作正常
|
||||
- [ ] **浏览器控制台** - 无 ReferenceError 或 404 错误
|
||||
|
||||
## 🚀 启动测试
|
||||
|
||||
### 1. 重启服务(必须)
|
||||
```bash
|
||||
cd D:\Claude_dms3\ccw
|
||||
npm run dev
|
||||
```
|
||||
|
||||
### 2. 打开浏览器控制台
|
||||
- 访问: `http://localhost:3456`
|
||||
- 按 `F12` 打开开发者工具
|
||||
- 切换到 **Console** 标签
|
||||
|
||||
### 3. 逐个测试按钮
|
||||
按照上述测试场景,逐个点击按钮并观察:
|
||||
- 浏览器控制台输出
|
||||
- Network 标签中的 API 请求
|
||||
- 页面上的成功/失败提示
|
||||
|
||||
## 📊 API 端点映射表
|
||||
|
||||
| 前端调用 | 后端路由 | 状态 |
|
||||
|---------|---------|------|
|
||||
| `/api/mcp-add-global-server` | `/api/mcp-add-global-server` | ✅ 匹配 |
|
||||
| `/api/mcp-copy-server` | `/api/mcp-copy-server` | ✅ 匹配 |
|
||||
| `/api/codex-mcp-add` | `/api/codex-mcp-add` | ✅ 匹配 |
|
||||
| `/api/mcp-config` | `/api/mcp-config` | ✅ 匹配 |
|
||||
| `/api/mcp-toggle` | `/api/mcp-toggle` | ✅ 匹配 |
|
||||
|
||||
## 🐛 如果仍有问题
|
||||
|
||||
### 检查项:
|
||||
1. **服务是否重启?** 必须重启才能加载新代码
|
||||
2. **浏览器缓存?** 按 `Ctrl+Shift+R` 强制刷新
|
||||
3. **控制台错误?** 检查是否有 JavaScript 错误
|
||||
4. **Network 请求?** 查看 API 请求的状态码和响应
|
||||
|
||||
### 需要提供的调试信息:
|
||||
- 浏览器控制台完整错误信息(截图或文本)
|
||||
- Network 标签中失败请求的详情
|
||||
- CCW View 服务端控制台输出
|
||||
- 点击的具体按钮和操作步骤
|
||||
|
||||
## 📈 修复效果
|
||||
|
||||
| 问题 | 修复前 | 修复后 |
|
||||
|-----|-------|-------|
|
||||
| 全局安装按钮 | ❌ 404 错误 | ✅ 正常工作 |
|
||||
| 全局更新按钮 | ❌ 404 错误 | ✅ 正常工作 |
|
||||
| 工作空间安装 | ⚠️ 可能失效 | ✅ 稳定工作 |
|
||||
| 工作空间更新 | ⚠️ 可能失效 | ✅ 稳定工作 |
|
||||
| 从其他项目安装 | ❌ ReferenceError | ✅ 正常工作 |
|
||||
| Codex 安装 | ⚠️ 可能失效 | ✅ 稳定工作 |
|
||||
|
||||
## 🎯 技术细节
|
||||
|
||||
### Gemini 分析发现
|
||||
Gemini AI 通过执行流程追踪和代码模式分析,准确识别了:
|
||||
1. 前后端 API 端点不一致
|
||||
2. 函数名称拼写错误导致的引用失败
|
||||
3. JavaScript 作用域问题导致的事件处理失效
|
||||
|
||||
### 修复优势
|
||||
- **健壮性提升**: 使用 `addEventListener` 替代内联 `onclick`
|
||||
- **可维护性**: 函数名称统一,减少混淆
|
||||
- **调试友好**: 所有 API 调用端点与后端完全匹配
|
||||
|
||||
## 📝 修复日志
|
||||
|
||||
- **2025-12-17**: 初始问题报告 - 安装按钮无响应
|
||||
- **2025-12-17**: 发现 API 端点不匹配问题(问题 1)
|
||||
- **2025-12-17**: Gemini 分析发现额外 2 个问题(问题 2、3)
|
||||
- **2025-12-17**: 完成所有修复并重新编译
|
||||
- **2025-12-17**: 创建完整的测试和调试指南
|
||||
@@ -1,274 +0,0 @@
|
||||
# CCW MCP 工具安装问题调试指南
|
||||
|
||||
## 🎯 已修复的所有问题(完整清单)
|
||||
|
||||
### 问题 1: API 端点不匹配 ✅ 已修复
|
||||
**位置**: `components/mcp-manager.js`
|
||||
**原因**: 前端调用 `/api/mcp-add-global`,后端定义 `/api/mcp-add-global-server`
|
||||
**修复**:
|
||||
- Line 960: `installCcwToolsMcp()` - 全局安装端点已修正
|
||||
- Line 1024: `updateCcwToolsMcp()` - 全局更新端点已修正
|
||||
|
||||
### 问题 2: 未定义的函数引用 ✅ 已修复
|
||||
**位置**: `views/mcp-manager.js`
|
||||
**原因**: 调用不存在的函数 `installMcpToProject`,正确函数名是 `copyMcpServerToProject`
|
||||
**修复**:
|
||||
- Line 1352: "Install to Project" 按钮事件处理已修正
|
||||
- Line 1847: 模板安装逻辑已修正
|
||||
|
||||
### 问题 3: 全局作用域污染导致按钮失效 ✅ 已修复
|
||||
**位置**: `views/mcp-manager.js`
|
||||
**原因**: CCW Tools 按钮使用内联 `onclick` 属性,函数不在全局作用域导致无响应
|
||||
**修复**:
|
||||
- Lines 239, 424, 430, 437, 443: 所有 `onclick` 改为 `data-action` 属性
|
||||
- Line 1397-1413: 添加健壮的事件监听器,使用 `addEventListener`
|
||||
|
||||
## 测试步骤
|
||||
|
||||
### 1. 重启 CCW View 服务
|
||||
|
||||
**重要:** 必须重启服务才能加载修复后的代码。
|
||||
|
||||
```bash
|
||||
# 方法 1: 直接运行
|
||||
cd D:\Claude_dms3\ccw
|
||||
npm run dev
|
||||
|
||||
# 方法 2: 使用 ccw 命令
|
||||
ccw view
|
||||
```
|
||||
|
||||
### 2. 打开浏览器控制台
|
||||
|
||||
在浏览器中访问 `http://localhost:3456`,按 `F12` 打开开发者工具,切换到 **Console** 标签。
|
||||
|
||||
### 3. 测试安装按钮
|
||||
|
||||
#### 测试场景 A: 安装到工作空间 (Workspace)
|
||||
|
||||
1. 导航到 **MCP Manager** 页面
|
||||
2. 找到 **CCW Tools MCP** 卡片
|
||||
3. 选择至少一个工具(勾选复选框)
|
||||
4. 点击 **"Install to Workspace"** 按钮
|
||||
5. **观察控制台输出**:
|
||||
- ✅ 成功:看到 "Installing CCW Tools MCP to workspace..." 提示
|
||||
- ❌ 失败:看到错误信息
|
||||
|
||||
#### 测试场景 B: 安装到全局 (Global)
|
||||
|
||||
1. 选择至少一个工具
|
||||
2. 点击 **"Install Globally"** 按钮
|
||||
3. **观察控制台输出**
|
||||
|
||||
#### 测试场景 C: 更新工具配置
|
||||
|
||||
1. 如果已安装,修改工具选择(添加或删除工具)
|
||||
2. 点击 **"Update in Workspace"** 或 **"Update Globally"** 按钮
|
||||
3. **观察控制台输出**
|
||||
|
||||
#### 测试场景 D: 从其他项目安装
|
||||
|
||||
1. 滚动到 **"Available from Other Projects"** 部分
|
||||
2. 找到想要安装的 MCP 服务器
|
||||
3. 点击 **"Install to Project"** 按钮
|
||||
4. **观察控制台输出**
|
||||
|
||||
## 常见错误排查
|
||||
|
||||
### 错误 1: 502 Bad Gateway
|
||||
|
||||
**原因:** CCW View 服务未正确运行
|
||||
|
||||
**解决方法:**
|
||||
```bash
|
||||
# 停止所有 node 进程
|
||||
taskkill /F /IM node.exe
|
||||
|
||||
# 重新启动服务
|
||||
cd D:\Claude_dms3\ccw
|
||||
npm run dev
|
||||
```
|
||||
|
||||
### 错误 2: 404 Not Found (API 端点)
|
||||
|
||||
**原因:** API 路由未正确加载
|
||||
|
||||
**解决方法:**
|
||||
1. 确认已运行 `npm run build`
|
||||
2. 检查 `dist/core/routes/mcp-routes.js` 是否存在
|
||||
3. 重启服务
|
||||
|
||||
### 错误 3: 按钮点击无反应
|
||||
|
||||
**检查清单:**
|
||||
- [ ] 是否选择了至少一个工具?(如果没有选择,会显示警告)
|
||||
- [ ] 浏览器控制台是否有 JavaScript 错误?
|
||||
- [ ] 网络标签是否显示 API 请求?
|
||||
|
||||
**调试方法:**
|
||||
```javascript
|
||||
// 在浏览器控制台执行以下命令测试函数是否可用
|
||||
typeof installCcwToolsMcp // 应该返回 "function"
|
||||
typeof updateCcwToolsMcp // 应该返回 "function"
|
||||
```
|
||||
|
||||
### 错误 4: Network Error / CORS Error
|
||||
|
||||
**原因:** 前后端端口不一致
|
||||
|
||||
**解决方法:**
|
||||
- 确认 CCW View 运行在正确的端口(默认 3456)
|
||||
- 检查浏览器访问的 URL 是否正确
|
||||
|
||||
## 网络请求监控
|
||||
|
||||
在浏览器开发者工具的 **Network** 标签中,点击按钮后应该看到:
|
||||
|
||||
### 成功的请求示例
|
||||
|
||||
**请求:**
|
||||
```
|
||||
POST http://localhost:3456/api/mcp-add-global-server
|
||||
```
|
||||
|
||||
**请求体:**
|
||||
```json
|
||||
{
|
||||
"serverName": "ccw-tools",
|
||||
"serverConfig": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "ccw-mcp"],
|
||||
"env": {
|
||||
"CCW_ENABLED_TOOLS": "write_file,edit_file,codex_lens,smart_search"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**响应:**
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"serverName": "ccw-tools",
|
||||
"scope": "global"
|
||||
}
|
||||
```
|
||||
|
||||
### 失败的请求示例
|
||||
|
||||
**状态码:** 404, 500, 502
|
||||
|
||||
**常见错误响应:**
|
||||
```json
|
||||
{
|
||||
"error": "serverName and serverConfig are required",
|
||||
"status": 400
|
||||
}
|
||||
```
|
||||
|
||||
## 日志检查
|
||||
|
||||
### 服务器日志
|
||||
|
||||
CCW View 服务运行时的控制台输出应该显示:
|
||||
```
|
||||
CCW Dashboard running at http://localhost:3456
|
||||
```
|
||||
|
||||
如果看到错误,记录完整错误信息。
|
||||
|
||||
### 浏览器日志
|
||||
|
||||
打开控制台(F12)后,所有与 MCP 相关的日志会显示:
|
||||
- API 请求和响应
|
||||
- JavaScript 错误
|
||||
- 网络错误
|
||||
|
||||
## 成功安装的验证
|
||||
|
||||
安装成功后,应该:
|
||||
1. 看到成功提示:`"CCW Tools installed to workspace (4 tools)"`
|
||||
2. MCP 卡片显示 ✓ 图标和工具数量
|
||||
3. 在项目根目录生成 `.mcp.json` 文件(workspace 安装)
|
||||
4. 或在 `~/.claude.json` 中添加配置(global 安装)
|
||||
|
||||
## 手动验证配置文件
|
||||
|
||||
### Workspace 安装 (.mcp.json)
|
||||
|
||||
```bash
|
||||
cat D:\Claude_dms3\.mcp.json
|
||||
```
|
||||
|
||||
应该包含:
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"ccw-tools": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "ccw-mcp"],
|
||||
"env": {
|
||||
"CCW_ENABLED_TOOLS": "write_file,edit_file,codex_lens,smart_search"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Global 安装 (~/.claude.json)
|
||||
|
||||
```bash
|
||||
# Windows
|
||||
type %USERPROFILE%\.claude.json
|
||||
|
||||
# Linux/Mac
|
||||
cat ~/.claude.json
|
||||
```
|
||||
|
||||
应该包含 `mcpServers` 部分。
|
||||
|
||||
## 需要报告的信息
|
||||
|
||||
如果问题仍未解决,请提供:
|
||||
|
||||
1. **浏览器控制台完整错误信息**
|
||||
2. **Network 标签中失败的 API 请求详情**
|
||||
- 请求 URL
|
||||
- 请求方法
|
||||
- 状态码
|
||||
- 响应内容
|
||||
3. **CCW View 服务端日志**
|
||||
4. **操作系统和浏览器版本**
|
||||
5. **CCW 版本** (`ccw --version`)
|
||||
|
||||
## 快速测试脚本
|
||||
|
||||
在浏览器控制台运行以下脚本测试完整流程:
|
||||
|
||||
```javascript
|
||||
// 测试 API 端点可用性
|
||||
async function testMcpEndpoints() {
|
||||
const endpoints = [
|
||||
'/api/mcp-config',
|
||||
'/api/mcp-add-global-server',
|
||||
'/api/mcp-copy-server'
|
||||
];
|
||||
|
||||
for (const endpoint of endpoints) {
|
||||
try {
|
||||
const response = await fetch(endpoint);
|
||||
console.log(`✓ ${endpoint}: ${response.status}`);
|
||||
} catch (error) {
|
||||
console.error(`✗ ${endpoint}: ${error.message}`);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
testMcpEndpoints();
|
||||
```
|
||||
|
||||
## 已知限制
|
||||
|
||||
- 必须至少选择一个工具才能安装
|
||||
- 安装到全局需要写入 `~/.claude.json` 的权限
|
||||
- Windows 用户确保路径使用正确的斜杠方向
|
||||
@@ -1,94 +0,0 @@
|
||||
# Session Management Design Evolution Analysis
|
||||
|
||||
## 1. Abstraction Layer Value Analysis
|
||||
|
||||
The current architecture employs a "Thick Tool, Thin CLI" pattern.
|
||||
|
||||
* **CLI Layer (`session.ts`)**: Acts primarily as a UI adapter. Its value lies in:
|
||||
* **UX Enhancement**: formatting JSON outputs into human-readable text (colors, indentation).
|
||||
* **Shortcuts**: providing semantic commands like `status` and `task` which map to generic `update` operations in the backend.
|
||||
* **Safety**: specialized error handling (e.g., `EPIPE`) and user feedback.
|
||||
* **Tool Layer (`session-manager.ts`)**: Encapsulates the core business logic.
|
||||
* **Centralized Security**: The `validatePathParams` and `findSession` functions ensure operations are confined to valid session scopes, preventing path traversal.
|
||||
* **Path Routing**: The `PATH_ROUTES` constant abstracts the physical file structure away from the logical operations. Consumers request "plan" or "task", not specific file paths.
|
||||
* **Polymorphism**: Handles both "Standard WFS" (heavy workflow) and "Lite" (ephemeral) sessions through a unified interface.
|
||||
|
||||
**Verdict**: The abstraction is high-value for **security** and **consistency**, ensuring that all session interactions (whether from CLI or Agent) adhere to the same structural invariants. However, the semantic mapping is thinning, with the CLI often just passing raw JSON `content` directly to the tool.
|
||||
|
||||
## 2. Hidden Complexity Costs
|
||||
|
||||
The "Unified Session Manager" design hides significant complexity that is beginning to leak:
|
||||
|
||||
* **Discovery Overhead**: `findSession` performs a linear search across 4 distinct directory roots (`active`, `archived`, `lite-plan`, `lite-fix`) for *every single operation*. As the number of sessions grows, this disk I/O could become a bottleneck.
|
||||
* **Leaky Abstractions in Handling "Lite" Sessions**:
|
||||
* `executeInit` contains explicit branching logic (`if (location === 'lite-plan'...)`).
|
||||
* `executeArchive` explicitly throws errors for Lite sessions.
|
||||
* The "Unified" interface creates a false promise of compatibility; consumers must "know" that `archive` doesn't work for Lite sessions, breaking the Liskov Substitution Principle.
|
||||
* **Routing Table Explosion**: `PATH_ROUTES` is becoming a "God Object" mapping. It mixes different domains:
|
||||
* Core Workflow (`session`, `plan`)
|
||||
* Task Management (`task`, `summary`)
|
||||
* Review Systems (`review-dim`, `review-iter`)
|
||||
* Lite System (`lite-plan`, `exploration`)
|
||||
* *Cost*: Adding a new feature requires touching the Schema, the Routing Table, and often the Operation Switch.
|
||||
|
||||
## 3. Parameter Transformation Overhead
|
||||
|
||||
Data undergoes multiple transformations, creating friction:
|
||||
|
||||
1. **CLI Args -> Options Object**: `args` parsed into `InitOptions`, `ReadOptions`.
|
||||
2. **Options -> Tool Params**: Specialized options (`options.taskId`) are manually mapped to generic `path_params`.
|
||||
* *Risk*: The CLI must implicitly know which `content_type` requires which `path_params`. For example, `readAction` manually constructs `path_params` for `taskId`, `filename`, `dimension`, etc. If the Tool changes a required param, the CLI breaks.
|
||||
3. **Tool Params -> Zod Validation**: The tool re-validates the structure.
|
||||
4. **Tool -> File System**: The tool maps logical params to physical paths.
|
||||
|
||||
**High Friction Area**: The generic `path_params` object. It forces a loose contract. A strict type system (e.g., distinct interfaces for `ReadTaskParams` vs `ReadPlanParams`) is lost in favor of a generic `Record<string, string>`.
|
||||
|
||||
## 4. Alternative Architecture Proposals
|
||||
|
||||
### Proposal A: Domain-Specific Tools (Split by Lifecycle)
|
||||
Split the monolithic `session_manager` into targeted tools.
|
||||
* **Components**: `wfs_manager` (Standard Workflow), `lite_session_manager` (Lite/Ephemeral).
|
||||
* **Pros**:
|
||||
* Clean separation of concerns. `lite` tools don't need `archive` or `task` logic.
|
||||
* Simpler Schemas.
|
||||
* Faster discovery (look in 1 place).
|
||||
* **Cons**:
|
||||
* Agent confusion: "Which tool do I use to read a file?"
|
||||
* Duplicated utility code (file reading, writing).
|
||||
|
||||
### Proposal B: Resource-Oriented Architecture (REST-like)
|
||||
Focus on Resources rather than Operations.
|
||||
* **Components**: `task_tool` (CRUD for tasks), `session_tool` (Lifecycle), `file_tool` (Safe FS access within session).
|
||||
* **Pros**:
|
||||
* Aligns with how LLMs think (Action on Object).
|
||||
* `task_tool` can enforce strict schemas for task status updates, removing the "magic string" status updates in the current CLI.
|
||||
* **Cons**:
|
||||
* Loss of the "Session" as a coherent unit of work.
|
||||
* Harder to implement "global" operations like `archive` which touch multiple resources.
|
||||
|
||||
### Proposal C: Strategy Pattern (Internal Refactor)
|
||||
Keep the Unified Interface, but refactor internals.
|
||||
* **Design**: `SessionManager` class delegates to `SessionStrategy` implementations (`StandardStrategy`, `LiteStrategy`).
|
||||
* **Pros**:
|
||||
* Removes `if (lite)` checks from main logic.
|
||||
* Preserves the simple "one tool" interface for Agents.
|
||||
* Allows `LiteStrategy` to throw "NotSupported" cleanly or handle `archive` differently (e.g., delete).
|
||||
* **Cons**:
|
||||
* Does not solve the `path_params` loose typing issue.
|
||||
|
||||
## 5. Recommended Optimal Design
|
||||
|
||||
**Hybrid Approach: Strategy Pattern + Stronger Typing**
|
||||
|
||||
1. **Refactor `session-manager.ts` to use a Strategy Pattern.**
|
||||
* Define a `SessionStrategy` interface: `init`, `resolvePath`, `list`, `archive`.
|
||||
* Implement `StandardWorkflowStrategy` and `LiteWorkflowStrategy`.
|
||||
* The `handler` simply identifies the session type (via `findSession` or input param) and delegates.
|
||||
|
||||
2. **Flatten the Path Resolution.**
|
||||
* Instead of `path_params: { task_id: "1" }`, promote widely used IDs to top-level optional params in the Zod schema: `task_id?: string`, `filename?: string`. This makes the contract explicit to the LLM.
|
||||
|
||||
3. **Deprecate "Hybrid" content types.**
|
||||
* Instead of `content_type="lite-plan"`, just use `content_type="plan"` and let the `LiteStrategy` decide where that lives (`plan.json` vs `IMPL_PLAN.md`). This unifies the language the Agent uses—it always "reads the plan", regardless of session type.
|
||||
|
||||
**Benefit**: This maintains the ease of use for the Agent (one tool) while cleaning up the internal complexity and removing the "Leaky Abstractions" where the Agent currently has to know if it's in a Lite or Standard session to ask for the right file type.
|
||||
566
README.md
566
README.md
@@ -1,312 +1,348 @@
|
||||
# 🚀 Claude Code Workflow (CCW)
|
||||
|
||||
[](https://smithery.ai/skills?ns=catlog22&utm_source=github&utm_medium=badge)
|
||||
|
||||
|
||||
<div align="center">
|
||||
|
||||
[](https://github.com/catlog22/Claude-Code-Workflow/releases)
|
||||
[](https://www.npmjs.com/package/claude-code-workflow)
|
||||
[](LICENSE)
|
||||
[]()
|
||||
[](https://github.com/catlog22/Claude-Code-Workflow/actions/workflows/visual-tests.yml)
|
||||
<!-- Animated Header -->
|
||||
<img src="https://capsule-render.vercel.app/api?type=waving&color=gradient&customColorList=6,11,20&height=180§ion=header&text=Claude%20Code%20Workflow&fontSize=42&fontColor=fff&animation=twinkling&fontAlignY=32&desc=Multi-Agent%20AI%20Development%20Framework&descAlignY=52&descSize=18"/>
|
||||
|
||||
**Languages:** [English](README.md) | [中文](README_CN.md)
|
||||
<!-- Badges -->
|
||||
<p>
|
||||
<a href="https://github.com/catlog22/Claude-Code-Workflow/releases"><img src="https://img.shields.io/badge/version-v6.3.33-6366F1?style=flat-square" alt="Version"/></a>
|
||||
<a href="https://www.npmjs.com/package/claude-code-workflow"><img src="https://img.shields.io/npm/v/claude-code-workflow?style=flat-square&color=cb3837" alt="npm"/></a>
|
||||
<a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-10B981?style=flat-square" alt="License"/></a>
|
||||
<a href="https://github.com/catlog22/Claude-Code-Workflow/stargazers"><img src="https://img.shields.io/github/stars/catlog22/Claude-Code-Workflow?style=flat-square&color=F59E0B" alt="Stars"/></a>
|
||||
<a href="https://github.com/catlog22/Claude-Code-Workflow/issues"><img src="https://img.shields.io/github/issues/catlog22/Claude-Code-Workflow?style=flat-square&color=EF4444" alt="Issues"/></a>
|
||||
</p>
|
||||
|
||||
**[English](README.md) | [中文](README_CN.md)**
|
||||
|
||||
<br/>
|
||||
|
||||
<!-- Typing Animation -->
|
||||
<a href="https://git.io/typing-svg"><img src="https://readme-typing-svg.demolab.com?font=Fira+Code&weight=600&size=22&pause=1000&color=6366F1¢er=true&vCenter=true&random=false&width=600&lines=JSON-Driven+Multi-Agent+Framework;4-Level+Workflow+System;Semantic+CLI+Orchestration;Gemini+%7C+Codex+%7C+OpenCode+%7C+Qwen+%7C+Claude" alt="Typing SVG" /></a>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
<br/>
|
||||
|
||||
**Claude Code Workflow (CCW)** is a JSON-driven multi-agent development framework with intelligent CLI orchestration (Gemini/Qwen/Codex), context-first architecture, and automated workflow execution. It transforms AI development from simple prompt chaining into a powerful orchestration system.
|
||||
<!-- Quick Links -->
|
||||
<div align="center">
|
||||
<a href="#-quick-start"><img src="https://img.shields.io/badge/🚀_Quick_Start-4285F4?style=flat-square" alt="Quick Start"/></a>
|
||||
<a href="WORKFLOW_GUIDE.md"><img src="https://img.shields.io/badge/📖_Workflow_Guide-34A853?style=flat-square" alt="Guide"/></a>
|
||||
<a href="#-cli-tool-installation"><img src="https://img.shields.io/badge/🛠️_CLI_Tools-EA4335?style=flat-square" alt="CLI Tools"/></a>
|
||||
<a href="#-architecture"><img src="https://img.shields.io/badge/🏗️_Architecture-FBBC05?style=flat-square" alt="Architecture"/></a>
|
||||
</div>
|
||||
|
||||
> **🎉 Version 6.3.19: Search Enhancement & CLI Tools Upgrade**
|
||||
>
|
||||
> **New Features**:
|
||||
> - 🔍 **Dense + Reranker Search**: Cross-Encoder reranking for improved result relevance
|
||||
> - 💻 **OpenCode AI Support**: New OpenCode CLI tool integration
|
||||
> - 🛠️ **Service Architecture**: Preload service, cache management, UV package manager support
|
||||
> - 📊 **Issue Multi-Queue Execution**: Supports Codex for long-running autonomous work
|
||||
>
|
||||
> **Recommended Workflow**:
|
||||
> - 🚀 **Issue Workflow** (`/issue:plan` → `/issue:queue` → `/issue:execute`): Recommend **Codex** executor for long-running autonomous coding
|
||||
>
|
||||
> See [CHANGELOG.md](CHANGELOG.md) for complete details and migration guide.
|
||||
|
||||
> 📚 **New to CCW?** Check out the [**Getting Started Guide**](GETTING_STARTED.md) for a beginner-friendly 5-minute tutorial!
|
||||
<br/>
|
||||
|
||||
---
|
||||
|
||||
## ✨ Core Concepts
|
||||
## ✨ Key Features
|
||||
|
||||
CCW is built on a set of core principles that distinguish it from traditional AI development approaches:
|
||||
<div align="center">
|
||||
<table>
|
||||
<tr>
|
||||
<td width="50%">
|
||||
|
||||
- **Context-First Architecture**: Eliminates uncertainty during execution through pre-defined context gathering, ensuring agents have the right information *before* implementation.
|
||||
- **JSON-First State Management**: Task state is fully stored in `.task/IMPL-*.json` files as the single source of truth, enabling programmatic orchestration without state drift.
|
||||
- **Autonomous Multi-Stage Orchestration**: Commands chain-invoke specialized sub-commands and agents to automate complex workflows with zero user intervention.
|
||||
- **Multi-Model Strategy**: Leverages the unique strengths of different AI models (e.g., Gemini for analysis, Codex for implementation) for superior results.
|
||||
- **Layered Memory System**: A 4-tier documentation system that provides context at the appropriate abstraction level, preventing information overload.
|
||||
- **Specialized Role-Based Agents**: A suite of agents (`@code-developer`, `@test-fix-agent`, etc.) that emulate a real software team for diverse tasks.
|
||||
### 🎯 4-Level Workflows
|
||||
From `lite-lite-lite` (instant) to `brainstorm` (multi-role analysis)
|
||||
|
||||
---
|
||||
### 🔄 Multi-CLI Orchestration
|
||||
Gemini, Qwen, Codex, Claude - auto-select or manual
|
||||
|
||||
## ⚙️ Installation
|
||||
### ⚡ Dependency-Aware Parallelism
|
||||
Agent parallel execution without worktree complexity
|
||||
|
||||
### **📋 Requirements**
|
||||
</td>
|
||||
<td width="50%">
|
||||
|
||||
| Platform | Node.js | Additional |
|
||||
|----------|---------|------------|
|
||||
| Windows | 20.x or 22.x LTS (recommended) | Node 23+ requires [Visual Studio Build Tools](https://visualstudio.microsoft.com/visual-cpp-build-tools/) |
|
||||
| macOS | 18.x+ | Xcode Command Line Tools |
|
||||
| Linux | 18.x+ | build-essential |
|
||||
### 🔧 Issue Workflow
|
||||
Post-development maintenance with optional worktree isolation
|
||||
|
||||
> **Note**: The `better-sqlite3` dependency requires native compilation. Using Node.js LTS versions avoids build issues.
|
||||
### 📦 JSON-First State
|
||||
`.task/IMPL-*.json` as single source of truth
|
||||
|
||||
### **📦 npm Install (Recommended)**
|
||||
### 🖥️ Dashboard
|
||||
Visual session management, CodexLens search, graph explorer
|
||||
|
||||
Install globally via npm:
|
||||
```bash
|
||||
npm install -g claude-code-workflow
|
||||
```
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
Then install workflow files to your system:
|
||||
```bash
|
||||
# Interactive installation
|
||||
ccw install
|
||||
|
||||
# Global installation (to ~/.claude)
|
||||
ccw install -m Global
|
||||
|
||||
# Project-specific installation
|
||||
ccw install -m Path -p /path/to/project
|
||||
```
|
||||
|
||||
### **✅ Verify Installation**
|
||||
After installation, open **Claude Code** and verify that workflow commands are available by running:
|
||||
```bash
|
||||
/workflow:session:list
|
||||
```
|
||||
If slash commands (e.g., `/workflow:*`) are recognized, the installation was successful.
|
||||
|
||||
---
|
||||
|
||||
## 🖥️ CCW CLI Tool
|
||||
|
||||
The `ccw` command provides a powerful CLI for managing your Claude Code Workflow installation:
|
||||
|
||||
### **Commands**
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `ccw install` | Install workflow files to Global (~/.claude) or specific Path |
|
||||
| `ccw upgrade` | Upgrade existing installations to current package version |
|
||||
| `ccw uninstall` | Remove workflow files from an installation |
|
||||
| `ccw view` | Open the workflow dashboard in browser |
|
||||
| `ccw serve` | Start dashboard server without opening browser |
|
||||
| `ccw list` | List all managed installations |
|
||||
| `ccw cli -p "..."` | Execute CLI tools (Gemini/Qwen/Codex) with prompt |
|
||||
| `ccw core-memory` | Manage session clustering and memory |
|
||||
|
||||
### **Usage Examples**
|
||||
|
||||
```bash
|
||||
# Install globally
|
||||
ccw install -m Global
|
||||
|
||||
# Install to specific project
|
||||
ccw install -m Path -p ./my-project
|
||||
|
||||
# Open dashboard
|
||||
ccw view
|
||||
|
||||
# Start dashboard server on custom port
|
||||
ccw serve --port 8080
|
||||
|
||||
# Upgrade all installations
|
||||
ccw upgrade -a
|
||||
|
||||
# List installations
|
||||
ccw list
|
||||
```
|
||||
|
||||
### **Dashboard Features**
|
||||
|
||||
The CCW Dashboard (`ccw view`) provides:
|
||||
- 📊 **Session Overview**: View all workflow sessions with status and progress
|
||||
- 📋 **Task Management**: Track task execution and completion
|
||||
- 🔍 **CodexLens Manager**: Native code indexing with FTS + Semantic + Hybrid search
|
||||
- 🧠 **Core Memory**: Session clustering visualization with cluster management
|
||||
- 📄 **CLAUDE.md Manager**: File tree viewer for configuration management
|
||||
- 🎯 **Skills Manager**: View and manage Claude Code skills
|
||||
- 🕸️ **Graph Explorer**: Interactive code relationship visualization (Cytoscape.js)
|
||||
- ⚙️ **MCP Manager**: Configure and monitor MCP servers
|
||||
- 🪝 **Hook Manager**: Manage Claude Code hooks
|
||||
- ❓ **Help View**: Internationalized help documentation
|
||||
- 💻 **CLI Manager**: CLI execution history with session resume
|
||||
|
||||
> 📖 See [**Dashboard Guide**](DASHBOARD_GUIDE.md) and [**Dashboard Operations**](DASHBOARD_OPERATIONS_EN.md) for detailed documentation.
|
||||
|
||||
---
|
||||
|
||||
## 🔒 Security
|
||||
|
||||
The dashboard server is **localhost-bound by default** and **API endpoints require authentication**. See `ccw/docs/SECURITY.md` for the full security model, token usage, and safe deployment guidance.
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Command Reference
|
||||
|
||||
CCW provides a rich set of commands for managing workflows, tasks, and interactions with AI tools. For a complete list and detailed descriptions of all available commands, please refer to the [**COMMAND_REFERENCE.md**](COMMAND_REFERENCE.md) file.
|
||||
|
||||
For detailed technical specifications of each command, see [**COMMAND_SPEC.md**](COMMAND_SPEC.md).
|
||||
|
||||
---
|
||||
|
||||
### 💡 **Need Help? Use the Interactive Command Guide**
|
||||
|
||||
CCW includes a built-in **Command Guide Skill** to help you discover and use commands effectively:
|
||||
|
||||
- **`CCW-help`** - Get interactive help and command recommendations
|
||||
- **`CCW-issue`** - Report bugs or request features using guided templates
|
||||
|
||||
The Command Guide provides:
|
||||
- 🔍 **Smart Command Search** - Find commands by keyword, category, or use case
|
||||
- 🤖 **Next-Step Recommendations** - Get suggestions for what to do after any command
|
||||
- 📖 **Detailed Documentation** - View arguments, examples, and best practices
|
||||
- 🎓 **Beginner Onboarding** - Learn the 14 core commands through guided learning paths
|
||||
- 📝 **Issue Reporting** - Generate standardized bug reports and feature requests
|
||||
|
||||
**Usage Examples**:
|
||||
```
|
||||
User: "CCW-help"
|
||||
→ Interactive menu with command search, recommendations, and documentation
|
||||
|
||||
User: "What should I do after /workflow:plan?"
|
||||
→ Recommends /workflow:execute, /workflow:action-plan-verify with workflow patterns
|
||||
|
||||
User: "CCW-issue"
|
||||
→ Guided template generation for bugs, features, or question inquiries
|
||||
```
|
||||
> 📖 **New?** See [Workflow Guide](WORKFLOW_GUIDE.md) for the complete 4-level workflow system.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Quick Start
|
||||
|
||||
The best way to get started is by following the 5-minute tutorial in the [**Getting Started Guide**](GETTING_STARTED.md).
|
||||
|
||||
Here's a quick example of a common development workflow:
|
||||
|
||||
### **Option 1: Lite-Plan Workflow** (⚡ Recommended for Quick Tasks)
|
||||
|
||||
Lightweight interactive workflow with in-memory planning and immediate execution:
|
||||
### Install CCW
|
||||
|
||||
```bash
|
||||
# Basic usage with auto-detection
|
||||
/workflow:lite-plan "Add JWT authentication to user login"
|
||||
|
||||
# Force code exploration
|
||||
/workflow:lite-plan -e "Refactor logging module for better performance"
|
||||
|
||||
# Basic usage
|
||||
/workflow:lite-plan "Add unit tests for authentication service"
|
||||
npm install -g claude-code-workflow
|
||||
ccw install -m Global
|
||||
```
|
||||
|
||||
**Interactive Flow**:
|
||||
1. **Phase 1**: Automatic task analysis and smart code exploration (if needed)
|
||||
2. **Phase 2**: Answer clarification questions (if any)
|
||||
3. **Phase 3**: Review generated plan and task breakdown
|
||||
4. **Phase 4**: Three-dimensional confirmation:
|
||||
- ✅ Confirm/Modify/Cancel task
|
||||
- 🔧 Choose execution: Agent / Provide Plan Only / CLI (Gemini/Qwen/Codex)
|
||||
- 🔍 Optional code review: No / Claude / Gemini / Qwen / Codex
|
||||
5. **Phase 5**: Watch live execution and task tracking
|
||||
### Choose Your Workflow Level
|
||||
|
||||
### **Option 2: Lite-Fix Workflow** (🐛 Recommended for Bug Fixes)
|
||||
<div align="center">
|
||||
<table>
|
||||
<tr><th>Level</th><th>Command</th><th>Use Case</th></tr>
|
||||
<tr><td><b>1</b></td><td><code>/workflow:lite-lite-lite</code></td><td>Quick fixes, config changes</td></tr>
|
||||
<tr><td><b>2</b></td><td><code>/workflow:lite-plan</code></td><td>Clear single-module features</td></tr>
|
||||
<tr><td><b>2</b></td><td><code>/workflow:lite-fix</code></td><td>Bug diagnosis and fix</td></tr>
|
||||
<tr><td><b>2</b></td><td><code>/workflow:multi-cli-plan</code></td><td>Multi-perspective analysis</td></tr>
|
||||
<tr><td><b>3</b></td><td><code>/workflow:plan</code></td><td>Multi-module development</td></tr>
|
||||
<tr><td><b>3</b></td><td><code>/workflow:tdd-plan</code></td><td>Test-driven development</td></tr>
|
||||
<tr><td><b>4</b></td><td><code>/workflow:brainstorm:auto-parallel</code></td><td>New features, architecture design</td></tr>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
Intelligent bug diagnosis and fix workflow with adaptive severity assessment:
|
||||
### Workflow Examples
|
||||
|
||||
```bash
|
||||
# Standard bug fix (auto-adapts based on severity)
|
||||
/workflow:lite-fix "User avatar upload fails with 413 error"
|
||||
# Level 1: Instant execution
|
||||
/workflow:lite-lite-lite "Fix typo in README"
|
||||
|
||||
# Production hotfix mode
|
||||
/workflow:lite-fix --hotfix "Payment gateway 5xx errors"
|
||||
# Level 2: Lightweight planning
|
||||
/workflow:lite-plan "Add JWT authentication"
|
||||
/workflow:lite-fix "User upload fails with 413 error"
|
||||
|
||||
# Level 3: Standard planning with session
|
||||
/workflow:plan "Implement payment gateway integration"
|
||||
/workflow:execute
|
||||
|
||||
# Level 4: Multi-role brainstorming
|
||||
/workflow:brainstorm:auto-parallel "Design real-time collaboration system" --count 5
|
||||
/workflow:plan --session WFS-xxx
|
||||
/workflow:execute
|
||||
```
|
||||
|
||||
**Workflow Features**:
|
||||
- **Phase 1**: Intelligent root cause diagnosis with adaptive search
|
||||
- **Phase 2**: Automatic impact assessment and risk scoring
|
||||
- **Phase 3**: Fix strategy generation based on complexity
|
||||
- **Phase 4**: Risk-aware verification planning
|
||||
- **Phase 5**: User confirmation with execution selection
|
||||
- **Phase 6**: Execution dispatch with complete artifact tracking
|
||||
|
||||
**Session Artifacts** (saved to `.workflow/.lite-fix/{bug-slug}-{timestamp}/`):
|
||||
- `diagnosis.json` - Root cause analysis and reproduction steps
|
||||
- `impact.json` - Risk score, severity, and workflow adaptations
|
||||
- `fix-plan.json` - Fix strategy and implementation tasks
|
||||
- `task.json` - Enhanced Task JSON with complete context
|
||||
- `followup.json` - Auto-generated follow-up tasks (hotfix mode only)
|
||||
|
||||
### **Option 3: Full Workflow** (📋 Comprehensive Planning)
|
||||
|
||||
Traditional multi-stage workflow for complex projects:
|
||||
|
||||
1. **Create Plan** (auto-starts session):
|
||||
```bash
|
||||
/workflow:plan "Implement JWT-based user login and registration"
|
||||
```
|
||||
2. **Execute Plan**:
|
||||
```bash
|
||||
/workflow:execute
|
||||
```
|
||||
3. **View Status** (optional):
|
||||
```bash
|
||||
/workflow:status
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📚 Documentation
|
||||
## 🛠️ CLI Tool Installation
|
||||
|
||||
CCW provides comprehensive documentation to help you get started quickly and master advanced features:
|
||||
|
||||
### 📖 **Getting Started**
|
||||
- [**Getting Started Guide**](GETTING_STARTED.md) - 5-minute quick start tutorial
|
||||
- [**Installation Guide**](INSTALL.md) - Detailed installation instructions ([中文](INSTALL_CN.md))
|
||||
- [**Workflow Decision Guide**](WORKFLOW_DECISION_GUIDE.md) - 🌳 Interactive flowchart to choose the right command
|
||||
- [**Examples**](EXAMPLES.md) - Real-world use cases and practical examples
|
||||
- [**FAQ**](FAQ.md) - Common questions and troubleshooting
|
||||
|
||||
### 🖥️ **Dashboard**
|
||||
- [**Dashboard Guide**](DASHBOARD_GUIDE.md) - Dashboard user guide and interface overview
|
||||
- [**Dashboard Operations**](DASHBOARD_OPERATIONS_EN.md) - Detailed operation instructions
|
||||
|
||||
### 🔄 **Workflow Guides**
|
||||
- [**Issue Loop Workflow**](docs/workflows/ISSUE_LOOP_WORKFLOW.md) - Batch issue processing with two-phase lifecycle (accumulate → resolve)
|
||||
|
||||
### 🏗️ **Architecture & Design**
|
||||
- [**Architecture Overview**](ARCHITECTURE.md) - System design and core components
|
||||
- [**Project Introduction**](PROJECT_INTRODUCTION.md) - Detailed project overview
|
||||
- [**Workflow Diagrams**](WORKFLOW_DIAGRAMS.md) - Visual workflow representations
|
||||
|
||||
### 📋 **Command Reference**
|
||||
- [**Command Reference**](COMMAND_REFERENCE.md) - Complete list of all commands
|
||||
- [**Command Spec**](COMMAND_SPEC.md) - Detailed technical specifications
|
||||
- [**Command Flow Standard**](COMMAND_FLOW_STANDARD.md) - Command design patterns
|
||||
|
||||
### 🤝 **Contributing**
|
||||
- [**Contributing Guide**](CONTRIBUTING.md) - How to contribute to CCW
|
||||
- [**Changelog**](CHANGELOG.md) - Version history and release notes
|
||||
<div align="center">
|
||||
<table>
|
||||
<tr><th>CLI</th><th>Description</th><th>Official Docs</th></tr>
|
||||
<tr><td><b>Gemini</b></td><td>Google AI analysis</td><td><a href="https://github.com/google-gemini/gemini-cli">google-gemini/gemini-cli</a></td></tr>
|
||||
<tr><td><b>Codex</b></td><td>OpenAI autonomous coding</td><td><a href="https://github.com/openai/codex">openai/codex</a></td></tr>
|
||||
<tr><td><b>OpenCode</b></td><td>Open-source multi-model</td><td><a href="https://github.com/opencode-ai/opencode">opencode-ai/opencode</a></td></tr>
|
||||
<tr><td><b>Qwen</b></td><td>Alibaba Qwen-Code</td><td><a href="https://github.com/QwenLM">QwenLM/Qwen</a></td></tr>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 🤝 Contributing & Support
|
||||
## 🎭 Semantic CLI Invocation
|
||||
|
||||
- **Repository**: [GitHub - Claude-Code-Workflow](https://github.com/catlog22/Claude-Code-Workflow)
|
||||
- **Issues**: Report bugs or request features on [GitHub Issues](https://github.com/catlog22/Claude-Code-Workflow/issues).
|
||||
- **Discussions**: Join the [Community Forum](https://github.com/catlog22/Claude-Code-Workflow/discussions).
|
||||
- **Contributing**: See [CONTRIBUTING.md](CONTRIBUTING.md) for contribution guidelines.
|
||||
<div align="center">
|
||||
<img src="https://img.shields.io/badge/Just_Describe-What_You_Want-6366F1?style=flat-square"/>
|
||||
<img src="https://img.shields.io/badge/CCW_Handles-The_Rest-10B981?style=flat-square"/>
|
||||
</div>
|
||||
|
||||
<br/>
|
||||
|
||||
Users can **semantically specify CLI tools** in prompts - the system automatically invokes the corresponding CLI.
|
||||
|
||||
### Basic Invocation
|
||||
|
||||
<div align="center">
|
||||
|
||||
| User Prompt | System Action |
|
||||
|-------------|---------------|
|
||||
| "Use Gemini to analyze the auth module" | Auto-invoke `gemini` CLI for analysis |
|
||||
| "Let Codex review this code" | Auto-invoke `codex` CLI for review |
|
||||
| "Ask Qwen about performance optimization" | Auto-invoke `qwen` CLI for consultation |
|
||||
|
||||
</div>
|
||||
|
||||
### Multi-CLI Orchestration
|
||||
|
||||
<div align="center">
|
||||
|
||||
| Pattern | User Prompt Example |
|
||||
|---------|---------------------|
|
||||
| **Collaborative** | "Use Gemini and Codex to collaboratively analyze security vulnerabilities" |
|
||||
| **Parallel** | "Have Gemini, Codex, and Qwen analyze the architecture in parallel" |
|
||||
| **Iterative** | "Use Gemini to diagnose, then Codex to fix, iterate until resolved" |
|
||||
| **Pipeline** | "Gemini designs the solution, Codex implements, Claude reviews" |
|
||||
|
||||
</div>
|
||||
|
||||
<details>
|
||||
<summary><b>📝 More Examples</b></summary>
|
||||
|
||||
```text
|
||||
# Single CLI invocation
|
||||
User: "Use Gemini to analyze the database query performance"
|
||||
→ System auto-calls: gemini CLI with analysis task
|
||||
|
||||
# Collaborative analysis
|
||||
User: "Use Gemini and Codex to collaboratively review the authentication flow"
|
||||
→ System auto-calls: gemini + codex CLIs, synthesizes results
|
||||
|
||||
# Parallel multi-perspective
|
||||
User: "Have all available CLIs analyze this architecture design in parallel"
|
||||
→ System auto-calls: gemini, codex, qwen in parallel → merged report
|
||||
|
||||
# Sequential pipeline
|
||||
User: "Use Gemini to plan the refactoring, then Codex to implement it"
|
||||
→ System auto-calls: gemini (plan) → codex (implement) sequentially
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Custom CLI Registration
|
||||
|
||||
Register **any API as a custom CLI** via Dashboard interface:
|
||||
|
||||
```bash
|
||||
ccw view # Open Dashboard → Status → API Settings → Add Custom CLI
|
||||
```
|
||||
|
||||
<div align="center">
|
||||
|
||||
| Field | Example |
|
||||
|-------|---------|
|
||||
| **Name** | `deepseek` |
|
||||
| **Endpoint** | `https://api.deepseek.com/v1/chat` |
|
||||
| **API Key** | `your-api-key` |
|
||||
|
||||
</div>
|
||||
|
||||
> ⚙️ Register once, invoke semantically forever - no code changes needed.
|
||||
|
||||
---
|
||||
|
||||
## 🔍 ACE Tool Configuration
|
||||
|
||||
ACE (Augment Context Engine) provides powerful semantic code search.
|
||||
|
||||
<div align="center">
|
||||
|
||||
| Method | Link |
|
||||
|--------|------|
|
||||
| **Official** | [Augment MCP Documentation](https://docs.augmentcode.com/context-services/mcp/overview) |
|
||||
| **Proxy** | [ace-tool (GitHub)](https://github.com/eastxiaodong/ace-tool) |
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 📚 CodexLens Local Search
|
||||
|
||||
> ⚠️ **In Development**: CodexLens is under iterative optimization. Some features may be unstable.
|
||||
|
||||
<div align="center">
|
||||
<table>
|
||||
<tr><th>Search Mode</th><th>Description</th></tr>
|
||||
<tr><td><b>FTS</b></td><td>Full-text search, based on SQLite FTS5</td></tr>
|
||||
<tr><td><b>Semantic</b></td><td>Semantic search, using local embedding models</td></tr>
|
||||
<tr><td><b>Hybrid</b></td><td>Hybrid search, combining FTS + Semantic + Reranking</td></tr>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
<details>
|
||||
<summary><b>📦 Installation</b></summary>
|
||||
|
||||
```bash
|
||||
# Enter codex-lens directory
|
||||
cd codex-lens
|
||||
|
||||
# Install dependencies
|
||||
pip install -e .
|
||||
|
||||
# Initialize index
|
||||
codexlens index /path/to/project
|
||||
```
|
||||
|
||||
Open Dashboard via `ccw view`, manage indexes and execute searches in **CodexLens Manager**.
|
||||
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
## 💻 CCW CLI Commands
|
||||
|
||||
```bash
|
||||
ccw install # Install workflow files
|
||||
ccw view # Open dashboard
|
||||
ccw cli -p "..." # Execute CLI tools (Gemini/Qwen/Codex)
|
||||
ccw upgrade -a # Upgrade all installations
|
||||
```
|
||||
|
||||
### Dashboard Features
|
||||
|
||||
<div align="center">
|
||||
<table>
|
||||
<tr><th>Feature</th><th>Description</th></tr>
|
||||
<tr><td><b>Session Overview</b></td><td>Track workflow sessions and progress</td></tr>
|
||||
<tr><td><b>CodexLens</b></td><td>FTS + Semantic + Hybrid code search</td></tr>
|
||||
<tr><td><b>Graph Explorer</b></td><td>Interactive code relationship visualization</td></tr>
|
||||
<tr><td><b>CLI Manager</b></td><td>Execution history with session resume</td></tr>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 📖 Documentation
|
||||
|
||||
<div align="center">
|
||||
|
||||
| Document | Description |
|
||||
|----------|-------------|
|
||||
| [**Workflow Guide**](WORKFLOW_GUIDE.md) | 4-level workflow system (recommended) |
|
||||
| [**Getting Started**](GETTING_STARTED.md) | 5-minute quick start |
|
||||
| [**Dashboard Guide**](DASHBOARD_GUIDE.md) | Dashboard user guide |
|
||||
| [**FAQ**](FAQ.md) | Common questions |
|
||||
| [**Changelog**](CHANGELOG.md) | Version history |
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 🏗️ Architecture
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Main Workflow (4 Levels) │
|
||||
│ ⚡ Level 1: lite-lite-lite (instant, no artifacts) │
|
||||
│ 📝 Level 2: lite-plan / lite-fix / multi-cli-plan (→ execute) │
|
||||
│ 📊 Level 3: plan / tdd-plan / test-fix-gen (session persist) │
|
||||
│ 🧠 Level 4: brainstorm:auto-parallel → plan → execute │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Issue Workflow (Supplement) │
|
||||
│ 🔍 discover → 📋 plan → 📦 queue → ▶️ execute (worktree) │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**Core Principles:**
|
||||
- ⚡ **Dependency Analysis** solves parallelism - no worktree needed for main workflow
|
||||
- 🔧 **Issue Workflow** supplements main workflow for post-development maintenance
|
||||
- 🎯 Select workflow level based on complexity - avoid over-engineering
|
||||
|
||||
---
|
||||
|
||||
## 🤝 Contributing
|
||||
|
||||
<div align="center">
|
||||
<a href="https://github.com/catlog22/Claude-Code-Workflow"><img src="https://img.shields.io/badge/GitHub-Repository-181717?style=flat-square" alt="GitHub"/></a>
|
||||
<a href="https://github.com/catlog22/Claude-Code-Workflow/issues"><img src="https://img.shields.io/badge/Issues-Report_Bug-EF4444?style=flat-square" alt="Issues"/></a>
|
||||
<a href="CONTRIBUTING.md"><img src="https://img.shields.io/badge/Contributing-Guide-10B981?style=flat-square" alt="Contributing"/></a>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 📄 License
|
||||
|
||||
This project is licensed under the **MIT License**. See the [LICENSE](LICENSE) file for details.
|
||||
<div align="center">
|
||||
|
||||
MIT License - see [LICENSE](LICENSE)
|
||||
|
||||
<br/>
|
||||
|
||||
<!-- Footer -->
|
||||
<img src="https://capsule-render.vercel.app/api?type=waving&color=gradient&customColorList=6,11,20&height=100§ion=footer"/>
|
||||
|
||||
</div>
|
||||
|
||||
556
README_CN.md
556
README_CN.md
@@ -1,292 +1,348 @@
|
||||
# 🚀 Claude Code Workflow (CCW)
|
||||
<div align="center">
|
||||
|
||||
[](https://smithery.ai/skills?ns=catlog22&utm_source=github&utm_medium=badge)
|
||||
<!-- Animated Header -->
|
||||
<img src="https://capsule-render.vercel.app/api?type=waving&color=gradient&customColorList=6,11,20&height=180§ion=header&text=Claude%20Code%20Workflow&fontSize=42&fontColor=fff&animation=twinkling&fontAlignY=32&desc=多智能体%20AI%20开发框架&descAlignY=52&descSize=18"/>
|
||||
|
||||
<!-- Badges -->
|
||||
<p>
|
||||
<a href="https://github.com/catlog22/Claude-Code-Workflow/releases"><img src="https://img.shields.io/badge/version-v6.3.33-6366F1?style=flat-square" alt="Version"/></a>
|
||||
<a href="https://www.npmjs.com/package/claude-code-workflow"><img src="https://img.shields.io/npm/v/claude-code-workflow?style=flat-square&color=cb3837" alt="npm"/></a>
|
||||
<a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-10B981?style=flat-square" alt="License"/></a>
|
||||
<a href="https://github.com/catlog22/Claude-Code-Workflow/stargazers"><img src="https://img.shields.io/github/stars/catlog22/Claude-Code-Workflow?style=flat-square&color=F59E0B" alt="Stars"/></a>
|
||||
<a href="https://github.com/catlog22/Claude-Code-Workflow/issues"><img src="https://img.shields.io/github/issues/catlog22/Claude-Code-Workflow?style=flat-square&color=EF4444" alt="Issues"/></a>
|
||||
</p>
|
||||
|
||||
**[English](README.md) | [中文](README_CN.md)**
|
||||
|
||||
<br/>
|
||||
|
||||
<!-- Typing Animation -->
|
||||
<a href="https://git.io/typing-svg"><img src="https://readme-typing-svg.demolab.com?font=Fira+Code&weight=600&size=22&pause=1000&color=6366F1¢er=true&vCenter=true&random=false&width=600&lines=JSON+驱动的多智能体框架;4+级工作流系统;语义化+CLI+编排;Gemini+%7C+Codex+%7C+OpenCode+%7C+Qwen+%7C+Claude" alt="Typing SVG" /></a>
|
||||
|
||||
</div>
|
||||
|
||||
<br/>
|
||||
|
||||
<!-- Quick Links -->
|
||||
<div align="center">
|
||||
<a href="#-快速开始"><img src="https://img.shields.io/badge/🚀_快速开始-4285F4?style=flat-square" alt="Quick Start"/></a>
|
||||
<a href="WORKFLOW_GUIDE_CN.md"><img src="https://img.shields.io/badge/📖_工作流指南-34A853?style=flat-square" alt="Guide"/></a>
|
||||
<a href="#-cli-工具安装"><img src="https://img.shields.io/badge/🛠️_CLI_工具-EA4335?style=flat-square" alt="CLI Tools"/></a>
|
||||
<a href="#-架构概览"><img src="https://img.shields.io/badge/🏗️_架构-FBBC05?style=flat-square" alt="Architecture"/></a>
|
||||
</div>
|
||||
|
||||
<br/>
|
||||
|
||||
---
|
||||
|
||||
## ✨ 核心特性
|
||||
|
||||
<div align="center">
|
||||
<table>
|
||||
<tr>
|
||||
<td width="50%">
|
||||
|
||||
### 🎯 4 级工作流
|
||||
从 `lite-lite-lite`(即时执行)到 `brainstorm`(多角色分析)
|
||||
|
||||
### 🔄 多 CLI 编排
|
||||
Gemini、Qwen、Codex、Claude - 自动选择或手动指定
|
||||
|
||||
### ⚡ 依赖感知并行
|
||||
Agent 并行执行,无需 worktree 复杂性
|
||||
|
||||
</td>
|
||||
<td width="50%">
|
||||
|
||||
### 🔧 Issue 工作流
|
||||
开发后维护,可选 worktree 隔离
|
||||
|
||||
### 📦 JSON 优先状态
|
||||
`.task/IMPL-*.json` 作为唯一事实来源
|
||||
|
||||
### 🖥️ Dashboard
|
||||
可视化会话管理、CodexLens 搜索、图浏览器
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
> 📖 **新用户?** 查看 [工作流指南](WORKFLOW_GUIDE_CN.md) 了解完整的 4 级工作流系统。
|
||||
|
||||
---
|
||||
|
||||
## 🚀 快速开始
|
||||
|
||||
### 安装 CCW
|
||||
|
||||
```bash
|
||||
npm install -g claude-code-workflow
|
||||
ccw install -m Global
|
||||
```
|
||||
|
||||
### 选择工作流级别
|
||||
|
||||
<div align="center">
|
||||
<table>
|
||||
<tr><th>级别</th><th>命令</th><th>使用场景</th></tr>
|
||||
<tr><td><b>1</b></td><td><code>/workflow:lite-lite-lite</code></td><td>快速修复、配置调整</td></tr>
|
||||
<tr><td><b>2</b></td><td><code>/workflow:lite-plan</code></td><td>明确的单模块功能</td></tr>
|
||||
<tr><td><b>2</b></td><td><code>/workflow:lite-fix</code></td><td>Bug 诊断修复</td></tr>
|
||||
<tr><td><b>2</b></td><td><code>/workflow:multi-cli-plan</code></td><td>多视角分析</td></tr>
|
||||
<tr><td><b>3</b></td><td><code>/workflow:plan</code></td><td>多模块开发</td></tr>
|
||||
<tr><td><b>3</b></td><td><code>/workflow:tdd-plan</code></td><td>测试驱动开发</td></tr>
|
||||
<tr><td><b>4</b></td><td><code>/workflow:brainstorm:auto-parallel</code></td><td>新功能、架构设计</td></tr>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
### 工作流示例
|
||||
|
||||
```bash
|
||||
# Level 1: 即时执行
|
||||
/workflow:lite-lite-lite "修复 README 中的拼写错误"
|
||||
|
||||
# Level 2: 轻量规划
|
||||
/workflow:lite-plan "添加 JWT 认证"
|
||||
/workflow:lite-fix "用户上传失败返回 413 错误"
|
||||
|
||||
# Level 3: 标准规划 + Session
|
||||
/workflow:plan "实现支付网关集成"
|
||||
/workflow:execute
|
||||
|
||||
# Level 4: 多角色头脑风暴
|
||||
/workflow:brainstorm:auto-parallel "设计实时协作系统" --count 5
|
||||
/workflow:plan --session WFS-xxx
|
||||
/workflow:execute
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ CLI 工具安装
|
||||
|
||||
<div align="center">
|
||||
<table>
|
||||
<tr><th>CLI</th><th>说明</th><th>官方文档</th></tr>
|
||||
<tr><td><b>Gemini</b></td><td>Google AI 分析</td><td><a href="https://github.com/google-gemini/gemini-cli">google-gemini/gemini-cli</a></td></tr>
|
||||
<tr><td><b>Codex</b></td><td>OpenAI 自主编码</td><td><a href="https://github.com/openai/codex">openai/codex</a></td></tr>
|
||||
<tr><td><b>OpenCode</b></td><td>开源多模型</td><td><a href="https://github.com/opencode-ai/opencode">opencode-ai/opencode</a></td></tr>
|
||||
<tr><td><b>Qwen</b></td><td>阿里云 Qwen-Code</td><td><a href="https://github.com/QwenLM">QwenLM/Qwen</a></td></tr>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 🎭 语义化 CLI 调用
|
||||
|
||||
<div align="center">
|
||||
<img src="https://img.shields.io/badge/只需描述-你想要什么-6366F1?style=flat-square"/>
|
||||
<img src="https://img.shields.io/badge/CCW_处理-剩下的一切-10B981?style=flat-square"/>
|
||||
</div>
|
||||
|
||||
<br/>
|
||||
|
||||
用户可以在提示词中 **语义指定 CLI 工具** - 系统自动调用对应的 CLI。
|
||||
|
||||
### 基础调用
|
||||
|
||||
<div align="center">
|
||||
|
||||
[](https://github.com/catlog22/Claude-Code-Workflow/releases)
|
||||
[](https://www.npmjs.com/package/claude-code-workflow)
|
||||
[](LICENSE)
|
||||
[]()
|
||||
| 用户提示词 | 系统动作 |
|
||||
|------------|----------|
|
||||
| "使用 Gemini 分析 auth 模块" | 自动调用 `gemini` CLI 进行分析 |
|
||||
| "让 Codex 审查这段代码" | 自动调用 `codex` CLI 进行审查 |
|
||||
| "问问 Qwen 性能优化建议" | 自动调用 `qwen` CLI 进行咨询 |
|
||||
|
||||
**语言:** [English](README.md) | [中文](README_CN.md)
|
||||
</div>
|
||||
|
||||
### 多 CLI 编排
|
||||
|
||||
<div align="center">
|
||||
|
||||
| 模式 | 用户提示词示例 |
|
||||
|------|----------------|
|
||||
| **协同分析** | "使用 Gemini 和 Codex 协同分析安全漏洞" |
|
||||
| **并行执行** | "让 Gemini、Codex、Qwen 并行分析架构设计" |
|
||||
| **迭代优化** | "用 Gemini 诊断问题,然后 Codex 修复,迭代直到解决" |
|
||||
| **流水线** | "Gemini 设计方案,Codex 实现,Claude 审查" |
|
||||
|
||||
</div>
|
||||
|
||||
<details>
|
||||
<summary><b>📝 更多示例</b></summary>
|
||||
|
||||
```text
|
||||
# 单 CLI 调用
|
||||
用户: "使用 Gemini 分析数据库查询性能"
|
||||
→ 系统自动调用: gemini CLI 执行分析任务
|
||||
|
||||
# 协同分析
|
||||
用户: "使用 Gemini 和 Codex 协同审查认证流程"
|
||||
→ 系统自动调用: gemini + codex CLI,综合分析结果
|
||||
|
||||
# 并行多视角
|
||||
用户: "让所有可用的 CLI 并行分析这个架构设计"
|
||||
→ 系统自动调用: gemini, codex, qwen 并行执行 → 合并报告
|
||||
|
||||
# 顺序流水线
|
||||
用户: "用 Gemini 规划重构方案,然后 Codex 实现"
|
||||
→ 系统自动调用: gemini(规划)→ codex(实现)顺序执行
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### 自定义 CLI 注册
|
||||
|
||||
通过 Dashboard 界面 **注册任意 API 为自定义 CLI**:
|
||||
|
||||
```bash
|
||||
ccw view # 打开 Dashboard → Status → API Settings → 添加自定义 CLI
|
||||
```
|
||||
|
||||
<div align="center">
|
||||
|
||||
| 字段 | 示例 |
|
||||
|------|------|
|
||||
| **名称** | `deepseek` |
|
||||
| **端点** | `https://api.deepseek.com/v1/chat` |
|
||||
| **API Key** | `your-api-key` |
|
||||
|
||||
</div>
|
||||
|
||||
> ⚙️ 注册一次,永久语义调用 - 无需修改代码。
|
||||
|
||||
---
|
||||
|
||||
## 🔍 ACE Tool 配置
|
||||
|
||||
ACE (Augment Context Engine) 提供强大的语义代码搜索能力。
|
||||
|
||||
<div align="center">
|
||||
|
||||
| 方式 | 链接 |
|
||||
|------|------|
|
||||
| **官方** | [Augment MCP 文档](https://docs.augmentcode.com/context-services/mcp/overview) |
|
||||
| **代理** | [ace-tool (GitHub)](https://github.com/eastxiaodong/ace-tool) |
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
**Claude Code Workflow (CCW)** 是一个 JSON 驱动的多智能体开发框架,具有智能 CLI 编排(Gemini/Qwen/Codex)、上下文优先架构和自动化工作流执行。它将 AI 开发从简单的提示词链接转变为一个强大的编排系统。
|
||||
## 📚 CodexLens 本地搜索
|
||||
|
||||
> **🎉 版本 6.3.19: 搜索增强与 CLI 工具升级**
|
||||
>
|
||||
> **新功能亮点**:
|
||||
> - 🔍 **Dense + Reranker 搜索**: Cross-Encoder 重排序提升结果相关性
|
||||
> - 💻 **OpenCode AI 支持**: 新增 OpenCode CLI 工具集成
|
||||
> - 🛠️ **服务架构优化**: 预加载服务、缓存管理、UV 包管理器支持
|
||||
> - 📊 **Issue 多队列执行**: 支持 Codex 长时间自主工作
|
||||
>
|
||||
> **推荐工作流**:
|
||||
> - 🚀 **Issue 工作流** (`/issue:plan` → `/issue:queue` → `/issue:execute`): 推荐使用 **Codex** 执行器,支持长时间自主编码工作
|
||||
>
|
||||
> 详见 [CHANGELOG.md](CHANGELOG.md) 获取完整详情和迁移指南。
|
||||
> ⚠️ **开发中**: CodexLens 正在迭代优化中,部分功能可能不稳定。
|
||||
|
||||
> 📚 **第一次使用 CCW?** 查看 [**快速上手指南**](GETTING_STARTED_CN.md) 获取新手友好的 5 分钟教程!
|
||||
<div align="center">
|
||||
<table>
|
||||
<tr><th>搜索模式</th><th>说明</th></tr>
|
||||
<tr><td><b>FTS</b></td><td>全文搜索,基于 SQLite FTS5</td></tr>
|
||||
<tr><td><b>Semantic</b></td><td>语义搜索,基于本地嵌入模型</td></tr>
|
||||
<tr><td><b>Hybrid</b></td><td>混合搜索,结合 FTS + 语义 + 重排序</td></tr>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## ✨ 核心概念
|
||||
|
||||
CCW 构建在一系列核心原则之上,这些原则使其与传统的 AI 开发方法区别开来:
|
||||
|
||||
- **上下文优先架构**: 通过预定义的上下文收集消除执行过程中的不确定性,确保智能体在实现*之前*就拥有正确的信息。
|
||||
- **JSON 优先的状态管理**: 任务状态完全存储在 `.task/IMPL-*.json` 文件中作为唯一的事实来源,实现无状态漂移的程序化编排。
|
||||
- **自主多阶段编排**: 命令链式调用专门的子命令和智能体,以零用户干预的方式自动化复杂的工作流。
|
||||
- **多模型策略**: 充分利用不同 AI 模型(如 Gemini 用于分析,Codex 用于实现)的独特优势,以获得更优越的结果。
|
||||
- **分层内存系统**: 一个 4 层文档系统,在适当的抽象级别上提供上下文,防止信息过载。
|
||||
- **专门的基于角色的智能体**: 一套模拟真实软件团队的智能体(`@code-developer`, `@test-fix-agent` 等),用于处理多样化的任务。
|
||||
|
||||
---
|
||||
|
||||
## ⚙️ 安装
|
||||
|
||||
### **📦 npm 安装(推荐)**
|
||||
|
||||
通过 npm 全局安装:
|
||||
```bash
|
||||
npm install -g claude-code-workflow
|
||||
```
|
||||
|
||||
然后将工作流文件安装到您的系统:
|
||||
```bash
|
||||
# 交互式安装
|
||||
ccw install
|
||||
|
||||
# 全局安装(到 ~/.claude)
|
||||
ccw install -m Global
|
||||
|
||||
# 项目特定安装
|
||||
ccw install -m Path -p /path/to/project
|
||||
```
|
||||
|
||||
### **✅ 验证安装**
|
||||
安装后,打开 **Claude Code** 并通过运行以下命令检查工作流命令是否可用:
|
||||
```bash
|
||||
/workflow:session:list
|
||||
```
|
||||
如果斜杠命令(例如 `/workflow:*`)被识别,则表示安装成功。
|
||||
|
||||
---
|
||||
|
||||
## 🖥️ CCW CLI 工具
|
||||
|
||||
`ccw` 命令提供了强大的 CLI 来管理您的 Claude Code Workflow 安装:
|
||||
|
||||
### **命令**
|
||||
|
||||
| 命令 | 描述 |
|
||||
|---------|-------------|
|
||||
| `ccw install` | 安装工作流文件到全局 (~/.claude) 或指定路径 |
|
||||
| `ccw upgrade` | 升级现有安装到当前包版本 |
|
||||
| `ccw uninstall` | 从安装中移除工作流文件 |
|
||||
| `ccw view` | 在浏览器中打开工作流仪表板 |
|
||||
| `ccw serve` | 启动仪表板服务器而不打开浏览器 |
|
||||
| `ccw list` | 列出所有管理的安装 |
|
||||
| `ccw cli -p "..."` | 使用提示词执行 CLI 工具 (Gemini/Qwen/Codex) |
|
||||
| `ccw core-memory` | 管理会话聚类和记忆 |
|
||||
|
||||
### **使用示例**
|
||||
<details>
|
||||
<summary><b>📦 安装</b></summary>
|
||||
|
||||
```bash
|
||||
# 全局安装
|
||||
ccw install -m Global
|
||||
# 进入 codex-lens 目录
|
||||
cd codex-lens
|
||||
|
||||
# 安装到指定项目
|
||||
ccw install -m Path -p ./my-project
|
||||
# 安装依赖
|
||||
pip install -e .
|
||||
|
||||
# 打开仪表板
|
||||
ccw view
|
||||
|
||||
# 在自定义端口启动仪表板服务器
|
||||
ccw serve --port 8080
|
||||
|
||||
# 升级所有安装
|
||||
ccw upgrade -a
|
||||
|
||||
# 列出安装
|
||||
ccw list
|
||||
# 初始化索引
|
||||
codexlens index /path/to/project
|
||||
```
|
||||
|
||||
### **Dashboard 功能**
|
||||
通过 `ccw view` 打开 Dashboard,在 **CodexLens Manager** 中管理索引和执行搜索。
|
||||
|
||||
CCW Dashboard (`ccw view`) 提供:
|
||||
- 📊 **会话概览**: 查看所有工作流会话的状态和进度
|
||||
- 📋 **任务管理**: 跟踪任务执行和完成情况
|
||||
- 🔍 **CodexLens 管理器**: 原生代码索引,支持 FTS + 语义 + 混合搜索
|
||||
- 🧠 **核心记忆**: 会话聚类可视化与聚类管理
|
||||
- 📄 **CLAUDE.md 管理器**: 配置管理的文件树查看器
|
||||
- 🎯 **技能管理器**: 查看和管理 Claude Code 技能
|
||||
- 🕸️ **图浏览器**: 交互式代码关系可视化 (Cytoscape.js)
|
||||
- ⚙️ **MCP 管理器**: 配置和监控 MCP 服务器
|
||||
- 🪝 **Hook 管理器**: 管理 Claude Code Hooks
|
||||
- ❓ **帮助视图**: 国际化帮助文档
|
||||
- 💻 **CLI 管理器**: CLI 执行历史与会话恢复
|
||||
|
||||
> 📖 详见 [**Dashboard 用户指南**](DASHBOARD_GUIDE.md) 和 [**Dashboard 操作指南**](DASHBOARD_OPERATIONS.md)。
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ 命令参考
|
||||
|
||||
CCW 提供了一套丰富的命令,用于管理工作流、任务以及与 AI 工具的交互。有关所有可用命令的完整列表和详细说明,请参阅 [**COMMAND_REFERENCE.md**](COMMAND_REFERENCE.md) 文件。
|
||||
|
||||
有关每个命令的详细技术规范,请参阅 [**COMMAND_SPEC.md**](COMMAND_SPEC.md)。
|
||||
|
||||
---
|
||||
|
||||
### 💡 **需要帮助?使用交互式命令指南**
|
||||
|
||||
CCW 包含内置的**命令指南技能**,帮助您有效地发现和使用命令:
|
||||
|
||||
- **`CCW-help`** - 获取交互式帮助和命令推荐
|
||||
- **`CCW-issue`** - 使用引导模板报告错误或请求功能
|
||||
|
||||
命令指南提供:
|
||||
- 🔍 **智能命令搜索** - 按关键词、分类或使用场景查找命令
|
||||
- 🤖 **下一步推荐** - 获取任何命令之后的操作建议
|
||||
- 📖 **详细文档** - 查看参数、示例和最佳实践
|
||||
- 🎓 **新手入门** - 通过引导式学习路径学习 14 个核心命令
|
||||
- 📝 **问题报告** - 生成标准化的错误报告和功能请求
|
||||
|
||||
**使用示例**:
|
||||
```
|
||||
用户: "CCW-help"
|
||||
→ 交互式菜单,包含命令搜索、推荐和文档
|
||||
|
||||
用户: "执行完 /workflow:plan 后做什么?"
|
||||
→ 推荐 /workflow:execute、/workflow:action-plan-verify 及工作流模式
|
||||
|
||||
用户: "CCW-issue"
|
||||
→ 引导式模板生成,用于错误、功能或问题咨询
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🚀 快速入门
|
||||
|
||||
开始使用的最佳方式是遵循 [**快速上手指南**](GETTING_STARTED_CN.md) 中的 5 分钟教程。
|
||||
|
||||
以下是一个常见开发工作流的快速示例:
|
||||
|
||||
### **选项 1: Lite-Plan 工作流** (⚡ 推荐用于快速任务)
|
||||
|
||||
轻量级交互式工作流,内存中规划并立即执行:
|
||||
## 💻 CCW CLI 命令
|
||||
|
||||
```bash
|
||||
# 基本用法,自动检测
|
||||
/workflow:lite-plan "为用户登录添加 JWT 认证"
|
||||
|
||||
# 强制代码探索
|
||||
/workflow:lite-plan -e "重构日志模块以提高性能"
|
||||
|
||||
# 基本用法
|
||||
/workflow:lite-plan "为认证服务添加单元测试"
|
||||
ccw install # 安装工作流文件
|
||||
ccw view # 打开 Dashboard
|
||||
ccw cli -p "..." # 执行 CLI 工具 (Gemini/Qwen/Codex)
|
||||
ccw upgrade -a # 升级所有安装
|
||||
```
|
||||
|
||||
**交互流程**:
|
||||
1. **阶段 1**: 自动任务分析和智能代码探索(如需要)
|
||||
2. **阶段 2**: 回答澄清问题(如有)
|
||||
3. **阶段 3**: 查看生成的计划和任务分解
|
||||
4. **阶段 4**: 三维确认:
|
||||
- ✅ 确认/修改/取消任务
|
||||
- 🔧 选择执行方式: 智能体 / 仅提供计划 / CLI(Gemini/Qwen/Codex)
|
||||
- 🔍 可选代码审查: 否 / Claude / Gemini / Qwen / Codex
|
||||
5. **阶段 5**: 观察实时执行和任务跟踪
|
||||
### Dashboard 功能
|
||||
|
||||
### **选项 2: Lite-Fix 工作流** (🐛 推荐用于 Bug 修复)
|
||||
|
||||
智能 Bug 诊断和修复工作流,具有自适应严重性评估:
|
||||
|
||||
```bash
|
||||
# 标准 Bug 修复(根据严重性自动适应)
|
||||
/workflow:lite-fix "用户头像上传失败,返回 413 错误"
|
||||
|
||||
# 生产热修复模式
|
||||
/workflow:lite-fix --hotfix "支付网关 5xx 错误"
|
||||
```
|
||||
|
||||
**工作流特性**:
|
||||
- **阶段 1**: 智能根因诊断,采用自适应搜索
|
||||
- **阶段 2**: 自动影响评估和风险评分
|
||||
- **阶段 3**: 基于复杂度的修复策略生成
|
||||
- **阶段 4**: 风险感知的验证计划
|
||||
- **阶段 5**: 用户确认与执行选择
|
||||
- **阶段 6**: 执行调度,完整产物跟踪
|
||||
|
||||
**会话产物** (保存到 `.workflow/.lite-fix/{bug-slug}-{timestamp}/`):
|
||||
- `diagnosis.json` - 根因分析和复现步骤
|
||||
- `impact.json` - 风险评分、严重性和工作流适应
|
||||
- `fix-plan.json` - 修复策略和实现任务
|
||||
- `task.json` - 包含完整上下文的增强任务 JSON
|
||||
- `followup.json` - 自动生成的跟进任务(仅热修复模式)
|
||||
|
||||
### **选项 3: 完整工作流** (📋 综合规划)
|
||||
|
||||
适用于复杂项目的传统多阶段工作流:
|
||||
|
||||
1. **创建计划**(自动启动会话):
|
||||
```bash
|
||||
/workflow:plan "实现基于 JWT 的用户登录和注册"
|
||||
```
|
||||
2. **执行计划**:
|
||||
```bash
|
||||
/workflow:execute
|
||||
```
|
||||
3. **查看状态**(可选):
|
||||
```bash
|
||||
/workflow:status
|
||||
```
|
||||
<div align="center">
|
||||
<table>
|
||||
<tr><th>功能</th><th>说明</th></tr>
|
||||
<tr><td><b>会话概览</b></td><td>跟踪工作流会话和进度</td></tr>
|
||||
<tr><td><b>CodexLens</b></td><td>FTS + 语义 + 混合代码搜索</td></tr>
|
||||
<tr><td><b>图浏览器</b></td><td>交互式代码关系可视化</td></tr>
|
||||
<tr><td><b>CLI 管理器</b></td><td>执行历史与会话恢复</td></tr>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 📚 文档
|
||||
## 📖 文档
|
||||
|
||||
CCW 提供全面的文档,帮助您快速上手并掌握高级功能:
|
||||
<div align="center">
|
||||
|
||||
### 📖 **快速入门**
|
||||
- [**快速上手指南**](GETTING_STARTED_CN.md) - 5 分钟快速入门教程
|
||||
- [**安装指南**](INSTALL_CN.md) - 详细安装说明 ([English](INSTALL.md))
|
||||
- [**工作流决策指南**](WORKFLOW_DECISION_GUIDE.md) - 🌳 交互式流程图帮助选择正确的命令
|
||||
- [**示例**](EXAMPLES.md) - 真实世界用例和实践示例 (English)
|
||||
- [**常见问题**](FAQ.md) - 常见问题和故障排除 (English)
|
||||
| 文档 | 说明 |
|
||||
|------|------|
|
||||
| [**工作流指南**](WORKFLOW_GUIDE_CN.md) | 4 级工作流系统(推荐) |
|
||||
| [**快速开始**](GETTING_STARTED_CN.md) | 5 分钟快速入门 |
|
||||
| [**Dashboard 指南**](DASHBOARD_GUIDE.md) | Dashboard 用户指南 |
|
||||
| [**常见问题**](FAQ.md) | 常见问题解答 |
|
||||
| [**更新日志**](CHANGELOG.md) | 版本历史 |
|
||||
|
||||
### 🖥️ **Dashboard**
|
||||
- [**Dashboard 用户指南**](DASHBOARD_GUIDE.md) - Dashboard 界面概览和功能说明
|
||||
- [**Dashboard 操作指南**](DASHBOARD_OPERATIONS.md) - 详细操作步骤说明
|
||||
|
||||
### 🏗️ **架构与设计**
|
||||
- [**架构概览**](ARCHITECTURE.md) - 系统设计和核心组件 (English)
|
||||
- [**项目介绍**](PROJECT_INTRODUCTION.md) - 详细项目概览
|
||||
- [**工作流图示**](WORKFLOW_DIAGRAMS.md) - 可视化工作流表示 (English)
|
||||
|
||||
### 📋 **命令参考**
|
||||
- [**命令参考**](COMMAND_REFERENCE.md) - 所有命令的完整列表 (English)
|
||||
- [**命令规范**](COMMAND_SPEC.md) - 详细技术规范 (English)
|
||||
- [**命令流程标准**](COMMAND_FLOW_STANDARD.md) - 命令设计模式 (English)
|
||||
|
||||
### 🤝 **贡献**
|
||||
- [**贡献指南**](CONTRIBUTING.md) - 如何为 CCW 做贡献 (English)
|
||||
- [**更新日志**](CHANGELOG.md) - 版本历史和发布说明
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 🤝 贡献与支持
|
||||
## 🏗️ 架构概览
|
||||
|
||||
- **仓库**: [GitHub - Claude-Code-Workflow](https://github.com/catlog22/Claude-Code-Workflow)
|
||||
- **问题**: 在 [GitHub Issues](https://github.com/catlog22/Claude-Code-Workflow/issues) 上报告错误或请求功能。
|
||||
- **讨论**: 加入 [社区论坛](https://github.com/catlog22/Claude-Code-Workflow/discussions)。
|
||||
- **贡献**: 查看 [CONTRIBUTING.md](CONTRIBUTING.md) 了解贡献指南。
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ 主干工作流 (4 级) │
|
||||
│ ⚡ Level 1: lite-lite-lite (即时执行,无产物) │
|
||||
│ 📝 Level 2: lite-plan / lite-fix / multi-cli-plan (→ execute) │
|
||||
│ 📊 Level 3: plan / tdd-plan / test-fix-gen (Session 持久化) │
|
||||
│ 🧠 Level 4: brainstorm:auto-parallel → plan → execute │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Issue 工作流 (补充) │
|
||||
│ 🔍 discover → 📋 plan → 📦 queue → ▶️ execute (worktree) │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**核心原则:**
|
||||
- ⚡ **依赖分析** 解决并行问题 - 主干工作流无需 worktree
|
||||
- 🔧 **Issue 工作流** 补充主干工作流,用于开发后维护
|
||||
- 🎯 根据复杂度选择工作流级别 - 避免过度工程化
|
||||
|
||||
---
|
||||
|
||||
## 🤝 贡献
|
||||
|
||||
<div align="center">
|
||||
<a href="https://github.com/catlog22/Claude-Code-Workflow"><img src="https://img.shields.io/badge/GitHub-仓库-181717?style=flat-square" alt="GitHub"/></a>
|
||||
<a href="https://github.com/catlog22/Claude-Code-Workflow/issues"><img src="https://img.shields.io/badge/Issues-报告问题-EF4444?style=flat-square" alt="Issues"/></a>
|
||||
<a href="CONTRIBUTING.md"><img src="https://img.shields.io/badge/贡献-指南-10B981?style=flat-square" alt="Contributing"/></a>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 📄 许可证
|
||||
|
||||
此项目根据 **MIT 许可证** 授权。详见 [LICENSE](LICENSE) 文件。
|
||||
<div align="center">
|
||||
|
||||
MIT License - 详见 [LICENSE](LICENSE)
|
||||
|
||||
<br/>
|
||||
|
||||
<!-- Footer -->
|
||||
<img src="https://capsule-render.vercel.app/api?type=waving&color=gradient&customColorList=6,11,20&height=100§ion=footer"/>
|
||||
|
||||
</div>
|
||||
|
||||
@@ -1,853 +0,0 @@
|
||||
# 🌳 CCW Workflow Decision Guide
|
||||
|
||||
本指南帮助您选择正确的命令和工作流程,适用于软件开发的完整生命周期。
|
||||
|
||||
---
|
||||
|
||||
## 📊 全生命周期命令选择流程图
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start([开始新任务]) --> Q0{这是Bug修复吗?}
|
||||
|
||||
Q0 -->|是| BugFix[🐛 Bug修复流程]
|
||||
Q0 -->|否| Q1{知道要做什么吗?}
|
||||
|
||||
BugFix --> BugSeverity{了解问题根因?}
|
||||
BugSeverity -->|清楚| LiteFix[/ /workflow:lite-fix<br>标准Bug修复 /]
|
||||
BugSeverity -->|生产事故| HotFix[/ /workflow:lite-fix --hotfix<br>热修复模式 /]
|
||||
BugSeverity -->|不清楚| BugDiag[/ /workflow:lite-fix<br>自动诊断根因 /]
|
||||
|
||||
BugDiag --> LiteFix
|
||||
LiteFix --> BugComplete[Bug修复完成]
|
||||
HotFix --> FollowUp[/ 自动生成跟进任务<br>全面修复+事后分析 /]
|
||||
FollowUp --> BugComplete
|
||||
BugComplete --> End([任务完成])
|
||||
|
||||
Q1 -->|不知道| Ideation[💡 构思阶段<br>需求探索]
|
||||
Q1 -->|知道| Q2{知道怎么做吗?}
|
||||
|
||||
Ideation --> BrainIdea[/ /workflow:brainstorm:auto-parallel<br>探索产品方向和功能定位 /]
|
||||
BrainIdea --> Q2
|
||||
|
||||
Q2 -->|不知道| Design[🏗️ 设计探索阶段<br>架构方案探索]
|
||||
Q2 -->|知道| Q3{需要UI设计吗?}
|
||||
|
||||
Design --> BrainDesign[/ /workflow:brainstorm:auto-parallel<br>探索技术方案和架构 /]
|
||||
BrainDesign --> Q3
|
||||
|
||||
Q3 -->|需要| UIDesign[🎨 UI设计阶段]
|
||||
Q3 -->|不需要| Q4{任务复杂度?}
|
||||
|
||||
UIDesign --> Q3a{有参考设计吗?}
|
||||
Q3a -->|有| UIImitate[/ /workflow:ui-design:imitate-auto<br>--input 本地文件/图片 /]
|
||||
Q3a -->|无| UIExplore[/ /workflow:ui-design:explore-auto<br>--prompt 设计描述 /]
|
||||
|
||||
UIImitate --> UISync[/ /workflow:ui-design:design-sync<br>同步设计系统 /]
|
||||
UIExplore --> UISync
|
||||
UISync --> Q4
|
||||
|
||||
Q4 -->|简单快速| LitePlan[⚡ 轻量规划<br>/workflow:lite-plan]
|
||||
Q4 -->|复杂完整| FullPlan[📋 完整规划<br>/workflow:plan]
|
||||
|
||||
LitePlan --> Q5{需要代码探索?}
|
||||
Q5 -->|需要| LitePlanE[/ /workflow:lite-plan -e<br>任务描述 /]
|
||||
Q5 -->|不需要| LitePlanNormal[/ /workflow:lite-plan<br>任务描述 /]
|
||||
|
||||
LitePlanE --> LiteConfirm[三维确认:<br>1️⃣ 任务批准<br>2️⃣ 执行方式<br>3️⃣ 代码审查]
|
||||
LitePlanNormal --> LiteConfirm
|
||||
|
||||
LiteConfirm --> Q6{选择执行方式}
|
||||
Q6 -->|Agent| LiteAgent[/ /workflow:lite-execute<br>使用@code-developer /]
|
||||
Q6 -->|CLI工具| LiteCLI[CLI执行<br>Gemini/Qwen/Codex]
|
||||
Q6 -->|仅计划| UserImpl[用户手动实现]
|
||||
|
||||
FullPlan --> PlanVerify{验证计划质量?}
|
||||
PlanVerify -->|是| Verify[/ /workflow:action-plan-verify /]
|
||||
PlanVerify -->|否| Execute
|
||||
Verify --> Q7{验证通过?}
|
||||
Q7 -->|否| FixPlan[修复计划问题]
|
||||
Q7 -->|是| Execute
|
||||
FixPlan --> Execute
|
||||
|
||||
Execute[🚀 执行阶段<br>/workflow:execute]
|
||||
LiteAgent --> TestDecision
|
||||
LiteCLI --> TestDecision
|
||||
UserImpl --> TestDecision
|
||||
Execute --> TestDecision
|
||||
|
||||
TestDecision{需要测试吗?}
|
||||
TestDecision -->|TDD模式| TDD[/ /workflow:tdd-plan<br>测试驱动开发 /]
|
||||
TestDecision -->|后置测试| TestGen[/ /workflow:test-gen<br>生成测试 /]
|
||||
TestDecision -->|已有测试| TestCycle[/ /workflow:test-cycle-execute<br>测试修复循环 /]
|
||||
TestDecision -->|不需要| Review
|
||||
|
||||
TDD --> TDDExecute[/ /workflow:execute<br>Red-Green-Refactor /]
|
||||
TDDExecute --> TDDVerify[/ /workflow:tdd-verify<br>验证TDD合规 /]
|
||||
TDDVerify --> Review
|
||||
|
||||
TestGen --> TestExecute[/ /workflow:execute<br>执行测试任务 /]
|
||||
TestExecute --> TestResult{测试通过?}
|
||||
TestResult -->|否| TestCycle
|
||||
TestResult -->|是| Review
|
||||
|
||||
TestCycle --> TestPass{通过率≥95%?}
|
||||
TestPass -->|否,继续修复| TestCycle
|
||||
TestPass -->|是| Review
|
||||
|
||||
Review[📝 审查阶段]
|
||||
Review --> Q8{需要专项审查?}
|
||||
Q8 -->|安全| SecurityReview[/ /workflow:review<br>--type security /]
|
||||
Q8 -->|架构| ArchReview[/ /workflow:review<br>--type architecture /]
|
||||
Q8 -->|质量| QualityReview[/ /workflow:review<br>--type quality /]
|
||||
Q8 -->|综合| GeneralReview[/ /workflow:review<br>综合审查 /]
|
||||
Q8 -->|不需要| Complete
|
||||
|
||||
SecurityReview --> Complete
|
||||
ArchReview --> Complete
|
||||
QualityReview --> Complete
|
||||
GeneralReview --> Complete
|
||||
|
||||
Complete[✅ 完成阶段<br>/workflow:session:complete]
|
||||
Complete --> End
|
||||
|
||||
style Start fill:#e1f5ff
|
||||
style BugFix fill:#ffccbc
|
||||
style LiteFix fill:#ffccbc
|
||||
style HotFix fill:#ff8a65
|
||||
style BugDiag fill:#ffccbc
|
||||
style BugComplete fill:#c8e6c9
|
||||
style End fill:#c8e6c9
|
||||
style BrainIdea fill:#fff9c4
|
||||
style BrainDesign fill:#fff9c4
|
||||
style UIImitate fill:#f8bbd0
|
||||
style UIExplore fill:#f8bbd0
|
||||
style LitePlan fill:#b3e5fc
|
||||
style FullPlan fill:#b3e5fc
|
||||
style Execute fill:#c5e1a5
|
||||
style TDD fill:#ffccbc
|
||||
style TestGen fill:#ffccbc
|
||||
style TestCycle fill:#ffccbc
|
||||
style Review fill:#d1c4e9
|
||||
style Complete fill:#c8e6c9
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 决策关键点说明
|
||||
|
||||
### 0️⃣ **首要决策 - "这是Bug修复吗?"**
|
||||
|
||||
| 情况 | 命令 | 说明 |
|
||||
|------|------|------|
|
||||
| 🐛 **标准Bug修复** | `/workflow:lite-fix "bug描述"` | 自适应严重性评估,完整诊断→影响评估→修复→验证 |
|
||||
| 🔥 **生产热修复** | `/workflow:lite-fix --hotfix "bug描述"` | 最小化诊断,快速修复,自动生成跟进任务 |
|
||||
| ❓ **根因不清楚** | `/workflow:lite-fix` | 自动进行深度诊断并执行修复 |
|
||||
| ✅ **功能开发** | 继续后续流程 | 不是Bug修复,按正常开发流程 |
|
||||
|
||||
**Lite-Fix 工作流特性**:
|
||||
- **阶段 1**: 智能根因诊断(自适应搜索策略)
|
||||
- **阶段 2**: 自动影响评估和风险评分(0-10分)
|
||||
- **阶段 3**: 修复策略生成(单一最优 vs 多选项)
|
||||
- **阶段 4**: 风险感知验证计划(完整测试 → 烟雾测试)
|
||||
- **阶段 5**: 用户确认(执行方式 + 验证级别 + 可选审查)
|
||||
- **阶段 6**: 执行调度 + 会话产物跟踪
|
||||
|
||||
**会话产物** (保存到 `.workflow/.lite-fix/{bug-slug}-{timestamp}/`):
|
||||
- `diagnosis.json` - 根因分析、复现步骤
|
||||
- `impact.json` - 风险评分、严重性、工作流适应
|
||||
- `fix-plan.json` - 修复策略、实现任务
|
||||
- `task.json` - 完整上下文的增强任务 JSON
|
||||
- `followup.json` - 跟进任务(仅热修复模式)
|
||||
|
||||
**示例**:
|
||||
```bash
|
||||
# 标准Bug修复(自动适应严重性)
|
||||
/workflow:lite-fix "用户头像上传失败,返回 413 错误"
|
||||
→ 自动诊断 → 风险评分 6.5 (High) → 快速修复策略 → 集成测试
|
||||
|
||||
# 生产热修复(紧急修复)
|
||||
/workflow:lite-fix --hotfix "支付网关返回 5xx 错误"
|
||||
→ 最小化诊断 → 假设 Critical → 手术式修复 → 烟雾测试
|
||||
→ 自动生成: 全面修复任务(3天内)+ 事后分析(1周内)
|
||||
|
||||
# 根因不清楚(lite-fix 自动诊断)
|
||||
/workflow:lite-fix "购物车随机丢失商品"
|
||||
→ 自动深度诊断 → 识别根因 → 实现修复
|
||||
```
|
||||
|
||||
**何时使用 lite-fix**:
|
||||
- ✅ 任何有明确症状的Bug(自动适应严重性)
|
||||
- ✅ 本地化修复(1-5个文件)
|
||||
- ✅ 生产事故(使用 `--hotfix` 模式)
|
||||
- ✅ 根因不清楚(自动进行深度诊断)
|
||||
- ❌ 需要架构变更 → 用 `/workflow:plan --mode bugfix`
|
||||
|
||||
---
|
||||
|
||||
### 1️⃣ **构思阶段 - "知道要做什么吗?"**
|
||||
|
||||
| 情况 | 命令 | 说明 |
|
||||
|------|------|------|
|
||||
| ❌ 不确定产品方向 | `/workflow:brainstorm:auto-parallel "探索XXX领域的产品机会"` | 产品经理、用户体验专家等多角色分析 |
|
||||
| ✅ 明确功能需求 | 跳过,进入设计阶段 | 已知道要构建什么功能 |
|
||||
|
||||
**示例**:
|
||||
```bash
|
||||
# 不确定场景:我想做一个协作工具,但不确定具体做什么
|
||||
/workflow:brainstorm:auto-parallel "探索团队协作工具的产品定位和核心功能" --count 5
|
||||
|
||||
# 确定场景:我要做一个实时文档协作编辑器(需求明确)
|
||||
# 跳过构思,进入设计阶段
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2️⃣ **设计阶段 - "知道怎么做吗?"**
|
||||
|
||||
| 情况 | 命令 | 说明 |
|
||||
|------|------|------|
|
||||
| ❌ 不知道技术方案 | `/workflow:brainstorm:auto-parallel "设计XXX系统架构"` | 系统架构师、安全专家等分析技术方案 |
|
||||
| ✅ 清晰实现路径 | 跳过,直接进入规划 | 已知道用什么技术栈、架构模式 |
|
||||
|
||||
**示例**:
|
||||
```bash
|
||||
# 不知道怎么做:实时协作编辑的冲突解决机制?用什么算法?
|
||||
/workflow:brainstorm:auto-parallel "设计实时协作文档编辑系统的冲突解决机制" --count 4
|
||||
|
||||
# 知道怎么做:使用Operational Transformation + WebSocket + Redis
|
||||
# 跳过设计探索,直接规划实现
|
||||
/workflow:plan "使用OT算法实现实时协作编辑,WebSocket通信,Redis存储"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3️⃣ **UI设计阶段 - "需要UI设计吗?"**
|
||||
|
||||
| 情况 | 命令 | 说明 |
|
||||
|------|------|------|
|
||||
| 🎨 有参考设计 | `/workflow:ui-design:imitate-auto --input "本地文件/图片"` | 基于本地参考文件/图片复制设计 |
|
||||
| 🎨 从零设计 | `/workflow:ui-design:explore-auto --prompt "描述"` | 生成多个设计变体 |
|
||||
| ⏭️ 后端/无UI | 跳过 | 纯后端API、CLI工具等 |
|
||||
|
||||
**示例**:
|
||||
```bash
|
||||
# 有参考:使用本地截图或代码文件
|
||||
/workflow:ui-design:imitate-auto --input "design-refs/*.png"
|
||||
# 或从现有代码导入
|
||||
/workflow:ui-design:imitate-auto --input "./src/components"
|
||||
|
||||
# 无参考:从零设计
|
||||
/workflow:ui-design:explore-auto --prompt "现代简洁的文档协作编辑界面" --style-variants 3
|
||||
|
||||
# 同步设计到项目
|
||||
/workflow:ui-design:design-sync --session WFS-xxx --selected-prototypes "v1,v2"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4️⃣ **规划阶段 - 选择工作流类型**
|
||||
|
||||
| 工作流 | 适用场景 | 特点 |
|
||||
|--------|---------|------|
|
||||
| `/workflow:lite-plan` | 快速任务、小功能 | 内存规划、三维确认、快速执行 |
|
||||
| `/workflow:plan` | 复杂项目、团队协作 | 持久化计划、质量门禁、完整追溯 |
|
||||
|
||||
**Lite-Plan 三维确认**:
|
||||
1. **任务批准**:确认/修改/取消
|
||||
2. **执行方式**:Agent / 提供计划 / CLI工具(Gemini/Qwen/Codex)
|
||||
3. **代码审查**:否 / Claude / Gemini / Qwen / Codex
|
||||
|
||||
**示例**:
|
||||
```bash
|
||||
# 简单任务
|
||||
/workflow:lite-plan "添加用户头像上传功能"
|
||||
|
||||
# 需要代码探索
|
||||
/workflow:lite-plan -e "重构认证模块为OAuth2标准"
|
||||
|
||||
# 复杂项目
|
||||
/workflow:plan "实现完整的实时协作编辑系统"
|
||||
/workflow:action-plan-verify # 验证计划质量
|
||||
/workflow:execute
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5️⃣ **测试阶段 - 选择测试策略**
|
||||
|
||||
| 策略 | 命令 | 适用场景 |
|
||||
|------|------|---------|
|
||||
| **TDD模式** | `/workflow:tdd-plan` | 从头开始,测试驱动开发 |
|
||||
| **后置测试** | `/workflow:test-gen` | 代码已完成,补充测试 |
|
||||
| **测试修复** | `/workflow:test-cycle-execute` | 已有测试,需要修复失败用例 |
|
||||
|
||||
**示例**:
|
||||
```bash
|
||||
# TDD:先写测试,再实现
|
||||
/workflow:tdd-plan "用户认证模块"
|
||||
/workflow:execute # Red-Green-Refactor循环
|
||||
/workflow:tdd-verify # 验证TDD合规
|
||||
|
||||
# 后置测试:代码完成后补测试
|
||||
/workflow:test-gen WFS-user-auth-implementation
|
||||
/workflow:execute
|
||||
|
||||
# 测试修复:已有测试,但失败率高
|
||||
/workflow:test-cycle-execute --max-iterations 5
|
||||
# 自动迭代修复直到通过率≥95%
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 6️⃣ **审查阶段 - 选择审查类型**
|
||||
|
||||
| 类型 | 命令 | 关注点 |
|
||||
|------|------|--------|
|
||||
| **安全审查** | `/workflow:review --type security` | SQL注入、XSS、认证漏洞 |
|
||||
| **架构审查** | `/workflow:review --type architecture` | 设计模式、耦合度、可扩展性 |
|
||||
| **质量审查** | `/workflow:review --type quality` | 代码风格、复杂度、可维护性 |
|
||||
| **综合审查** | `/workflow:review` | 全方位检查 |
|
||||
|
||||
**示例**:
|
||||
```bash
|
||||
# 安全关键系统
|
||||
/workflow:review --type security
|
||||
|
||||
# 架构重构后
|
||||
/workflow:review --type architecture
|
||||
|
||||
# 日常开发
|
||||
/workflow:review --type quality
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 7️⃣ **CLI 工具协作模式 - 多模型智能协同**
|
||||
|
||||
本项目集成了三种 CLI 工具,支持灵活的串联、并行和混合执行方式:
|
||||
|
||||
| 工具 | 核心能力 | 上下文长度 | 适用场景 |
|
||||
|------|---------|-----------|---------|
|
||||
| **Gemini** | 深度分析、架构设计、规划 | 超长上下文 | 代码理解、执行流追踪、技术方案评估 |
|
||||
| **Qwen** | 代码审查、模式识别 | 超长上下文 | Gemini 备选、多维度分析 |
|
||||
| **Codex** | 精确代码撰写、Bug定位 | 标准上下文 | 功能实现、测试生成、代码重构 |
|
||||
|
||||
#### 📋 三种执行模式
|
||||
|
||||
**1. 串联执行(Serial Execution)** - 顺序依赖
|
||||
|
||||
适用场景:后续任务依赖前一任务的结果
|
||||
|
||||
```bash
|
||||
# 示例:分析后实现
|
||||
# Step 1: Gemini 分析架构
|
||||
使用 gemini 分析认证模块的架构设计,识别关键组件和数据流
|
||||
|
||||
# Step 2: Codex 基于分析结果实现
|
||||
让 codex 根据上述架构分析,实现 JWT 认证中间件
|
||||
```
|
||||
|
||||
**执行流程**:
|
||||
```
|
||||
Gemini 分析 → 输出架构报告 → Codex 读取报告 → 实现代码
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**2. 并行执行(Parallel Execution)** - 同时进行
|
||||
|
||||
适用场景:多个独立任务,无依赖关系
|
||||
|
||||
```bash
|
||||
# 示例:多维度分析
|
||||
用 gemini 分析认证模块的安全性,关注 JWT、密码存储、会话管理
|
||||
用 qwen 分析认证模块的性能瓶颈,识别慢查询和优化点
|
||||
让 codex 为认证模块生成单元测试,覆盖所有核心功能
|
||||
```
|
||||
|
||||
**执行流程**:
|
||||
```
|
||||
┌─ Gemini: 安全分析 ─┐
|
||||
并行 ───┼─ Qwen: 性能分析 ──┼─→ 汇总结果
|
||||
└─ Codex: 测试生成 ─┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**3. 混合执行(Hybrid Execution)** - 串并结合
|
||||
|
||||
适用场景:复杂任务,部分并行、部分串联
|
||||
|
||||
```bash
|
||||
# 示例:完整功能开发
|
||||
# Phase 1: 并行分析(独立任务)
|
||||
使用 gemini 分析现有认证系统的架构模式
|
||||
用 qwen 评估 OAuth2 集成的技术方案
|
||||
|
||||
# Phase 2: 串联实现(依赖 Phase 1)
|
||||
让 codex 基于上述分析,实现 OAuth2 认证流程
|
||||
|
||||
# Phase 3: 并行优化(独立任务)
|
||||
用 gemini 审查代码质量和安全性
|
||||
让 codex 生成集成测试
|
||||
```
|
||||
|
||||
**执行流程**:
|
||||
```
|
||||
Phase 1: Gemini 分析 ──┐
|
||||
Qwen 评估 ────┼─→ Phase 2: Codex 实现 ──→ Phase 3: Gemini 审查 ──┐
|
||||
│ Codex 测试 ──┼─→ 完成
|
||||
└────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 🎯 语义调用 vs 命令调用
|
||||
|
||||
**方式一:自然语言语义调用**(推荐)
|
||||
|
||||
```bash
|
||||
# 用户只需自然描述,Claude Code 自动调用工具
|
||||
"使用 gemini 分析这个模块的依赖关系"
|
||||
→ Claude Code 自动生成:cd src && gemini -p "分析依赖关系"
|
||||
|
||||
"让 codex 实现用户注册功能"
|
||||
→ Claude Code 自动生成:codex -C src/auth --full-auto exec "实现注册"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 🔗 语义调用与结果上下文(Memory)
|
||||
|
||||
通过自然语言描述,Claude 会自动选择并执行适当的 CLI 工具(Gemini/Qwen/Codex),分析结果作为后续操作的上下文。
|
||||
|
||||
**1. 语义调用示例**
|
||||
|
||||
```bash
|
||||
# 用自然语言描述需求,Claude 自动选择工具
|
||||
"使用 gemini 分析认证模块架构"
|
||||
→ Claude 自动执行 Gemini CLI 并保存结果
|
||||
|
||||
"让 qwen 评估性能瓶颈"
|
||||
→ Claude 自动执行 Qwen CLI 并保存结果
|
||||
|
||||
"用 codex 实现这个功能"
|
||||
→ Claude 自动执行 Codex CLI
|
||||
```
|
||||
|
||||
**2. 结果作为规划依据**
|
||||
|
||||
```bash
|
||||
# Step 1: 分析现状(生成 memory)
|
||||
使用 gemini 深度分析认证系统的架构、安全性和性能问题
|
||||
→ 输出:详细分析报告(自动保存)
|
||||
|
||||
# Step 2: 基于分析结果规划
|
||||
/workflow:plan "根据上述 Gemini 分析报告重构认证系统"
|
||||
→ 系统自动读取 .chat/ 中的分析报告作为上下文
|
||||
→ 生成精准的实施计划
|
||||
```
|
||||
|
||||
**3. 结果作为实现依据**
|
||||
|
||||
```bash
|
||||
# Step 1: 并行分析(生成多个 memory)
|
||||
使用 gemini 分析现有代码结构
|
||||
用 qwen 评估技术方案可行性
|
||||
→ 输出:多份分析报告
|
||||
|
||||
# Step 2: 基于所有分析结果实现
|
||||
让 codex 综合上述 Gemini 和 Qwen 的分析,实现最优方案
|
||||
→ Codex 自动读取前序分析结果
|
||||
→ 生成符合架构设计的代码
|
||||
```
|
||||
|
||||
**4. 跨会话引用**
|
||||
|
||||
```bash
|
||||
# 引用历史会话的分析结果
|
||||
"参考 WFS-2024-001 中的架构分析,用 codex 实现新的支付模块"
|
||||
→ Claude 自动加载指定会话的上下文
|
||||
→ 基于历史分析进行实现
|
||||
```
|
||||
|
||||
**5. Memory 更新循环**
|
||||
|
||||
```bash
|
||||
# 迭代优化流程
|
||||
使用 gemini 分析当前实现的问题
|
||||
→ 生成问题报告(memory)
|
||||
|
||||
让 codex 根据问题报告优化代码
|
||||
→ 实现改进(更新 memory)
|
||||
|
||||
用 qwen 验证优化效果
|
||||
→ 验证报告(追加 memory)
|
||||
|
||||
# 所有结果累积为完整的项目 memory
|
||||
→ 支持后续决策和实现
|
||||
```
|
||||
|
||||
**Memory 流转示例**:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Phase 1: 分析阶段(生成 Memory) │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Gemini 分析 → 架构分析报告 (.chat/analyze-001.md) │
|
||||
│ Qwen 评估 → 方案评估报告 (.chat/analyze-002.md) │
|
||||
└─────────────────────┬───────────────────────────────────────┘
|
||||
│ 作为 Memory 输入
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Phase 2: 规划阶段(使用 Memory) │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ /workflow:plan → 读取分析报告 → 生成实施计划 │
|
||||
│ (.task/IMPL-*.json) │
|
||||
└─────────────────────┬───────────────────────────────────────┘
|
||||
│ 作为 Memory 输入
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Phase 3: 实现阶段(使用 Memory) │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Codex 实现 → 读取计划+分析 → 生成代码 │
|
||||
│ (.chat/execute-001.md) │
|
||||
└─────────────────────┬───────────────────────────────────────┘
|
||||
│ 作为 Memory 输入
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Phase 4: 验证阶段(使用 Memory) │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Gemini 审查 → 读取实现代码 → 质量报告 │
|
||||
│ (.chat/review-001.md) │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
↓
|
||||
完整的项目 Memory 库
|
||||
支持未来所有决策和实现
|
||||
```
|
||||
|
||||
**最佳实践**:
|
||||
|
||||
1. **保持连续性**:在同一会话中执行相关任务,自动共享 memory
|
||||
2. **显式引用**:跨会话时明确引用历史分析(如"参考 WFS-xxx 的分析")
|
||||
3. **增量更新**:每次分析和实现都追加到 memory,形成完整的决策链
|
||||
4. **定期整理**:使用 `/memory:update-related` 将 CLI 结果整合到 CLAUDE.md
|
||||
5. **质量优先**:高质量的分析 memory 能显著提升后续实现质量
|
||||
|
||||
---
|
||||
|
||||
#### 🔄 工作流集成示例
|
||||
|
||||
**集成到 Lite 工作流**:
|
||||
|
||||
```bash
|
||||
# 1. 规划阶段:Gemini 分析
|
||||
/workflow:lite-plan -e "重构支付模块"
|
||||
→ 三维确认选择 "CLI 工具执行"
|
||||
|
||||
# 2. 执行阶段:选择执行方式
|
||||
# 选项 A: 串联执行
|
||||
→ "使用 gemini 分析支付流程" → "让 codex 重构代码"
|
||||
|
||||
# 选项 B: 并行分析 + 串联实现
|
||||
→ "用 gemini 分析架构" + "用 qwen 评估方案"
|
||||
→ "让 codex 基于分析结果重构"
|
||||
```
|
||||
|
||||
**集成到 Full 工作流**:
|
||||
|
||||
```bash
|
||||
# 1. 规划阶段
|
||||
/workflow:plan "实现分布式缓存"
|
||||
/workflow:action-plan-verify
|
||||
|
||||
# 2. 分析阶段(并行)
|
||||
使用 gemini 分析现有缓存架构
|
||||
用 qwen 评估 Redis 集群方案
|
||||
|
||||
# 3. 实现阶段(串联)
|
||||
/workflow:execute # 或使用 CLI
|
||||
让 codex 实现 Redis 集群集成
|
||||
|
||||
# 4. 测试阶段(并行)
|
||||
/workflow:test-gen WFS-cache
|
||||
→ 内部使用 gemini 分析 + codex 生成测试
|
||||
|
||||
# 5. 审查阶段(串联)
|
||||
用 gemini 审查代码质量
|
||||
/workflow:review --type architecture
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 💡 最佳实践
|
||||
|
||||
**何时使用串联**:
|
||||
- 实现依赖设计方案
|
||||
- 测试依赖代码实现
|
||||
- 优化依赖性能分析
|
||||
|
||||
**何时使用并行**:
|
||||
- 多维度分析(安全+性能+架构)
|
||||
- 多模块独立开发
|
||||
- 同时生成代码和测试
|
||||
|
||||
**何时使用混合**:
|
||||
- 复杂功能开发(分析→设计→实现→测试)
|
||||
- 大规模重构(评估→规划→执行→验证)
|
||||
- 技术栈迁移(调研→方案→实施→优化)
|
||||
|
||||
**工具选择建议**:
|
||||
1. **需要理解代码** → Gemini(首选)或 Qwen
|
||||
2. **需要编写代码** → Codex
|
||||
3. **复杂分析** → Gemini + Qwen 并行(互补验证)
|
||||
4. **精确实现** → Codex(基于 Gemini 分析)
|
||||
5. **快速原型** → 直接使用 Codex
|
||||
|
||||
---
|
||||
|
||||
## 🔄 典型场景完整流程
|
||||
|
||||
### 场景A:新功能开发(知道怎么做)
|
||||
|
||||
```bash
|
||||
# 1. 规划
|
||||
/workflow:plan "添加JWT认证和权限管理"
|
||||
|
||||
# 2. 验证计划
|
||||
/workflow:action-plan-verify
|
||||
|
||||
# 3. 执行
|
||||
/workflow:execute
|
||||
|
||||
# 4. 测试
|
||||
/workflow:test-gen WFS-jwt-auth
|
||||
/workflow:execute
|
||||
|
||||
# 5. 审查
|
||||
/workflow:review --type security
|
||||
|
||||
# 6. 完成
|
||||
/workflow:session:complete
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景B:新功能开发(不知道怎么做)
|
||||
|
||||
```bash
|
||||
# 1. 设计探索
|
||||
/workflow:brainstorm:auto-parallel "设计分布式缓存系统架构" --count 5
|
||||
|
||||
# 2. UI设计(如需要)
|
||||
/workflow:ui-design:explore-auto --prompt "缓存管理后台界面"
|
||||
/workflow:ui-design:design-sync --session WFS-xxx
|
||||
|
||||
# 3. 规划
|
||||
/workflow:plan
|
||||
|
||||
# 4. 验证
|
||||
/workflow:action-plan-verify
|
||||
|
||||
# 5. 执行
|
||||
/workflow:execute
|
||||
|
||||
# 6. TDD测试
|
||||
/workflow:tdd-plan "缓存系统核心模块"
|
||||
/workflow:execute
|
||||
|
||||
# 7. 审查
|
||||
/workflow:review --type architecture
|
||||
/workflow:review --type security
|
||||
|
||||
# 8. 完成
|
||||
/workflow:session:complete
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景C:快速功能开发(Lite工作流)
|
||||
|
||||
```bash
|
||||
# 1. 轻量规划(可能需要代码探索)
|
||||
/workflow:lite-plan -e "优化数据库查询性能"
|
||||
|
||||
# 2. 三维确认
|
||||
# - 确认任务
|
||||
# - 选择Agent执行
|
||||
# - 选择Gemini代码审查
|
||||
|
||||
# 3. 自动执行(/workflow:lite-execute内部调用)
|
||||
|
||||
# 4. 完成
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景D:Bug修复(标准流程)
|
||||
|
||||
```bash
|
||||
# 1. 标准Bug修复(自动适应严重性)
|
||||
/workflow:lite-fix "用户登录后token立即过期"
|
||||
|
||||
# 工作流自动执行:
|
||||
# → Phase 1: 诊断根因(JWT验证逻辑错误)
|
||||
# → Phase 2: 影响评估(风险评分 7.1 - High)
|
||||
# → Phase 3: 修复策略(快速补丁 vs 全面重构)
|
||||
# → Phase 4: 验证计划(集成测试)
|
||||
# → Phase 5: 用户确认(选择Agent执行)
|
||||
# → Phase 6: 执行修复 + 生成产物
|
||||
|
||||
# 2. 会话产物自动保存到:
|
||||
# .workflow/.lite-fix/user-login-token-expire-2025-01-23-14-30-45/
|
||||
# ├── diagnosis.json
|
||||
# ├── impact.json
|
||||
# ├── fix-plan.json
|
||||
# └── task.json
|
||||
|
||||
# 3. 完成
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景E:生产热修复(紧急模式)
|
||||
|
||||
```bash
|
||||
# 1. 热修复模式(最小化诊断)
|
||||
/workflow:lite-fix --hotfix "支付网关返回 5xx 错误"
|
||||
|
||||
# 工作流自动执行:
|
||||
# → Phase 1: 最小化诊断(已知问题)
|
||||
# → Phase 2: 假设 Critical(跳过详细评估)
|
||||
# → Phase 3: 单一手术式修复
|
||||
# → Phase 4: 烟雾测试(2-3分钟)
|
||||
# → Phase 5: 用户确认部署
|
||||
# → Phase 6: 执行 + 自动生成跟进任务
|
||||
|
||||
# 2. 自动生成跟进任务:
|
||||
# .workflow/.lite-fix/{session}/followup.json
|
||||
# ├── FOLLOWUP-001: 全面修复(3天内到期)
|
||||
# └── FOLLOWUP-002: 事后分析(1周内到期)
|
||||
|
||||
# 3. 完成
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎓 命令选择快速参考
|
||||
|
||||
### 按知识程度选择
|
||||
|
||||
| 你的情况 | 推荐命令 |
|
||||
|---------|---------|
|
||||
| 💭 不知道做什么 | `/workflow:brainstorm:auto-parallel "探索产品方向"` |
|
||||
| ❓ 知道做什么,不知道怎么做 | `/workflow:brainstorm:auto-parallel "设计技术方案"` |
|
||||
| ✅ 知道做什么,知道怎么做 | `/workflow:plan "具体实现描述"` |
|
||||
| ⚡ 简单明确的小任务 | `/workflow:lite-plan "任务描述"` |
|
||||
| 🐛 标准Bug修复 | `/workflow:lite-fix "bug描述"` |
|
||||
| 🔥 生产热修复 | `/workflow:lite-fix --hotfix "bug描述"` |
|
||||
|
||||
### 按项目阶段选择
|
||||
|
||||
| 阶段 | 命令 |
|
||||
|------|------|
|
||||
| 📋 **需求分析** | `/workflow:brainstorm:auto-parallel` |
|
||||
| 🏗️ **架构设计** | `/workflow:brainstorm:auto-parallel` |
|
||||
| 🎨 **UI设计** | `/workflow:ui-design:explore-auto` / `imitate-auto` |
|
||||
| 📝 **实现规划** | `/workflow:plan` / `/workflow:lite-plan` |
|
||||
| 🚀 **编码实现** | `/workflow:execute` / `/workflow:lite-execute` |
|
||||
| 🐛 **Bug修复** | `/workflow:lite-fix` (标准) / `--hotfix` (紧急) |
|
||||
| 🧪 **测试** | `/workflow:tdd-plan` / `/workflow:test-gen` |
|
||||
| 🔧 **测试修复** | `/workflow:test-cycle-execute` |
|
||||
| 📖 **代码审查** | `/workflow:review` |
|
||||
| ✅ **项目完成** | `/workflow:session:complete` |
|
||||
|
||||
### 按工作模式选择
|
||||
|
||||
| 模式 | 工作流 | 适用场景 |
|
||||
|------|--------|---------|
|
||||
| **🚀 敏捷快速** | Lite工作流 | 个人开发、快速迭代、原型验证 |
|
||||
| **🐛 Bug修复** | Lite-Fix工作流 | Bug诊断修复、生产热修复、测试修复循环 |
|
||||
| **📋 规范完整** | Full工作流 | 团队协作、企业项目、长期维护 |
|
||||
| **🧪 质量优先** | TDD工作流 | 核心模块、关键功能、高可靠性需求 |
|
||||
| **🎨 设计导向** | UI-Design工作流 | 前端项目、用户界面、设计系统 |
|
||||
|
||||
---
|
||||
|
||||
## 💡 专家建议
|
||||
|
||||
### 🔧 Issue 批量执行工作流 (v6.3.19 新增)
|
||||
|
||||
**适用场景**: 多个相关 Issue 需要批量规划和执行,支持长时间自主工作
|
||||
|
||||
| 阶段 | 命令 | 说明 |
|
||||
|------|------|------|
|
||||
| **规划** | `/issue:plan` | 为 Issue 生成解决方案和任务分解 |
|
||||
| **排队** | `/issue:queue` | 将解决方案形成执行队列,分析依赖关系 |
|
||||
| **执行** | `/issue:execute` | DAG 驱动的并行执行,每个解决方案一次提交 |
|
||||
|
||||
**执行器选择**:
|
||||
| 执行器 | 推荐场景 | 超时 |
|
||||
|--------|----------|------|
|
||||
| **Codex (推荐)** | 长时间自主编码,复杂多任务解决方案 | 2小时 |
|
||||
| Gemini | 需要大上下文分析的实现 | 1小时 |
|
||||
| Agent | Claude Code 子代理执行复杂任务 | 同步 |
|
||||
|
||||
**为什么推荐 Codex**:
|
||||
- ✅ **长时间自主工作**: 2小时超时,适合复杂解决方案
|
||||
- ✅ **完整写权限**: 自主创建、修改、删除文件
|
||||
- ✅ **后台执行**: 支持 `run_in_background: true`,不阻塞其他工作
|
||||
- ✅ **工作树隔离**: 配合 `--worktree` 实现真正并行执行
|
||||
|
||||
**示例工作流**:
|
||||
```bash
|
||||
# 1. 规划多个 Issue
|
||||
/issue:plan ISS-001 ISS-002 ISS-003
|
||||
|
||||
# 2. 形成执行队列
|
||||
/issue:queue
|
||||
|
||||
# 3. 使用 Codex 执行(推荐长时间任务)
|
||||
/issue:execute --worktree
|
||||
# → 选择 Codex 执行器
|
||||
# → 启用工作树隔离
|
||||
# → 并行批次自动执行
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### ✅ 最佳实践
|
||||
|
||||
1. **不确定时用头脑风暴**:宁可多花10分钟探索方案,也不要盲目实现后推翻重来
|
||||
2. **Bug修复优先用lite-fix**:自动适应严重性,完整产物跟踪,热修复自动生成跟进任务
|
||||
3. **复杂项目用Full工作流**:持久化计划便于团队协作和长期维护
|
||||
4. **小任务用Lite工作流**:快速完成,减少overhead
|
||||
5. **关键模块用TDD**:测试驱动开发保证质量
|
||||
6. **定期更新内存**:`/memory:update-related` 保持上下文准确
|
||||
7. **批量 Issue 用 issue 工作流**:`/issue:plan` → `/issue:queue` → `/issue:execute`,推荐 Codex 执行长时间任务
|
||||
|
||||
### ❌ 常见陷阱
|
||||
|
||||
1. **盲目跳过头脑风暴**:对不熟悉的技术领域也不探索,导致返工
|
||||
2. **过度使用头脑风暴**:简单功能也头脑风暴,浪费时间
|
||||
3. **忽略计划验证**:不运行 `/workflow:action-plan-verify`,导致执行时发现计划问题
|
||||
4. **Bug修复使用错误工具**:复杂Bug用lite-plan而非lite-fix,缺少诊断和影响评估
|
||||
5. **忽略测试**:不生成测试,代码质量无法保证
|
||||
6. **不完成会话**:不运行 `/workflow:session:complete`,会话状态混乱
|
||||
|
||||
---
|
||||
|
||||
## 🔗 相关文档
|
||||
|
||||
- [Getting Started Guide](GETTING_STARTED.md) - 快速入门教程
|
||||
- [Command Reference](COMMAND_REFERENCE.md) - 完整命令列表
|
||||
- [Architecture Overview](ARCHITECTURE.md) - 系统架构说明
|
||||
- [Examples](EXAMPLES.md) - 真实场景示例
|
||||
- [FAQ](FAQ.md) - 常见问题解答
|
||||
|
||||
---
|
||||
|
||||
**最后更新**: 2026-01-12
|
||||
**版本**: 6.3.19
|
||||
@@ -1,744 +0,0 @@
|
||||
# 🌳 CCW Workflow Decision Guide
|
||||
|
||||
This guide helps you choose the right commands and workflows for the complete software development lifecycle.
|
||||
|
||||
---
|
||||
|
||||
## 📊 Full Lifecycle Command Selection Flowchart
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start([Start New Feature/Project]) --> Q1{Know what to build?}
|
||||
|
||||
Q1 -->|No| Ideation[💡 Ideation Phase<br>Requirements Exploration]
|
||||
Q1 -->|Yes| Q2{Know how to build?}
|
||||
|
||||
Ideation --> BrainIdea[/ /workflow:brainstorm:auto-parallel<br>Explore product direction and positioning /]
|
||||
BrainIdea --> Q2
|
||||
|
||||
Q2 -->|No| Design[🏗️ Design Exploration<br>Architecture Solution Discovery]
|
||||
Q2 -->|Yes| Q3{Need UI design?}
|
||||
|
||||
Design --> BrainDesign[/ /workflow:brainstorm:auto-parallel<br>Explore technical solutions and architecture /]
|
||||
BrainDesign --> Q3
|
||||
|
||||
Q3 -->|Yes| UIDesign[🎨 UI Design Phase]
|
||||
Q3 -->|No| Q4{Task complexity?}
|
||||
|
||||
UIDesign --> Q3a{Have reference design?}
|
||||
Q3a -->|Yes| UIImitate[/ /workflow:ui-design:imitate-auto<br>--input local files/images /]
|
||||
Q3a -->|No| UIExplore[/ /workflow:ui-design:explore-auto<br>--prompt design description /]
|
||||
|
||||
UIImitate --> UISync[/ /workflow:ui-design:design-sync<br>Sync design system /]
|
||||
UIExplore --> UISync
|
||||
UISync --> Q4
|
||||
|
||||
Q4 -->|Simple & Quick| LitePlan[⚡ Lightweight Planning<br>/workflow:lite-plan]
|
||||
Q4 -->|Complex & Complete| FullPlan[📋 Full Planning<br>/workflow:plan]
|
||||
|
||||
LitePlan --> Q5{Need code exploration?}
|
||||
Q5 -->|Yes| LitePlanE[/ /workflow:lite-plan -e<br>task description /]
|
||||
Q5 -->|No| LitePlanNormal[/ /workflow:lite-plan<br>task description /]
|
||||
|
||||
LitePlanE --> LiteConfirm[Three-Dimensional Confirmation:<br>1️⃣ Task Approval<br>2️⃣ Execution Method<br>3️⃣ Code Review]
|
||||
LitePlanNormal --> LiteConfirm
|
||||
|
||||
LiteConfirm --> Q6{Choose execution method}
|
||||
Q6 -->|Agent| LiteAgent[/ /workflow:lite-execute<br>Using @code-developer /]
|
||||
Q6 -->|CLI Tools| LiteCLI[CLI Execution<br>Gemini/Qwen/Codex]
|
||||
Q6 -->|Plan Only| UserImpl[Manual User Implementation]
|
||||
|
||||
FullPlan --> PlanVerify{Verify plan quality?}
|
||||
PlanVerify -->|Yes| Verify[/ /workflow:action-plan-verify /]
|
||||
PlanVerify -->|No| Execute
|
||||
Verify --> Q7{Verification passed?}
|
||||
Q7 -->|No| FixPlan[Fix plan issues]
|
||||
Q7 -->|Yes| Execute
|
||||
FixPlan --> Execute
|
||||
|
||||
Execute[🚀 Execution Phase<br>/workflow:execute]
|
||||
LiteAgent --> TestDecision
|
||||
LiteCLI --> TestDecision
|
||||
UserImpl --> TestDecision
|
||||
Execute --> TestDecision
|
||||
|
||||
TestDecision{Need testing?}
|
||||
TestDecision -->|TDD Mode| TDD[/ /workflow:tdd-plan<br>Test-Driven Development /]
|
||||
TestDecision -->|Post-Implementation Testing| TestGen[/ /workflow:test-gen<br>Generate tests /]
|
||||
TestDecision -->|Existing Tests| TestCycle[/ /workflow:test-cycle-execute<br>Test-fix cycle /]
|
||||
TestDecision -->|No| Review
|
||||
|
||||
TDD --> TDDExecute[/ /workflow:execute<br>Red-Green-Refactor /]
|
||||
TDDExecute --> TDDVerify[/ /workflow:tdd-verify<br>Verify TDD compliance /]
|
||||
TDDVerify --> Review
|
||||
|
||||
TestGen --> TestExecute[/ /workflow:execute<br>Execute test tasks /]
|
||||
TestExecute --> TestResult{Tests passed?}
|
||||
TestResult -->|No| TestCycle
|
||||
TestResult -->|Yes| Review
|
||||
|
||||
TestCycle --> TestPass{Pass rate ≥95%?}
|
||||
TestPass -->|No, continue fixing| TestCycle
|
||||
TestPass -->|Yes| Review
|
||||
|
||||
Review[📝 Review Phase]
|
||||
Review --> Q8{Need specialized review?}
|
||||
Q8 -->|Security| SecurityReview[/ /workflow:review<br>--type security /]
|
||||
Q8 -->|Architecture| ArchReview[/ /workflow:review<br>--type architecture /]
|
||||
Q8 -->|Quality| QualityReview[/ /workflow:review<br>--type quality /]
|
||||
Q8 -->|Comprehensive| GeneralReview[/ /workflow:review<br>Comprehensive review /]
|
||||
Q8 -->|No| Complete
|
||||
|
||||
SecurityReview --> Complete
|
||||
ArchReview --> Complete
|
||||
QualityReview --> Complete
|
||||
GeneralReview --> Complete
|
||||
|
||||
Complete[✅ Completion Phase<br>/workflow:session:complete]
|
||||
Complete --> End([Project Complete])
|
||||
|
||||
style Start fill:#e1f5ff
|
||||
style End fill:#c8e6c9
|
||||
style BrainIdea fill:#fff9c4
|
||||
style BrainDesign fill:#fff9c4
|
||||
style UIImitate fill:#f8bbd0
|
||||
style UIExplore fill:#f8bbd0
|
||||
style LitePlan fill:#b3e5fc
|
||||
style FullPlan fill:#b3e5fc
|
||||
style Execute fill:#c5e1a5
|
||||
style TDD fill:#ffccbc
|
||||
style TestGen fill:#ffccbc
|
||||
style TestCycle fill:#ffccbc
|
||||
style Review fill:#d1c4e9
|
||||
style Complete fill:#c8e6c9
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Decision Point Explanations
|
||||
|
||||
### 1️⃣ **Ideation Phase - "Know what to build?"**
|
||||
|
||||
| Situation | Command | Description |
|
||||
|-----------|---------|-------------|
|
||||
| ❌ Uncertain about product direction | `/workflow:brainstorm:auto-parallel "Explore XXX domain product opportunities"` | Multi-role analysis with Product Manager, UX Expert, etc. |
|
||||
| ✅ Clear feature requirements | Skip to design phase | Already know what functionality to build |
|
||||
|
||||
**Examples**:
|
||||
```bash
|
||||
# Uncertain scenario: Want to build a collaboration tool, but unsure what exactly
|
||||
/workflow:brainstorm:auto-parallel "Explore team collaboration tool positioning and core features" --count 5
|
||||
|
||||
# Certain scenario: Building a real-time document collaboration editor (requirements clear)
|
||||
# Skip ideation, move to design phase
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2️⃣ **Design Phase - "Know how to build?"**
|
||||
|
||||
| Situation | Command | Description |
|
||||
|-----------|---------|-------------|
|
||||
| ❌ Don't know technical approach | `/workflow:brainstorm:auto-parallel "Design XXX system architecture"` | System Architect, Security Expert analyze technical solutions |
|
||||
| ✅ Clear implementation path | Skip to planning | Already know tech stack, architecture patterns |
|
||||
|
||||
**Examples**:
|
||||
```bash
|
||||
# Don't know how: Real-time collaboration conflict resolution? Which algorithm?
|
||||
/workflow:brainstorm:auto-parallel "Design conflict resolution mechanism for real-time collaborative document editing" --count 4
|
||||
|
||||
# Know how: Using Operational Transformation + WebSocket + Redis
|
||||
# Skip design exploration, go directly to planning
|
||||
/workflow:plan "Implement real-time collaborative editing using OT algorithm, WebSocket communication, Redis storage"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3️⃣ **UI Design Phase - "Need UI design?"**
|
||||
|
||||
| Situation | Command | Description |
|
||||
|-----------|---------|-------------|
|
||||
| 🎨 Have reference design | `/workflow:ui-design:imitate-auto --input "local files/images"` | Copy design from local reference files/images |
|
||||
| 🎨 Design from scratch | `/workflow:ui-design:explore-auto --prompt "description"` | Generate multiple design variants |
|
||||
| ⏭️ Backend/No UI | Skip | Pure backend API, CLI tools, etc. |
|
||||
|
||||
**Examples**:
|
||||
```bash
|
||||
# Have reference: Use local screenshots or code files
|
||||
/workflow:ui-design:imitate-auto --input "design-refs/*.png"
|
||||
# Or import from existing code
|
||||
/workflow:ui-design:imitate-auto --input "./src/components"
|
||||
|
||||
# No reference: Design from scratch
|
||||
/workflow:ui-design:explore-auto --prompt "Modern minimalist document collaboration editing interface" --style-variants 3
|
||||
|
||||
# Sync design to project
|
||||
/workflow:ui-design:design-sync --session WFS-xxx --selected-prototypes "v1,v2"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4️⃣ **Planning Phase - Choose Workflow Type**
|
||||
|
||||
| Workflow | Use Case | Characteristics |
|
||||
|----------|----------|-----------------|
|
||||
| `/workflow:lite-plan` | Quick tasks, small features | In-memory planning, three-dimensional confirmation, fast execution |
|
||||
| `/workflow:plan` | Complex projects, team collaboration | Persistent plans, quality gates, complete traceability |
|
||||
|
||||
**Lite-Plan Three-Dimensional Confirmation**:
|
||||
1. **Task Approval**: Confirm / Modify / Cancel
|
||||
2. **Execution Method**: Agent / Provide Plan / CLI Tools (Gemini/Qwen/Codex)
|
||||
3. **Code Review**: No / Claude / Gemini / Qwen / Codex
|
||||
|
||||
**Examples**:
|
||||
```bash
|
||||
# Simple task
|
||||
/workflow:lite-plan "Add user avatar upload feature"
|
||||
|
||||
# Need code exploration
|
||||
/workflow:lite-plan -e "Refactor authentication module to OAuth2 standard"
|
||||
|
||||
# Complex project
|
||||
/workflow:plan "Implement complete real-time collaborative editing system"
|
||||
/workflow:action-plan-verify # Verify plan quality
|
||||
/workflow:execute
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5️⃣ **Testing Phase - Choose Testing Strategy**
|
||||
|
||||
| Strategy | Command | Use Case |
|
||||
|----------|---------|----------|
|
||||
| **TDD Mode** | `/workflow:tdd-plan` | Starting from scratch, test-driven development |
|
||||
| **Post-Implementation Testing** | `/workflow:test-gen` | Code complete, add tests |
|
||||
| **Test Fixing** | `/workflow:test-cycle-execute` | Existing tests, need to fix failures |
|
||||
|
||||
**Examples**:
|
||||
```bash
|
||||
# TDD: Write tests first, then implement
|
||||
/workflow:tdd-plan "User authentication module"
|
||||
/workflow:execute # Red-Green-Refactor cycle
|
||||
/workflow:tdd-verify # Verify TDD compliance
|
||||
|
||||
# Post-implementation testing: Add tests after code complete
|
||||
/workflow:test-gen WFS-user-auth-implementation
|
||||
/workflow:execute
|
||||
|
||||
# Test fixing: Existing tests with high failure rate
|
||||
/workflow:test-cycle-execute --max-iterations 5
|
||||
# Auto-iterate fixes until pass rate ≥95%
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 6️⃣ **Review Phase - Choose Review Type**
|
||||
|
||||
| Type | Command | Focus |
|
||||
|------|---------|-------|
|
||||
| **Security Review** | `/workflow:review --type security` | SQL injection, XSS, authentication vulnerabilities |
|
||||
| **Architecture Review** | `/workflow:review --type architecture` | Design patterns, coupling, scalability |
|
||||
| **Quality Review** | `/workflow:review --type quality` | Code style, complexity, maintainability |
|
||||
| **Comprehensive Review** | `/workflow:review` | All-around inspection |
|
||||
|
||||
**Examples**:
|
||||
```bash
|
||||
# Security-critical system
|
||||
/workflow:review --type security
|
||||
|
||||
# After architecture refactoring
|
||||
/workflow:review --type architecture
|
||||
|
||||
# Daily development
|
||||
/workflow:review --type quality
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 7️⃣ **CLI Tools Collaboration Mode - Multi-Model Intelligent Coordination**
|
||||
|
||||
This project integrates three CLI tools supporting flexible serial, parallel, and hybrid execution:
|
||||
|
||||
| Tool | Core Capabilities | Context Length | Use Cases |
|
||||
|------|------------------|----------------|-----------|
|
||||
| **Gemini** | Deep analysis, architecture design, planning | Ultra-long context | Code understanding, execution flow tracing, technical solution evaluation |
|
||||
| **Qwen** | Code review, pattern recognition | Ultra-long context | Gemini alternative, multi-dimensional analysis |
|
||||
| **Codex** | Precise code writing, bug location | Standard context | Feature implementation, test generation, code refactoring |
|
||||
|
||||
#### 📋 Three Execution Modes
|
||||
|
||||
**1. Serial Execution** - Sequential dependency
|
||||
|
||||
Use case: Subsequent tasks depend on previous results
|
||||
|
||||
```bash
|
||||
# Example: Analyze then implement
|
||||
# Step 1: Gemini analyzes architecture
|
||||
Use gemini to analyze the authentication module's architecture design, identify key components and data flow
|
||||
|
||||
# Step 2: Codex implements based on analysis
|
||||
Have codex implement JWT authentication middleware based on the above architecture analysis
|
||||
```
|
||||
|
||||
**Execution flow**:
|
||||
```
|
||||
Gemini analysis → Output architecture report → Codex reads report → Implement code
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**2. Parallel Execution** - Concurrent processing
|
||||
|
||||
Use case: Multiple independent tasks with no dependencies
|
||||
|
||||
```bash
|
||||
# Example: Multi-dimensional analysis
|
||||
Use gemini to analyze authentication module security, focus on JWT, password storage, session management
|
||||
Use qwen to analyze authentication module performance bottlenecks, identify slow queries and optimization points
|
||||
Have codex generate unit tests for authentication module, covering all core features
|
||||
```
|
||||
|
||||
**Execution flow**:
|
||||
```
|
||||
┌─ Gemini: Security analysis ─┐
|
||||
Parallel ┼─ Qwen: Performance analysis ┼─→ Aggregate results
|
||||
└─ Codex: Test generation ────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**3. Hybrid Execution** - Combined serial and parallel
|
||||
|
||||
Use case: Complex tasks with both parallel and serial phases
|
||||
|
||||
```bash
|
||||
# Example: Complete feature development
|
||||
# Phase 1: Parallel analysis (independent tasks)
|
||||
Use gemini to analyze existing authentication system architecture patterns
|
||||
Use qwen to evaluate OAuth2 integration technical solutions
|
||||
|
||||
# Phase 2: Serial implementation (depends on Phase 1)
|
||||
Have codex implement OAuth2 authentication flow based on above analysis
|
||||
|
||||
# Phase 3: Parallel optimization (independent tasks)
|
||||
Use gemini to review code quality and security
|
||||
Have codex generate integration tests
|
||||
```
|
||||
|
||||
**Execution flow**:
|
||||
```
|
||||
Phase 1: Gemini analysis ──┐
|
||||
Qwen evaluation ──┼─→ Phase 2: Codex implementation ──→ Phase 3: Gemini review ──┐
|
||||
│ Codex tests ───┼─→ Complete
|
||||
└──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 🎯 Semantic Invocation vs Command Invocation
|
||||
|
||||
**Method 1: Natural Language Semantic Invocation** (Recommended)
|
||||
|
||||
```bash
|
||||
# Users simply describe naturally, Claude Code auto-invokes tools
|
||||
"Use gemini to analyze this module's dependencies"
|
||||
→ Claude Code auto-generates: cd src && gemini -p "Analyze dependencies"
|
||||
|
||||
"Have codex implement user registration feature"
|
||||
→ Claude Code auto-generates: codex -C src/auth --full-auto exec "Implement registration"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 🔗 Semantic Invocation & Results Context (Memory)
|
||||
|
||||
Through natural language, Claude automatically selects and executes appropriate CLI tools (Gemini/Qwen/Codex), with results serving as context for subsequent operations.
|
||||
|
||||
**1. Semantic Invocation Examples**
|
||||
|
||||
```bash
|
||||
# Describe needs in natural language, Claude auto-selects tools
|
||||
"Use gemini to analyze authentication module architecture"
|
||||
→ Claude auto-executes Gemini CLI and saves results
|
||||
|
||||
"Have qwen evaluate performance bottlenecks"
|
||||
→ Claude auto-executes Qwen CLI and saves results
|
||||
|
||||
"Use codex to implement this feature"
|
||||
→ Claude auto-executes Codex CLI
|
||||
```
|
||||
|
||||
**2. Results as Planning Basis**
|
||||
|
||||
```bash
|
||||
# Step 1: Analyze current state (generate memory)
|
||||
Use gemini to deeply analyze authentication system architecture, security, and performance issues
|
||||
→ Output: Detailed analysis report (auto-saved)
|
||||
|
||||
# Step 2: Plan based on analysis results
|
||||
/workflow:plan "Refactor authentication system based on above Gemini analysis report"
|
||||
→ System automatically reads analysis reports from .chat/ as context
|
||||
→ Generate precise implementation plan
|
||||
```
|
||||
|
||||
**3. Results as Implementation Basis**
|
||||
|
||||
```bash
|
||||
# Step 1: Parallel analysis (generate multiple memories)
|
||||
Use gemini to analyze existing code structure
|
||||
Use qwen to evaluate technical solution feasibility
|
||||
→ Output: Multiple analysis reports
|
||||
|
||||
# Step 2: Implement based on all analysis results
|
||||
Have codex synthesize above Gemini and Qwen analyses to implement optimal solution
|
||||
→ Codex automatically reads prior analysis results
|
||||
→ Generate code conforming to architecture design
|
||||
```
|
||||
|
||||
**4. Cross-Session References**
|
||||
|
||||
```bash
|
||||
# Reference historical session analysis results
|
||||
"Refer to architecture analysis in WFS-2024-001, use codex to implement new payment module"
|
||||
→ Claude automatically loads specified session context
|
||||
→ Implement based on historical analysis
|
||||
```
|
||||
|
||||
**5. Memory Update Loop**
|
||||
|
||||
```bash
|
||||
# Iterative optimization flow
|
||||
Use gemini to analyze problems in current implementation
|
||||
→ Generate problem report (memory)
|
||||
|
||||
Have codex optimize code based on problem report
|
||||
→ Implement improvements (update memory)
|
||||
|
||||
Use qwen to verify optimization effectiveness
|
||||
→ Verification report (append to memory)
|
||||
|
||||
# All results accumulate as complete project memory
|
||||
→ Support subsequent decisions and implementation
|
||||
```
|
||||
|
||||
**Memory Flow Example**:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Phase 1: Analysis Phase (Generate Memory) │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Gemini analysis → Architecture report (.chat/analyze-001.md)│
|
||||
│ Qwen evaluation → Solution report (.chat/analyze-002.md) │
|
||||
└─────────────────────┬───────────────────────────────────────┘
|
||||
│ As Memory Input
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Phase 2: Planning Phase (Use Memory) │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ /workflow:plan → Read analysis reports → Generate plan │
|
||||
│ (.task/IMPL-*.json) │
|
||||
└─────────────────────┬───────────────────────────────────────┘
|
||||
│ As Memory Input
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Phase 3: Implementation Phase (Use Memory) │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Codex implement → Read plan+analysis → Generate code │
|
||||
│ (.chat/execute-001.md) │
|
||||
└─────────────────────┬───────────────────────────────────────┘
|
||||
│ As Memory Input
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Phase 4: Verification Phase (Use Memory) │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Gemini review → Read implementation code → Quality report│
|
||||
│ (.chat/review-001.md) │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
↓
|
||||
Complete Project Memory Library
|
||||
Supporting All Future Decisions and Implementation
|
||||
```
|
||||
|
||||
**Best Practices**:
|
||||
|
||||
1. **Maintain Continuity**: Execute related tasks in the same session to automatically share memory
|
||||
2. **Explicit References**: Explicitly reference historical analyses when crossing sessions (e.g., "Refer to WFS-xxx analysis")
|
||||
3. **Incremental Updates**: Each analysis and implementation appends to memory, forming complete decision chain
|
||||
4. **Regular Organization**: Use `/memory:update-related` to consolidate CLI results into CLAUDE.md
|
||||
5. **Quality First**: High-quality analysis memory significantly improves subsequent implementation quality
|
||||
|
||||
---
|
||||
|
||||
#### 🔄 Workflow Integration Examples
|
||||
|
||||
**Integration with Lite Workflow**:
|
||||
|
||||
```bash
|
||||
# 1. Planning phase: Gemini analysis
|
||||
/workflow:lite-plan -e "Refactor payment module"
|
||||
→ Three-dimensional confirmation selects "CLI Tools execution"
|
||||
|
||||
# 2. Execution phase: Choose execution method
|
||||
# Option A: Serial execution
|
||||
→ "Use gemini to analyze payment flow" → "Have codex refactor code"
|
||||
|
||||
# Option B: Parallel analysis + Serial implementation
|
||||
→ "Use gemini to analyze architecture" + "Use qwen to evaluate solution"
|
||||
→ "Have codex refactor based on analysis results"
|
||||
```
|
||||
|
||||
**Integration with Full Workflow**:
|
||||
|
||||
```bash
|
||||
# 1. Planning phase
|
||||
/workflow:plan "Implement distributed cache"
|
||||
/workflow:action-plan-verify
|
||||
|
||||
# 2. Analysis phase (parallel)
|
||||
Use gemini to analyze existing cache architecture
|
||||
Use qwen to evaluate Redis cluster solution
|
||||
|
||||
# 3. Implementation phase (serial)
|
||||
/workflow:execute # Or use CLI
|
||||
Have codex implement Redis cluster integration
|
||||
|
||||
# 4. Testing phase (parallel)
|
||||
/workflow:test-gen WFS-cache
|
||||
→ Internally uses gemini analysis + codex test generation
|
||||
|
||||
# 5. Review phase (serial)
|
||||
Use gemini to review code quality
|
||||
/workflow:review --type architecture
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 💡 Best Practices
|
||||
|
||||
**When to use serial**:
|
||||
- Implementation depends on design solution
|
||||
- Testing depends on code implementation
|
||||
- Optimization depends on performance analysis
|
||||
|
||||
**When to use parallel**:
|
||||
- Multi-dimensional analysis (security + performance + architecture)
|
||||
- Multi-module independent development
|
||||
- Simultaneous code and test generation
|
||||
|
||||
**When to use hybrid**:
|
||||
- Complex feature development (analysis → design → implementation → testing)
|
||||
- Large-scale refactoring (evaluation → planning → execution → verification)
|
||||
- Tech stack migration (research → solution → implementation → optimization)
|
||||
|
||||
**Tool selection guidelines**:
|
||||
1. **Need to understand code** → Gemini (preferred) or Qwen
|
||||
2. **Need to write code** → Codex
|
||||
3. **Complex analysis** → Gemini + Qwen parallel (complementary verification)
|
||||
4. **Precise implementation** → Codex (based on Gemini analysis)
|
||||
5. **Quick prototype** → Direct Codex usage
|
||||
|
||||
---
|
||||
|
||||
## 🔄 Complete Flow for Typical Scenarios
|
||||
|
||||
### Scenario A: New Feature Development (Know How to Build)
|
||||
|
||||
```bash
|
||||
# 1. Planning
|
||||
/workflow:plan "Add JWT authentication and permission management"
|
||||
|
||||
# 2. Verify plan
|
||||
/workflow:action-plan-verify
|
||||
|
||||
# 3. Execute
|
||||
/workflow:execute
|
||||
|
||||
# 4. Testing
|
||||
/workflow:test-gen WFS-jwt-auth
|
||||
/workflow:execute
|
||||
|
||||
# 5. Review
|
||||
/workflow:review --type security
|
||||
|
||||
# 6. Complete
|
||||
/workflow:session:complete
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Scenario B: New Feature Development (Don't Know How to Build)
|
||||
|
||||
```bash
|
||||
# 1. Design exploration
|
||||
/workflow:brainstorm:auto-parallel "Design distributed cache system architecture" --count 5
|
||||
|
||||
# 2. UI design (if needed)
|
||||
/workflow:ui-design:explore-auto --prompt "Cache management dashboard interface"
|
||||
/workflow:ui-design:design-sync --session WFS-xxx
|
||||
|
||||
# 3. Planning
|
||||
/workflow:plan
|
||||
|
||||
# 4. Verification
|
||||
/workflow:action-plan-verify
|
||||
|
||||
# 5. Execution
|
||||
/workflow:execute
|
||||
|
||||
# 6. TDD testing
|
||||
/workflow:tdd-plan "Cache system core modules"
|
||||
/workflow:execute
|
||||
|
||||
# 7. Review
|
||||
/workflow:review --type architecture
|
||||
/workflow:review --type security
|
||||
|
||||
# 8. Complete
|
||||
/workflow:session:complete
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Scenario C: Quick Feature Development (Lite Workflow)
|
||||
|
||||
```bash
|
||||
# 1. Lightweight planning (may need code exploration)
|
||||
/workflow:lite-plan -e "Optimize database query performance"
|
||||
|
||||
# 2. Three-dimensional confirmation
|
||||
# - Confirm task
|
||||
# - Choose Agent execution
|
||||
# - Choose Gemini code review
|
||||
|
||||
# 3. Auto-execution (called internally by /workflow:lite-execute)
|
||||
|
||||
# 4. Complete
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Scenario D: Bug Fixing
|
||||
|
||||
```bash
|
||||
# 1. Intelligent bug fix workflow (includes diagnosis)
|
||||
/workflow:lite-fix "User login fails with token expired error"
|
||||
|
||||
# 2. Test fix (if needed)
|
||||
/workflow:test-cycle-execute
|
||||
|
||||
# 3. Complete
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎓 Quick Command Reference
|
||||
|
||||
### Choose by Knowledge Level
|
||||
|
||||
| Your Situation | Recommended Command |
|
||||
|----------------|---------------------|
|
||||
| 💭 Don't know what to build | `/workflow:brainstorm:auto-parallel "Explore product direction"` |
|
||||
| ❓ Know what, don't know how | `/workflow:brainstorm:auto-parallel "Design technical solution"` |
|
||||
| ✅ Know what and how | `/workflow:plan "Specific implementation description"` |
|
||||
| ⚡ Simple, clear small task | `/workflow:lite-plan "Task description"` |
|
||||
| 🐛 Bug fixing | `/workflow:lite-fix "bug description"` |
|
||||
|
||||
### Choose by Project Phase
|
||||
|
||||
| Phase | Command |
|
||||
|-------|---------|
|
||||
| 📋 **Requirements Analysis** | `/workflow:brainstorm:auto-parallel` |
|
||||
| 🏗️ **Architecture Design** | `/workflow:brainstorm:auto-parallel` |
|
||||
| 🎨 **UI Design** | `/workflow:ui-design:explore-auto` / `imitate-auto` |
|
||||
| 📝 **Implementation Planning** | `/workflow:plan` / `/workflow:lite-plan` |
|
||||
| 🚀 **Coding Implementation** | `/workflow:execute` / `/workflow:lite-execute` |
|
||||
| 🧪 **Testing** | `/workflow:tdd-plan` / `/workflow:test-gen` |
|
||||
| 🔧 **Test Fixing** | `/workflow:test-cycle-execute` |
|
||||
| 📖 **Code Review** | `/workflow:review` |
|
||||
| ✅ **Project Completion** | `/workflow:session:complete` |
|
||||
|
||||
### Choose by Work Mode
|
||||
|
||||
| Mode | Workflow | Use Case |
|
||||
|------|----------|----------|
|
||||
| **🚀 Agile & Fast** | Lite Workflow | Personal dev, rapid iteration, prototype validation |
|
||||
| **📋 Standard & Complete** | Full Workflow | Team collaboration, enterprise projects, long-term maintenance |
|
||||
| **🧪 Quality-First** | TDD Workflow | Core modules, critical features, high reliability requirements |
|
||||
| **🎨 Design-Driven** | UI-Design Workflow | Frontend projects, user interfaces, design systems |
|
||||
|
||||
---
|
||||
|
||||
## 💡 Expert Advice
|
||||
|
||||
### 🔧 Issue Batch Execution Workflow (v6.3.19 New)
|
||||
|
||||
**Use Case**: Multiple related issues requiring batch planning and execution, supports long-running autonomous work
|
||||
|
||||
| Phase | Command | Description |
|
||||
|-------|---------|-------------|
|
||||
| **Plan** | `/issue:plan` | Generate solutions and task breakdown for issues |
|
||||
| **Queue** | `/issue:queue` | Form execution queue, analyze dependencies |
|
||||
| **Execute** | `/issue:execute` | DAG-driven parallel execution, one commit per solution |
|
||||
|
||||
**Executor Selection**:
|
||||
| Executor | Recommended For | Timeout |
|
||||
|----------|-----------------|---------|
|
||||
| **Codex (Recommended)** | Long-running autonomous coding, complex multi-task solutions | 2 hours |
|
||||
| Gemini | Large context analysis and implementation | 1 hour |
|
||||
| Agent | Claude Code sub-agent for complex tasks | Sync |
|
||||
|
||||
**Why Codex is Recommended**:
|
||||
- ✅ **Long-running autonomous work**: 2-hour timeout, suitable for complex solutions
|
||||
- ✅ **Full write access**: Autonomously create, modify, delete files
|
||||
- ✅ **Background execution**: Supports `run_in_background: true`, non-blocking
|
||||
- ✅ **Worktree isolation**: Combined with `--worktree` for true parallel execution
|
||||
|
||||
**Example Workflow**:
|
||||
```bash
|
||||
# 1. Plan multiple issues
|
||||
/issue:plan ISS-001 ISS-002 ISS-003
|
||||
|
||||
# 2. Form execution queue
|
||||
/issue:queue
|
||||
|
||||
# 3. Execute with Codex (recommended for long tasks)
|
||||
/issue:execute --worktree
|
||||
# → Select Codex executor
|
||||
# → Enable worktree isolation
|
||||
# → Parallel batches auto-execute
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### ✅ Best Practices
|
||||
|
||||
1. **Use brainstorming when uncertain**: Better to spend 10 minutes exploring solutions than blindly implementing and rewriting
|
||||
2. **Use Full workflow for complex projects**: Persistent plans facilitate team collaboration and long-term maintenance
|
||||
3. **Use Lite workflow for small tasks**: Complete quickly, reduce overhead
|
||||
4. **Use TDD for critical modules**: Test-driven development ensures quality
|
||||
5. **Regularly update memory**: `/memory:update-related` keeps context accurate
|
||||
6. **Use issue workflow for batch issues**: `/issue:plan` → `/issue:queue` → `/issue:execute`, recommend Codex for long-running tasks
|
||||
|
||||
### ❌ Common Pitfalls
|
||||
|
||||
1. **Blindly skipping brainstorming**: Not exploring unfamiliar technical domains leads to rework
|
||||
2. **Overusing brainstorming**: Brainstorming even simple features wastes time
|
||||
3. **Ignoring plan verification**: Not running `/workflow:action-plan-verify` causes execution issues
|
||||
4. **Ignoring testing**: Not generating tests, code quality cannot be guaranteed
|
||||
5. **Not completing sessions**: Not running `/workflow:session:complete` causes session state confusion
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Related Documentation
|
||||
|
||||
- [Getting Started Guide](GETTING_STARTED.md) - Quick start tutorial
|
||||
- [Command Reference](COMMAND_REFERENCE.md) - Complete command list
|
||||
- [Architecture Overview](ARCHITECTURE.md) - System architecture explanation
|
||||
- [Examples](EXAMPLES.md) - Real-world scenario examples
|
||||
- [FAQ](FAQ.md) - Frequently asked questions
|
||||
|
||||
---
|
||||
|
||||
**Last Updated**: 2026-01-12
|
||||
**Version**: 6.3.19
|
||||
@@ -1,764 +0,0 @@
|
||||
# Claude Code Workflow (CCW) - Enhanced Workflow Diagrams
|
||||
|
||||
Based on comprehensive analysis of changes since v1.0, this document provides detailed mermaid diagrams illustrating the CCW architecture and execution flows.
|
||||
|
||||
## 1. System Architecture Overview
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "CLI Interface Layer"
|
||||
CLI[CLI Commands]
|
||||
GEM[Gemini CLI]
|
||||
COD[Codex CLI]
|
||||
WRAPPER[Gemini Wrapper]
|
||||
end
|
||||
|
||||
subgraph "Session Management"
|
||||
SESSION["workflow-session.json"]
|
||||
WDIR[".workflow/ directories"]
|
||||
ACTIVE_DIR[".workflow/active/"]
|
||||
ARCHIVE_DIR[".workflow/archives/"]
|
||||
end
|
||||
|
||||
subgraph "Task System"
|
||||
TASK_JSON[".task/impl-*.json"]
|
||||
HIERARCHY["Task Hierarchy (max 2 levels)"]
|
||||
STATUS["Task Status Management"]
|
||||
end
|
||||
|
||||
subgraph "Agent Orchestration"
|
||||
PLAN_AGENT[Conceptual Planning Agent]
|
||||
ACTION_AGENT[Action Planning Agent]
|
||||
CODE_AGENT[Code Developer]
|
||||
REVIEW_AGENT[Code Review Agent]
|
||||
MEMORY_AGENT[Memory Gemini Bridge]
|
||||
end
|
||||
|
||||
subgraph "Template System"
|
||||
ANALYSIS_TMPL[Analysis Templates]
|
||||
DEV_TMPL[Development Templates]
|
||||
PLAN_TMPL[Planning Templates]
|
||||
REVIEW_TMPL[Review Templates]
|
||||
end
|
||||
|
||||
subgraph "Output Generation"
|
||||
TODO_MD["TODO_LIST.md"]
|
||||
IMPL_MD["IMPL_PLAN.md"]
|
||||
SUMMARY[".summaries/"]
|
||||
CHAT[".chat/ sessions"]
|
||||
end
|
||||
|
||||
CLI --> GEM
|
||||
CLI --> COD
|
||||
CLI --> WRAPPER
|
||||
WRAPPER --> GEM
|
||||
|
||||
GEM --> PLAN_AGENT
|
||||
COD --> CODE_AGENT
|
||||
|
||||
PLAN_AGENT --> TASK_JSON
|
||||
ACTION_AGENT --> TASK_JSON
|
||||
CODE_AGENT --> TASK_JSON
|
||||
|
||||
TASK_JSON --> HIERARCHY
|
||||
HIERARCHY --> STATUS
|
||||
|
||||
SESSION --> MARKER
|
||||
MARKER --> WDIR
|
||||
|
||||
ANALYSIS_TMPL --> GEM
|
||||
DEV_TMPL --> COD
|
||||
PLAN_TMPL --> PLAN_AGENT
|
||||
|
||||
TASK_JSON --> TODO_MD
|
||||
TASK_JSON --> IMPL_MD
|
||||
STATUS --> SUMMARY
|
||||
GEM --> CHAT
|
||||
COD --> CHAT
|
||||
```
|
||||
|
||||
## 2. Command Execution Flow
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant User
|
||||
participant CLI
|
||||
participant GeminiWrapper as Gemini Wrapper
|
||||
participant GeminiCLI as Gemini CLI
|
||||
participant CodexCLI as Codex CLI
|
||||
participant Agent
|
||||
participant TaskSystem as Task System
|
||||
participant FileSystem as File System
|
||||
|
||||
User->>CLI: Command Request
|
||||
CLI->>CLI: Parse Command Type
|
||||
|
||||
alt Analysis Task
|
||||
CLI->>GeminiWrapper: Analysis Request
|
||||
GeminiWrapper->>GeminiWrapper: Check Token Limit
|
||||
GeminiWrapper->>GeminiWrapper: Set Approval Mode
|
||||
GeminiWrapper->>GeminiCLI: Execute Analysis
|
||||
GeminiCLI->>FileSystem: Read Codebase
|
||||
GeminiCLI->>Agent: Route to Planning Agent
|
||||
else Development Task
|
||||
CLI->>CodexCLI: Development Request
|
||||
CodexCLI->>Agent: Route to Code Agent
|
||||
end
|
||||
|
||||
Agent->>TaskSystem: Create/Update Tasks
|
||||
TaskSystem->>FileSystem: Save task JSON
|
||||
Agent->>Agent: Execute Task Logic
|
||||
Agent->>FileSystem: Apply Changes
|
||||
Agent->>TaskSystem: Update Task Status
|
||||
TaskSystem->>FileSystem: Regenerate Markdown Views
|
||||
Agent->>CLI: Return Results
|
||||
CLI->>User: Display Results
|
||||
```
|
||||
|
||||
## 3. Session Management Flow
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> SessionInit: Create New Session
|
||||
|
||||
SessionInit --> CreateStructure: mkdir .workflow/WFS-session-name
|
||||
CreateStructure --> CreateJSON: Create workflow-session.json
|
||||
CreateJSON --> CreatePlan: Create IMPL_PLAN.md
|
||||
CreatePlan --> CreateTasks: Create .task/ directory
|
||||
CreateTasks --> Active: Session Ready in .workflow/active/
|
||||
|
||||
Active --> Paused: Switch to Another Session
|
||||
Active --> Working: Execute Tasks
|
||||
Active --> Completed: All Tasks Done
|
||||
|
||||
Paused --> Active: Resume Session (set marker)
|
||||
Working --> Active: Task Complete
|
||||
Completed --> [*]: Archive Session
|
||||
|
||||
state Working {
|
||||
[*] --> TaskExecution
|
||||
TaskExecution --> AgentProcessing
|
||||
AgentProcessing --> TaskUpdate
|
||||
TaskUpdate --> [*]
|
||||
}
|
||||
```
|
||||
|
||||
## 4. Task Lifecycle Management
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph "Task Creation"
|
||||
REQ[Requirements] --> ANALYZE{Analysis Needed?}
|
||||
ANALYZE -->|Yes| GEMINI[Gemini Analysis]
|
||||
ANALYZE -->|No| DIRECT[Direct Creation]
|
||||
GEMINI --> CONTEXT[Extract Context]
|
||||
CONTEXT --> TASK_JSON[Create impl-*.json]
|
||||
DIRECT --> TASK_JSON
|
||||
end
|
||||
|
||||
subgraph "Task Hierarchy"
|
||||
TASK_JSON --> SIMPLE{<5 Tasks?}
|
||||
SIMPLE -->|Yes| SINGLE[Single Level: impl-N]
|
||||
SIMPLE -->|No| MULTI[Two Levels: impl-N.M]
|
||||
|
||||
SINGLE --> EXEC1[Direct Execution]
|
||||
MULTI --> DECOMP[Task Decomposition]
|
||||
DECOMP --> SUBTASKS[Create Subtasks]
|
||||
SUBTASKS --> EXEC2[Execute Leaf Tasks]
|
||||
end
|
||||
|
||||
subgraph "Task Execution"
|
||||
EXEC1 --> AGENT_SELECT[Select Agent]
|
||||
EXEC2 --> AGENT_SELECT
|
||||
AGENT_SELECT --> PLAN_A[Planning Agent]
|
||||
AGENT_SELECT --> CODE_A[Code Agent]
|
||||
AGENT_SELECT --> REVIEW_A[Review Agent]
|
||||
|
||||
PLAN_A --> UPDATE_STATUS[Update Status]
|
||||
CODE_A --> UPDATE_STATUS
|
||||
REVIEW_A --> UPDATE_STATUS
|
||||
|
||||
UPDATE_STATUS --> COMPLETED{All Done?}
|
||||
COMPLETED -->|No| NEXT_TASK[Next Task]
|
||||
COMPLETED -->|Yes| SUMMARY[Generate Summary]
|
||||
|
||||
NEXT_TASK --> AGENT_SELECT
|
||||
SUMMARY --> REGEN[Regenerate Views]
|
||||
REGEN --> DONE[Session Complete]
|
||||
end
|
||||
```
|
||||
|
||||
## 5. CLI Tool Integration Architecture
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "User Input Layer"
|
||||
CMD[User Commands]
|
||||
INTENT{Task Intent}
|
||||
end
|
||||
|
||||
subgraph "CLI Routing Layer"
|
||||
DISPATCHER[Command Dispatcher]
|
||||
GEMINI_ROUTE[Gemini Route]
|
||||
CODEX_ROUTE[Codex Route]
|
||||
end
|
||||
|
||||
subgraph "Gemini Analysis Path"
|
||||
WRAPPER[Gemini Wrapper]
|
||||
TOKEN_CHECK{Token Limit Check}
|
||||
APPROVAL_MODE[Set Approval Mode]
|
||||
GEMINI_EXEC[Gemini Execution]
|
||||
|
||||
subgraph "Gemini Features"
|
||||
ALL_FILES[--all-files Mode]
|
||||
PATTERNS["@{pattern} Mode"]
|
||||
TEMPLATES[Template Integration]
|
||||
end
|
||||
end
|
||||
|
||||
subgraph "Codex Development Path"
|
||||
CODEX_EXEC[Codex --full-auto exec]
|
||||
AUTO_DISCOVERY[Automatic File Discovery]
|
||||
CONTEXT_AWARE[Context-Aware Execution]
|
||||
|
||||
subgraph "Codex Features"
|
||||
EXPLICIT_PATTERNS["@{pattern} Control"]
|
||||
AUTONOMOUS[Full Autonomous Mode]
|
||||
TEMPLATE_INTEGRATION[Template Support]
|
||||
end
|
||||
end
|
||||
|
||||
subgraph "Backend Processing"
|
||||
FILE_ANALYSIS[File Analysis]
|
||||
CONTEXT_EXTRACTION[Context Extraction]
|
||||
CODE_GENERATION[Code Generation]
|
||||
VALIDATION[Validation & Testing]
|
||||
end
|
||||
|
||||
subgraph "Output Layer"
|
||||
RESULTS[Command Results]
|
||||
ARTIFACTS[Generated Artifacts]
|
||||
DOCUMENTATION[Updated Documentation]
|
||||
end
|
||||
|
||||
CMD --> INTENT
|
||||
INTENT -->|Analyze/Review/Understand| GEMINI_ROUTE
|
||||
INTENT -->|Implement/Build/Develop| CODEX_ROUTE
|
||||
|
||||
GEMINI_ROUTE --> WRAPPER
|
||||
WRAPPER --> TOKEN_CHECK
|
||||
TOKEN_CHECK -->|<2M tokens| ALL_FILES
|
||||
TOKEN_CHECK -->|>2M tokens| PATTERNS
|
||||
ALL_FILES --> APPROVAL_MODE
|
||||
PATTERNS --> APPROVAL_MODE
|
||||
APPROVAL_MODE --> GEMINI_EXEC
|
||||
GEMINI_EXEC --> TEMPLATES
|
||||
|
||||
CODEX_ROUTE --> CODEX_EXEC
|
||||
CODEX_EXEC --> AUTO_DISCOVERY
|
||||
AUTO_DISCOVERY --> CONTEXT_AWARE
|
||||
CONTEXT_AWARE --> AUTONOMOUS
|
||||
AUTONOMOUS --> TEMPLATE_INTEGRATION
|
||||
|
||||
TEMPLATES --> FILE_ANALYSIS
|
||||
TEMPLATE_INTEGRATION --> FILE_ANALYSIS
|
||||
|
||||
FILE_ANALYSIS --> CONTEXT_EXTRACTION
|
||||
CONTEXT_EXTRACTION --> CODE_GENERATION
|
||||
CODE_GENERATION --> VALIDATION
|
||||
VALIDATION --> RESULTS
|
||||
|
||||
RESULTS --> ARTIFACTS
|
||||
ARTIFACTS --> DOCUMENTATION
|
||||
```
|
||||
|
||||
## 6. Agent Workflow Coordination
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant TaskSystem as Task System
|
||||
participant PlanningAgent as Conceptual Planning
|
||||
participant ActionAgent as Action Planning
|
||||
participant CodeAgent as Code Developer
|
||||
participant ReviewAgent as Code Review
|
||||
participant MemoryAgent as Memory Bridge
|
||||
|
||||
TaskSystem->>PlanningAgent: New Complex Task
|
||||
PlanningAgent->>PlanningAgent: Strategic Analysis
|
||||
PlanningAgent->>ActionAgent: High-Level Plan
|
||||
|
||||
ActionAgent->>ActionAgent: Break Down into Tasks
|
||||
ActionAgent->>TaskSystem: Create Task Hierarchy
|
||||
TaskSystem->>TaskSystem: Generate impl-*.json files
|
||||
|
||||
loop For Each Implementation Task
|
||||
TaskSystem->>CodeAgent: Execute Task
|
||||
CodeAgent->>CodeAgent: Analyze Context
|
||||
CodeAgent->>CodeAgent: Generate Code
|
||||
CodeAgent->>TaskSystem: Update Status
|
||||
|
||||
TaskSystem->>ReviewAgent: Review Code
|
||||
ReviewAgent->>ReviewAgent: Quality Check
|
||||
ReviewAgent->>ReviewAgent: Test Validation
|
||||
ReviewAgent->>TaskSystem: Approval/Feedback
|
||||
|
||||
alt Code Needs Revision
|
||||
TaskSystem->>CodeAgent: Implement Changes
|
||||
else Code Approved
|
||||
TaskSystem->>TaskSystem: Mark Complete
|
||||
end
|
||||
end
|
||||
|
||||
TaskSystem->>MemoryAgent: Update Documentation
|
||||
MemoryAgent->>MemoryAgent: Generate Summaries
|
||||
MemoryAgent->>MemoryAgent: Update README/Docs
|
||||
MemoryAgent->>TaskSystem: Documentation Complete
|
||||
```
|
||||
|
||||
## 7. Template System Architecture
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph "Template Categories"
|
||||
ANALYSIS[Analysis Templates]
|
||||
DEVELOPMENT[Development Templates]
|
||||
PLANNING[Planning Templates]
|
||||
AUTOMATION[Automation Templates]
|
||||
REVIEW[Review Templates]
|
||||
INTEGRATION[Integration Templates]
|
||||
end
|
||||
|
||||
subgraph "Template Files"
|
||||
ANALYSIS --> PATTERN[pattern.txt]
|
||||
ANALYSIS --> ARCH[architecture.txt]
|
||||
ANALYSIS --> SECURITY[security.txt]
|
||||
|
||||
DEVELOPMENT --> FEATURE[feature.txt]
|
||||
DEVELOPMENT --> COMPONENT[component.txt]
|
||||
DEVELOPMENT --> REFACTOR[refactor.txt]
|
||||
|
||||
PLANNING --> BREAKDOWN[task-breakdown.txt]
|
||||
PLANNING --> MIGRATION[migration.txt]
|
||||
|
||||
AUTOMATION --> SCAFFOLD[scaffold.txt]
|
||||
AUTOMATION --> DEPLOY[deployment.txt]
|
||||
|
||||
REVIEW --> CODE_REVIEW[code-review.txt]
|
||||
|
||||
INTEGRATION --> API[api-design.txt]
|
||||
INTEGRATION --> DATABASE[database.txt]
|
||||
end
|
||||
|
||||
subgraph "Usage Integration"
|
||||
CLI_GEMINI[Gemini CLI]
|
||||
CLI_CODEX[Codex CLI]
|
||||
AGENTS[Agent System]
|
||||
|
||||
CLI_GEMINI --> ANALYSIS
|
||||
CLI_CODEX --> DEVELOPMENT
|
||||
CLI_CODEX --> AUTOMATION
|
||||
AGENTS --> PLANNING
|
||||
AGENTS --> REVIEW
|
||||
AGENTS --> INTEGRATION
|
||||
end
|
||||
|
||||
subgraph "Template Resolution"
|
||||
CAT_CMD["$(cat ~/.claude/workflows/cli-templates/prompts/[category]/[template].txt)"]
|
||||
MULTI_TMPL[Multi-Template Composition]
|
||||
HEREDOC[HEREDOC Support]
|
||||
end
|
||||
|
||||
PATTERN --> CAT_CMD
|
||||
FEATURE --> CAT_CMD
|
||||
BREAKDOWN --> CAT_CMD
|
||||
|
||||
CAT_CMD --> MULTI_TMPL
|
||||
MULTI_TMPL --> HEREDOC
|
||||
HEREDOC --> CLI_GEMINI
|
||||
HEREDOC --> CLI_CODEX
|
||||
```
|
||||
|
||||
## 8. Complexity Management System
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
INPUT[Task Input] --> ASSESS{Assess Complexity}
|
||||
|
||||
ASSESS -->|<5 tasks| SIMPLE[Simple Workflow]
|
||||
ASSESS -->|5-15 tasks| MEDIUM[Medium Workflow]
|
||||
ASSESS -->|>15 tasks| COMPLEX[Complex Workflow]
|
||||
|
||||
subgraph "Simple Workflow"
|
||||
SIMPLE_STRUCT[Single-Level: impl-N]
|
||||
SIMPLE_EXEC[Direct Execution]
|
||||
SIMPLE_MIN[Minimal Overhead]
|
||||
|
||||
SIMPLE --> SIMPLE_STRUCT
|
||||
SIMPLE_STRUCT --> SIMPLE_EXEC
|
||||
SIMPLE_EXEC --> SIMPLE_MIN
|
||||
end
|
||||
|
||||
subgraph "Medium Workflow"
|
||||
MEDIUM_STRUCT[Two-Level: impl-N.M]
|
||||
MEDIUM_PROGRESS[Progress Tracking]
|
||||
MEDIUM_DOCS[Auto Documentation]
|
||||
|
||||
MEDIUM --> MEDIUM_STRUCT
|
||||
MEDIUM_STRUCT --> MEDIUM_PROGRESS
|
||||
MEDIUM_PROGRESS --> MEDIUM_DOCS
|
||||
end
|
||||
|
||||
subgraph "Complex Workflow"
|
||||
COMPLEX_STRUCT[Deep Hierarchy]
|
||||
COMPLEX_ORCHESTRATION[Multi-Agent Orchestration]
|
||||
COMPLEX_COORD[Full Coordination]
|
||||
|
||||
COMPLEX --> COMPLEX_STRUCT
|
||||
COMPLEX_STRUCT --> COMPLEX_ORCHESTRATION
|
||||
COMPLEX_ORCHESTRATION --> COMPLEX_COORD
|
||||
end
|
||||
|
||||
subgraph "Dynamic Adaptation"
|
||||
RUNTIME_UPGRADE[Runtime Complexity Upgrade]
|
||||
SATURATION_CONTROL[Task Saturation Control]
|
||||
INTELLIGENT_DECOMP[Intelligent Decomposition]
|
||||
end
|
||||
|
||||
SIMPLE_MIN --> RUNTIME_UPGRADE
|
||||
MEDIUM_DOCS --> RUNTIME_UPGRADE
|
||||
COMPLEX_COORD --> SATURATION_CONTROL
|
||||
SATURATION_CONTROL --> INTELLIGENT_DECOMP
|
||||
```
|
||||
|
||||
## Key Architectural Changes Since v1.0
|
||||
|
||||
### Major Enhancements:
|
||||
1. **Intelligent Task Saturation Control**: Prevents overwhelming agents with too many simultaneous tasks
|
||||
2. **Gemini Wrapper Intelligence**: Automatic token management and approval mode detection
|
||||
3. **Path-Specific Analysis**: Task-specific path management for precise CLI analysis
|
||||
4. **Template System Integration**: Unified template system across all CLI tools
|
||||
5. **Session Context Passing**: Proper context management for agent coordination
|
||||
6. **On-Demand File Creation**: Improved performance through lazy initialization
|
||||
7. **Enhanced Error Handling**: Comprehensive error logging and recovery
|
||||
8. **Codex Full-Auto Mode**: Maximum autonomous development capabilities
|
||||
9. **Cross-Tool Template Compatibility**: Seamless template sharing between Gemini and Codex
|
||||
|
||||
### Performance Improvements:
|
||||
- 10-minute execution timeout for complex operations
|
||||
- Sub-millisecond JSON query performance
|
||||
- Atomic session switching with zero overhead
|
||||
- Intelligent file discovery reducing context switching
|
||||
|
||||
## 9. Complete Development Workflow (Workflow vs Task Commands)
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
START[Project Requirement] --> SESSION["/workflow:session:start"]
|
||||
|
||||
SESSION --> PLANNING_CHOICE{Choose Planning Method}
|
||||
|
||||
PLANNING_CHOICE -->|Collaborative Analysis| BRAINSTORM["/workflow:brainstorm"]
|
||||
PLANNING_CHOICE -->|AI-Powered Planning| GEMINI_PLAN["/gemini:mode:plan"]
|
||||
PLANNING_CHOICE -->|Document Analysis| DOC_ANALYSIS["Document Review"]
|
||||
PLANNING_CHOICE -->|Direct Planning| DIRECT_PLAN["/workflow:plan"]
|
||||
|
||||
subgraph "Brainstorming Path"
|
||||
BRAINSTORM --> SYNTHESIS["/workflow:brainstorm:synthesis"]
|
||||
SYNTHESIS --> BRAINSTORM_PLAN["/workflow:plan --from-brainstorming"]
|
||||
end
|
||||
|
||||
subgraph "Gemini Planning Path"
|
||||
GEMINI_PLAN --> GEMINI_ANALYSIS["Gemini Analysis Results"]
|
||||
GEMINI_ANALYSIS --> GEMINI_WF_PLAN["/workflow:plan"]
|
||||
end
|
||||
|
||||
subgraph "Document Analysis Path"
|
||||
DOC_ANALYSIS --> DOC_INSIGHTS["Extract Requirements"]
|
||||
DOC_INSIGHTS --> DOC_PLAN["/workflow:plan"]
|
||||
end
|
||||
|
||||
BRAINSTORM_PLAN --> WORKFLOW_EXECUTE
|
||||
GEMINI_WF_PLAN --> WORKFLOW_EXECUTE
|
||||
DOC_PLAN --> WORKFLOW_EXECUTE
|
||||
DIRECT_PLAN --> WORKFLOW_EXECUTE
|
||||
|
||||
WORKFLOW_EXECUTE["/workflow:execute"] --> TASK_CREATION["Auto-Create Tasks"]
|
||||
|
||||
subgraph "Task Management Layer"
|
||||
TASK_CREATION --> TASK_BREAKDOWN["/task:breakdown"]
|
||||
TASK_BREAKDOWN --> TASK_EXECUTE["/task:execute"]
|
||||
TASK_EXECUTE --> TASK_STATUS{Task Status}
|
||||
|
||||
TASK_STATUS -->|More Tasks| NEXT_TASK["/task:execute next"]
|
||||
TASK_STATUS -->|Blocked| TASK_REPLAN["/task:replan"]
|
||||
TASK_STATUS -->|Complete| TASK_DONE[Task Complete]
|
||||
|
||||
NEXT_TASK --> TASK_EXECUTE
|
||||
TASK_REPLAN --> TASK_EXECUTE
|
||||
end
|
||||
|
||||
TASK_DONE --> ALL_DONE{All Tasks Done?}
|
||||
ALL_DONE -->|No| TASK_EXECUTE
|
||||
ALL_DONE -->|Yes| WORKFLOW_REVIEW["/workflow:review"]
|
||||
|
||||
WORKFLOW_REVIEW --> FINAL_DOCS["/update-memory-related"]
|
||||
FINAL_DOCS --> PROJECT_COMPLETE[Project Complete]
|
||||
```
|
||||
|
||||
## 10. Workflow Command Relationships
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph "Session Management"
|
||||
WFS_START["/workflow:session:start"]
|
||||
WFS_RESUME["/workflow:session:resume"]
|
||||
WFS_LIST["/workflow:session:list"]
|
||||
WFS_COMPLETE["/workflow:session:complete"]
|
||||
|
||||
WFS_START --> WFS_LIST
|
||||
WFS_LIST --> WFS_RESUME
|
||||
WFS_RESUME --> WFS_COMPLETE
|
||||
end
|
||||
|
||||
subgraph "Planning Phase"
|
||||
WF_BRAINSTORM["/workflow:brainstorm"]
|
||||
WF_PLAN["/workflow:plan"]
|
||||
WF_PLAN_DEEP["/workflow:plan-deep"]
|
||||
|
||||
WF_BRAINSTORM --> WF_PLAN
|
||||
WF_PLAN_DEEP --> WF_PLAN
|
||||
end
|
||||
|
||||
subgraph "Execution Phase"
|
||||
WF_EXECUTE["/workflow:execute"]
|
||||
WF_REVIEW["/workflow:review"]
|
||||
|
||||
WF_EXECUTE --> WF_REVIEW
|
||||
end
|
||||
|
||||
subgraph "Task Layer"
|
||||
TASK_CREATE["/task:create"]
|
||||
TASK_BREAKDOWN["/task:breakdown"]
|
||||
TASK_EXECUTE["/task:execute"]
|
||||
TASK_REPLAN["/task:replan"]
|
||||
|
||||
TASK_CREATE --> TASK_BREAKDOWN
|
||||
TASK_BREAKDOWN --> TASK_EXECUTE
|
||||
TASK_EXECUTE --> TASK_REPLAN
|
||||
TASK_REPLAN --> TASK_EXECUTE
|
||||
end
|
||||
|
||||
WFS_START --> WF_BRAINSTORM
|
||||
WF_PLAN --> WF_EXECUTE
|
||||
WF_EXECUTE --> TASK_CREATE
|
||||
```
|
||||
|
||||
## 11. Planning Method Selection Flow
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
PROJECT_START[New Project/Feature] --> COMPLEXITY{Assess Complexity}
|
||||
|
||||
COMPLEXITY -->|Simple < 5 tasks| SIMPLE_FLOW
|
||||
COMPLEXITY -->|Medium 5-15 tasks| MEDIUM_FLOW
|
||||
COMPLEXITY -->|Complex > 15 tasks| COMPLEX_FLOW
|
||||
|
||||
subgraph SIMPLE_FLOW["Simple Workflow"]
|
||||
S_DIRECT["/workflow:plan (direct)"]
|
||||
S_EXECUTE["/workflow:execute --type=simple"]
|
||||
S_TASKS["Direct task execution"]
|
||||
|
||||
S_DIRECT --> S_EXECUTE --> S_TASKS
|
||||
end
|
||||
|
||||
subgraph MEDIUM_FLOW["Medium Workflow"]
|
||||
M_CHOICE{Planning Method?}
|
||||
M_GEMINI["/gemini:mode:plan"]
|
||||
M_DOCS["Review existing docs"]
|
||||
M_PLAN["/workflow:plan"]
|
||||
M_EXECUTE["/workflow:execute --type=medium"]
|
||||
M_BREAKDOWN["/task:breakdown"]
|
||||
|
||||
M_CHOICE -->|AI Planning| M_GEMINI
|
||||
M_CHOICE -->|Documentation| M_DOCS
|
||||
M_GEMINI --> M_PLAN
|
||||
M_DOCS --> M_PLAN
|
||||
M_PLAN --> M_EXECUTE
|
||||
M_EXECUTE --> M_BREAKDOWN
|
||||
end
|
||||
|
||||
subgraph COMPLEX_FLOW["Complex Workflow"]
|
||||
C_BRAINSTORM["/workflow:brainstorm --perspectives=multiple"]
|
||||
C_SYNTHESIS["/workflow:brainstorm:synthesis"]
|
||||
C_PLAN_DEEP["/workflow:plan-deep"]
|
||||
C_PLAN["/workflow:plan --from-brainstorming"]
|
||||
C_EXECUTE["/workflow:execute --type=complex"]
|
||||
C_TASKS["Hierarchical task management"]
|
||||
|
||||
C_BRAINSTORM --> C_SYNTHESIS
|
||||
C_SYNTHESIS --> C_PLAN_DEEP
|
||||
C_PLAN_DEEP --> C_PLAN
|
||||
C_PLAN --> C_EXECUTE
|
||||
C_EXECUTE --> C_TASKS
|
||||
end
|
||||
```
|
||||
|
||||
## 12. Brainstorming to Execution Pipeline
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant User
|
||||
participant WF as Workflow System
|
||||
participant BS as Brainstorm Agents
|
||||
participant PLAN as Planning Agent
|
||||
participant TASK as Task System
|
||||
participant EXEC as Execution Agents
|
||||
|
||||
User->>WF: /workflow:session:start "Feature Name"
|
||||
WF->>User: Session Created
|
||||
|
||||
User->>BS: /workflow:brainstorm "topic" --perspectives=system-architect,security-expert
|
||||
BS->>BS: Multiple Agent Perspectives
|
||||
BS->>WF: Generate Ideas & Analysis
|
||||
|
||||
User->>BS: /workflow:brainstorm:synthesis
|
||||
BS->>WF: Consolidated Recommendations
|
||||
|
||||
User->>PLAN: /workflow:plan --from-brainstorming
|
||||
PLAN->>PLAN: Convert Ideas to Implementation Plan
|
||||
PLAN->>WF: Generate IMPL_PLAN.md + TODO_LIST.md
|
||||
|
||||
User->>WF: /workflow:execute --type=complex
|
||||
WF->>TASK: Auto-create task hierarchy
|
||||
TASK->>TASK: Create impl-*.json files
|
||||
|
||||
loop Task Execution
|
||||
User->>EXEC: /task:execute impl-1
|
||||
EXEC->>EXEC: Execute Implementation
|
||||
EXEC->>TASK: Update task status
|
||||
|
||||
alt Task needs breakdown
|
||||
EXEC->>TASK: /task:breakdown impl-1
|
||||
TASK->>TASK: Create subtasks
|
||||
else Task blocked
|
||||
EXEC->>TASK: /task:replan impl-1
|
||||
TASK->>TASK: Adjust task plan
|
||||
end
|
||||
end
|
||||
|
||||
User->>WF: /workflow:review
|
||||
WF->>User: Quality validation complete
|
||||
|
||||
User->>WF: /update-memory-related
|
||||
WF->>User: Documentation updated
|
||||
```
|
||||
|
||||
## 13. Task Command Hierarchy and Dependencies
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "Workflow Layer"
|
||||
WF_PLAN["/workflow:plan"]
|
||||
WF_EXECUTE["/workflow:execute"]
|
||||
WF_REVIEW["/workflow:review"]
|
||||
end
|
||||
|
||||
subgraph "Task Management Layer"
|
||||
TASK_CREATE["/task:create"]
|
||||
TASK_BREAKDOWN["/task:breakdown"]
|
||||
TASK_REPLAN["/task:replan"]
|
||||
end
|
||||
|
||||
subgraph "Task Execution Layer"
|
||||
TASK_EXECUTE["/task:execute"]
|
||||
|
||||
subgraph "Execution Modes"
|
||||
MANUAL["--mode=guided"]
|
||||
AUTO["--mode=auto"]
|
||||
end
|
||||
|
||||
subgraph "Agent Selection"
|
||||
CODE_AGENT["--agent=code-developer"]
|
||||
PLAN_AGENT["--agent=planning-agent"]
|
||||
REVIEW_AGENT["--agent=code-review-test-agent"]
|
||||
end
|
||||
end
|
||||
|
||||
subgraph "Task Hierarchy"
|
||||
MAIN_TASK["impl-1 (Main Task)"]
|
||||
SUB_TASK1["impl-1.1 (Subtask)"]
|
||||
SUB_TASK2["impl-1.2 (Subtask)"]
|
||||
|
||||
MAIN_TASK --> SUB_TASK1
|
||||
MAIN_TASK --> SUB_TASK2
|
||||
end
|
||||
|
||||
WF_PLAN --> TASK_CREATE
|
||||
WF_EXECUTE --> TASK_CREATE
|
||||
TASK_CREATE --> TASK_BREAKDOWN
|
||||
TASK_BREAKDOWN --> MAIN_TASK
|
||||
MAIN_TASK --> SUB_TASK1
|
||||
MAIN_TASK --> SUB_TASK2
|
||||
|
||||
SUB_TASK1 --> TASK_EXECUTE
|
||||
SUB_TASK2 --> TASK_EXECUTE
|
||||
|
||||
TASK_EXECUTE --> MANUAL
|
||||
TASK_EXECUTE --> AUTO
|
||||
TASK_EXECUTE --> CODE_AGENT
|
||||
TASK_EXECUTE --> PLAN_AGENT
|
||||
TASK_EXECUTE --> REVIEW_AGENT
|
||||
|
||||
TASK_EXECUTE --> TASK_REPLAN
|
||||
TASK_REPLAN --> TASK_BREAKDOWN
|
||||
```
|
||||
|
||||
## 14. CLI Integration in Workflow Context
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph "Planning Phase CLIs"
|
||||
GEMINI_PLAN["/gemini:mode:plan"]
|
||||
GEMINI_ANALYZE["/gemini:analyze"]
|
||||
CODEX_PLAN["/codex:mode:plan"]
|
||||
end
|
||||
|
||||
subgraph "Execution Phase CLIs"
|
||||
GEMINI_EXEC["/gemini:execute"]
|
||||
CODEX_AUTO["/codex:mode:auto"]
|
||||
CODEX_EXEC["/codex:execute"]
|
||||
end
|
||||
|
||||
subgraph "Workflow Commands"
|
||||
WF_BRAINSTORM["/workflow:brainstorm"]
|
||||
WF_PLAN["/workflow:plan"]
|
||||
WF_EXECUTE["/workflow:execute"]
|
||||
end
|
||||
|
||||
subgraph "Task Commands"
|
||||
TASK_CREATE["/task:create"]
|
||||
TASK_EXECUTE["/task:execute"]
|
||||
end
|
||||
|
||||
subgraph "Context Integration"
|
||||
UPDATE_MEMORY["/update-memory-related"]
|
||||
CONTEXT["/context"]
|
||||
end
|
||||
|
||||
GEMINI_PLAN --> WF_PLAN
|
||||
GEMINI_ANALYZE --> WF_BRAINSTORM
|
||||
CODEX_PLAN --> WF_PLAN
|
||||
|
||||
WF_PLAN --> TASK_CREATE
|
||||
WF_EXECUTE --> TASK_EXECUTE
|
||||
|
||||
TASK_EXECUTE --> GEMINI_EXEC
|
||||
TASK_EXECUTE --> CODEX_AUTO
|
||||
TASK_EXECUTE --> CODEX_EXEC
|
||||
|
||||
CODEX_AUTO --> UPDATE_MEMORY
|
||||
GEMINI_EXEC --> CONTEXT
|
||||
|
||||
UPDATE_MEMORY --> WF_EXECUTE
|
||||
CONTEXT --> TASK_EXECUTE
|
||||
```
|
||||
731
WORKFLOW_GUIDE.md
Normal file
731
WORKFLOW_GUIDE.md
Normal file
@@ -0,0 +1,731 @@
|
||||
# CCW Workflow Difficulty Guide
|
||||
|
||||
## Overview
|
||||
|
||||
CCW provides two workflow systems: **Main Workflow** and **Issue Workflow**, working together to cover the complete software development lifecycle.
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Main Workflow │
|
||||
│ │
|
||||
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
|
||||
│ │ Level 1 │ → │ Level 2 │ → │ Level 3 │ → │ Level 4 │ │
|
||||
│ │ Rapid │ │ Lightweight │ │ Standard │ │ Brainstorm │ │
|
||||
│ │ │ │ │ │ │ │ │ │
|
||||
│ │ lite-lite- │ │ lite-plan │ │ plan │ │ brainstorm │ │
|
||||
│ │ lite │ │ lite-fix │ │ tdd-plan │ │ :auto- │ │
|
||||
│ │ │ │ multi-cli- │ │ test-fix- │ │ parallel │ │
|
||||
│ │ │ │ plan │ │ gen │ │ ↓ │ │
|
||||
│ │ │ │ │ │ │ │ plan │ │
|
||||
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
|
||||
│ │
|
||||
│ Complexity: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━▶ │
|
||||
│ Low High │
|
||||
└─────────────────────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
│ After development
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Issue Workflow │
|
||||
│ │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ Accumulate │ → │ Plan │ → │ Execute │ │
|
||||
│ │ Discover & │ │ Batch │ │ Parallel │ │
|
||||
│ │ Collect │ │ Planning │ │ Execution │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
│ │
|
||||
│ Supplementary role: Maintain main branch stability, worktree isolation │
|
||||
└─────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Main Workflow vs Issue Workflow
|
||||
|
||||
### Design Philosophy
|
||||
|
||||
| Aspect | Main Workflow | Issue Workflow |
|
||||
|--------|---------------|----------------|
|
||||
| **Purpose** | Primary development cycle | Post-development maintenance |
|
||||
| **Timing** | Feature development phase | After main workflow completes |
|
||||
| **Scope** | Complete feature implementation | Targeted fixes/enhancements |
|
||||
| **Parallelism** | Dependency analysis → Agent parallel | Worktree isolation (optional) |
|
||||
| **Branch Model** | Work on current branch | Can use isolated worktree |
|
||||
|
||||
### Why Main Workflow Doesn't Use Worktree Automatically?
|
||||
|
||||
**Dependency analysis already solves parallelism**:
|
||||
|
||||
1. Planning phase (`/workflow:plan`) performs dependency analysis
|
||||
2. Automatically identifies task dependencies and critical paths
|
||||
3. Partitions into **parallel groups** (independent tasks) and **serial chains** (dependent tasks)
|
||||
4. Agents execute independent tasks in parallel without filesystem isolation
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ Dependency Analysis │
|
||||
│ │
|
||||
│ Task A ─────┐ │
|
||||
│ ├──→ Parallel Group 1 ──→ Agent 1 │
|
||||
│ Task B ─────┘ │
|
||||
│ │
|
||||
│ Task C ────────→ Serial Chain ──────→ Agent 2 │
|
||||
│ ↓ │
|
||||
│ Task D ────────→ │
|
||||
│ │
|
||||
│ Same worktree, parallelism through scheduling │
|
||||
└─────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Why Issue Workflow Supports Worktree?
|
||||
|
||||
Issue Workflow serves as a **supplementary mechanism** with different scenarios:
|
||||
|
||||
1. Main development complete, merged to `main`
|
||||
2. Issues discovered requiring fixes
|
||||
3. Need to fix without affecting current development
|
||||
4. Worktree isolation keeps main branch stable
|
||||
|
||||
```
|
||||
Development → Release → Discover Issue → Worktree Fix → Merge back
|
||||
↑ │
|
||||
└────────────── Continue new feature ←─────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Level 1: Rapid Execution (lite-lite-lite)
|
||||
|
||||
**Simplest - Single CLI analysis to execution, zero artifacts**
|
||||
|
||||
### Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Complexity** | Low |
|
||||
| **Artifacts** | None |
|
||||
| **State** | Stateless |
|
||||
| **CLI Selection** | Auto-analyze task type |
|
||||
| **Iteration** | Via AskUser |
|
||||
|
||||
### Flow
|
||||
|
||||
```
|
||||
User Input → Clarification → Auto-select CLI → Parallel Analysis → Show Results → Direct Execute
|
||||
↓
|
||||
No intermediate files
|
||||
```
|
||||
|
||||
### Command
|
||||
|
||||
```bash
|
||||
/workflow:lite-lite-lite
|
||||
# Or CCW auto-selects for simple tasks
|
||||
```
|
||||
|
||||
### Use Cases
|
||||
|
||||
- ✅ Quick fixes
|
||||
- ✅ Simple feature additions
|
||||
- ✅ Configuration adjustments
|
||||
- ✅ Small-scope renaming
|
||||
- ❌ Multi-module changes
|
||||
- ❌ Need persistent records
|
||||
|
||||
---
|
||||
|
||||
## Level 2: Lightweight Planning
|
||||
|
||||
**Lightweight - In-memory planning or single analysis, fast iteration**
|
||||
|
||||
### Included Workflows
|
||||
|
||||
| Workflow | Purpose | Artifacts | Execution |
|
||||
|----------|---------|-----------|-----------|
|
||||
| `lite-plan` | Clear requirement development | memory://plan | → `lite-execute` |
|
||||
| `lite-fix` | Bug diagnosis and fix | `.workflow/.lite-fix/` | → `lite-execute` |
|
||||
| `multi-cli-plan` | Multi-perspective tasks | `.workflow/.multi-cli-plan/` | → `lite-execute` |
|
||||
|
||||
### Common Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Complexity** | Low-Medium |
|
||||
| **State** | Session-scoped / Lightweight persistence |
|
||||
| **Execution** | Unified via `lite-execute` |
|
||||
| **Use Case** | Relatively clear requirements |
|
||||
|
||||
---
|
||||
|
||||
### 2.1 lite-plan → lite-execute
|
||||
|
||||
**In-memory planning + Direct execution**
|
||||
|
||||
```
|
||||
┌─────────────────┐ ┌─────────────────┐
|
||||
│ lite-plan │ ──→ │ lite-execute │
|
||||
│ In-memory plan │ │ Direct execute │
|
||||
└─────────────────┘ └─────────────────┘
|
||||
```
|
||||
|
||||
```bash
|
||||
/workflow:lite-plan # Planning
|
||||
/workflow:lite-execute # Execution
|
||||
```
|
||||
|
||||
**Use Case**: Clear single-module features
|
||||
|
||||
---
|
||||
|
||||
### 2.2 lite-fix
|
||||
|
||||
**Intelligent diagnosis + Fix (5 phases)**
|
||||
|
||||
```
|
||||
Phase 1: Bug Analysis & Diagnosis
|
||||
├─ Intelligent severity pre-assessment (Low/Medium/High/Critical)
|
||||
└─ Parallel cli-explore-agent diagnosis (1-4 angles)
|
||||
|
||||
Phase 2: Clarification (optional)
|
||||
└─ Aggregate clarification needs, AskUserQuestion
|
||||
|
||||
Phase 3: Fix Planning
|
||||
├─ Low/Medium → Claude direct planning
|
||||
└─ High/Critical → cli-lite-planning-agent
|
||||
|
||||
Phase 4: Confirmation & Selection
|
||||
└─ User confirms execution method
|
||||
|
||||
Phase 5: Execute
|
||||
└─ SlashCommand("/workflow:lite-execute --in-memory --mode bugfix")
|
||||
```
|
||||
|
||||
```bash
|
||||
/workflow:lite-fix # Standard fix
|
||||
/workflow:lite-fix --hotfix # Emergency hotfix (skip diagnosis)
|
||||
```
|
||||
|
||||
**Artifacts**: `.workflow/.lite-fix/{bug-slug}-{date}/`
|
||||
- `diagnosis-{angle}.json` (1-4 diagnosis files)
|
||||
- `diagnoses-manifest.json`
|
||||
- `fix-plan.json`
|
||||
|
||||
**Use Case**: Bug diagnosis, production emergencies
|
||||
|
||||
---
|
||||
|
||||
### 2.3 multi-cli-plan → lite-execute
|
||||
|
||||
**Multi-CLI collaborative analysis + Consensus convergence (5 phases)**
|
||||
|
||||
```
|
||||
Phase 1: Context Gathering
|
||||
└─ ACE semantic search, build context package
|
||||
|
||||
Phase 2: Multi-CLI Discussion (iterative)
|
||||
├─ cli-discuss-agent executes Gemini + Codex + Claude
|
||||
├─ Cross-verification, synthesize solutions
|
||||
└─ Loop until convergence or max rounds
|
||||
|
||||
Phase 3: Present Options
|
||||
└─ Display solutions with trade-offs
|
||||
|
||||
Phase 4: User Decision
|
||||
└─ User selects solution
|
||||
|
||||
Phase 5: Plan Generation
|
||||
├─ cli-lite-planning-agent generates plan
|
||||
└─ → lite-execute
|
||||
```
|
||||
|
||||
```bash
|
||||
/workflow:multi-cli-plan "task description" # Multi-CLI collaborative planning
|
||||
/workflow:lite-execute # Execute selected solution
|
||||
```
|
||||
|
||||
**Artifacts**: `.workflow/.multi-cli-plan/{MCP-task-slug-date}/`
|
||||
- `rounds/*/synthesis.json` (per-round analysis)
|
||||
- `context-package.json`
|
||||
- `IMPL_PLAN.md` + `plan.json`
|
||||
|
||||
**vs lite-plan comparison**:
|
||||
|
||||
| Aspect | multi-cli-plan | lite-plan |
|
||||
|--------|---------------|-----------|
|
||||
| **Context** | ACE semantic search | Manual file patterns |
|
||||
| **Analysis** | Multi-CLI cross-verification | Single planning |
|
||||
| **Iteration** | Multiple rounds until convergence | Single round |
|
||||
| **Confidence** | High (consensus-driven) | Medium (single perspective) |
|
||||
|
||||
**Use Case**: Multi-perspective analysis, technology selection, solution comparison
|
||||
|
||||
---
|
||||
|
||||
## Level 3: Standard Planning
|
||||
|
||||
**Standard - Complete planning + Persistent Session + Verification**
|
||||
|
||||
### Included Workflows
|
||||
|
||||
| Workflow | Purpose | Phases | Artifact Location |
|
||||
|----------|---------|--------|-------------------|
|
||||
| `plan` | Complex feature development | 5 phases | `.workflow/active/{session}/` |
|
||||
| `tdd-plan` | Test-driven development | 6 phases | `.workflow/active/{session}/` |
|
||||
| `test-fix-gen` | Test fix generation | 5 phases | `.workflow/active/WFS-test-{session}/` |
|
||||
|
||||
### Common Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Complexity** | Medium-High |
|
||||
| **Artifacts** | Persistent files (`.workflow/active/{session}/`) |
|
||||
| **State** | Full session management |
|
||||
| **Verification** | Built-in verification steps |
|
||||
| **Execution** | `/workflow:execute` |
|
||||
| **Use Case** | Multi-module, traceable tasks |
|
||||
|
||||
---
|
||||
|
||||
### 3.1 plan → verify → execute
|
||||
|
||||
**5-phase complete planning workflow**
|
||||
|
||||
```
|
||||
Phase 1: Session Discovery
|
||||
└─ /workflow:session:start --auto
|
||||
|
||||
Phase 2: Context Gathering
|
||||
└─ /workflow:tools:context-gather
|
||||
└─ Returns context-package.json + conflict_risk
|
||||
|
||||
Phase 3: Conflict Resolution (conditional)
|
||||
└─ IF conflict_risk ≥ medium → /workflow:tools:conflict-resolution
|
||||
|
||||
Phase 4: Task Generation
|
||||
└─ /workflow:tools:task-generate-agent
|
||||
└─ Returns IMPL_PLAN.md + IMPL-*.json + TODO_LIST.md
|
||||
|
||||
Return: Summary + Next Steps
|
||||
```
|
||||
|
||||
```bash
|
||||
/workflow:plan "task description" # Complete planning
|
||||
/workflow:action-plan-verify # Verify plan (recommended)
|
||||
/workflow:execute # Execute
|
||||
/workflow:review # (optional) Review
|
||||
```
|
||||
|
||||
**Artifacts**: `.workflow/active/{WFS-session}/`
|
||||
- `workflow-session.json`
|
||||
- `IMPL_PLAN.md`
|
||||
- `TODO_LIST.md`
|
||||
- `.task/IMPL-*.json`
|
||||
- `.process/context-package.json`
|
||||
|
||||
**Use Case**: Multi-module changes, refactoring, dependency analysis needed
|
||||
|
||||
---
|
||||
|
||||
### 3.2 tdd-plan → execute → tdd-verify
|
||||
|
||||
**6-phase test-driven development workflow**
|
||||
|
||||
```
|
||||
Phase 1: Session Discovery
|
||||
└─ /workflow:session:start --type tdd --auto
|
||||
|
||||
Phase 2: Context Gathering
|
||||
└─ /workflow:tools:context-gather
|
||||
|
||||
Phase 3: Test Coverage Analysis
|
||||
└─ /workflow:tools:test-context-gather
|
||||
└─ Detect test framework, analyze coverage
|
||||
|
||||
Phase 4: Conflict Resolution (conditional)
|
||||
└─ IF conflict_risk ≥ medium → /workflow:tools:conflict-resolution
|
||||
|
||||
Phase 5: TDD Task Generation
|
||||
└─ /workflow:tools:task-generate-tdd
|
||||
└─ Generate IMPL tasks with built-in Red-Green-Refactor cycles
|
||||
|
||||
Phase 6: TDD Structure Validation
|
||||
└─ Verify TDD structure compliance
|
||||
```
|
||||
|
||||
```bash
|
||||
/workflow:tdd-plan "feature description" # TDD planning
|
||||
/workflow:action-plan-verify # Verify (recommended)
|
||||
/workflow:execute # Execute (follow Red-Green-Refactor)
|
||||
/workflow:tdd-verify # Verify TDD compliance
|
||||
```
|
||||
|
||||
**TDD Task Structure**:
|
||||
- Each IMPL task contains complete internal Red-Green-Refactor cycle
|
||||
- `meta.tdd_workflow: true`
|
||||
- `flow_control.implementation_approach` contains 3 steps (red/green/refactor)
|
||||
- Green phase includes test-fix-cycle configuration
|
||||
|
||||
**Use Case**: Test-driven development, high-quality feature requirements
|
||||
|
||||
---
|
||||
|
||||
### 3.3 test-fix-gen → test-cycle-execute
|
||||
|
||||
**5-phase test fix generation workflow**
|
||||
|
||||
```
|
||||
Phase 1: Create Test Session
|
||||
└─ /workflow:session:start --type test --new
|
||||
|
||||
Phase 2: Gather Test Context
|
||||
├─ Session Mode: /workflow:tools:test-context-gather
|
||||
└─ Prompt Mode: /workflow:tools:context-gather
|
||||
|
||||
Phase 3: Test Generation Analysis
|
||||
└─ /workflow:tools:test-concept-enhanced
|
||||
└─ Multi-layer test requirements (L0: Static, L1: Unit, L2: Integration, L3: E2E)
|
||||
|
||||
Phase 4: Generate Test Tasks
|
||||
└─ /workflow:tools:test-task-generate
|
||||
└─ IMPL-001 (generate) + IMPL-001.5 (quality gate) + IMPL-002 (execute fix)
|
||||
|
||||
Phase 5: Return Summary
|
||||
└─ → /workflow:test-cycle-execute
|
||||
```
|
||||
|
||||
**Dual-mode support**:
|
||||
| Mode | Input Pattern | Context Source |
|
||||
|------|---------------|----------------|
|
||||
| Session Mode | `WFS-xxx` | Source session summaries |
|
||||
| Prompt Mode | Text/file path | Direct codebase analysis |
|
||||
|
||||
```bash
|
||||
/workflow:test-fix-gen WFS-user-auth-v2 # Session Mode
|
||||
/workflow:test-fix-gen "Test the auth API" # Prompt Mode
|
||||
/workflow:test-cycle-execute # Execute test-fix cycle
|
||||
```
|
||||
|
||||
**Artifacts**: `.workflow/active/WFS-test-{session}/`
|
||||
- `.task/IMPL-001.json` (test understanding & generation)
|
||||
- `.task/IMPL-001.5-review.json` (quality gate)
|
||||
- `.task/IMPL-002.json` (test execution & fix cycle)
|
||||
- `.process/TEST_ANALYSIS_RESULTS.md`
|
||||
|
||||
**Use Case**: Test failure fixes, coverage improvement
|
||||
|
||||
---
|
||||
|
||||
## Level 4: Brainstorming (brainstorm:auto-parallel)
|
||||
|
||||
**Most Complex - Multi-role brainstorming + Complete planning + Execution**
|
||||
|
||||
### Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Complexity** | High |
|
||||
| **Artifacts** | Multi-role analysis docs + `IMPL_PLAN.md` |
|
||||
| **Role Count** | 3-9 (default 3) |
|
||||
| **Execution Mode** | Phase 1/3 sequential, Phase 2 parallel |
|
||||
|
||||
### 3-Phase Flow
|
||||
|
||||
```
|
||||
Phase 1: Interactive Framework Generation
|
||||
└─ /workflow:brainstorm:artifacts
|
||||
├─ Topic analysis, generate questions
|
||||
├─ Role selection (user confirmation)
|
||||
├─ Role question collection
|
||||
├─ Conflict detection and resolution
|
||||
└─ Generate guidance-specification.md
|
||||
|
||||
Phase 2: Parallel Role Analysis (parallel)
|
||||
└─ N × Task(conceptual-planning-agent)
|
||||
├─ Each role analyzes independently
|
||||
└─ Parallel generate {role}/analysis.md
|
||||
|
||||
Phase 3: Synthesis Integration
|
||||
└─ /workflow:brainstorm:synthesis
|
||||
└─ Integrate all role analyses → synthesis-specification.md
|
||||
```
|
||||
|
||||
### Commands
|
||||
|
||||
```bash
|
||||
/workflow:brainstorm:auto-parallel "topic" [--count N] [--style-skill package]
|
||||
/workflow:plan --session {sessionId} # Plan based on brainstorm results
|
||||
/workflow:action-plan-verify # Verify
|
||||
/workflow:execute # Execute
|
||||
```
|
||||
|
||||
### Available Roles
|
||||
|
||||
| Role | Description |
|
||||
|------|-------------|
|
||||
| `system-architect` | System Architect |
|
||||
| `ui-designer` | UI Designer |
|
||||
| `ux-expert` | UX Expert |
|
||||
| `product-manager` | Product Manager |
|
||||
| `product-owner` | Product Owner |
|
||||
| `data-architect` | Data Architect |
|
||||
| `scrum-master` | Scrum Master |
|
||||
| `subject-matter-expert` | Domain Expert |
|
||||
| `test-strategist` | Test Strategist |
|
||||
|
||||
### Artifact Structure
|
||||
|
||||
```
|
||||
.workflow/active/WFS-{topic}/
|
||||
├── workflow-session.json # Session metadata
|
||||
└── .brainstorming/
|
||||
├── guidance-specification.md # Framework (Phase 1)
|
||||
├── {role}/
|
||||
│ ├── analysis.md # Main document
|
||||
│ └── analysis-{slug}.md # Sub-documents (optional, max 5)
|
||||
└── synthesis-specification.md # Integration (Phase 3)
|
||||
```
|
||||
|
||||
### Use Cases
|
||||
|
||||
- ✅ New feature design
|
||||
- ✅ System architecture refactoring
|
||||
- ✅ Exploratory requirements
|
||||
- ✅ Uncertain implementation approach
|
||||
- ✅ Multi-dimensional trade-offs needed
|
||||
- ❌ Clear requirements
|
||||
- ❌ Time-sensitive tasks
|
||||
|
||||
---
|
||||
|
||||
## Issue Workflow
|
||||
|
||||
**Main Workflow Supplement - Post-development continuous maintenance**
|
||||
|
||||
### Two-Phase Lifecycle
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ Phase 1: Accumulation │
|
||||
│ │
|
||||
│ Triggers: │
|
||||
│ • Post-task review │
|
||||
│ • Code review findings │
|
||||
│ • Test failures │
|
||||
│ │
|
||||
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
|
||||
│ │ discover │ │ discover- │ │ new │ │
|
||||
│ │ Auto-find │ │ by-prompt │ │ Manual │ │
|
||||
│ └────────────┘ └────────────┘ └────────────┘ │
|
||||
│ │
|
||||
│ Continuously accumulate issues to pending queue │
|
||||
└─────────────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
│ After sufficient accumulation
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ Phase 2: Batch Resolution │
|
||||
│ │
|
||||
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
|
||||
│ │ plan │ ──→ │ queue │ ──→ │ execute │ │
|
||||
│ │ --all- │ │ Optimize │ │ Parallel │ │
|
||||
│ │ pending │ │ order │ │ execution │ │
|
||||
│ └────────────┘ └────────────┘ └────────────┘ │
|
||||
│ │
|
||||
│ Supports worktree isolation, maintains main branch stability │
|
||||
└─────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Command List
|
||||
|
||||
**Accumulation Phase:**
|
||||
```bash
|
||||
/issue:discover # Multi-perspective auto-discovery
|
||||
/issue:discover-by-prompt # Prompt-based discovery
|
||||
/issue:new # Manual creation
|
||||
```
|
||||
|
||||
**Batch Resolution:**
|
||||
```bash
|
||||
/issue:plan --all-pending # Batch plan all pending
|
||||
/issue:queue # Generate optimized execution queue
|
||||
/issue:execute # Parallel execution
|
||||
```
|
||||
|
||||
### Collaboration with Main Workflow
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ Development Iteration Loop │
|
||||
│ │
|
||||
│ ┌─────────┐ ┌─────────┐ │
|
||||
│ │ Feature │ ──→ Main Workflow ──→ Done ──→│ Review │ │
|
||||
│ │ Request │ (Level 1-4) └────┬────┘ │
|
||||
│ └─────────┘ │ │
|
||||
│ ▲ │ Issues found │
|
||||
│ │ ▼ │
|
||||
│ │ ┌─────────┐ │
|
||||
│ │ │ Issue │ │
|
||||
│ │ │ Workflow│ │
|
||||
│ Continue│ └────┬────┘ │
|
||||
│ new │ │ │
|
||||
│ feature │ ┌──────────────────────────┘ │
|
||||
│ │ │ Fix complete │
|
||||
│ │ ▼ │
|
||||
│ ┌────┴────┐◀────── │
|
||||
│ │ Main │ Merge │
|
||||
│ │ Branch │ back │
|
||||
│ └─────────┘ │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Workflow Selection Guide
|
||||
|
||||
### Quick Selection Table
|
||||
|
||||
| Scenario | Recommended Workflow | Level |
|
||||
|----------|---------------------|-------|
|
||||
| Quick fixes, config adjustments | `lite-lite-lite` | 1 |
|
||||
| Clear single-module features | `lite-plan → lite-execute` | 2 |
|
||||
| Bug diagnosis and fix | `lite-fix` | 2 |
|
||||
| Production emergencies | `lite-fix --hotfix` | 2 |
|
||||
| Technology selection, solution comparison | `multi-cli-plan → lite-execute` | 2 |
|
||||
| Multi-module changes, refactoring | `plan → verify → execute` | 3 |
|
||||
| Test-driven development | `tdd-plan → execute → tdd-verify` | 3 |
|
||||
| Test failure fixes | `test-fix-gen → test-cycle-execute` | 3 |
|
||||
| New features, architecture design | `brainstorm:auto-parallel → plan → execute` | 4 |
|
||||
| Post-development issue fixes | Issue Workflow | - |
|
||||
|
||||
### Decision Flowchart
|
||||
|
||||
```
|
||||
Start
|
||||
│
|
||||
├─ Is it post-development maintenance?
|
||||
│ ├─ Yes → Issue Workflow
|
||||
│ └─ No ↓
|
||||
│
|
||||
├─ Are requirements clear?
|
||||
│ ├─ Uncertain → Level 4 (brainstorm:auto-parallel)
|
||||
│ └─ Clear ↓
|
||||
│
|
||||
├─ Need persistent Session?
|
||||
│ ├─ Yes → Level 3 (plan / tdd-plan / test-fix-gen)
|
||||
│ └─ No ↓
|
||||
│
|
||||
├─ Need multi-perspective / solution comparison?
|
||||
│ ├─ Yes → Level 2 (multi-cli-plan)
|
||||
│ └─ No ↓
|
||||
│
|
||||
├─ Is it a bug fix?
|
||||
│ ├─ Yes → Level 2 (lite-fix)
|
||||
│ └─ No ↓
|
||||
│
|
||||
├─ Need planning?
|
||||
│ ├─ Yes → Level 2 (lite-plan)
|
||||
│ └─ No → Level 1 (lite-lite-lite)
|
||||
```
|
||||
|
||||
### Complexity Indicators
|
||||
|
||||
System auto-evaluates complexity based on these keywords:
|
||||
|
||||
| Weight | Keywords |
|
||||
|--------|----------|
|
||||
| +2 | refactor, migrate, architect, system |
|
||||
| +2 | multiple, across, all, entire |
|
||||
| +1 | integrate, api, database |
|
||||
| +1 | security, performance, scale |
|
||||
|
||||
- **High complexity** (≥4): Auto-select Level 3-4
|
||||
- **Medium complexity** (2-3): Auto-select Level 2
|
||||
- **Low complexity** (<2): Auto-select Level 1
|
||||
|
||||
---
|
||||
|
||||
## Semantic CLI Invocation
|
||||
|
||||
Users can **semantically specify CLI tools** in prompts - the system automatically invokes the corresponding CLI.
|
||||
|
||||
### Basic Invocation
|
||||
|
||||
| User Prompt | System Action |
|
||||
|-------------|---------------|
|
||||
| "Use Gemini to analyze the auth module" | Auto-invoke `gemini` CLI for analysis |
|
||||
| "Let Codex review this code" | Auto-invoke `codex` CLI for review |
|
||||
| "Ask Qwen about performance optimization" | Auto-invoke `qwen` CLI for consultation |
|
||||
|
||||
### Multi-CLI Orchestration
|
||||
|
||||
| Pattern | User Prompt Example |
|
||||
|---------|---------------------|
|
||||
| **Collaborative** | "Use Gemini and Codex to collaboratively analyze security vulnerabilities" |
|
||||
| **Parallel** | "Have Gemini, Codex, and Qwen analyze the architecture in parallel" |
|
||||
| **Iterative** | "Use Gemini to diagnose, then Codex to fix, iterate until resolved" |
|
||||
| **Pipeline** | "Gemini designs the solution, Codex implements, Claude reviews" |
|
||||
|
||||
### Custom CLI Registration
|
||||
|
||||
Register **any API as a custom CLI** via Dashboard interface:
|
||||
|
||||
```bash
|
||||
ccw view # Open Dashboard → Status → API Settings → Add Custom CLI
|
||||
```
|
||||
|
||||
| Field | Example |
|
||||
|-------|---------|
|
||||
| **Name** | `deepseek` |
|
||||
| **Endpoint** | `https://api.deepseek.com/v1/chat` |
|
||||
| **API Key** | `your-api-key` |
|
||||
|
||||
> Register once, invoke semantically forever - no code changes needed.
|
||||
|
||||
---
|
||||
|
||||
## ACE Tool Configuration
|
||||
|
||||
ACE (Augment Context Engine) provides powerful semantic code search. Two configuration methods available:
|
||||
|
||||
| Method | Link |
|
||||
|--------|------|
|
||||
| **Official** | [Augment MCP Documentation](https://docs.augmentcode.com/context-services/mcp/overview) |
|
||||
| **Proxy** | [ace-tool (GitHub)](https://github.com/eastxiaodong/ace-tool) |
|
||||
|
||||
### Usage Example
|
||||
|
||||
```javascript
|
||||
mcp__ace-tool__search_context({
|
||||
project_root_path: "/path/to/project",
|
||||
query: "authentication logic"
|
||||
})
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
### Level Overview
|
||||
|
||||
| Level | Name | Included Workflows | Artifacts | Execution |
|
||||
|-------|------|-------------------|-----------|-----------|
|
||||
| **1** | Rapid | `lite-lite-lite` | None | Direct execute |
|
||||
| **2** | Lightweight | `lite-plan`, `lite-fix`, `multi-cli-plan` | Memory/Lightweight files | → `lite-execute` |
|
||||
| **3** | Standard | `plan`, `tdd-plan`, `test-fix-gen` | Session persistence | → `execute` / `test-cycle-execute` |
|
||||
| **4** | Brainstorm | `brainstorm:auto-parallel` → `plan` | Multi-role analysis + Session | → `execute` |
|
||||
| **-** | Issue | `discover` → `plan` → `queue` → `execute` | Issue records | Worktree isolation (optional) |
|
||||
|
||||
### Core Principles
|
||||
|
||||
1. **Main Workflow** solves parallelism through **dependency analysis + Agent parallel execution**, no worktree needed
|
||||
2. **Issue Workflow** serves as a **supplementary mechanism**, supporting worktree isolation to maintain main branch stability
|
||||
3. Select appropriate workflow level based on task complexity, **avoid over-engineering**
|
||||
4. Level 2 workflow selection criteria:
|
||||
- Clear requirements → `lite-plan`
|
||||
- Bug fix → `lite-fix`
|
||||
- Need multi-perspective → `multi-cli-plan`
|
||||
5. Level 3 workflow selection criteria:
|
||||
- Standard development → `plan`
|
||||
- Test-driven → `tdd-plan`
|
||||
- Test fix → `test-fix-gen`
|
||||
730
WORKFLOW_GUIDE_CN.md
Normal file
730
WORKFLOW_GUIDE_CN.md
Normal file
@@ -0,0 +1,730 @@
|
||||
# CCW Workflow Difficulty Guide
|
||||
|
||||
## Overview
|
||||
|
||||
CCW 提供两类工作流体系:**主干工作流** (Main Workflow) 和 **Issue 工作流** (Issue Workflow),它们协同覆盖软件开发的完整生命周期。
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Main Workflow (主干工作流) │
|
||||
│ │
|
||||
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
|
||||
│ │ Level 1 │ → │ Level 2 │ → │ Level 3 │ → │ Level 4 │ │
|
||||
│ │ 急速执行 │ │ 轻量规划 │ │ 标准规划 │ │ 头脑风暴 │ │
|
||||
│ │ │ │ │ │ │ │ │ │
|
||||
│ │ lite-lite- │ │ lite-plan │ │ plan │ │ brainstorm │ │
|
||||
│ │ lite │ │ lite-fix │ │ tdd-plan │ │ :auto- │ │
|
||||
│ │ │ │ multi-cli- │ │ test-fix- │ │ parallel │ │
|
||||
│ │ │ │ plan │ │ gen │ │ ↓ │ │
|
||||
│ │ │ │ │ │ │ │ plan │ │
|
||||
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
|
||||
│ │
|
||||
│ 复杂度: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━▶ │
|
||||
│ 低 高 │
|
||||
└─────────────────────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
│ 开发完成后
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Issue Workflow (Issue 工作流) │
|
||||
│ │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ Accumulate │ → │ Plan │ → │ Execute │ │
|
||||
│ │ 发现 & 积累 │ │ 批量规划 │ │ 并行执行 │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
│ │
|
||||
│ 补充角色: 维护主分支稳定,支持 worktree 隔离 │
|
||||
└─────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 主干工作流与 Issue 工作流的关系
|
||||
|
||||
### 设计哲学
|
||||
|
||||
| 维度 | 主干工作流 (Main) | Issue 工作流 (Issue) |
|
||||
|------|-------------------|---------------------|
|
||||
| **定位** | 主要开发周期 | 开发后的维护补充 |
|
||||
| **时机** | 功能开发阶段 | 主干开发完成后 |
|
||||
| **范围** | 完整功能实现 | 针对性修复/增强 |
|
||||
| **并行策略** | 依赖分析 → Agent 并行 | Worktree 隔离 (可选) |
|
||||
| **分支模型** | 在当前分支工作 | 可使用独立 worktree |
|
||||
|
||||
### 为什么主干工作流不自动使用 Worktree?
|
||||
|
||||
**依赖分析已解决并行问题**:
|
||||
|
||||
1. 规划阶段 (`/workflow:plan`) 执行依赖分析
|
||||
2. 自动识别任务依赖和关键路径
|
||||
3. 划分**并行组** (独立任务) 和**串行链** (依赖任务)
|
||||
4. Agent 并行执行独立任务,无需文件系统隔离
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ Dependency Analysis (依赖分析) │
|
||||
│ │
|
||||
│ Task A ─────┐ │
|
||||
│ ├──→ Parallel Group 1 ──→ Agent 1 │
|
||||
│ Task B ─────┘ │
|
||||
│ │
|
||||
│ Task C ────────→ Serial Chain ──────→ Agent 2 │
|
||||
│ ↓ │
|
||||
│ Task D ────────→ │
|
||||
│ │
|
||||
│ 同一 worktree,通过调度实现并行 │
|
||||
└─────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 为什么 Issue 工作流支持 Worktree?
|
||||
|
||||
Issue 工作流作为**补充机制**,场景不同:
|
||||
|
||||
1. 主干开发完成,已合并到 `main`
|
||||
2. 发现需要修复的问题
|
||||
3. 需要在不影响当前开发的情况下修复
|
||||
4. Worktree 隔离让主分支保持稳定
|
||||
|
||||
```
|
||||
开发完成 → 发布 → 发现 Issue → Worktree 隔离修复 → 合并回主干
|
||||
↑ │
|
||||
└──────────── 继续新功能开发 ←─────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Level 1: 急速执行 (lite-lite-lite)
|
||||
|
||||
**最简单 - 一次 CLI 分析到执行,零产物**
|
||||
|
||||
### 特点
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|-----|
|
||||
| **复杂度** | 低 |
|
||||
| **产物** | 无文件 |
|
||||
| **状态** | 无状态 |
|
||||
| **CLI 选择** | 自动分析任务类型 |
|
||||
| **迭代方式** | 通过 AskUser |
|
||||
|
||||
### 流程
|
||||
|
||||
```
|
||||
用户输入 → 需求澄清 → 自动选择 CLI → 并行分析 → 展示结果 → 直接执行
|
||||
↓
|
||||
无中间文件
|
||||
```
|
||||
|
||||
### 命令
|
||||
|
||||
```bash
|
||||
/workflow:lite-lite-lite
|
||||
# 或 CCW 自动识别简单任务时选择
|
||||
```
|
||||
|
||||
### 适用场景
|
||||
|
||||
- ✅ 快速修复
|
||||
- ✅ 简单功能添加
|
||||
- ✅ 配置调整
|
||||
- ✅ 小范围重命名
|
||||
- ❌ 多模块改动
|
||||
- ❌ 需要持久化记录
|
||||
|
||||
---
|
||||
|
||||
## Level 2: 轻量规划
|
||||
|
||||
**轻量 - 内存规划或单次分析,快速迭代**
|
||||
|
||||
### 包含工作流
|
||||
|
||||
| 工作流 | 用途 | 产物 | 执行方式 |
|
||||
|--------|------|------|----------|
|
||||
| `lite-plan` | 明确需求的功能开发 | memory://plan | → `lite-execute` |
|
||||
| `lite-fix` | Bug 诊断修复 | `.workflow/.lite-fix/` | → `lite-execute` |
|
||||
| `multi-cli-plan` | 需要多视角的任务 | `.workflow/.multi-cli-plan/` | → `lite-execute` |
|
||||
|
||||
### 共同特点
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|-----|
|
||||
| **复杂度** | 低-中 |
|
||||
| **状态** | 会话内 / 轻量持久化 |
|
||||
| **执行** | 统一通过 `lite-execute` |
|
||||
| **适用** | 需求相对明确的任务 |
|
||||
|
||||
---
|
||||
|
||||
### 2.1 lite-plan → lite-execute
|
||||
|
||||
**内存规划 + 直接执行**
|
||||
|
||||
```
|
||||
┌─────────────────┐ ┌─────────────────┐
|
||||
│ lite-plan │ ──→ │ lite-execute │
|
||||
│ 内存中规划 │ │ 直接执行 │
|
||||
└─────────────────┘ └─────────────────┘
|
||||
```
|
||||
|
||||
```bash
|
||||
/workflow:lite-plan # 规划
|
||||
/workflow:lite-execute # 执行
|
||||
```
|
||||
|
||||
**适用**: 明确需求的单模块功能
|
||||
|
||||
---
|
||||
|
||||
### 2.2 lite-fix
|
||||
|
||||
**智能诊断 + 修复 (5 阶段)**
|
||||
|
||||
```
|
||||
Phase 1: Bug Analysis & Diagnosis
|
||||
├─ 智能严重性预评估 (Low/Medium/High/Critical)
|
||||
└─ 并行 cli-explore-agent 诊断 (1-4 个角度)
|
||||
|
||||
Phase 2: Clarification (可选)
|
||||
└─ 聚合澄清需求,AskUserQuestion
|
||||
|
||||
Phase 3: Fix Planning
|
||||
├─ Low/Medium → Claude 直接规划
|
||||
└─ High/Critical → cli-lite-planning-agent
|
||||
|
||||
Phase 4: Confirmation & Selection
|
||||
└─ 用户确认执行方式
|
||||
|
||||
Phase 5: Execute
|
||||
└─ SlashCommand("/workflow:lite-execute --in-memory --mode bugfix")
|
||||
```
|
||||
|
||||
```bash
|
||||
/workflow:lite-fix # 标准修复
|
||||
/workflow:lite-fix --hotfix # 紧急热修复 (跳过诊断)
|
||||
```
|
||||
|
||||
**产物**: `.workflow/.lite-fix/{bug-slug}-{date}/`
|
||||
- `diagnosis-{angle}.json` (1-4 个诊断文件)
|
||||
- `diagnoses-manifest.json`
|
||||
- `fix-plan.json`
|
||||
|
||||
**适用**: Bug 诊断修复、紧急生产问题
|
||||
|
||||
---
|
||||
|
||||
### 2.3 multi-cli-plan → lite-execute
|
||||
|
||||
**多 CLI 协作分析 + 共识收敛 (5 阶段)**
|
||||
|
||||
```
|
||||
Phase 1: Context Gathering
|
||||
└─ ACE 语义搜索,构建上下文包
|
||||
|
||||
Phase 2: Multi-CLI Discussion (迭代)
|
||||
├─ cli-discuss-agent 执行 Gemini + Codex + Claude
|
||||
├─ 交叉验证,合成方案
|
||||
└─ 循环直到收敛或达到最大轮数
|
||||
|
||||
Phase 3: Present Options
|
||||
└─ 展示方案及权衡
|
||||
|
||||
Phase 4: User Decision
|
||||
└─ 用户选择方案
|
||||
|
||||
Phase 5: Plan Generation
|
||||
├─ cli-lite-planning-agent 生成计划
|
||||
└─ → lite-execute
|
||||
```
|
||||
|
||||
```bash
|
||||
/workflow:multi-cli-plan "task description" # 多 CLI 协作规划
|
||||
/workflow:lite-execute # 执行选定方案
|
||||
```
|
||||
|
||||
**产物**: `.workflow/.multi-cli-plan/{MCP-task-slug-date}/`
|
||||
- `rounds/*/synthesis.json` (每轮分析)
|
||||
- `context-package.json`
|
||||
- `IMPL_PLAN.md` + `plan.json`
|
||||
|
||||
**vs lite-plan 对比**:
|
||||
|
||||
| 维度 | multi-cli-plan | lite-plan |
|
||||
|------|---------------|-----------|
|
||||
| **上下文** | ACE 语义搜索 | 手动文件模式 |
|
||||
| **分析** | 多 CLI 交叉验证 | 单次规划 |
|
||||
| **迭代** | 多轮直到收敛 | 单轮 |
|
||||
| **置信度** | 高 (共识驱动) | 中 (单一视角) |
|
||||
|
||||
**适用**: 需要多视角分析、技术选型、方案比较
|
||||
|
||||
---
|
||||
|
||||
## Level 3: 标准规划
|
||||
|
||||
**标准 - 完整规划 + 持久化 Session + 验证**
|
||||
|
||||
### 包含工作流
|
||||
|
||||
| 工作流 | 用途 | 阶段数 | 产物位置 |
|
||||
|--------|------|--------|----------|
|
||||
| `plan` | 复杂功能开发 | 5 阶段 | `.workflow/active/{session}/` |
|
||||
| `tdd-plan` | 测试驱动开发 | 6 阶段 | `.workflow/active/{session}/` |
|
||||
| `test-fix-gen` | 测试修复生成 | 5 阶段 | `.workflow/active/WFS-test-{session}/` |
|
||||
|
||||
### 共同特点
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|-----|
|
||||
| **复杂度** | 中-高 |
|
||||
| **产物** | 持久化文件 (`.workflow/active/{session}/`) |
|
||||
| **状态** | 完整 session 管理 |
|
||||
| **验证** | 内置验证步骤 |
|
||||
| **执行** | `/workflow:execute` |
|
||||
| **适用** | 多模块、需要追溯的任务 |
|
||||
|
||||
---
|
||||
|
||||
### 3.1 plan → verify → execute
|
||||
|
||||
**5 阶段完整规划工作流**
|
||||
|
||||
```
|
||||
Phase 1: Session Discovery
|
||||
└─ /workflow:session:start --auto
|
||||
|
||||
Phase 2: Context Gathering
|
||||
└─ /workflow:tools:context-gather
|
||||
└─ 返回 context-package.json + conflict_risk
|
||||
|
||||
Phase 3: Conflict Resolution (条件触发)
|
||||
└─ IF conflict_risk ≥ medium → /workflow:tools:conflict-resolution
|
||||
|
||||
Phase 4: Task Generation
|
||||
└─ /workflow:tools:task-generate-agent
|
||||
└─ 返回 IMPL_PLAN.md + IMPL-*.json + TODO_LIST.md
|
||||
|
||||
Return: Summary + Next Steps
|
||||
```
|
||||
|
||||
```bash
|
||||
/workflow:plan "task description" # 完整规划
|
||||
/workflow:action-plan-verify # 验证计划 (推荐)
|
||||
/workflow:execute # 执行
|
||||
/workflow:review # (可选) 审查
|
||||
```
|
||||
|
||||
**产物**: `.workflow/active/{WFS-session}/`
|
||||
- `workflow-session.json`
|
||||
- `IMPL_PLAN.md`
|
||||
- `TODO_LIST.md`
|
||||
- `.task/IMPL-*.json`
|
||||
- `.process/context-package.json`
|
||||
|
||||
**适用**: 多模块改动、重构任务、需要依赖分析
|
||||
|
||||
---
|
||||
|
||||
### 3.2 tdd-plan → execute → tdd-verify
|
||||
|
||||
**6 阶段测试驱动开发工作流**
|
||||
|
||||
```
|
||||
Phase 1: Session Discovery
|
||||
└─ /workflow:session:start --type tdd --auto
|
||||
|
||||
Phase 2: Context Gathering
|
||||
└─ /workflow:tools:context-gather
|
||||
|
||||
Phase 3: Test Coverage Analysis
|
||||
└─ /workflow:tools:test-context-gather
|
||||
└─ 检测测试框架,分析覆盖率
|
||||
|
||||
Phase 4: Conflict Resolution (条件触发)
|
||||
└─ IF conflict_risk ≥ medium → /workflow:tools:conflict-resolution
|
||||
|
||||
Phase 5: TDD Task Generation
|
||||
└─ /workflow:tools:task-generate-tdd
|
||||
└─ 生成内置 Red-Green-Refactor 循环的 IMPL 任务
|
||||
|
||||
Phase 6: TDD Structure Validation
|
||||
└─ 验证 TDD 结构合规性
|
||||
```
|
||||
|
||||
```bash
|
||||
/workflow:tdd-plan "feature description" # TDD 规划
|
||||
/workflow:action-plan-verify # 验证 (推荐)
|
||||
/workflow:execute # 执行 (遵循 Red-Green-Refactor)
|
||||
/workflow:tdd-verify # 验证 TDD 流程合规
|
||||
```
|
||||
|
||||
**TDD 任务结构**:
|
||||
- 每个 IMPL 任务包含完整的 Red-Green-Refactor 内部循环
|
||||
- `meta.tdd_workflow: true`
|
||||
- `flow_control.implementation_approach` 包含 3 步 (red/green/refactor)
|
||||
- Green 阶段包含 test-fix-cycle 配置
|
||||
|
||||
**适用**: 测试驱动开发、高质量要求的功能
|
||||
|
||||
---
|
||||
|
||||
### 3.3 test-fix-gen → test-cycle-execute
|
||||
|
||||
**5 阶段测试修复生成工作流**
|
||||
|
||||
```
|
||||
Phase 1: Create Test Session
|
||||
└─ /workflow:session:start --type test --new
|
||||
|
||||
Phase 2: Gather Test Context
|
||||
├─ Session Mode: /workflow:tools:test-context-gather
|
||||
└─ Prompt Mode: /workflow:tools:context-gather
|
||||
|
||||
Phase 3: Test Generation Analysis
|
||||
└─ /workflow:tools:test-concept-enhanced
|
||||
└─ 多层测试需求 (L0: Static, L1: Unit, L2: Integration, L3: E2E)
|
||||
|
||||
Phase 4: Generate Test Tasks
|
||||
└─ /workflow:tools:test-task-generate
|
||||
└─ IMPL-001 (生成) + IMPL-001.5 (质量门) + IMPL-002 (执行修复)
|
||||
|
||||
Phase 5: Return Summary
|
||||
└─ → /workflow:test-cycle-execute
|
||||
```
|
||||
|
||||
**双模式支持**:
|
||||
| 模式 | 输入模式 | 上下文来源 |
|
||||
|------|----------|-----------|
|
||||
| Session Mode | `WFS-xxx` | 源 session 摘要 |
|
||||
| Prompt Mode | 文本/文件路径 | 直接代码库分析 |
|
||||
|
||||
```bash
|
||||
/workflow:test-fix-gen WFS-user-auth-v2 # Session Mode
|
||||
/workflow:test-fix-gen "Test the auth API" # Prompt Mode
|
||||
/workflow:test-cycle-execute # 执行测试修复循环
|
||||
```
|
||||
|
||||
**产物**: `.workflow/active/WFS-test-{session}/`
|
||||
- `.task/IMPL-001.json` (测试理解与生成)
|
||||
- `.task/IMPL-001.5-review.json` (质量门)
|
||||
- `.task/IMPL-002.json` (测试执行与修复循环)
|
||||
- `.process/TEST_ANALYSIS_RESULTS.md`
|
||||
|
||||
**适用**: 测试失败修复、覆盖率提升
|
||||
|
||||
---
|
||||
|
||||
## Level 4: 头脑风暴 (brainstorm:auto-parallel)
|
||||
|
||||
**最复杂 - 多角色头脑风暴 + 完整规划 + 执行**
|
||||
|
||||
### 特点
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|-----|
|
||||
| **复杂度** | 高 |
|
||||
| **产物** | 多角色分析文档 + `IMPL_PLAN.md` |
|
||||
| **角色数** | 3-9 个 (默认 3) |
|
||||
| **执行模式** | Phase 1/3 串行,Phase 2 并行 |
|
||||
|
||||
### 3 阶段流程
|
||||
|
||||
```
|
||||
Phase 1: Interactive Framework Generation
|
||||
└─ /workflow:brainstorm:artifacts
|
||||
├─ Topic 分析,生成问题
|
||||
├─ 角色选择 (用户确认)
|
||||
├─ 角色问题收集
|
||||
├─ 冲突检测与解决
|
||||
└─ 生成 guidance-specification.md
|
||||
|
||||
Phase 2: Parallel Role Analysis (并行)
|
||||
└─ N × Task(conceptual-planning-agent)
|
||||
├─ 每个角色独立分析
|
||||
└─ 并行生成 {role}/analysis.md
|
||||
|
||||
Phase 3: Synthesis Integration
|
||||
└─ /workflow:brainstorm:synthesis
|
||||
└─ 整合所有角色分析 → synthesis-specification.md
|
||||
```
|
||||
|
||||
### 命令
|
||||
|
||||
```bash
|
||||
/workflow:brainstorm:auto-parallel "topic" [--count N] [--style-skill package]
|
||||
/workflow:plan --session {sessionId} # 基于头脑风暴结果规划
|
||||
/workflow:action-plan-verify # 验证
|
||||
/workflow:execute # 执行
|
||||
```
|
||||
|
||||
### 可用角色
|
||||
|
||||
| 角色 | 描述 |
|
||||
|------|------|
|
||||
| `system-architect` | 系统架构师 |
|
||||
| `ui-designer` | UI 设计师 |
|
||||
| `ux-expert` | UX 专家 |
|
||||
| `product-manager` | 产品经理 |
|
||||
| `product-owner` | 产品负责人 |
|
||||
| `data-architect` | 数据架构师 |
|
||||
| `scrum-master` | 敏捷教练 |
|
||||
| `subject-matter-expert` | 领域专家 |
|
||||
| `test-strategist` | 测试策略师 |
|
||||
|
||||
### 产物结构
|
||||
|
||||
```
|
||||
.workflow/active/WFS-{topic}/
|
||||
├── workflow-session.json # Session 元数据
|
||||
└── .brainstorming/
|
||||
├── guidance-specification.md # 框架 (Phase 1)
|
||||
├── {role}/
|
||||
│ ├── analysis.md # 主文档
|
||||
│ └── analysis-{slug}.md # 子文档 (可选,最多 5 个)
|
||||
└── synthesis-specification.md # 整合 (Phase 3)
|
||||
```
|
||||
|
||||
### 适用场景
|
||||
|
||||
- ✅ 全新功能设计
|
||||
- ✅ 系统架构重构
|
||||
- ✅ 探索性需求
|
||||
- ✅ 不确定如何实现
|
||||
- ✅ 需要多维度权衡
|
||||
- ❌ 需求已明确
|
||||
- ❌ 时间紧迫的任务
|
||||
|
||||
---
|
||||
|
||||
## Issue 工作流
|
||||
|
||||
**主干工作流的补充 - 开发后的持续维护**
|
||||
|
||||
### 两阶段生命周期
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ Phase 1: Accumulation (积累阶段) │
|
||||
│ │
|
||||
│ 触发源: │
|
||||
│ • 任务完成后的 review │
|
||||
│ • 代码审查发现 │
|
||||
│ • 测试失败 │
|
||||
│ │
|
||||
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
|
||||
│ │ discover │ │ discover- │ │ new │ │
|
||||
│ │ 自动发现 │ │ by-prompt │ │ 手动创建 │ │
|
||||
│ └────────────┘ └────────────┘ └────────────┘ │
|
||||
│ │
|
||||
│ 持续积累 Issue 到待处理队列 │
|
||||
└─────────────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
│ 积累足够后
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ Phase 2: Batch Resolution (批量解决) │
|
||||
│ │
|
||||
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
|
||||
│ │ plan │ ──→ │ queue │ ──→ │ execute │ │
|
||||
│ │ --all- │ │ 优化顺序 │ │ 并行执行 │ │
|
||||
│ │ pending │ │ 冲突分析 │ │ │ │
|
||||
│ └────────────┘ └────────────┘ └────────────┘ │
|
||||
│ │
|
||||
│ 支持 Worktree 隔离,保持主分支稳定 │
|
||||
└─────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 命令清单
|
||||
|
||||
**积累阶段:**
|
||||
```bash
|
||||
/issue:discover # 多视角自动发现
|
||||
/issue:discover-by-prompt # 基于提示发现
|
||||
/issue:new # 手动创建
|
||||
```
|
||||
|
||||
**批量解决:**
|
||||
```bash
|
||||
/issue:plan --all-pending # 批量规划所有待处理
|
||||
/issue:queue # 生成优化执行队列
|
||||
/issue:execute # 并行执行
|
||||
```
|
||||
|
||||
### 与主干工作流的协作模式
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ 开发迭代循环 │
|
||||
│ │
|
||||
│ ┌─────────┐ ┌─────────┐ │
|
||||
│ │ Feature │ ──→ Main Workflow ──→ 完成 ──→│ Review │ │
|
||||
│ │ Request │ (Level 1-4) └────┬────┘ │
|
||||
│ └─────────┘ │ │
|
||||
│ ▲ │ 发现问题 │
|
||||
│ │ ▼ │
|
||||
│ │ ┌─────────┐ │
|
||||
│ │ │ Issue │ │
|
||||
│ │ │ Workflow│ │
|
||||
│ 继续 │ └────┬────┘ │
|
||||
│ 新功能│ │ │
|
||||
│ │ ┌──────────────────────────────┘ │
|
||||
│ │ │ 修复完成 │
|
||||
│ │ ▼ │
|
||||
│ ┌────┴────┐◀────── │
|
||||
│ │ Main │ 合并 │
|
||||
│ │ Branch │ 回主干 │
|
||||
│ └─────────┘ │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 工作流选择指南
|
||||
|
||||
### 快速选择表
|
||||
|
||||
| 场景 | 推荐工作流 | Level |
|
||||
|------|-----------|-------|
|
||||
| 快速修复、配置调整 | `lite-lite-lite` | 1 |
|
||||
| 明确需求的单模块功能 | `lite-plan → lite-execute` | 2 |
|
||||
| Bug 诊断修复 | `lite-fix` | 2 |
|
||||
| 紧急生产问题 | `lite-fix --hotfix` | 2 |
|
||||
| 技术选型、方案比较 | `multi-cli-plan → lite-execute` | 2 |
|
||||
| 多模块改动、重构 | `plan → verify → execute` | 3 |
|
||||
| 测试驱动开发 | `tdd-plan → execute → tdd-verify` | 3 |
|
||||
| 测试失败修复 | `test-fix-gen → test-cycle-execute` | 3 |
|
||||
| 全新功能、架构设计 | `brainstorm:auto-parallel → plan → execute` | 4 |
|
||||
| 开发后问题修复 | Issue Workflow | - |
|
||||
|
||||
### 决策流程图
|
||||
|
||||
```
|
||||
开始
|
||||
│
|
||||
├─ 是开发后的维护问题?
|
||||
│ ├─ 是 → Issue Workflow
|
||||
│ └─ 否 ↓
|
||||
│
|
||||
├─ 需求是否明确?
|
||||
│ ├─ 不确定 → Level 4 (brainstorm:auto-parallel)
|
||||
│ └─ 明确 ↓
|
||||
│
|
||||
├─ 需要持久化 Session?
|
||||
│ ├─ 是 → Level 3 (plan / tdd-plan / test-fix-gen)
|
||||
│ └─ 否 ↓
|
||||
│
|
||||
├─ 需要多视角 / 方案比较?
|
||||
│ ├─ 是 → Level 2 (multi-cli-plan)
|
||||
│ └─ 否 ↓
|
||||
│
|
||||
├─ 是 Bug 修复?
|
||||
│ ├─ 是 → Level 2 (lite-fix)
|
||||
│ └─ 否 ↓
|
||||
│
|
||||
├─ 是否需要规划?
|
||||
│ ├─ 是 → Level 2 (lite-plan)
|
||||
│ └─ 否 → Level 1 (lite-lite-lite)
|
||||
```
|
||||
|
||||
### 复杂度指标
|
||||
|
||||
系统根据以下关键词自动评估复杂度:
|
||||
|
||||
| 权重 | 关键词 |
|
||||
|------|--------|
|
||||
| +2 | refactor, 重构, migrate, 迁移, architect, 架构, system, 系统 |
|
||||
| +2 | multiple, 多个, across, 跨, all, 所有, entire, 整个 |
|
||||
| +1 | integrate, 集成, api, database, 数据库 |
|
||||
| +1 | security, 安全, performance, 性能, scale, 扩展 |
|
||||
|
||||
- **高复杂度** (≥4): 自动选择 Level 3-4
|
||||
- **中复杂度** (2-3): 自动选择 Level 2
|
||||
- **低复杂度** (<2): 自动选择 Level 1
|
||||
|
||||
---
|
||||
|
||||
## 语义化 CLI 调用
|
||||
|
||||
用户可以在提示词中 **语义指定 CLI 工具** - 系统自动调用对应的 CLI。
|
||||
|
||||
### 基础调用
|
||||
|
||||
| 用户提示词 | 系统动作 |
|
||||
|------------|----------|
|
||||
| "使用 Gemini 分析 auth 模块" | 自动调用 `gemini` CLI 进行分析 |
|
||||
| "让 Codex 审查这段代码" | 自动调用 `codex` CLI 进行审查 |
|
||||
| "问问 Qwen 性能优化建议" | 自动调用 `qwen` CLI 进行咨询 |
|
||||
|
||||
### 多 CLI 编排
|
||||
|
||||
| 模式 | 用户提示词示例 |
|
||||
|------|----------------|
|
||||
| **协同分析** | "使用 Gemini 和 Codex 协同分析安全漏洞" |
|
||||
| **并行执行** | "让 Gemini、Codex、Qwen 并行分析架构设计" |
|
||||
| **迭代优化** | "用 Gemini 诊断问题,然后 Codex 修复,迭代直到解决" |
|
||||
| **流水线** | "Gemini 设计方案,Codex 实现,Claude 审查" |
|
||||
|
||||
### 自定义 CLI 注册
|
||||
|
||||
通过 Dashboard 界面 **注册任意 API 为自定义 CLI**:
|
||||
|
||||
```bash
|
||||
ccw view # 打开 Dashboard → Status → API Settings → 添加自定义 CLI
|
||||
```
|
||||
|
||||
| 字段 | 示例 |
|
||||
|------|------|
|
||||
| **名称** | `deepseek` |
|
||||
| **端点** | `https://api.deepseek.com/v1/chat` |
|
||||
| **API Key** | `your-api-key` |
|
||||
|
||||
> 注册一次,永久语义调用 - 无需修改代码。
|
||||
|
||||
---
|
||||
|
||||
## ACE Tool 配置
|
||||
|
||||
ACE (Augment Context Engine) 提供强大的语义代码搜索能力。两种配置方式:
|
||||
|
||||
| 方式 | 链接 |
|
||||
|------|------|
|
||||
| **官方** | [Augment MCP 文档](https://docs.augmentcode.com/context-services/mcp/overview) |
|
||||
| **代理** | [ace-tool (GitHub)](https://github.com/eastxiaodong/ace-tool) |
|
||||
|
||||
### 使用示例
|
||||
|
||||
```javascript
|
||||
mcp__ace-tool__search_context({
|
||||
project_root_path: "/path/to/project",
|
||||
query: "authentication logic"
|
||||
})
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 总结
|
||||
|
||||
### 分级总览
|
||||
|
||||
| Level | 名称 | 包含工作流 | 产物 | 执行方式 |
|
||||
|-------|------|-----------|------|----------|
|
||||
| **1** | 急速执行 | `lite-lite-lite` | 无 | 直接执行 |
|
||||
| **2** | 轻量规划 | `lite-plan`, `lite-fix`, `multi-cli-plan` | 内存/轻量文件 | → `lite-execute` |
|
||||
| **3** | 标准规划 | `plan`, `tdd-plan`, `test-fix-gen` | Session 持久化 | → `execute` / `test-cycle-execute` |
|
||||
| **4** | 头脑风暴 | `brainstorm:auto-parallel` → `plan` | 多角色分析 + Session | → `execute` |
|
||||
| **-** | Issue | `discover` → `plan` → `queue` → `execute` | Issue 记录 | Worktree 隔离 (可选) |
|
||||
|
||||
### 核心原则
|
||||
|
||||
1. **主干工作流**通过**依赖分析 + Agent 并行**解决并行问题,无需 worktree
|
||||
2. **Issue 工作流**作为**补充机制**,支持 worktree 隔离以保持主分支稳定
|
||||
3. 根据任务复杂度选择合适的工作流层级,**避免过度工程化**
|
||||
4. Level 2 的三个工作流选择依据:
|
||||
- 需求明确 → `lite-plan`
|
||||
- Bug 修复 → `lite-fix`
|
||||
- 需要多视角 → `multi-cli-plan`
|
||||
5. Level 3 的三个工作流选择依据:
|
||||
- 标准开发 → `plan`
|
||||
- 测试驱动 → `tdd-plan`
|
||||
- 测试修复 → `test-fix-gen`
|
||||
15
ccw-vscode-bridge/.vscode/tasks.json
vendored
Normal file
15
ccw-vscode-bridge/.vscode/tasks.json
vendored
Normal file
@@ -0,0 +1,15 @@
|
||||
{
|
||||
"version": "2.0.0",
|
||||
"tasks": [
|
||||
{
|
||||
"type": "npm",
|
||||
"script": "compile",
|
||||
"problemMatcher": "$tsc",
|
||||
"label": "npm: compile",
|
||||
"group": {
|
||||
"kind": "build",
|
||||
"isDefault": true
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user