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>
2026-02-12 02:37:45 +08:00 · 2025-12-08 21:09:21 +08:00
parent 8b29f6bb7c
commit 813bfa8f97
67 changed files with 1311 additions and 1737 deletions
--- a/.claude/skills/command-guide/reference/agents/action-planning-agent.md
+++ b/.claude/skills/command-guide/reference/agents/action-planning-agent.md
@@ -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)