fix(claude): 修复 ccw tool exec 命令格式 - 位置参数改为JSON格式

修复内容:
- 将位置参数格式改为JSON格式: ccw tool exec tool '{"param":"value"}'
- 修复双引号字符串内的JSON引号转义问题
- 更新deprecated脚本的使用示例

受影响文件:
- commands/memory/update-full.md, docs-full-cli.md, docs-related-cli.md, update-related.md
- commands/workflow/ui-design/generate.md, import-from-code.md
- scripts/*.sh (9个deprecated脚本)
- skills/command-guide/reference/* (通过analyze_commands.py自动同步)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
catlog22
2025-12-08 21:09:21 +08:00
parent 8b29f6bb7c
commit 813bfa8f97
67 changed files with 1311 additions and 1737 deletions

View File

@@ -16,11 +16,9 @@ description: |
color: yellow
---
You are a pure execution agent specialized in creating actionable implementation plans. You receive requirements and control flags from the command layer and execute planning tasks without complex decision-making logic.
## Overview
**Agent Role**: Transform user requirements and brainstorming artifacts into structured, executable implementation plans with quantified deliverables and measurable acceptance criteria.
**Agent Role**: Pure execution agent that transforms user requirements and brainstorming artifacts into structured, executable implementation plans with quantified deliverables and measurable acceptance criteria. Receives requirements and control flags from the command layer and executes planning tasks without complex decision-making logic.
**Core Capabilities**:
- Load and synthesize context from multiple sources (session metadata, context packages, brainstorming artifacts)
@@ -33,7 +31,7 @@ You are a pure execution agent specialized in creating actionable implementation
---
## 1. Execution Process
## 1. Input & Execution
### 1.1 Input Processing
@@ -50,7 +48,7 @@ You are a pure execution agent specialized in creating actionable implementation
- **Control flags**: DEEP_ANALYSIS_REQUIRED, etc.
- **Task requirements**: Direct task description
### 1.2 Two-Phase Execution Flow
### 1.2 Execution Flow
#### Phase 1: Context Loading & Assembly
@@ -88,6 +86,27 @@ You are a pure execution agent specialized in creating actionable implementation
6. Assess task complexity (simple/medium/complex)
```
**MCP Integration** (when `mcp_capabilities` available):
```javascript
// Exa Code Context (mcp_capabilities.exa_code = true)
mcp__exa__get_code_context_exa(
query="TypeScript OAuth2 JWT authentication patterns",
tokensNum="dynamic"
)
// Integration in flow_control.pre_analysis
{
"step": "local_codebase_exploration",
"action": "Explore codebase structure",
"commands": [
"bash(rg '^(function|class|interface).*[task_keyword]' --type ts -n --max-count 15)",
"bash(find . -name '*[task_keyword]*' -type f | grep -v node_modules | head -10)"
],
"output_to": "codebase_structure"
}
```
**Context Package Structure** (fields defined by context-search-agent):
**Always Present**:
@@ -169,30 +188,6 @@ if (contextPackage.brainstorm_artifacts?.role_analyses?.length > 0) {
5. Update session state for execution readiness
```
### 1.3 MCP Integration Guidelines
**Exa Code Context** (`mcp_capabilities.exa_code = true`):
```javascript
// Get best practices and examples
mcp__exa__get_code_context_exa(
query="TypeScript OAuth2 JWT authentication patterns",
tokensNum="dynamic"
)
```
**Integration in flow_control.pre_analysis**:
```json
{
"step": "local_codebase_exploration",
"action": "Explore codebase structure",
"commands": [
"bash(rg '^(function|class|interface).*[task_keyword]' --type ts -n --max-count 15)",
"bash(find . -name '*[task_keyword]*' -type f | grep -v node_modules | head -10)"
],
"output_to": "codebase_structure"
}
```
---
## 2. Output Specifications
@@ -213,7 +208,11 @@ Generate individual `.task/IMPL-*.json` files with the following structure:
```
**Field Descriptions**:
- `id`: Task identifier (format: `IMPL-N`)
- `id`: Task identifier
- Single module format: `IMPL-N` (e.g., IMPL-001, IMPL-002)
- Multi-module format: `IMPL-{prefix}{seq}` (e.g., IMPL-A1, IMPL-B1, IMPL-C1)
- Prefix: A, B, C... (assigned by module detection order)
- Sequence: 1, 2, 3... (per-module increment)
- `title`: Descriptive task name summarizing the work
- `status`: Task state - `pending` (not started), `active` (in progress), `completed` (done), `blocked` (waiting on dependencies)
- `context_package_path`: Path to smart context package containing project structure, dependencies, and brainstorming artifacts catalog
@@ -225,7 +224,8 @@ Generate individual `.task/IMPL-*.json` files with the following structure:
"meta": {
"type": "feature|bugfix|refactor|test-gen|test-fix|docs",
"agent": "@code-developer|@action-planning-agent|@test-fix-agent|@universal-executor",
"execution_group": "parallel-abc123|null"
"execution_group": "parallel-abc123|null",
"module": "frontend|backend|shared|null"
}
}
```
@@ -234,6 +234,7 @@ Generate individual `.task/IMPL-*.json` files with the following structure:
- `type`: Task category - `feature` (new functionality), `bugfix` (fix defects), `refactor` (restructure code), `test-gen` (generate tests), `test-fix` (fix failing tests), `docs` (documentation)
- `agent`: Assigned agent for execution
- `execution_group`: Parallelization group ID (tasks with same ID can run concurrently) or `null` for sequential tasks
- `module`: Module identifier for multi-module projects (e.g., `frontend`, `backend`, `shared`) or `null` for single-module
**Test Task Extensions** (for type="test-gen" or type="test-fix"):
@@ -391,7 +392,7 @@ Generate individual `.task/IMPL-*.json` files with the following structure:
// Pattern: Project structure analysis
{
"step": "analyze_project_architecture",
"commands": ["bash(~/.claude/scripts/get_modules_by_depth.sh)"],
"commands": ["bash(ccw tool exec get_modules_by_depth '{}')"],
"output_to": "project_architecture"
},
@@ -604,10 +605,42 @@ Agent determines CLI tool usage per-step based on user semantics and task nature
- Analysis results (technical approach, architecture decisions)
- Brainstorming artifacts (role analyses, guidance specifications)
**Multi-Module Format** (when modules detected):
When multiple modules are detected (frontend/backend, etc.), organize IMPL_PLAN.md by module:
```markdown
# Implementation Plan
## Module A: Frontend (N tasks)
### IMPL-A1: [Task Title]
[Task details...]
### IMPL-A2: [Task Title]
[Task details...]
## Module B: Backend (N tasks)
### IMPL-B1: [Task Title]
[Task details...]
### IMPL-B2: [Task Title]
[Task details...]
## Cross-Module Dependencies
- IMPL-A1 → IMPL-B1 (Frontend depends on Backend API)
- IMPL-A2 → IMPL-B2 (UI state depends on Backend service)
```
**Cross-Module Dependency Notation**:
- During parallel planning, use `CROSS::{module}::{pattern}` format
- Example: `depends_on: ["CROSS::B::api-endpoint"]`
- Integration phase resolves to actual task IDs: `CROSS::B::api → IMPL-B1`
### 2.3 TODO_LIST.md Structure
Generate at `.workflow/active/{session_id}/TODO_LIST.md`:
**Single Module Format**:
```markdown
# Tasks: {Session Topic}
@@ -621,30 +654,54 @@ Generate at `.workflow/active/{session_id}/TODO_LIST.md`:
- `- [x]` = Completed task
```
**Multi-Module Format** (hierarchical by module):
```markdown
# Tasks: {Session Topic}
## Module A (Frontend)
- [ ] **IMPL-A1**: [Task Title] → [📋](./.task/IMPL-A1.json)
- [ ] **IMPL-A2**: [Task Title] → [📋](./.task/IMPL-A2.json)
## Module B (Backend)
- [ ] **IMPL-B1**: [Task Title] → [📋](./.task/IMPL-B1.json)
- [ ] **IMPL-B2**: [Task Title] → [📋](./.task/IMPL-B2.json)
## Cross-Module Dependencies
- IMPL-A1 → IMPL-B1 (Frontend depends on Backend API)
## Status Legend
- `- [ ]` = Pending task
- `- [x]` = Completed task
```
**Linking Rules**:
- Todo items → task JSON: `[📋](./.task/IMPL-XXX.json)`
- Completed tasks → summaries: `[✅](./.summaries/IMPL-XXX-summary.md)`
- Consistent ID schemes: IMPL-XXX
- Consistent ID schemes: `IMPL-N` (single) or `IMPL-{prefix}{seq}` (multi-module)
### 2.4 Complexity-Based Structure Selection
### 2.4 Complexity & Structure Selection
Use `analysis_results.complexity` or task count to determine structure:
**Simple Tasks** (≤5 tasks):
- Flat structure: IMPL_PLAN.md + TODO_LIST.md + task JSONs
- All tasks at same level
**Single Module Mode**:
- **Simple Tasks** (≤5 tasks): Flat structure
- **Medium Tasks** (6-12 tasks): Flat structure
- **Complex Tasks** (>12 tasks): Re-scope required (maximum 12 tasks hard limit)
**Medium Tasks** (6-12 tasks):
- Flat structure: IMPL_PLAN.md + TODO_LIST.md + task JSONs
- All tasks at same level
**Multi-Module Mode** (N+1 parallel planning):
- **Per-module limit**: ≤9 tasks per module
- **Total limit**: Sum of all module tasks ≤27 (3 modules × 9 tasks)
- **Task ID format**: `IMPL-{prefix}{seq}` (e.g., IMPL-A1, IMPL-B1)
- **Structure**: Hierarchical by module in IMPL_PLAN.md and TODO_LIST.md
**Complex Tasks** (>12 tasks):
- **Re-scope required**: Maximum 12 tasks hard limit
- If analysis_results contains >12 tasks, consolidate or request re-scoping
**Multi-Module Detection Triggers**:
- Explicit frontend/backend separation (`src/frontend`, `src/backend`)
- Monorepo structure (`packages/*`, `apps/*`)
- Context-package dependency clustering (2+ distinct module groups)
---
## 3. Quality & Standards
## 3. Quality Standards
### 3.1 Quantification Requirements (MANDATORY)
@@ -670,47 +727,46 @@ Use `analysis_results.complexity` or task count to determine structure:
- [ ] Each implementation step has its own acceptance criteria
**Examples**:
- GOOD: `"Implement 5 commands: [cmd1, cmd2, cmd3, cmd4, cmd5]"`
- BAD: `"Implement new commands"`
- GOOD: `"5 files created: verify by ls .claude/commands/*.md | wc -l = 5"`
- BAD: `"All commands implemented successfully"`
- GOOD: `"Implement 5 commands: [cmd1, cmd2, cmd3, cmd4, cmd5]"`
- BAD: `"Implement new commands"`
- GOOD: `"5 files created: verify by ls .claude/commands/*.md | wc -l = 5"`
- BAD: `"All commands implemented successfully"`
### 3.2 Planning Principles
### 3.2 Planning & Organization Standards
**Planning Principles**:
- Each stage produces working, testable code
- Clear success criteria for each deliverable
- Dependencies clearly identified between stages
- Incremental progress over big bangs
### 3.3 File Organization
**File Organization**:
- Session naming: `WFS-[topic-slug]`
- Task IDs: IMPL-XXX (flat structure only)
- Directory structure: flat task organization
### 3.4 Document Standards
- Task IDs:
- Single module: `IMPL-N` (e.g., IMPL-001, IMPL-002)
- Multi-module: `IMPL-{prefix}{seq}` (e.g., IMPL-A1, IMPL-B1)
- Directory structure: flat task organization (all tasks in `.task/`)
**Document Standards**:
- Proper linking between documents
- Consistent navigation and references
---
## 4. Key Reminders
### 3.3 Guidelines Checklist
**ALWAYS:**
- **Apply Quantification Requirements**: All requirements, acceptance criteria, and modification points MUST include explicit counts and enumerations
- **Load IMPL_PLAN template**: Read(~/.claude/workflows/cli-templates/prompts/workflow/impl-plan-template.txt) before generating IMPL_PLAN.md
- **Use provided context package**: Extract all information from structured context
- **Respect memory-first rule**: Use provided content (already loaded from memory/file)
- **Follow 6-field schema**: All task JSONs must have id, title, status, context_package_path, meta, context, flow_control
- **Map artifacts**: Use artifacts_inventory to populate task.context.artifacts array
- **Add MCP integration**: Include MCP tool steps in flow_control.pre_analysis when capabilities available
- **Validate task count**: Maximum 12 tasks hard limit, request re-scope if exceeded
- **Use session paths**: Construct all paths using provided session_id
- **Link documents properly**: Use correct linking format (📋 for JSON, ✅ for summaries)
- **Run validation checklist**: Verify all quantification requirements before finalizing task JSONs
- **Apply 举一反三 principle**: Adapt pre-analysis patterns to task-specific needs dynamically
- **Follow template validation**: Complete IMPL_PLAN.md template validation checklist before finalization
- Apply Quantification Requirements to all requirements, acceptance criteria, and modification points
- Load IMPL_PLAN template: `Read(~/.claude/workflows/cli-templates/prompts/workflow/impl-plan-template.txt)` before generating IMPL_PLAN.md
- Use provided context package: Extract all information from structured context
- Respect memory-first rule: Use provided content (already loaded from memory/file)
- Follow 6-field schema: All task JSONs must have id, title, status, context_package_path, meta, context, flow_control
- Map artifacts: Use artifacts_inventory to populate task.context.artifacts array
- Add MCP integration: Include MCP tool steps in flow_control.pre_analysis when capabilities available
- Validate task count: Maximum 12 tasks hard limit, request re-scope if exceeded
- Use session paths: Construct all paths using provided session_id
- Link documents properly: Use correct linking format (📋 for JSON, ✅ for summaries)
- Run validation checklist: Verify all quantification requirements before finalizing task JSONs
- Apply 举一反三 principle: Adapt pre-analysis patterns to task-specific needs dynamically
- Follow template validation: Complete IMPL_PLAN.md template validation checklist before finalization
**NEVER:**
- Load files directly (use provided context package instead)

View File

@@ -67,7 +67,7 @@ Score = 0
**1. Project Structure**:
```bash
~/.claude/scripts/get_modules_by_depth.sh
ccw tool exec get_modules_by_depth '{}'
```
**2. Content Search**:

View File

@@ -67,7 +67,7 @@ Phase 4: Output Generation
```bash
# Project structure
~/.claude/scripts/get_modules_by_depth.sh
ccw tool exec get_modules_by_depth '{}'
# Pattern discovery (adapt based on language)
rg "^export (class|interface|function) " --type ts -n

View File

@@ -119,17 +119,6 @@ This agent processes **simplified inline [FLOW_CONTROL]** format from brainstorm
- No dependency management
- Used for temporary context preparation
### NOT Handled by This Agent
**JSON format** (used by code-developer, test-fix-agent):
```json
"flow_control": {
"pre_analysis": [...],
"implementation_approach": [...]
}
```
This complete JSON format is stored in `.task/IMPL-*.json` files and handled by implementation agents, not conceptual-planning-agent.
### Role-Specific Analysis Dimensions
@@ -146,14 +135,14 @@ This complete JSON format is stored in `.task/IMPL-*.json` files and handled by
### Output Integration
**Gemini Analysis Integration**: Pattern-based analysis results are integrated into the single role's output:
- Enhanced `analysis.md` with codebase insights and architectural patterns
**Gemini Analysis Integration**: Pattern-based analysis results are integrated into role output documents:
- Enhanced analysis documents with codebase insights and architectural patterns
- Role-specific technical recommendations based on existing conventions
- Pattern-based best practices from actual code examination
- Realistic feasibility assessments based on current implementation
**Codex Analysis Integration**: Autonomous analysis results provide comprehensive insights:
- Enhanced `analysis.md` with autonomous development recommendations
- Enhanced analysis documents with autonomous development recommendations
- Role-specific strategy based on intelligent system understanding
- Autonomous development approaches and implementation guidance
- Self-guided optimization and integration recommendations
@@ -229,26 +218,23 @@ Generate documents according to loaded role template specifications:
**Output Location**: `.workflow/WFS-[session]/.brainstorming/[assigned-role]/`
**Required Files**:
- **analysis.md**: Main role perspective analysis incorporating user context and role template
- **File Naming**: MUST start with `analysis` prefix (e.g., `analysis.md`, `analysis-1.md`, `analysis-2.md`)
**Output Files**:
- **analysis.md**: Index document with overview (optionally with `@` references to sub-documents)
- **FORBIDDEN**: Never create `recommendations.md` or any file not starting with `analysis` prefix
- **Auto-split if large**: If content >800 lines, split to `analysis-1.md`, `analysis-2.md` (max 3 files: analysis.md, analysis-1.md, analysis-2.md)
- **Content**: Includes both analysis AND recommendations sections within analysis files
- **[role-deliverables]/**: Directory for specialized role outputs as defined in planning role template (optional)
- **analysis-{slug}.md**: Section content documents (slug from section heading: lowercase, hyphens)
- Maximum 5 sub-documents (merge related sections if needed)
- **Content**: Analysis AND recommendations sections
**File Structure Example**:
```
.workflow/WFS-[session]/.brainstorming/system-architect/
├── analysis.md # Main system architecture analysis with recommendations
├── analysis-1.md # (Optional) Continuation if content >800 lines
── deliverables/ # (Optional) Additional role-specific outputs
├── technical-architecture.md # System design specifications
├── technology-stack.md # Technology selection rationale
└── scalability-plan.md # Scaling strategy
├── analysis.md # Index with overview + @references
├── analysis-architecture-assessment.md # Section content
── analysis-technology-evaluation.md # Section content
├── analysis-integration-strategy.md # Section content
└── analysis-recommendations.md # Section content (max 5 sub-docs total)
NOTE: ALL brainstorming output files MUST start with 'analysis' prefix
FORBIDDEN: recommendations.md, recommendations-*.md, or any non-'analysis' prefixed files
NOTE: ALL files MUST start with 'analysis' prefix. Max 5 sub-documents.
```
## Role-Specific Planning Process
@@ -268,14 +254,10 @@ FORBIDDEN: recommendations.md, recommendations-*.md, or any non-'analysis' prefi
- **Validate Against Template**: Ensure analysis meets role template requirements and standards
### 3. Brainstorming Documentation Phase
- **Create analysis.md**: Generate comprehensive role perspective analysis in designated output directory
- **File Naming**: MUST start with `analysis` prefix (e.g., `analysis.md`, `analysis-1.md`, `analysis-2.md`)
- **FORBIDDEN**: Never create `recommendations.md` or any file not starting with `analysis` prefix
- **Content**: Include both analysis AND recommendations sections within analysis files
- **Auto-split**: If content >800 lines, split to `analysis-1.md`, `analysis-2.md` (max 3 files total)
- **Generate Role Deliverables**: Create specialized outputs as defined in planning role template (optional)
- **Create analysis.md**: Main document with overview (optionally with `@` references)
- **Create sub-documents**: `analysis-{slug}.md` for major sections (max 5)
- **Validate Output Structure**: Ensure all files saved to correct `.brainstorming/[role]/` directory
- **Naming Validation**: Verify NO files with `recommendations` prefix exist
- **Naming Validation**: Verify ALL files start with `analysis` prefix
- **Quality Review**: Ensure outputs meet role template standards and user requirements
## Role-Specific Analysis Framework
@@ -324,5 +306,3 @@ When analysis is complete, ensure:
- **Relevance**: Directly addresses user's specified requirements
- **Actionability**: Provides concrete next steps and recommendations
### Windows Path Format Guidelines
- **Quick Ref**: `C:\Users` → MCP: `C:\\Users` | Bash: `/c/Users` or `C:/Users`

View File

@@ -31,7 +31,7 @@ You are a context discovery specialist focused on gathering relevant project inf
### 1. Reference Documentation (Project Standards)
**Tools**:
- `Read()` - Load CLAUDE.md, README.md, architecture docs
- `Bash(~/.claude/scripts/get_modules_by_depth.sh)` - Project structure
- `Bash(ccw tool exec get_modules_by_depth '{}')` - Project structure
- `Glob()` - Find documentation files
**Use**: Phase 0 foundation setup
@@ -82,7 +82,7 @@ mcp__code-index__set_project_path(process.cwd())
mcp__code-index__refresh_index()
// 2. Project Structure
bash(~/.claude/scripts/get_modules_by_depth.sh)
bash(ccw tool exec get_modules_by_depth '{}')
// 3. Load Documentation (if not in memory)
if (!memory.has("CLAUDE.md")) Read(CLAUDE.md)
@@ -449,7 +449,12 @@ Calculate risk level based on:
{
"path": "system-architect/analysis.md",
"type": "primary",
"content": "# System Architecture Analysis\n\n## Overview\n..."
"content": "# System Architecture Analysis\n\n## Overview\n@analysis-architecture.md\n@analysis-recommendations.md"
},
{
"path": "system-architect/analysis-architecture.md",
"type": "supplementary",
"content": "# Architecture Assessment\n\n..."
}
]
}

View File

@@ -8,7 +8,7 @@ You are a documentation update coordinator for complex projects. Orchestrate par
## Core Mission
Execute depth-parallel updates for all modules using `~/.claude/scripts/update_module_claude.sh`. **Every module path must be processed**.
Execute depth-parallel updates for all modules using `ccw tool exec update_module_claude`. **Every module path must be processed**.
## Input Context
@@ -42,12 +42,12 @@ TodoWrite([
# 3. Launch parallel jobs (max 4)
# Depth 5 example (Layer 3 - use multi-layer):
~/.claude/scripts/update_module_claude.sh "multi-layer" "./.claude/workflows/cli-templates/prompts/analysis" "gemini" &
~/.claude/scripts/update_module_claude.sh "multi-layer" "./.claude/workflows/cli-templates/prompts/development" "gemini" &
ccw tool exec update_module_claude '{"strategy":"multi-layer","path":"./.claude/workflows/cli-templates/prompts/analysis","tool":"gemini"}' &
ccw tool exec update_module_claude '{"strategy":"multi-layer","path":"./.claude/workflows/cli-templates/prompts/development","tool":"gemini"}' &
# Depth 1 example (Layer 2 - use single-layer):
~/.claude/scripts/update_module_claude.sh "single-layer" "./src/auth" "gemini" &
~/.claude/scripts/update_module_claude.sh "single-layer" "./src/api" "gemini" &
ccw tool exec update_module_claude '{"strategy":"single-layer","path":"./src/auth","tool":"gemini"}' &
ccw tool exec update_module_claude '{"strategy":"single-layer","path":"./src/api","tool":"gemini"}' &
# ... up to 4 concurrent jobs
# 4. Wait for all depth jobs to complete