claude-code-workflow 6.3.53 → 7.0.0

package/.codex/AGENTS.md

@@ -1,122 +1,126 @@
-# Codex Code Guidelines
-
-
-## Code Quality Standards
-
-### Code Quality
-- Follow project's existing patterns
-- Match import style and naming conventions
-- Single responsibility per function/class
-- DRY (Don't Repeat Yourself)
-- YAGNI (You Aren't Gonna Need It)
-
-### Testing
-- Test all public functions
-- Test edge cases and error conditions
-- Mock external dependencies
-- Target 80%+ coverage
-
-### Error Handling
-- Proper try-catch blocks
-- Clear error messages
-- Graceful degradation
-- Don't expose sensitive info
-
-## Core Principles
-
-**Incremental Progress**:
-- Small, testable changes
-- Commit working code frequently
-- Build on previous work (subtasks)
-
-**Evidence-Based**:
-- Study 3+ similar patterns before implementing
-- Match project style exactly
-- Verify with existing code
-
-**Pragmatic**:
-- Boring solutions over clever code
-- Simple over complex
-- Adapt to project reality
-
-**Context Continuity** (Multi-Task):
-- Leverage resume for consistency
-- Maintain established patterns
-- Test integration between subtasks
-
-**Git Operations** (Parallel Task Safety):
-- Only stage/commit files directly produced by current task
-- Never touch unrelated changes or other task outputs
-- Use `git add <specific-files>` instead of `git add .`
-- Verify staged files before commit to avoid cross-task conflicts
-
-
-## System Optimization
-
-**Direct Binary Calls**: Always call binaries directly in `functions.shell`, set `workdir`, avoid shell wrappers (`bash -lc`, `cmd /c`, etc.)
-
-**Text Editing Priority**:
-1. Use `apply_patch` tool for all routine text edits
-2. Fall back to `sed` for single-line substitutions if unavailable
-3. Avoid Python editing scripts unless both fail
-
-**apply_patch invocation**:
-```json
-{
-  "command": ["apply_patch", "*** Begin Patch\n*** Update File: path/to/file\n@@\n- old\n+ new\n*** End Patch\n"],
-  "workdir": "<workdir>",
-  "justification": "Brief reason"
-}
-```
-
-**Windows UTF-8 Encoding** (before commands):
-```powershell
-[Console]::InputEncoding  = [Text.UTF8Encoding]::new($false)
-[Console]::OutputEncoding = [Text.UTF8Encoding]::new($false)
-chcp 65001 > $null
-```
-
-## Context Acquisition (MCP Tools Priority)
-
-**For task context gathering and analysis, ALWAYS prefer MCP tools**:
-
-1. **mcp__ace-tool__search_context** - HIGHEST PRIORITY for code discovery
-   - Semantic search with real-time codebase index
-   - Use for: finding implementations, understanding architecture, locating patterns
-   - Example: `mcp__ace-tool__search_context(project_root_path="/path", query="authentication logic")`
-
-2. **smart_search** - Fallback for structured search
-   - Use `smart_search(query="...")` for keyword/regex search
-   - Use `smart_search(action="find_files", pattern="*.ts")` for file discovery
-   - Supports modes: `auto`, `hybrid`, `exact`, `ripgrep`
-
-3. **read_file** - Batch file reading
-   - Read multiple files in parallel: `read_file(path="file1.ts")`, `read_file(path="file2.ts")`
-   - Supports glob patterns: `read_file(path="src/**/*.config.ts")`
-
-**Priority Order**:
-```
-ACE search_context (semantic) → smart_search (structured) → read_file (batch read) → shell commands (fallback)
-```
-
-**NEVER** use shell commands (`cat`, `find`, `grep`) when MCP tools are available.
-
-## Execution Checklist
-
-**Before**:
-- [ ] Understand PURPOSE and TASK clearly
-- [ ] Use ACE search_context first, fallback to smart_search for discovery
-- [ ] Use read_file to batch read context files, find 3+ patterns
-- [ ] Check RULES templates and constraints
-
-**During**:
-- [ ] Follow existing patterns exactly
-- [ ] Write tests alongside code
-- [ ] Run tests after every change
-- [ ] Commit working code incrementally
-
-**After**:
-- [ ] All tests pass
-- [ ] Coverage meets target
-- [ ] Build succeeds
-- [ ] All EXPECTED deliverables met
+# Codex Code Guidelines
+
+
+## Code Quality Standards
+
+### Code Quality
+- Follow project's existing patterns
+- Match import style and naming conventions
+- Single responsibility per function/class
+- DRY (Don't Repeat Yourself)
+- YAGNI (You Aren't Gonna Need It)
+
+### Testing
+- Test all public functions
+- Test edge cases and error conditions
+- Mock external dependencies
+- Target 80%+ coverage
+
+### Error Handling
+- Proper try-catch blocks
+- Clear error messages
+- Graceful degradation
+- Don't expose sensitive info
+
+## Core Principles
+
+**Incremental Progress**:
+- Small, testable changes
+- Commit working code frequently
+- Build on previous work (subtasks)
+
+**Evidence-Based**:
+- Study 3+ similar patterns before implementing
+- Match project style exactly
+- Verify with existing code
+
+**Pragmatic**:
+- Boring solutions over clever code
+- Simple over complex
+- Adapt to project reality
+
+**Context Continuity** (Multi-Task):
+- Leverage resume for consistency
+- Maintain established patterns
+- Test integration between subtasks
+
+**Git Operations** (Parallel Task Safety):
+- Only stage/commit files directly produced by current task
+- Never touch unrelated changes or other task outputs
+- Use `git add <specific-files>` instead of `git add .`
+- Verify staged files before commit to avoid cross-task conflicts
+
+**Multi-CLI Coexistence** (CRITICAL):
+- If your task conflicts with existing uncommitted changes, **STOP and report the conflict** instead of overwriting
+- Treat all pre-existing uncommitted changes as intentional work-in-progress by other tools
+
+
+## System Optimization
+
+**Direct Binary Calls**: Always call binaries directly in `functions.shell`, set `workdir`, avoid shell wrappers (`bash -lc`, `cmd /c`, etc.)
+
+**Text Editing Priority**:
+1. Use `apply_patch` tool for all routine text edits
+2. Fall back to `sed` for single-line substitutions if unavailable
+3. Avoid Python editing scripts unless both fail
+
+**apply_patch invocation**:
+```json
+{
+  "command": ["apply_patch", "*** Begin Patch\n*** Update File: path/to/file\n@@\n- old\n+ new\n*** End Patch\n"],
+  "workdir": "<workdir>",
+  "justification": "Brief reason"
+}
+```
+
+**Windows UTF-8 Encoding** (before commands):
+```powershell
+[Console]::InputEncoding  = [Text.UTF8Encoding]::new($false)
+[Console]::OutputEncoding = [Text.UTF8Encoding]::new($false)
+chcp 65001 > $null
+```
+
+## Context Acquisition (MCP Tools Priority)
+
+**For task context gathering and analysis, ALWAYS prefer MCP tools**:
+
+1. **mcp__ace-tool__search_context** - HIGHEST PRIORITY for code discovery
+   - Semantic search with real-time codebase index
+   - Use for: finding implementations, understanding architecture, locating patterns
+   - Example: `mcp__ace-tool__search_context(project_root_path="/path", query="authentication logic")`
+
+2. **smart_search** - Fallback for structured search
+   - Use `smart_search(query="...")` for keyword/regex search
+   - Use `smart_search(action="find_files", pattern="*.ts")` for file discovery
+   - Supports modes: `auto`, `hybrid`, `exact`, `ripgrep`
+
+3. **read_file** - Batch file reading
+   - Read multiple files in parallel: `read_file(path="file1.ts")`, `read_file(path="file2.ts")`
+   - Supports glob patterns: `read_file(path="src/**/*.config.ts")`
+
+**Priority Order**:
+```
+ACE search_context (semantic) → smart_search (structured) → read_file (batch read) → shell commands (fallback)
+```
+
+**NEVER** use shell commands (`cat`, `find`, `grep`) when MCP tools are available.
+
+## Execution Checklist
+
+**Before**:
+- [ ] Understand PURPOSE and TASK clearly
+- [ ] Use ACE search_context first, fallback to smart_search for discovery
+- [ ] Use read_file to batch read context files, find 3+ patterns
+- [ ] Check RULES templates and constraints
+
+**During**:
+- [ ] Follow existing patterns exactly
+- [ ] Write tests alongside code
+- [ ] Run tests after every change
+- [ ] Commit working code incrementally
+
+**After**:
+- [ ] All tests pass
+- [ ] Coverage meets target
+- [ ] Build succeeds
+- [ ] All EXPECTED deliverables met

package/.codex/agents/action-planning-agent.md

@@ -55,6 +55,17 @@ color: yellow
 **Step-by-step execution**:
 
 ```
+0. Load planning notes → Extract phase-level constraints (NEW)
+   Commands: Read('.workflow/active/{session-id}/planning-notes.md')
+   Output: Consolidated constraints from all workflow phases
+   Structure:
+     - User Intent: Original GOAL, KEY_CONSTRAINTS
+     - Context Findings: Critical files, architecture notes, constraints
+     - Conflict Decisions: Resolved conflicts, modified artifacts
+     - Consolidated Constraints: Numbered list of ALL constraints (Phase 1-3)
+
+   USAGE: This is the PRIMARY source of constraints. All task generation MUST respect these constraints.
+
 1. Load session metadata → Extract user input
    - User description: Original task/feature requirements
    - Project scope: User-specified boundaries and goals
@@ -175,7 +186,7 @@ if (contextPackage.brainstorm_artifacts?.role_analyses?.length > 0) {
    - Add quantified requirements and measurable acceptance criteria
 
 3. Create IMPL_PLAN.md
-   - Load template: Read(~/.claude/workflows/cli-templates/prompts/workflow/impl-plan-template.txt)
+   - Load template: Read(~/.ccw/workflows/cli-templates/prompts/workflow/impl-plan-template.txt)
    - Follow template structure and validation checklist
    - Populate all 8 sections with synthesized context
    - Document CCW workflow phase progression
@@ -277,8 +288,8 @@ function computeCliStrategy(task, allTasks) {
     "execution_group": "parallel-abc123|null",
     "module": "frontend|backend|shared|null",
     "execution_config": {
-      "method": "agent|hybrid|cli",
-      "cli_tool": "codex|gemini|qwen|auto",
+      "method": "agent|cli",
+      "cli_tool": "codex|gemini|qwen|auto|null",
       "enable_resume": true,
       "previous_cli_id": "string|null"
     }
@@ -292,32 +303,31 @@ function computeCliStrategy(task, allTasks) {
 - `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
 - `execution_config`: CLI execution settings (MUST align with userConfig from task-generate-agent)
-  - `method`: Execution method - `agent` (direct), `hybrid` (agent + CLI), `cli` (CLI only)
+  - `method`: Execution method - `agent` (direct) or `cli` (CLI only). Only two values in final task JSON.
   - `cli_tool`: Preferred CLI tool - `codex`, `gemini`, `qwen`, `auto`, or `null` (for agent-only)
   - `enable_resume`: Whether to use `--resume` for CLI continuity (default: true)
   - `previous_cli_id`: Previous task's CLI execution ID for resume (populated at runtime)
 
 **execution_config Alignment Rules** (MANDATORY):
 ```
-userConfig.executionMethod → meta.execution_config + implementation_approach
+userConfig.executionMethod → meta.execution_config
 
 "agent" →
   meta.execution_config = { method: "agent", cli_tool: null, enable_resume: false }
-  implementation_approach steps: NO command field (agent direct execution)
-
-"hybrid" →
-  meta.execution_config = { method: "hybrid", cli_tool: userConfig.preferredCliTool }
-  implementation_approach steps: command field ONLY on complex steps
+  Execution: Agent executes pre_analysis, then directly implements implementation_approach
 
 "cli" →
-  meta.execution_config = { method: "cli", cli_tool: userConfig.preferredCliTool }
-  implementation_approach steps: command field on ALL steps
+  meta.execution_config = { method: "cli", cli_tool: userConfig.preferredCliTool, enable_resume: true }
+  Execution: Agent executes pre_analysis, then hands off full context to CLI via buildCliHandoffPrompt()
+
+"hybrid" →
+  Per-task decision: set method to "agent" OR "cli" per task based on complexity
+  - Simple tasks (≤3 files, straightforward logic) → { method: "agent", cli_tool: null, enable_resume: false }
+  - Complex tasks (>3 files, complex logic, refactoring) → { method: "cli", cli_tool: userConfig.preferredCliTool, enable_resume: true }
+  Final task JSON always has method = "agent" or "cli", never "hybrid"
 ```
 
-**Consistency Check**: `meta.execution_config.method` MUST match presence of `command` fields:
-- `method: "agent"` → 0 steps have command field
-- `method: "hybrid"` → some steps have command field
-- `method: "cli"` → all steps have command field
+**IMPORTANT**: implementation_approach steps do NOT contain `command` fields. Execution routing is controlled by task-level `meta.execution_config.method` only.
 
 **Test Task Extensions** (for type="test-gen" or type="test-fix"):
 
@@ -336,7 +346,7 @@ userConfig.executionMethod → meta.execution_config + implementation_approach
 - `test_framework`: Existing test framework from project (required for test tasks)
 - `coverage_target`: Target code coverage percentage (optional)
 
-**Note**: CLI tool usage for test-fix tasks is now controlled via `flow_control.implementation_approach` steps with `command` fields, not via `meta.use_codex`.
+**Note**: CLI tool usage for test-fix tasks is now controlled via task-level `meta.execution_config.method`, not via `meta.use_codex`.
 
 #### Context Object
 
@@ -547,59 +557,45 @@ The examples above demonstrate **patterns**, not fixed requirements. Agent MUST:
 
 ##### Implementation Approach
 
-**Execution Modes**:
+**Execution Control**:
 
-The `implementation_approach` supports **two execution modes** based on the presence of the `command` field:
+The `implementation_approach` defines sequential implementation steps. Execution routing is controlled by **task-level `meta.execution_config.method`**, NOT by step-level `command` fields.
 
-1. **Default Mode (Agent Execution)** - `command` field **omitted**:
+**Two Execution Modes**:
+
+1. **Agent Mode** (`meta.execution_config.method = "agent"`):
    - Agent interprets `modification_points` and `logic_flow` autonomously
    - Direct agent execution with full context awareness
    - No external tool overhead
    - **Use for**: Standard implementation tasks where agent capability is sufficient
-   - **Required fields**: `step`, `title`, `description`, `modification_points`, `logic_flow`, `depends_on`, `output`
-
-2. **CLI Mode (Command Execution)** - `command` field **included**:
-   - Specified command executes the step directly
-   - Leverages specialized CLI tools (codex/gemini/qwen) for complex reasoning
-   - **Use for**: Large-scale features, complex refactoring, or when user explicitly requests CLI tool usage
-   - **Required fields**: Same as default mode **PLUS** `command`, `resume_from` (optional)
-   - **Command patterns** (with resume support):
-     - `ccw cli -p '[prompt]' --tool codex --mode write --cd [path]`
-     - `ccw cli -p '[prompt]' --resume ${previousCliId} --tool codex --mode write` (resume from previous)
-     - `ccw cli -p '[prompt]' --tool gemini --mode write --cd [path]` (write mode)
-   - **Resume mechanism**: When step depends on previous CLI execution, include `--resume` with previous execution ID
 
-**Semantic CLI Tool Selection**:
+2. **CLI Mode** (`meta.execution_config.method = "cli"`):
+   - Agent executes `pre_analysis`, then hands off full context to CLI via `buildCliHandoffPrompt()`
+   - CLI tool specified in `meta.execution_config.cli_tool` (codex/gemini/qwen)
+   - Leverages specialized CLI tools for complex reasoning
+   - **Use for**: Large-scale features, complex refactoring, or when userConfig.executionMethod = "cli"
 
-Agent determines CLI tool usage per-step based on user semantics and task nature.
-
-**Source**: Scan `metadata.task_description` from context-package.json for CLI tool preferences.
-
-**User Semantic Triggers** (patterns to detect in task_description):
-- "use Codex/codex" → Add `command` field with Codex CLI
-- "use Gemini/gemini" → Add `command` field with Gemini CLI
-- "use Qwen/qwen" → Add `command` field with Qwen CLI
-- "CLI execution" / "automated" → Infer appropriate CLI tool
+**Step Schema** (same for both modes):
+```json
+{
+  "step": 1,
+  "title": "Step title",
+  "description": "What to implement (may use [variable] placeholders from pre_analysis)",
+  "modification_points": ["Quantified changes: [list with counts]"],
+  "logic_flow": ["Implementation sequence"],
+  "depends_on": [0],
+  "output": "variable_name"
+}
+```
 
-**Task-Based Selection** (when no explicit user preference):
-- **Implementation/coding**: Codex preferred for autonomous development
-- **Analysis/exploration**: Gemini preferred for large context analysis
-- **Documentation**: Gemini/Qwen with write mode (`--mode write`)
-- **Testing**: Depends on complexity - simple=agent, complex=Codex
+**Required fields**: `step`, `title`, `description`, `modification_points`, `logic_flow`, `depends_on`, `output`
 
-**Default Behavior**: Agent always executes the workflow. CLI commands are embedded in `implementation_approach` steps:
-- Agent orchestrates task execution
-- When step has `command` field, agent executes it via CCW CLI
-- When step has no `command` field, agent implements directly
-- This maintains agent control while leveraging CLI tool power
+**IMPORTANT**: Do NOT add `command` field to implementation_approach steps. Execution routing is determined by task-level `meta.execution_config.method` only.
 
-**Key Principle**: The `command` field is **optional**. Agent decides based on user semantics and task complexity.
-
-**Examples**:
+**Example**:
 
 ```json
 [
-  // === DEFAULT MODE: Agent Execution (no command field) ===
   {
     "step": 1,
     "title": "Load and analyze role analyses",
@@ -636,33 +632,6 @@ Agent determines CLI tool usage per-step based on user semantics and task nature
     ],
     "depends_on": [1],
     "output": "implementation"
-  },
-
-  // === CLI MODE: Command Execution (optional command field) ===
-  {
-    "step": 3,
-    "title": "Execute implementation using CLI tool",
-    "description": "Use Codex/Gemini for complex autonomous execution",
-    "command": "ccw cli -p '[prompt]' --tool codex --mode write --cd [path]",
-    "modification_points": ["[Same as default mode]"],
-    "logic_flow": ["[Same as default mode]"],
-    "depends_on": [1, 2],
-    "output": "cli_implementation",
-    "cli_output_id": "step3_cli_id"  // Store execution ID for resume
-  },
-
-  // === CLI MODE with Resume: Continue from previous CLI execution ===
-  {
-    "step": 4,
-    "title": "Continue implementation with context",
-    "description": "Resume from previous step with accumulated context",
-    "command": "ccw cli -p '[continuation prompt]' --resume ${step3_cli_id} --tool codex --mode write",
-    "resume_from": "step3_cli_id",  // Reference previous step's CLI ID
-    "modification_points": ["[Continue from step 3]"],
-    "logic_flow": ["[Build on previous output]"],
-    "depends_on": [3],
-    "output": "continued_implementation",
-    "cli_output_id": "step4_cli_id"
   }
 ]
 ```
@@ -692,7 +661,7 @@ Agent determines CLI tool usage per-step based on user semantics and task nature
 **Template-Based Generation**:
 
 ```
-1. Load template: Read(~/.claude/workflows/cli-templates/prompts/workflow/impl-plan-template.txt)
+1. Load template: Read(~/.ccw/workflows/cli-templates/prompts/workflow/impl-plan-template.txt)
 2. Populate all sections following template structure
 3. Complete template validation checklist
 4. Generate at .workflow/active/{session_id}/IMPL_PLAN.md
@@ -785,13 +754,13 @@ Generate at `.workflow/active/{session_id}/TODO_LIST.md`:
 Use `analysis_results.complexity` or task count to determine structure:
 
 **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)
+- **Simple Tasks** (≤4 tasks): Flat structure
+- **Medium Tasks** (5-8 tasks): Flat structure
+- **Complex Tasks** (>8 tasks): Re-scope required (maximum 8 tasks hard limit)
 
 **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)
+- **Per-module limit**: ≤6 tasks per module
+- **Total limit**: No total limit (each module independently capped at 6 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
 
@@ -852,12 +821,38 @@ Use `analysis_results.complexity` or task count to determine structure:
 - Proper linking between documents
 - Consistent navigation and references
 
-### 3.3 Guidelines Checklist
+### 3.3 N+1 Context Recording
+
+**Purpose**: Record decisions and deferred items for N+1 planning continuity.
+
+**When**: After task generation, update `## N+1 Context` in planning-notes.md.
+
+**What to Record**:
+- **Decisions**: Architecture/technology choices with rationale (mark `Revisit?` if may change)
+- **Deferred**: Items explicitly moved to N+1 with reason
+
+**Example**:
+```markdown
+## N+1 Context
+### Decisions
+| Decision | Rationale | Revisit? |
+|----------|-----------|----------|
+| JWT over Session | Stateless scaling | No |
+| CROSS::B::api → IMPL-B1 | B1 defines base | Yes |
+
+### Deferred
+- [ ] Rate limiting - Requires Redis (N+1)
+- [ ] API versioning - Low priority
+```
+
+### 3.4 Guidelines Checklist
 
 **ALWAYS:**
+- **Load planning-notes.md FIRST**: Read planning-notes.md before context-package.json. Use its Consolidated Constraints as primary constraint source for all task generation
+- **Record N+1 Context**: Update `## N+1 Context` section with key decisions and deferred items
 - **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
 - 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
+- Load IMPL_PLAN template: `Read(~/.ccw/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
@@ -865,7 +860,7 @@ Use `analysis_results.complexity` or task count to determine structure:
 - **Compute CLI execution strategy**: Based on `depends_on`, set `cli_execution.strategy` (new/resume/fork/merge_fork)
 - 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
+- Validate task count: Maximum 8 tasks (single module) or 6 tasks per module (multi-module), 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
@@ -879,7 +874,7 @@ Use `analysis_results.complexity` or task count to determine structure:
 - Load files directly (use provided context package instead)
 - Assume default locations (always use session_id in paths)
 - Create circular dependencies in task.depends_on
-- Exceed 12 tasks without re-scoping
+- Exceed 8 tasks (single module) or 6 tasks per module (multi-module) without re-scoping
 - Skip artifact integration when artifacts_inventory is provided
 - Ignore MCP capabilities when available
 - Use fixed pre-analysis steps without task-specific adaptation

package/.codex/agents/cli-execution-agent.md

@@ -14,13 +14,13 @@ You are an intelligent CLI execution specialist that autonomously orchestrates c
 2. **Qwen (Fallback)** - Same capabilities as Gemini, use when unavailable
 3. **Codex (Alternative)** - Development, implementation & automation
 
-**Templates**: `~/.claude/workflows/cli-templates/prompts/`
+**Templates**: `~/.ccw/workflows/cli-templates/prompts/`
 - `analysis/` - pattern.txt, architecture.txt, code-execution-tracing.txt, security.txt, quality.txt
 - `development/` - feature.txt, refactor.txt, testing.txt, bug-diagnosis.txt
 - `planning/` - task-breakdown.txt, architecture-planning.txt
 - `memory/` - claude-module-unified.txt
 
-**Reference**: See `~/.claude/workflows/intelligent-tools-strategy.md` for complete usage guide
+**Reference**: See `~/.ccw/workflows/intelligent-tools-strategy.md` for complete usage guide
 
 ## 5-Phase Execution Workflow
 
@@ -129,7 +129,7 @@ CONTEXT: @CLAUDE.md @src/**/* @*.ts
 CONTEXT: @**/* @../shared/**/* @../types/**/*
 ```
 
-**2. Template Selection** (`~/.claude/workflows/cli-templates/prompts/`):
+**2. Template Selection** (`~/.ccw/workflows/cli-templates/prompts/`):
 ```
 analyze → analysis/code-execution-tracing.txt | analysis/pattern.txt
 execute → development/feature.txt
@@ -308,7 +308,7 @@ Codex unavailable → Gemini/Qwen write mode
 
 ## Templates Reference
 
-**Location**: `~/.claude/workflows/cli-templates/prompts/`
+**Location**: `~/.ccw/workflows/cli-templates/prompts/`
 
 **Analysis** (`analysis/`):
 - `pattern.txt` - Code pattern analysis