chore: bump version to 7.2.26

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

.ccw/workflows/cli-templates/schemas/team-tasks-schema.json

@@ -0,0 +1,255 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "team-tasks-schema",
+  "title": "Team Tasks State",
+  "description": "Universal tasks.json schema for all Codex team skills. Single source of truth for task state management, replacing Claude Code TaskCreate/TaskUpdate API.",
+
+  "type": "object",
+  "required": ["session_id", "skill", "pipeline", "requirement", "created_at", "tasks"],
+  "properties": {
+    "session_id": {
+      "type": "string",
+      "description": "Unique session identifier. Format: <skill-prefix>-<slug>-<YYYYMMDD>",
+      "pattern": "^[a-zA-Z0-9]+-[a-z0-9-]+-\\d{8}$",
+      "examples": ["tlv4-auth-system-20260324", "brs-product-strategy-20260324", "ao-api-perf-20260324"]
+    },
+    "skill": {
+      "type": "string",
+      "description": "Source team skill name (e.g., team-lifecycle-v4, team-brainstorm, team-arch-opt)"
+    },
+    "pipeline": {
+      "type": "string",
+      "description": "Selected pipeline name from the skill's specs/pipelines.md or specs/team-config.json"
+    },
+    "requirement": {
+      "type": "string",
+      "description": "Original user requirement text, verbatim"
+    },
+    "created_at": {
+      "type": "string",
+      "format": "date-time",
+      "description": "ISO 8601 creation timestamp with timezone"
+    },
+    "supervision": {
+      "type": "boolean",
+      "default": true,
+      "description": "Whether CHECKPOINT tasks are active"
+    },
+    "completed_waves": {
+      "type": "array",
+      "items": { "type": "integer", "minimum": 1 },
+      "default": [],
+      "description": "List of completed wave numbers"
+    },
+    "active_agents": {
+      "type": "object",
+      "additionalProperties": { "type": "string" },
+      "default": {},
+      "description": "Runtime tracking: { task_id: agent_id } for currently running agents"
+    },
+    "gc_rounds": {
+      "type": "integer",
+      "minimum": 0,
+      "default": 0,
+      "description": "Generator-Critic / Fix-Verify loop iteration count (skills with GC loops)"
+    },
+    "tasks": {
+      "type": "object",
+      "additionalProperties": { "$ref": "#/$defs/TaskEntry" },
+      "description": "Task registry: { TASK-ID: TaskEntry }"
+    }
+  },
+
+  "$defs": {
+    "TaskEntry": {
+      "type": "object",
+      "required": ["title", "description", "role", "deps", "wave", "status"],
+      "properties": {
+        "title": {
+          "type": "string",
+          "description": "Human-readable task name"
+        },
+        "description": {
+          "type": "string",
+          "description": "What the task should accomplish"
+        },
+        "role": {
+          "type": "string",
+          "description": "Role name matching roles/<role>/role.md in the skill directory"
+        },
+        "pipeline_phase": {
+          "type": "string",
+          "description": "Phase from the skill's pipelines.md Task Metadata Registry (skill-specific)"
+        },
+        "deps": {
+          "type": "array",
+          "items": { "type": "string" },
+          "default": [],
+          "description": "Task IDs that must complete before this task starts. All must be 'completed'"
+        },
+        "context_from": {
+          "type": "array",
+          "items": { "type": "string" },
+          "default": [],
+          "description": "Task IDs whose discoveries to load as upstream context"
+        },
+        "wave": {
+          "type": "integer",
+          "minimum": 1,
+          "description": "Execution wave number (1-based). Tasks in the same wave run in parallel"
+        },
+        "status": {
+          "type": "string",
+          "enum": ["pending", "in_progress", "completed", "failed", "skipped"],
+          "default": "pending",
+          "description": "Current task state"
+        },
+        "findings": {
+          "type": ["string", "null"],
+          "maxLength": 500,
+          "default": null,
+          "description": "Summary of task output (max 500 chars). Required when status=completed"
+        },
+        "quality_score": {
+          "type": ["number", "null"],
+          "minimum": 0,
+          "maximum": 100,
+          "default": null,
+          "description": "0-100, set by reviewer/evaluator roles only"
+        },
+        "supervision_verdict": {
+          "type": ["string", "null"],
+          "enum": ["pass", "warn", "block", null],
+          "default": null,
+          "description": "Set by CHECKPOINT/supervisor tasks only"
+        },
+        "error": {
+          "type": ["string", "null"],
+          "default": null,
+          "description": "Error description. Required when status=failed or status=skipped"
+        }
+      }
+    },
+
+    "DiscoveryEntry": {
+      "type": "object",
+      "required": ["task_id", "timestamp", "status", "findings", "data"],
+      "description": "Schema for discoveries/{task_id}.json — each task writes one on completion",
+      "properties": {
+        "task_id": {
+          "type": "string",
+          "description": "Matches the task key in tasks.json"
+        },
+        "worker": {
+          "type": "string",
+          "description": "Same as task_id (identifies the producing agent)"
+        },
+        "timestamp": {
+          "type": "string",
+          "format": "date-time",
+          "description": "ISO 8601 completion timestamp"
+        },
+        "type": {
+          "type": "string",
+          "description": "Same as pipeline_phase"
+        },
+        "status": {
+          "type": "string",
+          "enum": ["completed", "failed"]
+        },
+        "findings": {
+          "type": "string",
+          "maxLength": 500
+        },
+        "quality_score": {
+          "type": ["number", "null"]
+        },
+        "supervision_verdict": {
+          "type": ["string", "null"],
+          "enum": ["pass", "warn", "block", null]
+        },
+        "error": {
+          "type": ["string", "null"]
+        },
+        "data": {
+          "type": "object",
+          "properties": {
+            "key_findings": {
+              "type": "array",
+              "items": { "type": "string", "maxLength": 100 },
+              "maxItems": 5
+            },
+            "decisions": {
+              "type": "array",
+              "items": { "type": "string" },
+              "description": "Include rationale, not just choice"
+            },
+            "files_modified": {
+              "type": "array",
+              "items": { "type": "string" },
+              "description": "Only for implementation tasks"
+            },
+            "verification": {
+              "type": "string",
+              "enum": ["self-validated", "peer-reviewed", "tested"]
+            },
+            "risks_logged": {
+              "type": "integer",
+              "description": "CHECKPOINT only: count of risks"
+            },
+            "blocks_detected": {
+              "type": "integer",
+              "description": "CHECKPOINT only: count of blocking issues"
+            }
+          }
+        },
+        "artifacts_produced": {
+          "type": "array",
+          "items": { "type": "string" },
+          "description": "Paths to generated artifact files"
+        }
+      }
+    }
+  },
+
+  "$comment_validation_rules": {
+    "structural": [
+      "Unique IDs: every key in tasks must be unique",
+      "Valid deps: every entry in deps must reference an existing task ID",
+      "Valid context_from: every entry in context_from must reference an existing task ID",
+      "No cycles: dependency graph must be a DAG",
+      "Wave ordering: if task A depends on task B, then A.wave > B.wave",
+      "Role exists: role must match a directory in the skill's roles/"
+    ],
+    "runtime": [
+      "Status transitions: pending->in_progress, in_progress->completed|failed, pending->skipped",
+      "Dependency check: task can only move to in_progress if all deps are completed",
+      "Skip propagation: if any dep is failed|skipped, task is automatically skipped",
+      "Discovery required: completed task MUST have discoveries/{task_id}.json",
+      "Findings required: completed task MUST have non-null findings",
+      "Error required: failed|skipped task MUST have non-null error",
+      "Supervision fields: CHECKPOINT tasks MUST set supervision_verdict on completion"
+    ]
+  },
+
+  "$comment_claude_code_mapping": {
+    "TaskCreate": {
+      "title": "tasks[id].title",
+      "description": "tasks[id].description",
+      "assignee": "tasks[id].role",
+      "status_open": "tasks[id].status = pending",
+      "metadata.deps": "tasks[id].deps",
+      "metadata.wave": "tasks[id].wave"
+    },
+    "TaskUpdate": {
+      "status_in_progress": "Write tasks[id].status = in_progress",
+      "status_completed": "Write tasks[id].status = completed + Write discoveries/{id}.json",
+      "status_failed": "Write tasks[id].status = failed + tasks[id].error"
+    },
+    "team_msg": {
+      "get_state": "Read tasks.json + Read discoveries/{upstream_id}.json",
+      "state_update": "Write discoveries/{task_id}.json",
+      "broadcast": "Write to wisdom/*.md"
+    }
+  }
+}

.ccw/workflows/cli-tools-usage.md

@@ -1,601 +1,203 @@
 # CLI Tools Execution Specification
 
-## Table of Contents
-1. [Configuration Reference](#configuration-reference)
-2. [Tool Selection](#tool-selection)
-3. [Prompt Template](#prompt-template)
-4. [CLI Execution](#cli-execution)
-5. [Auto-Invoke Triggers](#auto-invoke-triggers)
-6. [Best Practices](#best-practices)
+Unified reference for `ccw cli` — runs agent tools (gemini, qwen, codex, claude, opencode) with a shared interface for prompt, mode, model, directory, templates, and session resume.
+
+**References**: `~/.claude/cli-tools.json` (tool config), `~/.ccw/templates/cli/` (protocol + prompt templates)
 
 ---
 
-## Configuration Reference
+## 1. Quick Reference
 
-### Configuration File
+### Command Syntax
 
-**Path**: `~/.claude/cli-tools.json`
+```bash
+ccw cli -p "<PROMPT>" [options]
+```
 
-All tool availability, model selection, and routing are defined in this configuration file.
+### Options
 
-### Configuration Fields
+| Option | Description | Default |
+|--------|-------------|---------|
+| `-p, --prompt` | **Required**. Prompt text | — |
+| `--tool <name>` | Tool: gemini, qwen, codex, claude, opencode | First enabled in config |
+| `--mode <mode>` | `analysis` (read-only), `write` (create/modify/delete), `review` (codex-only) | `analysis` |
+| `--model <model>` | Model override | Tool's `primaryModel` |
+| `--cd <dir>` | Working directory | Current directory |
+| `--includeDirs <dirs>` | Additional directories (comma-separated) | — |
+| `--rule <template>` | Load protocol + prompt template | — (optional) |
+| `--id <id>` | Execution ID | Auto: `{prefix}-{HHmmss}-{rand4}` |
+| `--resume [id]` | Resume session (last if no id, comma-separated for merge) | — |
+
+### Mode Definition (Authoritative)
+
+| Mode | Permission | Auto-Invoke Safe | Use For |
+|------|-----------|------------------|---------|
+| `analysis` | Read-only | Yes | Review, exploration, diagnosis, architecture analysis |
+| `write` | Create/Modify/Delete | No — requires explicit intent | Implementation, bug fixes, refactoring |
+| `review` | Read-only (git-aware) | Yes | **Codex only**. Uncommitted changes, branch diffs, specific commits |
+
+> `--mode` is the **authoritative** permission control for ccw cli. The `MODE:` field inside prompt text is a hint for the agent — both should be consistent, but `--mode` governs actual behavior.
+
+**Codex review mode**: Target flags (`--uncommitted`, `--base`, `--commit`) are codex-only and mutually exclusive with `-p`.
+
+---
+
+## 2. Configuration
+
+### Config File: `~/.claude/cli-tools.json`
 
 | Field | Description |
 |-------|-------------|
-| `enabled` | Tool availability status |
-| `primaryModel` | Default model for the tool |
+| `enabled` | Tool availability |
+| `primaryModel` | Default model |
 | `secondaryModel` | Fallback model |
-| `tags` | Capability tags for routing |
+| `tags` | Capability tags (for caller-side routing) |
 
 ### Tool Types
 
 | Type | Usage | Capabilities |
 |------|-------|--------------|
-| `builtin` | `--tool gemini` | Full (analysis + write tools) |
-| `cli-wrapper` | `--tool doubao` | Full (analysis + write tools) |
-| `api-endpoint` | `--tool g25` | **Analysis only** (no file write tools) |
+| `builtin` | `--tool gemini` | Full (analysis + write) |
+| `cli-wrapper` | `--tool doubao` | Full (analysis + write) |
+| `api-endpoint` | `--tool g25` | **Analysis only** (no file write) |
 
-> **Note**: `api-endpoint` tools only support analysis and code generation responses. They cannot create, modify, or delete files.
+### Tool Selection
+
+1. Explicit `--tool` specified → use it (validate enabled)
+2. No `--tool` → first enabled tool in config order
+
+### Fallback Chain
+
+Primary model fails → `secondaryModel` → next enabled tool → first enabled (default).
 
 ---
 
-## Tool Selection
+## 3. Prompt Construction
 
-### Tag-Based Routing
+### Assembly Order
 
-Tools are selected based on **tags** defined in the configuration. Use tags to match task requirements to tool capabilities.
+`ccw cli` builds the final prompt as:
 
-#### Common Tags
+1. **Mode protocol** — loaded based on `--mode` (analysis-protocol.md / write-protocol.md)
+2. **User prompt** — the `-p` value
+3. **Rule template** — loaded from `--rule` template name (if specified)
 
-| Tag | Use Case |
-|-----|----------|
-| `analysis` | Code review, architecture analysis, exploration |
-| `implementation` | Feature development, bug fixes |
-| `documentation` | Doc generation, comments |
-| `testing` | Test creation, coverage analysis |
-| `refactoring` | Code restructuring |
-| `security` | Security audits, vulnerability scanning |
-
-### Selection Algorithm
+### Prompt Template (6 Fields)
 
 ```
-1. Parse task intent → extract required capabilities
-2. Load cli-tools.json → get enabled tools with tags
-3. Match tags → filter tools supporting required capabilities
-4. Select tool → choose by priority (explicit > tag-match > default)
-5. Select model → use primaryModel, fallback to secondaryModel
+PURPOSE: [goal] + [why] + [success criteria]
+TASK: [step 1] | [step 2] | [step 3]
+MODE: analysis|write
+CONTEXT: @[file patterns] | Memory: [prior work context]
+EXPECTED: [output format] + [quality criteria]
+CONSTRAINTS: [scope limits] | [special requirements]
 ```
 
-### Selection Decision Tree
+- **PURPOSE**: What + Why + Success. Not "Analyze code" but "Identify auth vulnerabilities; success = OWASP Top 10 covered"
+- **TASK**: Specific verbs. Not "Review code" but "Scan for SQL injection | Check XSS | Verify CSRF"
+- **MODE**: Must match `--mode` flag
+- **CONTEXT**: File scope + memory from prior work
+- **EXPECTED**: Deliverable format, not just "Report"
+- **CONSTRAINTS**: Task-specific limits (vs `--rule` which loads generic templates)
 
-```
-┌─ Explicit --tool specified?
-│  └─→ YES: Use specified tool (validate enabled)
-│
-└─ NO: Tag-based selection
-   ├─ Task requires tags?
-   │  └─→ Match tools with matching tags
-   │     └─→ Multiple matches? Use first enabled
-   │
-   └─ No tag match?
-      └─→ Use default tool (first enabled in config)
-```
+### CONTEXT: File Patterns + Directory
 
-### Command Structure
+- `@**/*` — all files in working directory (default)
+- `@src/**/*.ts` — scoped pattern
+- `@../shared/**/*` — sibling directory (**requires `--includeDirs`**)
+
+**Rule**: If CONTEXT uses `@../dir/**/*`, must add `--includeDirs ../dir`.
 
 ```bash
-# Explicit tool selection
-ccw cli -p "<PROMPT>" --tool <tool-id> --mode <analysis|write>
-
-# Model override
-ccw cli -p "<PROMPT>" --tool <tool-id> --model <model-id> --mode <analysis|write>
-
-# Code review (codex only - review mode and target flags are invalid for other tools)
-ccw cli -p "<PROMPT>" --tool codex --mode review
-ccw cli --tool codex --mode review --commit <hash>
-
-# Tag-based auto-selection (future)
-ccw cli -p "<PROMPT>" --tags <tag1,tag2> --mode <analysis|write>
+# Cross-directory example
+ccw cli -p "<PROMPT>" --tool gemini --mode analysis \
+  --cd "src/auth" --includeDirs "../shared"
 ```
 
-### Tool Fallback Chain
-
-When primary tool fails or is unavailable:
-1. Check `secondaryModel` for same tool
-2. Try next enabled tool with matching tags
-3. Fall back to default enabled tool
-
----
-
-## Prompt Template
-
-### Universal Prompt Template
-
-```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]
-CONSTRAINTS: [domain constraints]" --tool <tool-id> --mode <analysis|write> --rule <category-template>
-```
-
-### Intent Capture Checklist (Before CLI Execution)
-
-**⚠️ CRITICAL**: Before executing any CLI command, verify these intent dimensions:
-
-**Intent Validation Questions**:
-- [ ] Is the objective specific and measurable?
-- [ ] Are success criteria defined?
-- [ ] Is the scope clearly bounded?
-- [ ] Are constraints and limitations stated?
-- [ ] Is the expected output format clear?
-- [ ] Is the action level (read/write) explicit?
-
-### Template Structure
-
-Every command MUST include these fields:
-
-- **PURPOSE**
-  - Purpose: Goal + motivation + success
-  - Components: What + Why + Success Criteria + Constraints
-  - Bad Example: "Analyze code"
-  - Good Example: "Identify security vulnerabilities in auth module to pass compliance audit; success = all OWASP Top 10 addressed; scope = src/auth/** only"
-
-- **TASK**
-  - Purpose: Actionable steps
-  - Components: Specific verbs + targets
-  - Bad Example: "• Review code • Find issues"
-  - Good Example: "• Scan for SQL injection in query builders • Check XSS in template rendering • Verify CSRF token validation"
-
-- **MODE**
-  - Purpose: Permission level
-  - Components: analysis / write / auto
-  - Bad Example: (missing)
-  - Good Example: "analysis" or "write"
-
-- **CONTEXT**
-  - Purpose: File scope + history
-  - Components: File patterns + Memory
-  - Bad Example: "@**/*"
-  - Good Example: "@src/auth/**/*.ts @shared/utils/security.ts \| Memory: Previous auth refactoring (WFS-001)"
-
-- **EXPECTED**
-  - Purpose: Output specification
-  - Components: Format + Quality + Structure
-  - Bad Example: "Report"
-  - Good Example: "Markdown report with: severity levels (Critical/High/Medium/Low), file:line references, remediation code snippets, priority ranking"
-
-- **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
-
-**Format**: `CONTEXT: [file patterns] | Memory: [memory context]`
-
-#### File Patterns
-
-- **`@**/*`**: All files (default)
-- **`@src/**/*.ts`**: TypeScript in src
-- **`@../shared/**/*`**: Sibling directory (requires `--includeDirs`)
-- **`@CLAUDE.md`**: Specific file
-
-#### Memory Context
+### CONTEXT: Memory
 
 Include when building on previous work:
 
-```bash
-# Cross-task reference
+```
 Memory: Building on auth refactoring (commit abc123), implementing refresh tokens
-
-# Cross-module integration
-Memory: Integration with auth module, using shared error patterns from @shared/utils/errors.ts
+Memory: Integration with auth module, using shared error patterns
 ```
 
-**Memory Sources**:
-- **Related Tasks**: Previous refactoring, extensions, conflict resolution
-- **Tech Stack Patterns**: Framework conventions, security guidelines
-- **Cross-Module References**: Integration points, shared utilities, type dependencies
+### --rule Templates
 
-#### Pattern Discovery Workflow
+**Universal**: `universal-rigorous-style`, `universal-creative-style`
 
-For complex requirements, discover files BEFORE CLI execution:
+**Analysis**: `analysis-trace-code-execution`, `analysis-diagnose-bug-root-cause`, `analysis-analyze-code-patterns`, `analysis-analyze-technical-document`, `analysis-review-architecture`, `analysis-review-code-quality`, `analysis-analyze-performance`, `analysis-assess-security-risks`
+
+**Planning**: `planning-plan-architecture-design`, `planning-breakdown-task-steps`, `planning-design-component-spec`, `planning-plan-migration-strategy`
+
+**Development**: `development-implement-feature`, `development-refactor-codebase`, `development-generate-tests`, `development-implement-component-ui`, `development-debug-runtime-issues`
+
+### Complete Example
 
 ```bash
-# 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
-CONTEXT: @components/Auth.tsx @types/auth.d.ts | Memory: Previous type refactoring
-
-# Step 3: Execute CLI
-ccw cli -p "..." --tool <tool-id> --mode analysis --cd "src"
-```
-
-### --rule Configuration
-
-**Use `--rule` option to auto-load templates**:
-
-```bash
-ccw cli -p "..." --tool gemini --mode analysis --rule analysis-review-architecture
-```
-
-### Mode Protocol References
-
-**`--rule` auto-loads Protocol based on mode**:
-- `--mode analysis` → analysis-protocol.md
-- `--mode write` → write-protocol.md
-
-**Protocol Mapping**:
-
-- **`analysis`** mode
-  - Permission: Read-only
-  - Constraint: No file create/modify/delete
-
-- **`write`** mode
-  - Permission: Create/Modify/Delete files
-  - Constraint: Full workflow execution
-
-### Template System
-
-**Available `--rule` template names**:
-
-**Universal**:
-- `universal-rigorous-style` - Precise tasks
-- `universal-creative-style` - Exploratory tasks
-
-**Analysis**:
-- `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**:
-- `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**:
-- `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
-
----
-
-## CLI Execution
-
-### MODE Options
-
-- **`analysis`**
-  - Permission: Read-only
-  - Use For: Code review, architecture analysis, pattern discovery, exploration
-  - Specification: Safe for all tools
-
-- **`write`**
-  - Permission: Create/Modify/Delete
-  - Use For: Feature implementation, bug fixes, documentation, code creation, file modifications
-  - Specification: Requires explicit `--mode write`
-
-- **`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. Other tools MUST NOT use this mode
-  - **Constraint**: Target flags (`--uncommitted`, `--base`, `--commit`) are **codex-only** and mutually exclusive with prompt
-    - 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
-
-- **`--tool <tool>`**
-  - Description: Tool from config (e.g., gemini, qwen, codex)
-  - Default: First enabled tool in config
-
-- **`--mode <mode>`**
-  - Description: **REQUIRED**: analysis, write, review
-  - Default: **NONE** (must specify)
-  - Note: `review` mode is **codex-only**. Using `--mode review` with other tools (gemini/qwen/claude) is invalid and should be rejected
-
-- **`--model <model>`**
-  - Description: Model override
-  - Default: Tool's primaryModel from config
-
-- **`--cd "<path>"`**
-  - Description: Working directory (quote if path contains spaces)
-  - Default: current
-
-- **`--includeDirs "<dirs>"`**
-  - Description: Additional directories (comma-separated, quote if paths contain spaces)
-  - Default: none
-
-- **`--id <id>`**
-  - Description: Execution ID (recommended, auto-generated if omitted)
-  - Default: Auto-generated in format `{prefix}-{HHmmss}-{rand4}` (e.g., `gem-143022-x7k2`)
-  - Prefix mapping: gemini→gem, qwen→qwn, codex→cdx, claude→cld, opencode→opc
-  - Note: ID is always output to stderr as `[CCW_EXEC_ID=<id>]` for programmatic capture
-
-- **`--resume [id]`**
-  - 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`)
-
-When using `--cd`:
-- `@**/*` = Files within working directory tree only
-- CANNOT reference parent/sibling via @ alone
-- Must use `--includeDirs` for external directories
-
-#### Include Directories (`--includeDirs`)
-
-**TWO-STEP requirement for external files**:
-1. Add `--includeDirs` parameter
-2. Reference in CONTEXT with @ patterns
-
-```bash
-# Single directory
-ccw cli -p "CONTEXT: @**/* @../shared/**/*" --tool <tool-id> --mode analysis --cd "src/auth" --includeDirs "../shared"
-
-# Multiple directories
-ccw cli -p "..." --tool <tool-id> --mode analysis --cd "src/auth" --includeDirs "../shared,../types,../utils"
-```
-
-**Rule**: If CONTEXT contains `@../dir/**/*`, MUST include `--includeDirs ../dir`
-
-**Benefits**: Excludes unrelated directories, reduces token usage
-
-### Session Resume
-
-**When to Use**:
-- Multi-round planning (analysis → planning → implementation)
-- Multi-model collaboration (tool A → tool B on same topic)
-- Topic continuity (building on previous findings)
-
-**Usage**:
-
-```bash
-ccw cli -p "Continue analyzing" --tool <tool-id> --mode analysis --resume              # Resume last
-ccw cli -p "Fix issues found" --tool <tool-id> --mode write --resume <id>              # Resume specific
-ccw cli -p "Merge findings" --tool <tool-id> --mode analysis --resume <id1>,<id2>      # Merge multiple
-```
-
-- **`--resume`**: Last session
-- **`--resume <id>`**: Specific session
-- **`--resume <id1>,<id2>`**: Merge sessions (comma-separated)
-
-**Context Assembly** (automatic):
-```
-=== PREVIOUS CONVERSATION ===
-USER PROMPT: [Previous prompt]
-ASSISTANT RESPONSE: [Previous output]
-=== CONTINUATION ===
-[Your new prompt]
-```
-
-### Subcommands
-
-#### `show` — List All Executions
-
-```bash
-ccw cli show                     # Active + recent completed executions
-ccw cli show --all               # Include full history
-```
-
-Displays a unified table of running and recent executions with: ID, Tool, Mode, Status, Duration, Prompt Preview.
-
-#### `watch <id>` — Stream Execution Output
-
-```bash
-ccw cli watch <id>               # Stream until completion (output to stderr)
-ccw cli watch <id> --timeout 120 # Auto-exit after 120 seconds
-```
-
-Behavior:
-- Output written to **stderr** (does not pollute stdout)
-- Exit code: 0 = success, 1 = error, 2 = timeout
-- Callers can `ccw cli watch <id> 2>/dev/null` to silently wait
-
-#### `output <id>` — Get Execution Output
-
-```bash
-ccw cli output <id>              # Final result only (default)
-ccw cli output <id> --verbose    # Full metadata + raw output
-ccw cli output <id> --raw        # Raw stdout (for piping)
-```
-
-Default returns `finalOutput > parsedOutput > stdout` — agent's final response text only.
-`--verbose` shows full metadata (ID, turn, status, project) plus raw stdout/stderr.
-
-#### ID Workflow Example
-
-```bash
-# Execute with auto-generated ID
-ccw cli -p "analyze code" --tool gemini --mode analysis
-# stderr outputs: [CCW_EXEC_ID=gem-143022-x7k2]
-
-# Execute with custom ID
-ccw cli -p "implement feature" --tool gemini --mode write --id my-task-1
-# stderr outputs: [CCW_EXEC_ID=my-task-1]
-
-# Check status
-ccw cli show
-
-# Watch running execution
-ccw cli watch gem-143022-x7k2
-
-# Get final result
-ccw cli output gem-143022-x7k2
-
-# Capture ID programmatically
-EXEC_ID=$(ccw cli -p "test" --tool gemini --mode analysis 2>&1 | grep -oP 'CCW_EXEC_ID=\K[^\]]+')
-ccw cli output $EXEC_ID
-```
-
-### Command Examples
-
-#### Task-Type Specific Templates
-
-**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
-TASK: • Scan for injection flaws (SQL, command, LDAP) • Check authentication bypass vectors • Evaluate session management • Assess sensitive data exposure
+ccw cli -p "PURPOSE: Identify OWASP Top 10 vulnerabilities in auth module; success = all critical/high documented with remediation
+TASK: Scan for injection flaws | Check auth bypass vectors | Evaluate session management | Assess 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
+CONTEXT: @src/auth/**/* @src/middleware/auth.ts | Memory: Using bcrypt + JWT
+EXPECTED: Severity matrix, file:line references, remediation snippets, priority ranking
 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
-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
-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
-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
-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
-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
-CONSTRAINTS: Preserve all existing behavior | Tests must pass
-" --tool gemini --mode write --rule development-refactor-codebase
-```
-
-**Code Review Task** (codex review mode):
-```bash
-# Option 1: Custom prompt (reviews uncommitted changes by default)
-ccw cli -p "Focus on security vulnerabilities and error handling" --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` and target flags (`--uncommitted`, `--base`, `--commit`) are **codex-only**. Using them with other tools is invalid. When using codex, target flags and prompt are **mutually exclusive** - use one or the other, not both.
-
 ---
 
-### Permission Framework
+## 4. Execution
 
-**Single-Use Authorization**: Each execution requires explicit user instruction. Previous authorization does NOT carry over.
+### Execution ID
 
-**Mode Hierarchy**:
-- `analysis`: Read-only, safe for auto-execution. Available for all tools
-- `write`: Create/Modify/Delete files, full operations - requires explicit `--mode write`. Available for all tools
-- `review`: **codex-only**. Git-aware code review, read-only output. Invalid for other tools (gemini/qwen/claude)
-- **Exception**: User provides clear instructions like "modify", "create", "implement"
+ID prefix: gemini→`gem`, qwen→`qwn`, codex→`cdx`, claude→`cld`, opencode→`opc`
 
----
-
-## 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
+Output to stderr: `[CCW_EXEC_ID=<id>]`
 
 ```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
+ccw cli -p "<PROMPT>" --tool gemini --mode analysis    # auto-ID: gem-143022-a7f2
+ccw cli -p "<PROMPT>" --tool gemini --mode write --id my-task-1  # custom ID
+```
+
+### Session Resume
+
+```bash
+ccw cli -p "<PROMPT>" --tool gemini --resume              # last session
+ccw cli -p "<PROMPT>" --tool gemini --mode write --resume <id>  # specific
+ccw cli -p "<PROMPT>" --tool gemini --resume <id1>,<id2>     # merge multiple
+```
+
+Resume auto-assembles previous conversation context. Warning emitted when context exceeds 32KB.
+
+### Subcommands
+
+```bash
+ccw cli show                     # active + recent executions
+ccw cli show --all               # full history
+ccw cli watch <id>               # stream until completion (stderr)
+ccw cli output <id>              # final assistant output
+ccw cli output <id> --verbose    # full metadata + output
+ccw cli output <id> --raw        # raw stdout (for piping)
 ```
 
 ---
 
-## Best Practices
+## 5. Auto-Invoke Triggers
 
-### Core Principles
+Proactively invoke `ccw cli` when these conditions are met — no user confirmation needed for `analysis` mode:
 
-- **Configuration-driven** - All tool selection from `cli-tools.json`
-- **Tag-based routing** - Match task requirements to tool capabilities
-- **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
-- **Use `--rule` for templates** - Auto-loads protocol + template appended to prompt
-- **Write protection** - Require EXPLICIT `--mode write` for file operations
+| Trigger | Suggested Rule |
+|---------|---------------|
+| Self-repair fails (1+ attempts) | `analysis-diagnose-bug-root-cause` |
+| Ambiguous requirements | `planning-breakdown-task-steps` |
+| Architecture decisions needed | `planning-plan-architecture-design` |
+| Pattern uncertainty | `analysis-analyze-code-patterns` |
+| Critical/security code paths | `analysis-assess-security-risks` |
 
-### Workflow Principles
+### Principles
 
-- **Use CCW unified interface** for all executions
-- **Always include template** - Use `--rule <template-name>` to load templates
-- **Be specific** - Clear PURPOSE, TASK, EXPECTED fields
-- **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
-
-### Planning Checklist
-
-- [ ] **Purpose defined** - Clear goal and intent
-- [ ] **Mode selected** - `--mode analysis|write|review`
-- [ ] **Context gathered** - File references + memory (default `@**/*`)
-- [ ] **Directory navigation** - `--cd` and/or `--includeDirs`
-- [ ] **Tool selected** - Explicit `--tool` or tag-based auto-selection
-- [ ] **Rule template** - `--rule <template-name>` loads template
-- [ ] **Constraints** - Domain constraints in CONSTRAINTS field
-
-### Execution Workflow
-
-1. **Load configuration** - Read `cli-tools.json` for available tools
-2. **Match by tags** - Select tool based on task requirements
-3. **Validate enabled** - Ensure selected tool is enabled
-4. **Execute with mode** - Always specify `--mode analysis|write|review`
-5. **Fallback gracefully** - Use secondary model or next matching tool on failure
+- Default `--mode analysis` (safe, read-only)
+- Wait for results before next action
+- Tool fallback: `gemini` → `qwen` → `codex`
+- Rule suggestions are guidelines — choose the best fit

.claude/CLAUDE.md

@@ -10,10 +10,6 @@
 **Strictly follow the cli-tools.json configuration**
 
 Available CLI endpoints are dynamically defined by the config file
-## Tool Execution
-
-- **Context Requirements**: @~/.ccw/workflows/context-tools.md
-- **File Modification**: @~/.ccw/workflows/file-modification.md
 
 ### Agent Calls
 - **Always use `run_in_background: false`** for Agent tool calls: `Agent({ subagent_type: "xxx", prompt: "...", run_in_background: false })` to ensure synchronous execution and immediate result visibility
@@ -40,6 +36,26 @@ Available CLI endpoints are dynamically defined by the config file
 - **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
 
+## Workflow Session Awareness
+
+### Artifact Locations
+
+| Workflow | Directory | Summary File |
+|----------|-----------|-------------|
+| `workflow-plan` | `.workflow/active/WFS-*/` | `workflow-session.json` |
+| `workflow-lite-plan` | `.workflow/.lite-plan/{slug}-{date}/` | `plan.json` |
+| `analyze-with-file` | `.workflow/.analysis/ANL-*/` | `conclusions.json` |
+| `multi-cli-plan` | `.workflow/.multi-cli-plan/*/` | `session-state.json` |
+| `lite-fix` | `.workflow/.lite-fix/*/` | `fix-plan.json` |
+| Other | `.workflow/.debug/`, `.workflow/.scratchpad/`, `.workflow/archives/` | — |
+
+### Pre-Task Discovery
+
+Before starting any workflow skill, scan recent sessions (7 days) to avoid conflicts and reuse prior work:
+- If overlapping file scope found: warn user, suggest `--continue` or reference prior session
+- If complementary: feed prior findings into new session context
+- `memory/MEMORY.md` for cross-session knowledge; `.workflow/` for session-specific artifacts — reference session IDs, don't duplicate
+
 ## Code Diagnostics
 
 - **Prefer `mcp__ide__getDiagnostics`** for code error checking over shell-based TypeScript compilation

.claude/agents/action-planning-agent.md

@@ -829,6 +829,12 @@ Generate at `.workflow/active/{session_id}/plan.json` following `plan-overview-b
 
 **Generation Timing**: After all `.task/IMPL-*.json` files are generated, aggregate into plan.json.
 
+**Validation**: After writing plan.json and task files, validate with json_builder:
+```bash
+ccw tool exec json_builder '{"cmd":"validate","target":"<session>/plan.json","schema":"plan"}'
+ccw tool exec json_builder '{"cmd":"validate","target":"<session>/.task/IMPL-001.json","schema":"task"}'
+```
+
 ### 2.3 IMPL_PLAN.md Structure
 
 **Template-Based Generation**:

.claude/agents/cli-explore-agent.md

@@ -5,6 +5,7 @@ description: |
   Orchestrates 4-phase workflow: Task Understanding → Analysis Execution → Schema Validation → Output Generation.
   Spawned by /explore command orchestrator.
 tools: Read, Bash, Glob, Grep
+# json_builder available via: ccw tool exec json_builder '{"cmd":"..."}' (Bash)
 color: yellow
 ---
 
@@ -66,9 +67,9 @@ Phase 4: Output Generation
    Store result as `project_structure` for module-aware file discovery in Phase 2.
 
 2. **Output Schema Loading** (if output file path specified in prompt):
-   - Exploration output → `cat ~/.ccw/workflows/cli-templates/schemas/explore-json-schema.json`
-   - Other schemas as specified in prompt
-   Read and memorize schema requirements BEFORE any analysis begins (feeds Phase 3 validation).
+   - Get schema summary: `ccw tool exec json_builder '{"cmd":"info","schema":"explore"}'` (or "diagnosis" for bug analysis)
+   - Initialize output file: `ccw tool exec json_builder '{"cmd":"init","schema":"explore","output":"<output_path>"}'`
+   - The tool returns requiredFields, arrayFields, and enumFields — memorize these for Phase 2.
 
 3. **Project Context Loading** (from spec system):
    - Load exploration specs using: `ccw spec load --category exploration`
@@ -150,55 +151,56 @@ RULES: {from prompt, if template specified} | analysis=READ-ONLY
 ---
 
 <schema_validation>
-## Phase 3: Schema Validation
+## Phase 3: Incremental Build & Validation (via json_builder)
 
-### CRITICAL: Schema Compliance Protocol
+**This phase replaces manual JSON writing + self-validation with tool-assisted construction.**
 
-**This phase is MANDATORY when schema file is specified in prompt.**
-
-**Step 1: Read Schema FIRST**
-```
-Read(schema_file_path)
+**Step 1: Set text fields** (discovered during Phase 2 analysis)
+```bash
+ccw tool exec json_builder '{"cmd":"set","target":"<output_path>","ops":[
+  {"path":"project_structure","value":"..."},
+  {"path":"patterns","value":"..."},
+  {"path":"dependencies","value":"..."},
+  {"path":"integration_points","value":"..."},
+  {"path":"constraints","value":"..."}
+]}'
 ```
 
-**Step 2: Extract Schema Requirements**
+**Step 2: Append file entries** (as discovered — one `set` per batch)
+```bash
+ccw tool exec json_builder '{"cmd":"set","target":"<output_path>","ops":[
+  {"path":"relevant_files[+]","value":{"path":"src/auth.ts","relevance":0.9,"rationale":"Contains AuthService.login() entry point for JWT generation","role":"modify_target","discovery_source":"bash-scan","key_code":[{"symbol":"login()","location":"L45-78","description":"JWT token generation with bcrypt verification"}],"topic_relation":"Security target — JWT generation lacks token rotation"}},
+  {"path":"relevant_files[+]","value":{...}}
+]}'
+```
 
-Parse and memorize:
-1. **Root structure** - Is it array `[...]` or object `{...}`?
-2. **Required fields** - List all `"required": [...]` arrays
-3. **Field names EXACTLY** - Copy character-by-character (case-sensitive)
-4. **Enum values** - Copy exact strings (e.g., `"critical"` not `"Critical"`)
-5. **Nested structures** - Note flat vs nested requirements
+The tool **automatically validates** each operation:
+- enum values (role, discovery_source) → rejects invalid
+- minLength (rationale >= 10) → rejects too short
+- type checking → rejects wrong types
 
-**Step 3: File Rationale Validation** (MANDATORY for relevant_files / affected_files)
+**Step 3: Set metadata**
+```bash
+ccw tool exec json_builder '{"cmd":"set","target":"<output_path>","ops":[
+  {"path":"_metadata.timestamp","value":"auto"},
+  {"path":"_metadata.task_description","value":"..."},
+  {"path":"_metadata.source","value":"cli-explore-agent"},
+  {"path":"_metadata.exploration_angle","value":"..."},
+  {"path":"_metadata.exploration_index","value":1},
+  {"path":"_metadata.total_explorations","value":2}
+]}'
+```
 
-Every file entry MUST have:
-- `rationale` (required, minLength 10): Specific reason tied to the exploration topic, NOT generic
-  - GOOD: "Contains AuthService.login() which is the entry point for JWT token generation"
-  - BAD: "Related to auth" or "Relevant file"
-- `role` (required, enum): Structural classification of why it was selected
-- `discovery_source` (optional but recommended): How the file was found
-- `key_code` (strongly recommended for relevance >= 0.7): Array of {symbol, location?, description}
-  - GOOD: [{"symbol": "AuthService.login()", "location": "L45-L78", "description": "JWT token generation with bcrypt verification, returns token pair"}]
-  - BAD: [{"symbol": "login", "description": "login function"}]
-- `topic_relation` (strongly recommended for relevance >= 0.7): Connection from exploration angle perspective
-  - GOOD: "Security exploration targets this file because JWT generation lacks token rotation"
-  - BAD: "Related to security"
+**Step 4: Final validation**
+```bash
+ccw tool exec json_builder '{"cmd":"validate","target":"<output_path>"}'
+```
+Returns `{valid, errors, warnings, stats}`. If errors exist → fix with `set` → re-validate.
 
-**Step 4: Pre-Output Validation Checklist**
-
-Before writing ANY JSON output, verify:
-
-- [ ] Root structure matches schema (array vs object)
-- [ ] ALL required fields present at each level
-- [ ] Field names EXACTLY match schema (character-by-character)
-- [ ] Enum values EXACTLY match schema (case-sensitive)
-- [ ] Nested structures follow schema pattern (flat vs nested)
-- [ ] Data types correct (string, integer, array, object)
-- [ ] Every file in relevant_files has: path + relevance + rationale + role
-- [ ] Every rationale is specific (>10 chars, not generic)
-- [ ] Files with relevance >= 0.7 have key_code with symbol + description (minLength 10)
-- [ ] Files with relevance >= 0.7 have topic_relation explaining connection to angle (minLength 15)
+**Quality reminders** (enforced by tool, but be aware):
+- `rationale`: Must be specific, not generic ("Related to auth" → rejected by semantic check)
+- `key_code`: Strongly recommended for relevance >= 0.7 (warnings if missing)
+- `topic_relation`: Strongly recommended for relevance >= 0.7 (warnings if missing)
 </schema_validation>
 
 ---
@@ -212,16 +214,12 @@ Brief summary:
 - Task completion status
 - Key findings summary
 - Generated file paths (if any)
+- Validation result (from Phase 3 Step 4)
 
-### File Output (as specified in prompt)
+### File Output
 
-**MANDATORY WORKFLOW**:
-
-1. `Read()` schema file BEFORE generating output
-2. Extract ALL field names from schema
-3. Build JSON using ONLY schema field names
-4. Validate against checklist before writing
-5. Write file with validated content
+File is already written by json_builder during Phase 3 (init + set operations).
+Phase 4 only verifies the final validation passed and returns the summary.
 </output_generation>
 
 ---
@@ -243,28 +241,19 @@ Brief summary:
 
 **ALWAYS**:
 1. **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
-2. Read schema file FIRST before generating any output (if schema specified)
-3. Copy field names EXACTLY from schema (case-sensitive)
-4. Verify root structure matches schema (array vs object)
-5. Match nested/flat structures as schema requires
-6. Use exact enum values from schema (case-sensitive)
-7. Include ALL required fields at every level
-8. Include file:line references in findings
-9. **Every file MUST have rationale**: Specific selection basis tied to the topic (not generic)
-10. **Every file MUST have role**: Classify as modify_target/dependency/pattern_reference/test_target/type_definition/integration_point/config/context_only
-11. **Track discovery source**: Record how each file was found (bash-scan/cli-analysis/ace-search/dependency-trace/manual)
-12. **Populate key_code for high-relevance files**: relevance >= 0.7 → key_code array with symbol, location, description
-13. **Populate topic_relation for high-relevance files**: relevance >= 0.7 → topic_relation explaining file-to-angle connection
+2. **Use json_builder** for all JSON output: `init` → `set` (incremental) → `validate`
+3. Include file:line references in findings
+4. **Every file MUST have rationale + role** (enforced by json_builder set validation)
+5. **Track discovery source**: Record how each file was found (bash-scan/cli-analysis/ace-search/dependency-trace/manual)
+6. **Populate key_code + topic_relation for high-relevance files** (relevance >= 0.7; json_builder warns if missing)
 
 **Bash Tool**:
 - Use `run_in_background=false` for all Bash/CLI calls to ensure foreground execution
 
 **NEVER**:
-1. Modify any files (read-only agent)
-2. Skip schema reading step when schema is specified
-3. Guess field names - ALWAYS copy from schema
-4. Assume structure - ALWAYS verify against schema
-5. Omit required fields
+1. Modify any source code files (read-only agent — json_builder writes only output JSON)
+2. Hand-write JSON output — always use json_builder
+3. Skip the `validate` step before returning
 </operational_rules>
 
 <output_contract>
@@ -282,11 +271,8 @@ When exploration is complete, return one of:
 
 Before returning, verify:
 - [ ] All 4 phases were executed (or skipped with justification)
-- [ ] Schema was read BEFORE output generation (if schema specified)
-- [ ] All field names match schema exactly (case-sensitive)
-- [ ] Every file entry has rationale (specific, >10 chars) and role
-- [ ] High-relevance files (>= 0.7) have key_code and topic_relation
+- [ ] json_builder `init` was called at start
+- [ ] json_builder `validate` returned `valid: true` (or all errors were fixed)
 - [ ] Discovery sources are tracked for all findings
-- [ ] No files were modified (read-only agent)
-- [ ] Output format matches schema root structure (array vs object)
+- [ ] No source code files were modified (read-only agent)
 </quality_gate>

.claude/agents/cli-lite-planning-agent.md

@@ -139,16 +139,15 @@ When `process_docs: true`, generate planning-context.md before sub-plan.json:
 
 ## Schema-Driven Output
 
-**CRITICAL**: Read the schema reference first to determine output structure:
-- `plan-overview-base-schema.json` → Implementation plan with `approach`, `complexity`
-- `plan-overview-fix-schema.json` → Fix plan with `root_cause`, `severity`, `risk_level`
+**CRITICAL**: Get schema info via json_builder to determine output structure:
+- `ccw tool exec json_builder '{"cmd":"info","schema":"plan"}'` → Implementation plan with `approach`, `complexity`
+- `ccw tool exec json_builder '{"cmd":"info","schema":"plan-fix"}'` → Fix plan with `root_cause`, `severity`, `risk_level`
 
-```javascript
-// Step 1: Always read schema first
-const schema = Bash(`cat ${schema_path}`)
-
-// Step 2: Generate plan conforming to schema
-const planObject = generatePlanFromSchema(schema, context)
+After generating plan.json and .task/*.json, validate:
+```bash
+ccw tool exec json_builder '{"cmd":"validate","target":"<session>/plan.json","schema":"plan"}'
+# For each task file:
+ccw tool exec json_builder '{"cmd":"validate","target":"<session>/.task/TASK-001.json","schema":"task"}'
 ```
 
 </schema_driven_output>
@@ -863,7 +862,7 @@ function validateTask(task) {
 
 **ALWAYS**:
 - **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
-- **Read schema first** to determine output structure
+- **Get schema info via json_builder** to determine output structure
 - Generate task IDs (TASK-001/TASK-002 for plan, FIX-001/FIX-002 for fix-plan)
 - Include depends_on (even if empty [])
 - **Assign cli_execution_id** (`{sessionId}-{taskId}`)
@@ -981,7 +980,7 @@ Upon completion, return one of:
 
 Before returning, verify:
 
-- [ ] Schema reference was read and output structure matches schema type (base vs fix)
+- [ ] Schema info was obtained via json_builder and output structure matches schema type (base vs fix)
 - [ ] All tasks have valid IDs (TASK-NNN or FIX-NNN format)
 - [ ] All tasks have 2+ implementation steps
 - [ ] All convergence criteria are quantified and testable (no vague language)

.claude/agents/cli-planning-agent.md

@@ -31,6 +31,9 @@ If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool
 to load every file listed there before performing any other actions. This is your
 primary context.
 
+**Load Project Context** (from spec system):
+- Run: `ccw spec load --category test` for test framework context, coverage targets, and conventions
+
 **Core responsibilities:**
 - **FIRST: Execute CLI analysis** with appropriate templates and context
 - Parse structured results (fix strategies, root causes, modification points)

.claude/agents/debug-explore-agent.md

@@ -36,6 +36,7 @@ Phase 5: Fix & Verification
 ## Phase 1: Bug Analysis
 
 **Load Project Context** (from spec system):
+- Load debug specs using: `ccw spec load --category debug` for known issues, workarounds, and root-cause notes
 - Load exploration specs using: `ccw spec load --category exploration` for tech stack context and coding constraints
 
 **Session Setup**:

.claude/agents/issue-plan-agent.md

@@ -348,7 +348,7 @@ Write({ file_path: filePath, content: newContent })
 .workflow/issues/solutions/{issue-id}.jsonl
 ```
 
-Each line is a solution JSON containing tasks. Schema: `cat ~/.ccw/workflows/cli-templates/schemas/solution-schema.json`
+Each line is a solution JSON containing tasks. Schema: `ccw tool exec json_builder '{"cmd":"info","schema":"solution"}'`
 
 ### 2.2 Return Summary
 
@@ -388,7 +388,7 @@ Each line is a solution JSON containing tasks. Schema: `cat ~/.ccw/workflows/cli
 
 **ALWAYS**:
 1. **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
-2. Read schema first: `cat ~/.ccw/workflows/cli-templates/schemas/solution-schema.json`
+2. Get schema info: `ccw tool exec json_builder '{"cmd":"info","schema":"solution"}'` (replaces reading raw schema)
 3. Use ACE semantic search as PRIMARY exploration tool
 4. Fetch issue details via `ccw issue status <id> --json`
 5. **Analyze failure history**: Check `issue.feedback` for type='failure', stage='execute'
@@ -408,6 +408,11 @@ Each line is a solution JSON containing tasks. Schema: `cat ~/.ccw/workflows/cli
 4. **Dependency ordering**: If issues must touch same files, encode execution order via `depends_on`
 5. **Scope minimization**: Prefer smaller, focused modifications over broad refactoring
 
+**VALIDATE**: After writing solution JSONL, validate each solution:
+```bash
+ccw tool exec json_builder '{"cmd":"validate","target":".workflow/issues/solutions/<issue-id>.jsonl","schema":"solution"}'
+```
+
 **NEVER**:
 1. Execute implementation (return plan only)
 2. Use vague criteria ("works correctly", "good performance")

.claude/agents/tdd-developer.md

@@ -383,6 +383,7 @@ Bash(
 ### Context Loading (Inherited from code-developer)
 
 **Standard Context Sources**:
+- Test specs: Run `ccw spec load --category test` for test framework context, conventions, and coverage targets
 - Task JSON: `description`, `convergence.criteria`, `focus_paths`
 - Context Package: `context_package_path` → brainstorm artifacts, exploration results
 - Tech Stack: `meta.shared_context.tech_stack` (skip auto-detection if present)

.claude/agents/team-worker.md

@@ -99,8 +99,8 @@ Execute on every loop iteration:
    - Subject starts with this role's `prefix` + `-` (e.g., `DRAFT-`, `IMPL-`)
    - Status is `pending`
    - `blockedBy` list is empty (all dependencies resolved)
-   - **Owner matches** `agent_name` from prompt (e.g., task owner "explorer-1" matches agent_name "explorer-1"). This prevents parallel workers from claiming each other's tasks.
    - If role has `additional_prefixes` (e.g., reviewer handles REVIEW-* + QUALITY-* + IMPROVE-*), check all prefixes
+   - **NOTE**: Do NOT filter by owner name. The system appends numeric suffixes to agent names (e.g., `profiler` → `profiler-4`), making exact owner matching unreliable. Prefix-based filtering is sufficient to prevent cross-role task claiming.
 3. **No matching tasks?**
    - If first iteration → report idle, SendMessage "No tasks found for [role]", STOP
    - If inner loop continuation → proceed to Phase 5-F (all done)

.claude/agents/test-action-planning-agent.md

@@ -52,6 +52,9 @@ Read("d:\Claude_dms3\.claude\agents\action-planning-agent.md")
 ```
 <!-- TODO: verify mandatory read path -->
 
+**Load Project Context** (from spec system):
+- Run: `ccw spec load --category test` for test framework, coverage targets, and conventions
+
 </role>
 
 <test_specification_reference>

.claude/agents/test-context-search-agent.md

@@ -25,6 +25,7 @@ You are a test context discovery specialist focused on gathering test coverage i
 **Mandatory Initial Read:**
 - Project `CLAUDE.md` for coding standards and conventions
 - Test session metadata (`workflow-session.json`) for session context
+- Run: `ccw spec load --category test` for test framework, coverage targets, and conventions
 
 **Core Responsibilities:**
 - Coverage-first analysis of existing tests

.claude/agents/test-fix-agent.md

@@ -34,6 +34,9 @@ If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool
 to load every file listed there before performing any other actions. This is your
 primary context.
 
+**Load Project Context** (from spec system):
+- Run: `ccw spec load --category test` for test framework, coverage targets, and conventions
+
 ## Core Philosophy
 
 **"Tests Are the Review"** - When all tests pass across all layers, the code is approved and ready. No separate review process is needed.

.claude/agents/workflow-research-agent.md

@@ -0,0 +1,112 @@
+---
+name: workflow-research-agent
+description: External research agent — web search for API details, design patterns, best practices, and technology validation. Returns structured markdown, does NOT write files.
+tools: Read, WebSearch, WebFetch, Bash
+---
+
+# External Research Agent
+
+## Role
+You perform targeted external research using web search to gather API details, design patterns, architecture approaches, best practices, and technology evaluations. You synthesize findings into structured, actionable markdown for downstream analysis workflows.
+
+Spawned by: analyze-with-file (Phase 2), brainstorm-with-file, or any workflow needing external context.
+
+**CRITICAL**: Return structured markdown only. Do NOT write any files unless explicitly instructed in the prompt.
+
+## Process
+
+1. **Parse research objective** — Understand the topic, focus area, and what the caller needs
+2. **Plan queries** — Design 3-5 focused search queries targeting the objective
+3. **Execute searches** — Use `WebSearch` for general research, `WebFetch` for specific documentation pages
+4. **Cross-reference** — If codebase files are provided in prompt, `Read` them to ground research in actual code context
+5. **Synthesize findings** — Extract key insights, patterns, and recommendations from search results
+6. **Return structured output** — Markdown-formatted research findings
+
+## Research Modes
+
+### Detail Verification (default for analyze)
+Focus: verify assumptions, check best practices, validate technology choices, confirm patterns.
+Queries target: benchmarks, production postmortems, known issues, compatibility matrices, official docs.
+
+### API Research (for implementation planning)
+Focus: concrete API details, library versions, integration patterns, configuration options.
+Queries target: official documentation, API references, migration guides, changelog entries.
+
+### Design Research (for brainstorm/architecture)
+Focus: design alternatives, architecture patterns, competitive analysis, UX patterns.
+Queries target: design systems, pattern libraries, case studies, comparison articles.
+
+## Execution
+
+### Query Strategy
+```
+1. Parse topic → extract key technologies, patterns, concepts
+2. Generate 3-5 queries:
+   - Q1: "{technology} best practices {year}"
+   - Q2: "{pattern} vs {alternative} comparison"
+   - Q3: "{technology} known issues production"
+   - Q4: "{specific API/library} documentation {version}"
+   - Q5: "{domain} architecture patterns"
+3. Execute queries via WebSearch
+4. For promising results, WebFetch full content for detail extraction
+5. Synthesize across all sources
+```
+
+### Codebase Grounding
+When the prompt includes `codebase_context` (file paths, patterns, tech stack):
+- Read referenced files to understand actual usage
+- Compare external best practices against current implementation
+- Flag gaps between current code and recommended patterns
+
+## Output Format
+
+Return structured markdown (do NOT write files):
+
+```markdown
+## Research: {topic}
+
+### Key Findings
+- **{Finding 1}**: {detail} (confidence: HIGH|MEDIUM|LOW, source: {url_or_reference})
+- **{Finding 2}**: {detail} (confidence: HIGH|MEDIUM|LOW, source: {url_or_reference})
+
+### Technology / API Details
+- **{Library/API}**: version {X}, {key capabilities}
+  - Integration: {how to integrate}
+  - Caveats: {known issues or limitations}
+
+### Best Practices
+- {Practice 1}: {rationale} (source: {reference})
+- {Practice 2}: {rationale} (source: {reference})
+
+### Recommended Approach
+{Prescriptive recommendation with rationale — "use X" not "consider X or Y" when evidence is strong}
+
+### Alternatives Considered
+| Option | Pros | Cons | Verdict |
+|--------|------|------|---------|
+| {A} | ... | ... | Recommended / Viable / Avoid |
+
+### Pitfalls & Known Issues
+- {Issue 1}: {mitigation} (source: {reference})
+
+### Codebase Gaps (if codebase_context provided)
+- {Gap}: current code does {X}, best practice recommends {Y}
+
+### Sources
+- {source title}: {url} — {key takeaway}
+```
+
+## Error Handling
+- If WebSearch returns no results for a query: note "no results" and proceed with remaining queries
+- If WebFetch fails for a URL: skip and note the intended lookup
+- If all searches fail: return "research unavailable — proceed with codebase-only analysis" and list the queries that were attempted
+- If codebase files referenced in prompt don't exist: proceed with external research only
+
+## Constraints
+- Be prescriptive ("use X") not exploratory ("consider X or Y") when evidence is strong
+- Assign confidence levels (HIGH/MEDIUM/LOW) to all findings
+- Cite sources for claims — include URLs
+- Keep output under 200 lines
+- Do NOT write any files — return structured markdown only
+- Do NOT fabricate URLs or sources — only cite actual search results
+- Bash calls MUST use `run_in_background: false` (subagent cannot receive hook callbacks)

.claude/commands/ddd/auto.md

@@ -1,359 +0,0 @@
----
-name: auto
-description: Chain command - automated document-driven development flow. Detects project state and runs the appropriate chain for new or existing projects.
-argument-hint: "[-y|--yes] [--skip-spec] [--skip-build] [--spec <session-id>] [--resume] \"project idea or task description\""
-allowed-tools: TodoWrite(*), Agent(*), AskUserQuestion(*), Read(*), Grep(*), Glob(*), Bash(*), Edit(*), Write(*)
----
-
-## Auto Mode
-
-When `--yes` or `-y`: All sub-commands run in auto mode. Minimal human intervention.
-
-# DDD Auto Command (/ddd:auto)
-
-## Purpose
-
-Orchestrate the full document-driven development lifecycle. **Adapts to project state** — works for both new projects and existing codebases.
-
-## Flow Variants
-
-### Variant 1: New Project (no code, no spec)
-```
-spec-generator → ddd:index-build → ddd:plan → ddd:execute → verify → ddd:sync
-```
-
-### Variant 2: Existing Project (has code, no spec)
-```
-ddd:scan → ddd:plan → ddd:execute → verify → ddd:sync
-```
-
-### Variant 3: Existing Project with Spec (has code + spec)
-```
-ddd:index-build → ddd:plan → ddd:execute → verify → ddd:sync
-```
-
-### Variant 4: Index Exists (has doc-index.json)
-```
-ddd:plan → ddd:execute → verify → ddd:sync
-```
-
-## Flow Diagram
-
-```
-┌────────────────────────────────────────────────────────────┐
-│                       /ddd:auto                            │
-│                                                            │
-│  Stage 0: Detect Project State                             │
-│  ┌───────────────────────────────────┐                     │
-│  │ has_codebase? has_spec? has_index?│                     │
-│  └────────────┬──────────────────────┘                     │
-│               │                                            │
-│    ┌──────────┼──────────────┐                             │
-│    ▼          ▼              ▼                              │
-│  No Code    Code Only    Code + Spec   Index Exists        │
-│    │          │              │              │               │
-│    ▼          │              │              │               │
-│  Stage 1     │              │              │               │
-│  Spec Gen    │              │              │               │
-│    │          │              │              │               │
-│    ▼          │              ▼              │               │
-│  Stage 2a   Stage 2b    Stage 2a          │               │
-│  index-build ddd:scan   index-build       │               │
-│  (Path A or Path B auto-detected)          │               │
-│    │                                       │               │
-│    └───────────────────┬───────────────────┘               │
-│                        ▼                                   │
-│              Stage 3: DDD Plan (enhanced)                  │
-│              (doc-index query + exploration +               │
-│               clarification + task planning)               │
-│                        │                                   │
-│                        ▼                                   │
-│              Stage 4: Execute                              │
-│              (ddd:execute = doc-aware execution)            │
-│                        │                                   │
-│                        ▼                                   │
-│              Stage 4.5: Verify Gate                        │
-│              (convergence + build + lint + tests            │
-│               → execution-manifest.json)                   │
-│                        │                                   │
-│                   PASS / WARN → continue                   │
-│                   FAIL → ask user                          │
-│                        │                                   │
-│                        ▼                                   │
-│              Stage 5: Doc Sync                             │
-│              (auto-triggered with --from-manifest,          │
-│               or manual /ddd:sync)                         │
-└────────────────────────────────────────────────────────────┘
-```
-
-## Stage 0: Project State Detection
-
-Automatically detect project state to determine which stages to run:
-
-```
-Check 1: doc-index.json exists?    → has_index
-Check 2: SPEC-* directories exist? → has_spec
-Check 3: Source code directories?   → has_codebase
-Check 4: project-tech.json exists?  → has_tech_analysis
-```
-
-### Decision Matrix
-
-| has_codebase | has_spec | has_index | Action |
-|:---:|:---:|:---:|--------|
-| No | No | No | Stage 1 (spec-gen) → Stage 2a (index-build) → Stage 3-5 |
-| No | Yes | No | Stage 2a (index-build) → Stage 3-5 |
-| Yes | No | No | **Stage 2b (ddd:scan)** → Stage 3-5 |
-| Yes | Yes | No | Stage 2a (index-build) → Stage 3-5 |
-| Yes | * | Yes | **Skip to Stage 3** (index exists) |
-
-### Override Flags
-
-| Flag | Effect |
-|------|--------|
-| `--skip-spec` | Never run spec-generator |
-| `--skip-build` | Never run index-build |
-| `--spec <id>` | Use specific spec session, force Path A |
-| `--from-scratch` | Rebuild index even if exists |
-
-## Stage 1: Specification (conditional)
-
-### Run When
-- No codebase AND no spec AND `--skip-spec` not set
-- User provides a new project idea (not an existing task description)
-
-### Skip When
-- `--skip-spec` flag
-- Codebase already exists (existing project)
-- `--spec <id>` pointing to existing session
-
-### Execution
-```
-Invoke /spec-generator with user input
-→ Output: .workflow/.doc-index/specs/SPEC-{slug}-{date}/
-```
-
-## Stage 2: Index Construction (conditional)
-
-### Run When
-- `doc-index.json` does not exist
-- OR `--from-scratch` flag
-
-### Route Selection
-
-```
-Has spec outputs → Stage 2a: /ddd:index-build (spec-first)
-No spec, has code → Stage 2b: /ddd:scan (code-first)
-```
-
-### Stage 2a: /ddd:index-build (has spec)
-```
-Invoke /ddd:index-build [-y] [-s <spec-id>]
-→ Output: doc-index.json from spec entities + code mapping
-```
-
-### Stage 2b: /ddd:scan (no spec, has code)
-```
-Invoke /ddd:scan [-y]
-→ Output: doc-index.json from code analysis + inferred features
-```
-
-### Skip When
-- `--skip-build` flag
-- `doc-index.json` exists AND NOT `--from-scratch`
-  - In this case, suggest `/ddd:update` for incremental refresh
-
-## Stage 3: Planning (always runs)
-
-### Execution
-
-```
-Invoke /ddd:plan [-y] "task description"
-```
-
-The enhanced `/ddd:plan` now performs:
-1. Doc-index query (instant context from features, requirements, components, ADRs)
-2. Doc-index-guided exploration (1-4 angles based on affected features)
-3. Clarification (aggregate ambiguities from exploration + doc-index gaps)
-4. Task planning (plan.json + TASK-*.json with doc_context traceability)
-5. Handoff selection
-
-Output:
-- `plan.json` — plan overview with doc_context
-- `.task/TASK-*.json` — individual tasks with doc_context
-- `exploration-{angle}.json` — exploration results (if Phase 2 ran)
-- `planning-context.md` — legacy context package
-
-### Handoff Decision
-
-After planning, `/ddd:plan` presents execution options:
-
-| Option | Description | Auto-Select When |
-|--------|-------------|-----------------|
-| **ddd:execute** | Document-aware execution (recommended) | Default in ddd workflow |
-| **lite-execute** | Standard execution (no doc awareness) | When doc traceability not needed |
-| **direct** | Start coding with context | User prefers manual |
-| **stop** | Just the plan context | Planning/research only |
-
-With `-y`: Auto-select `ddd:execute`.
-
-## Stage 4: Execution
-
-Based on Stage 3 handoff decision:
-
-| Mode | Delegates To |
-|------|-------------|
-| **ddd:execute** | `/ddd:execute --in-memory` with plan.json + doc-index enrichment |
-| lite-execute | `/workflow:lite-execute` with plan.json path |
-| direct | Output context package, developer works manually |
-| stop | End here, no execution |
-
-### ddd:execute Features (when selected)
-- Doc-enriched task prompts (feature context + component docs + ADR constraints)
-- Per-batch impact verification (changes stay within planned scope)
-- Result persistence (`TASK-*.result.json` per task, `execution-manifest.json` per session)
-- Post-execution verify gate (Stage 4.5, unless `--skip-verify`)
-- Post-completion auto-sync with manifest (Stage 5 triggered automatically)
-
-**Note**: When using `ddd:execute`, Stage 4.5 and Stage 5 are auto-triggered. For other modes, run Stage 5 manually.
-
-## Stage 4.5: Verify Gate
-
-Embedded within `ddd:execute` (Step 4.5). Runs after all batches complete, before doc sync.
-
-### Purpose
-
-Quality gate ensuring execution output is correct before committing to documentation updates. Prevents bad code from being "blessed" into the doc-index.
-
-### Checks Performed
-
-| Check | Description | Gate Behavior |
-|-------|-------------|---------------|
-| **Convergence** | Run `task.convergence.verification` for each task | FAIL if any critical task fails |
-| **Build** | Run project build command (`tsc --noEmit`, etc.) | FAIL on build errors |
-| **Lint** | Run project linter (`eslint`, etc.) | WARN only (non-blocking) |
-| **Regression** | Run full test suite, compare to baseline | FAIL on new test failures |
-
-### Gate Results
-
-| Result | Action |
-|--------|--------|
-| **PASS** | All checks passed → proceed to Stage 5 |
-| **WARN** | Non-critical issues (lint warnings) → proceed with warnings logged |
-| **FAIL** | Critical issues → ask user: fix now / skip sync / abort |
-| **FAIL + `-y`** | Log failures, set `error_state` in session, stop |
-
-### Output
-
-- `execution-manifest.json` — persisted to session folder, consumed by Stage 5
-- Contains: task results, files_modified (with task attribution), verify gate results
-
-## Stage 5: Post-Task Sync
-
-### Trigger
-- **Auto**: `/ddd:execute` triggers `/ddd:sync --from-manifest` automatically after verify gate passes
-- **Manual**: User runs `/ddd:sync` after completing work in direct/lite-execute mode
-- **Resume**: `/ddd:auto --resume` after task completion
-
-### Execution
-```
-# Auto mode (from ddd:execute): uses manifest for precise change tracking
-Invoke /ddd:sync [-y] --task-id <id> --from-manifest {session}/execution-manifest.json "task summary"
-
-# Manual mode (from direct/lite-execute): falls back to git diff
-Invoke /ddd:sync [-y] [--task-id <id>] "task summary"
-
-→ Updates: doc-index.json, feature-maps/, tech-registry/, action-logs/
-```
-
-## State Tracking
-
-### Session File: `.workflow/.doc-index/.auto-session.json`
-
-```json
-{
-  "session_id": "DAUTO-{timestamp}",
-  "input": "user's original input",
-  "detected_state": {
-    "has_codebase": true,
-    "has_spec": false,
-    "has_index": false,
-    "build_path": "code-first"
-  },
-  "stages_completed": ["detect", "index-build", "plan"],
-  "current_stage": "execute",
-  "spec_session": "SPEC-{slug}-{date}|null",
-  "plan_session": "planning/{task-slug}-{date}/",
-  "plan_context": "planning/{task-slug}-{date}/plan.json",
-  "execution_mode": "ddd:execute|lite-execute|direct|stop",
-  "execution_manifest": "planning/{task-slug}-{date}/execution-manifest.json|null",
-  "verify_gate": "PASS|WARN|FAIL|null",
-  "error_state": null,
-  "last_error": {
-    "stage": "execute",
-    "message": "Task TASK-002 failed: compilation error",
-    "timestamp": "ISO8601",
-    "recoverable": true
-  },
-  "created_at": "ISO8601",
-  "last_updated": "ISO8601"
-}
-```
-
-### Resume
-```
-/ddd:auto --resume    → Resume from current_stage in .auto-session.json
-```
-
-### Error Recovery
-```
-/ddd:auto --resume
-  IF error_state is set:
-    Display last error context
-    Ask: retry current stage / skip to next / abort
-  ELSE:
-    Resume from current_stage normally
-```
-
-## Example Workflows
-
-### New Project (Full Flow)
-```
-/ddd:auto "Build a task management API with user auth and team features"
-→ Stage 0: No code, no spec → need spec-gen
-→ Stage 1: spec-generator produces full spec
-→ Stage 2: index-build creates index from spec + empty codebase
-→ Stage 3: ddd:plan produces plan.json + TASK-*.json with doc_context
-→ Stage 4: ddd:execute runs tasks with feature context enrichment
-→ Stage 4.5: verify gate — convergence ✓, build ✓, tests ✓ → PASS
-→ Stage 5: ddd:sync --from-manifest auto-triggered, updates index
-```
-
-### Existing Project, No Spec (Code-First)
-```
-/ddd:auto "Add rate limiting to API endpoints"
-→ Stage 0: Has code, no spec, no index
-→ Stage 2b: ddd:scan analyzes code, infers features from codebase
-→ Stage 3: ddd:plan queries index, explores with security + patterns angles
-→ Stage 4: ddd:execute runs with rate-limit component docs as context
-→ Stage 4.5: verify gate — convergence ✓, tests 41/42 (1 regression) → WARN
-→ Stage 5: ddd:sync --from-manifest, registers new rate-limit component
-```
-
-### Existing Project with Index (Incremental)
-```
-/ddd:auto "Fix auth token expiration bug"
-→ Stage 0: Has code, has index → skip to plan
-→ Stage 3: ddd:plan finds feat-auth, REQ-002, tech-auth-service (Low complexity, skip exploration)
-→ Stage 4: ddd:execute runs single task with auth feature context
-→ Stage 4.5: verify gate — convergence ✓, build ✓, tests ✓ → PASS
-→ Stage 5: ddd:sync --from-manifest, updates tech-auth-service code locations
-```
-
-### Planning Only
-```
-/ddd:auto "Investigate payment module architecture"
-→ Stage 0-2: (as needed)
-→ Stage 3: ddd:plan shows full context with exploration results
-→ Stage 4: user selects "stop" → gets plan.json + context package only
-```

.claude/commands/ddd/doc-generate.md

@@ -1,222 +0,0 @@
----
-name: doc-generate
-description: Generate full document tree from doc-index.json. Layer 3 (components) → Layer 2 (features) → Layer 1 (indexes/overview). Standalone or called by scan/index-build.
-argument-hint: "[-y|--yes] [--layer <3|2|1|all>] [--force] [--skip-overview] [--skip-schema]"
-allowed-tools: TodoWrite(*), Agent(*), AskUserQuestion(*), Read(*), Grep(*), Glob(*), Bash(*), Edit(*), Write(*)
----
-
-## Auto Mode
-
-When `--yes` or `-y`: Auto-generate all layers without confirmation prompts.
-
-# DDD Doc Generate Command (/ddd:doc-generate)
-
-## Purpose
-
-Generate the complete document tree from `doc-index.json`. **Single source of truth** for all document generation logic, following bottom-up Layer 3 → 2 → 1 strategy.
-
-```
-doc-index.json → tech-registry/*.md (L3) → feature-maps/*.md (L2) → _index.md + README + ARCHITECTURE (L1)
-```
-
-## When to Use
-
-| Scenario | Use |
-|----------|-----|
-| After `/ddd:scan` builds doc-index.json | **doc-generate** (auto-called by scan) |
-| After `/ddd:index-build` builds doc-index.json | **doc-generate** (auto-called by index-build) |
-| Rebuild all docs from existing index | **doc-generate --force** |
-| Regenerate only component docs | **doc-generate --layer 3** |
-| Regenerate only overview/index docs | **doc-generate --layer 1** |
-
-## Prerequisite
-
-- `doc-index.json` must exist at `.workflow/.doc-index/doc-index.json`
-- If not found → error: "No doc-index.json found. Run /ddd:scan or /ddd:index-build first."
-
-## Storage Output
-
-```
-.workflow/.doc-index/
-├── doc-index.json              ← Input (read-only, not modified)
-├── SCHEMA.md                   ← Schema documentation
-├── README.md                   ← Project overview (Layer 1)
-├── ARCHITECTURE.md             ← Architecture overview (Layer 1)
-├── feature-maps/               ← Feature documentation (Layer 2)
-│   ├── _index.md
-│   └── {feature-slug}.md
-├── tech-registry/              ← Component documentation (Layer 3)
-│   ├── _index.md
-│   └── {component-slug}.md
-└── planning/                   ← Planning sessions (Layer 1)
-    ├── _index.md               ← Planning sessions index
-    └── {task-slug}-{date}/     ← Individual session folders
-```
-
-## Phase 1: Load & Validate
-
-### 1.1 Load doc-index.json
-
-```
-Read .workflow/.doc-index/doc-index.json
-Validate: features[], technicalComponents[] are non-empty arrays
-```
-
-### 1.2 Schema Version Check
-
-```javascript
-const schemaVersion = docIndex.schema_version || '0.0';
-if (schemaVersion !== '1.0') {
-  warn(`Schema version mismatch: found ${schemaVersion}, expected 1.0`);
-}
-```
-
-### 1.3 Determine Generation Scope
-
-```
-IF --layer 3:  generate Layer 3 only
-IF --layer 2:  generate Layer 2 only (requires Layer 3 exists)
-IF --layer 1:  generate Layer 1 only (requires Layer 2 exists)
-IF --layer all (default): generate Layer 3 → 2 → 1
-```
-
-### 1.4 Check Existing Docs
-
-```
-IF docs already exist AND NOT --force:
-  Warn: "Documents already exist. Use --force to overwrite."
-  Ask user (unless -y → overwrite)
-```
-
-## Phase 2: Layer 3 -- Component Documentation
-
-For each component in `technicalComponents[]`, call the generate_ddd_docs endpoint:
-
-```bash
-for COMPONENT_ID in "${technicalComponents[@]}"; do
-  ccw tool exec generate_ddd_docs '{"strategy":"component","entityId":"'"$COMPONENT_ID"'","tool":"gemini"}'
-done
-```
-
-The endpoint handles:
-- Loading the component entity from doc-index.json
-- Building YAML frontmatter (layer: 3, component_id, name, type, features, code_locations, generated_at)
-- Constructing the CLI prompt with code context paths
-- **Including Change History section**: Pull related entries from `doc-index.json.actions[]` where `affectedComponents` includes this component ID. Display as timeline (date, action type, description)
-- Writing output to `.workflow/.doc-index/tech-registry/{slug}.md`
-- Tool fallback (gemini -> qwen -> codex) on failure
-
-Output: `.workflow/.doc-index/tech-registry/{component-slug}.md`
-
-## Phase 3: Layer 2 -- Feature Documentation
-
-For each feature in `features[]`, call the generate_ddd_docs endpoint:
-
-```bash
-for FEATURE_ID in "${features[@]}"; do
-  ccw tool exec generate_ddd_docs '{"strategy":"feature","entityId":"'"$FEATURE_ID"'","tool":"gemini"}'
-done
-```
-
-The endpoint handles:
-- Loading the feature entity from doc-index.json
-- Building YAML frontmatter (layer: 2, feature_id, name, epic_id, status, requirements, components, tags, generated_at)
-- Constructing the CLI prompt referencing Layer 3 component docs
-- **Including Change History section**: Pull related entries from `doc-index.json.actions[]` where `affectedFeatures` includes this feature ID. Display as timeline (date, action type, description)
-- Writing output to `.workflow/.doc-index/feature-maps/{slug}.md`
-- Tool fallback (gemini -> qwen -> codex) on failure
-
-Output: `.workflow/.doc-index/feature-maps/{feature-slug}.md`
-
-## Phase 4: Layer 1 -- Index & Overview Documentation
-
-### 4.1 Index Documents
-
-Generate catalog files for each subdirectory:
-
-```bash
-# Feature maps index
-ccw tool exec generate_ddd_docs '{"strategy":"index","entityId":"feature-maps","tool":"gemini"}'
-
-# Tech registry index
-ccw tool exec generate_ddd_docs '{"strategy":"index","entityId":"tech-registry","tool":"gemini"}'
-
-# Action logs index
-ccw tool exec generate_ddd_docs '{"strategy":"index","entityId":"action-logs","tool":"gemini"}'
-
-# Planning sessions index
-ccw tool exec generate_ddd_docs '{"strategy":"index","entityId":"planning","tool":"gemini"}'
-```
-
-Or generate all indexes at once (omit entityId):
-
-```bash
-ccw tool exec generate_ddd_docs '{"strategy":"index","tool":"gemini"}'
-```
-
-### 4.2 README.md (unless --skip-overview)
-
-```bash
-ccw tool exec generate_ddd_docs '{"strategy":"overview","tool":"gemini"}'
-```
-
-### 4.3 ARCHITECTURE.md (unless --skip-overview)
-
-```bash
-ccw tool exec generate_ddd_docs '{"strategy":"overview","entityId":"architecture","tool":"gemini"}'
-```
-
-## Phase 5: SCHEMA.md (unless --skip-schema)
-
-### 5.1 Generate Schema Documentation
-
-```bash
-ccw tool exec generate_ddd_docs '{"strategy":"schema","tool":"gemini"}'
-```
-
-### 5.2 Versioning Policy
-
-**Semantic Versioning**:
-- **Major** (X.0): Breaking changes (field removal, type changes, incompatible structure)
-- **Minor** (X.Y): Non-breaking additions (new optional fields, new sections)
-
-**Migration Protocol**:
-1. Detect version mismatch in ddd:plan/ddd:sync
-2. Log warning with migration instructions
-3. Provide migration script or regeneration option
-4. Update schema_version after successful migration
-
-## Phase 6: Generation Report
-
-```
-Document Generation Report
-
-Project: {name}
-Source: doc-index.json (build_path: {spec-first|code-first})
-
-Generated:
-  Layer 3 (Components): {N} documents in tech-registry/
-  Layer 2 (Features):   {N} documents in feature-maps/
-  Layer 1 (Indexes):    {N} documents (_index.md, README, ARCHITECTURE)
-  Schema:               SCHEMA.md
-
-Total: {N} documents generated
-```
-
-## Flags
-
-| Flag | Effect |
-|------|--------|
-| `-y, --yes` | Auto-confirm all decisions |
-| `--layer <3\|2\|1\|all>` | Generate specific layer only (default: all) |
-| `--force` | Overwrite existing documents |
-| `--skip-overview` | Skip README.md, ARCHITECTURE.md, planning/_index.md |
-| `--skip-schema` | Skip SCHEMA.md generation |
-
-## Integration Points
-
-- **Input from**: `doc-index.json` (from `/ddd:scan` or `/ddd:index-build`)
-- **Called by**: `/ddd:scan` (after index assembly), `/ddd:index-build` (after index assembly)
-- **Standalone**: Can be run independently on any project with existing doc-index.json
-- **Output**: Complete document tree in `.workflow/.doc-index/`
-- **Endpoint**: `ccw tool exec generate_ddd_docs` handles prompt construction, frontmatter, tool fallback, and file creation

.claude/commands/ddd/doc-refresh.md

@@ -1,218 +0,0 @@
----
-name: doc-refresh
-description: Incrementally update affected documents based on changed components/features. Layer 3 → 2 → 1 selective refresh. Called by sync/update or used standalone.
-argument-hint: "[-y|--yes] [--components <id1,id2,...>] [--features <id1,id2,...>] [--minimal] [--dry-run]"
-allowed-tools: TodoWrite(*), Agent(*), AskUserQuestion(*), Read(*), Grep(*), Glob(*), Bash(*), Edit(*), Write(*)
----
-
-## Auto Mode
-
-When `--yes` or `-y`: Auto-update affected documents without confirmation prompts.
-
-# DDD Doc Refresh Command (/ddd:doc-refresh)
-
-## Purpose
-
-Incrementally update **only the affected documents** after code changes. Unlike `/ddd:doc-generate` (full generation), this command selectively refreshes documents for specific components and features.
-
-```
-affected component/feature IDs → update tech-registry (L3) → update feature-maps (L2) → update indexes (L1)
-```
-
-## When to Use
-
-| Scenario | Use |
-|----------|-----|
-| After `/ddd:sync` detects code changes | **doc-refresh** (auto-called by sync) |
-| After `/ddd:update` traces impact | **doc-refresh** (auto-called by update) |
-| Manual refresh of specific component docs | **doc-refresh --components tech-auth-service** |
-| Quick metadata-only update | **doc-refresh --minimal --components tech-auth-service** |
-| Preview what would change | **doc-refresh --dry-run --components tech-auth-service** |
-
-## Prerequisite
-
-- `doc-index.json` must exist at `.workflow/.doc-index/doc-index.json`
-- At least one of `--components` or `--features` must be provided (or received from caller)
-- Corresponding documents must already exist (generated by `/ddd:doc-generate`)
-- If documents missing → error: "Documents not found. Run /ddd:doc-generate first."
-
-## Phase 1: Determine Refresh Scope
-
-### 1.1 Resolve Affected Entities
-
-```
-IF --components provided:
-  affected_components = parse comma-separated IDs
-  affected_features = lookup featureIds for each component in doc-index.json
-
-IF --features provided:
-  affected_features = parse comma-separated IDs
-  affected_components = union of all component IDs linked to features
-
-Merge both sets if both flags provided.
-```
-
-### 1.2 Validate Entities Exist
-
-For each ID, verify it exists in doc-index.json. Warn and skip missing IDs.
-
-### 1.3 Check Document Existence
-
-For each affected entity, check if corresponding .md file exists:
-- Missing Layer 3 doc → warn: "Component doc not found. Run /ddd:doc-generate first."
-- Missing Layer 2 doc → warn: "Feature doc not found. Run /ddd:doc-generate first."
-
-## Phase 2: Layer 3 — Update Component Docs
-
-For each affected component's `tech-registry/{slug}.md`:
-
-```bash
-ccw cli -p "PURPOSE: Update component documentation for {component.name} after code changes
-TASK:
-• Update code locations and line ranges
-• Update symbol list (add new exports, remove deleted)
-• Add change entry to history table
-• Refresh usage examples if API changed
-MODE: write
-CONTEXT: @{component.codeLocations[].path}
-EXPECTED: Updated markdown with current API state
-CONSTRAINTS: Preserve existing structure | Only update changed sections
-" --tool gemini --mode write --cd .workflow/.doc-index/tech-registry/
-```
-
-Update frontmatter:
-```markdown
----
-layer: 3
-component_id: tech-auth-service
-generated_at: {original}
-last_updated: ISO8601
----
-```
-
-### 2.1 Minimal Mode (--minimal)
-
-With `--minimal`, only update:
-- `codeLocations` in frontmatter
-- `last_updated` timestamp
-- Skip CLI call for content regeneration
-
-## Phase 3: Layer 2 — Update Feature Docs
-
-For each affected feature's `feature-maps/{slug}.md`:
-
-```bash
-ccw cli -p "PURPOSE: Update feature documentation for {feature.name} after component changes
-TASK:
-• Update component list if new components added
-• Update status if requirements now fully implemented
-• Add change entry to history table
-• Refresh integration guide if component APIs changed
-MODE: write
-CONTEXT: @.workflow/.doc-index/tech-registry/{affected-components}.md
-EXPECTED: Updated markdown reflecting current feature state
-CONSTRAINTS: Reference updated Layer 3 docs | Preserve business language
-" --tool gemini --mode write --cd .workflow/.doc-index/feature-maps/
-```
-
-Update frontmatter:
-```markdown
----
-layer: 2
-feature_id: feat-auth
-depends_on_layer3: [tech-auth-service, tech-user-model]
-generated_at: {original}
-last_updated: ISO8601
----
-```
-
-### 3.1 Minimal Mode (--minimal)
-
-With `--minimal`, only update:
-- Component list in frontmatter
-- Feature status (if requirements mapping changed)
-- `last_updated` timestamp
-- Skip CLI call for content regeneration
-
-## Phase 4: Layer 1 — Update Index Docs (conditional)
-
-### 4.1 Trigger Conditions
-
-| Condition | Action |
-|-----------|--------|
-| New component registered | Update `tech-registry/_index.md` |
-| Component removed | Update `tech-registry/_index.md` |
-| Feature status changed | Update `feature-maps/_index.md` |
-| New feature added | Update `feature-maps/_index.md` + README.md |
-| Major architecture change | Update ARCHITECTURE.md |
-| New action-log entry | Update `action-logs/_index.md` |
-
-### 4.2 Update _index.md Files
-
-Refresh table entries for affected features/components:
-- `feature-maps/_index.md`
-- `tech-registry/_index.md`
-- `action-logs/_index.md` (if new action entry)
-
-### 4.3 Update Overview Docs (only if significant)
-
-If new features added or major status changes:
-
-```bash
-ccw cli -p "PURPOSE: Update project overview docs after feature changes
-TASK:
-• Update README.md feature list
-• Update ARCHITECTURE.md if new components added
-• Update planning/_index.md with new planning sessions
-MODE: write
-CONTEXT: @.workflow/.doc-index/feature-maps/*.md @.workflow/.doc-index/doc-index.json
-EXPECTED: Updated overview docs with current project state
-CONSTRAINTS: High-level only | Link to Layer 2 for details
-" --tool gemini --mode write --cd .workflow/.doc-index/
-```
-
-### 4.4 Skip Layer 1
-
-With `--minimal` or when changes are minor (only code location updates): skip Layer 1 entirely.
-
-## Phase 5: Refresh Report
-
-```
-Document Refresh Report
-
-Affected Scope:
-  Components: {N} ({component IDs})
-  Features: {N} ({feature IDs})
-
-Updated:
-  Layer 3 (Components): {N} documents refreshed
-  Layer 2 (Features):   {N} documents refreshed
-  Layer 1 (Indexes):    {N} documents refreshed (or "skipped")
-
-Mode: {full|minimal}
-```
-
-## Dry-Run Mode
-
-With `--dry-run`:
-- Execute Phase 1 (scope determination)
-- Display what would be updated (affected files list)
-- Skip all file writes (Phase 2-4)
-- Output: "Dry-run complete. {N} documents would be refreshed."
-
-## Flags
-
-| Flag | Effect |
-|------|--------|
-| `-y, --yes` | Auto-confirm all updates |
-| `--components <ids>` | Comma-separated component IDs to refresh |
-| `--features <ids>` | Comma-separated feature IDs to refresh |
-| `--minimal` | Only update metadata/frontmatter, skip content regeneration |
-| `--dry-run` | Preview what would change without modifying files |
-
-## Integration Points
-
-- **Input from**: `doc-index.json`, affected entity IDs (from `/ddd:sync` or `/ddd:update`)
-- **Called by**: `/ddd:sync` (after change detection + index update), `/ddd:update` (after impact tracing + index update)
-- **Standalone**: Can be run independently to refresh specific component/feature docs
-- **Prerequisite**: Documents must exist (generated by `/ddd:doc-generate`)

.claude/commands/ddd/execute.md

@@ -1,416 +0,0 @@
----
-name: execute
-description: Document-aware execution engine — executes plan.json + TASK-*.json with doc-index context enrichment, per-batch impact verification, and post-completion doc sync.
-argument-hint: "[-y|--yes] [--skip-sync] [--skip-verify] [--plan <path>] [--in-memory] \"optional task description\""
-allowed-tools: TodoWrite(*), Agent(*), AskUserQuestion(*), Read(*), Grep(*), Glob(*), Bash(*), Edit(*), Write(*), mcp__ace-tool__search_context(*)
----
-
-## Auto Mode
-
-When `--yes` or `-y`: Auto-confirm all decisions, auto-sync after completion.
-
-# DDD Execute Command (/ddd:execute)
-
-## Purpose
-
-Same execution engine model as lite-execute, but each step is **doc-index-aware**:
-- Tasks are enriched with feature context, component docs, and architecture constraints
-- Per-batch impact verification ensures changes stay within planned scope
-- Post-completion automatically syncs the document index
-
-### Core Differentiator
-Unlike generic execution engines, ddd:execute leverages the document architecture:
-- Feature-maps provide business context for each task
-- Tech-registry provides implementation patterns to follow
-- ADRs surface as hard constraints during execution
-- Requirement acceptance criteria inform convergence verification
-
-## Prerequisite
-
-- `plan.json` + `.task/TASK-*.json` files from `/ddd:plan`
-- `doc-index.json` at `.workflow/.doc-index/doc-index.json`
-- If `--in-memory`: receives executionContext from `/ddd:plan` handoff
-
----
-
-## Step 1: Initialize & Load Context
-
-### 1.1 Locate Plan
-
-```
-IF --in-memory:
-  Load executionContext from ddd:plan handoff
-  plan_path = executionContext.plan_path
-  task_dir = executionContext.task_dir
-ELIF --plan <path>:
-  plan_path = <path>
-  task_dir = {dirname(path)}/.task/
-ELSE:
-  Scan .workflow/.doc-index/planning/ for most recent session
-  plan_path = {latest_session}/plan.json
-  task_dir = {latest_session}/.task/
-```
-
-### 1.2 Load Plan & Tasks
-
-- Read `plan.json` — validate against plan-overview-base-schema
-- Read all `TASK-*.json` from `.task/` directory — validate against task-schema
-- Read `doc-index.json` from `.workflow/.doc-index/`
-
-### 1.3 Pre-Load Doc Context
-
-For each task with `doc_context`:
-- Load referenced `feature_docs` (feature-maps/{slug}.md)
-- Load referenced `component_docs` (tech-registry/{slug}.md)
-- Load ADR excerpts from doc-index `architectureDecisions[]`
-- Extract requirement acceptance criteria from doc-index `requirements[]`
-- Load `doc_context.symbol_docs[]` documentation content (if present)
-
-### 1.4 Echo Strategy
-
-Display execution summary:
-
-```
-DDD Execute: {plan.summary}
-Complexity: {plan.complexity}
-Tasks: {plan.task_count}
-
-Doc-Index Impact:
-  Features: {doc_context.affected_features}
-  Requirements: {doc_context.affected_requirements}
-  Components: {doc_context.affected_components}
-  Constraints: {doc_context.architecture_constraints}
-
-Execution plan: {batch count} batches, {parallel tasks} parallel where possible
-```
-
----
-
-## Step 2: Task Grouping & Batch Creation
-
-### 2.1 Extract Dependencies
-
-From each `TASK-*.json`, read `depends_on[]` to build dependency graph.
-
-### 2.2 Group into Batches
-
-```
-Batch 1: Tasks with no dependencies (depends_on: [])
-Batch 2: Tasks depending only on Batch 1 tasks
-Batch 3: Tasks depending on Batch 1 + 2 tasks
-...
-```
-
-Within each batch, tasks with the same `parallel_group` can run concurrently.
-
-### 2.3 Assign Executor per Task
-
-| Signal | Executor |
-|--------|----------|
-| `meta.execution_config.method == "cli"` | CLI tool (gemini/codex/qwen) |
-| `meta.execution_config.method == "agent"` | Agent (code-developer/universal-executor) |
-| Default | Agent (code-developer) |
-
----
-
-## Step 3: Doc-Enriched Execution
-
-For each task in batch order, build an enriched prompt:
-
-### 3.1 Task Prompt Template
-
-```markdown
-## Goal
-${plan.summary} — specifically: ${task.title}
-
-## Document Context
-
-### Feature: ${feature.name} (${feature.id})
-${feature-map content excerpt — overview + requirements section}
-
-### Components
-${for each component in task.doc_context.component_ids:
-  tech-registry excerpt — responsibility + code locations + key patterns}
-
-### Symbol Documentation
-${if doc_context.symbol_docs is non-empty:
-  for each component in doc_context.component_ids:
-    #### ${component.name} Symbols (Top-5)
-    ${for each symbol in component.symbol_docs.slice(0, 5):
-      - **${symbol.name}** (${symbol.type}): ${symbol.doc_summary}
-        Source: `${symbol.source_path}` | Freshness: ${symbol.freshness}
-    }
-}
-
-### Architecture Constraints
-${for each ADR in task.doc_context.adr_ids:
-  ADR title + decision + rationale from doc-index}
-
-### Requirement Acceptance Criteria
-${for each requirement in task.doc_context.requirement_ids:
-  requirement title + priority + success criteria from doc-index}
-
-## Task Details
-${task.description}
-
-### Files to Modify
-${task.files[] — path, action, changes}
-
-### Implementation Steps
-${task.implementation[] — step-by-step guide}
-
-## Done When
-${task.convergence.criteria[]}
-${task.convergence.verification}
-```
-
-### 3.2 Execute Task
-
-**Agent execution**:
-```
-Agent(subagent_type="code-developer", prompt="{enriched prompt}")
-```
-
-**CLI execution**:
-```bash
-ccw cli -p "{enriched prompt}" --tool {cli_tool} --mode write
-```
-
-### 3.3 Record & Persist Result
-
-After each task completes:
-- Update `TASK-*.json` with `status`, `executed_at`, `result`
-- Track `result.files_modified` for impact verification
-- **Persist** result to `TASK-{id}.result.json` alongside the task file:
-
-```json
-{
-  "task_id": "TASK-001",
-  "status": "completed|failed",
-  "executed_at": "ISO8601",
-  "executor": "code-developer|gemini|codex",
-  "files_modified": [
-    { "path": "src/services/auth.ts", "action": "modified", "symbols_changed": ["AuthService.validate"] },
-    { "path": "src/routes/login.ts", "action": "created", "symbols_changed": ["loginRoute"] }
-  ],
-  "convergence_result": {
-    "criteria_met": ["Rate limiter middleware exists"],
-    "criteria_unmet": [],
-    "verification_output": "test output snippet..."
-  },
-  "error": null
-}
-```
-
-This file serves as the durable handoff between execute and sync — survives process interruptions.
-
----
-
-## Step 4: Per-Batch Impact Verification
-
-After each batch completes (unless `--skip-verify`):
-
-### 4.1 Trace Changed Files
-
-For each file modified in the batch:
-```
-changed_file → match to doc-index.technicalComponents[].codeLocations[].path
-  → component_ids → featureIds → requirementIds
-```
-
-### 4.2 Scope Verification
-
-Compare actual impact to planned impact:
-
-```
-Planned scope:
-  Features: [feat-auth]
-  Components: [tech-auth-service, tech-user-model]
-
-Actual impact:
-  Features: [feat-auth]              ← OK, within scope
-  Components: [tech-auth-service, tech-user-model, tech-email-service]
-                                     ← WARNING: tech-email-service not in plan
-```
-
-### 4.3 Flag Unexpected Impact
-
-If changes affect features/components NOT in `plan.doc_context`:
-- **Warning**: Display unexpected impact
-- **No -y**: Ask user to confirm continuation
-- **With -y**: Log warning, continue execution
-
-### 4.4 Skip Conditions
-
-Skip verification when:
-- `--skip-verify` flag is set
-- Only 1 batch (no intermediate verification needed for simple plans)
-
----
-
-## Step 4.5: Post-Execution Verify Gate
-
-After all batches complete, before doc sync (unless `--skip-verify`):
-
-### 4.5.1 Convergence Verification
-
-For each completed task with `convergence.verification`:
-```
-Execute: {task.convergence.verification}
-  → e.g., "npm test -- --grep rate-limit"
-Record: pass/fail → update TASK-{id}.result.json.convergence_result
-```
-
-### 4.5.2 Build & Lint Check
-
-```
-Run project build command (if configured):
-  → npm run build / tsc --noEmit / etc.
-Run project lint command (if configured):
-  → npm run lint / eslint src/ / etc.
-```
-
-If build or lint fails:
-- **No -y**: Display errors, ask user: fix now / continue anyway / abort
-- **With -y**: Log warning, continue (non-blocking)
-
-### 4.5.3 Regression Test
-
-```
-Run project test suite:
-  → npm test / pytest / etc.
-Compare: test results before execution (baseline) vs after
-```
-
-If tests fail:
-- **No -y**: Display failures, ask user: fix now / skip sync / abort
-- **With -y**: Log failures as warning in execution results, continue
-
-### 4.5.4 Verify Summary
-
-```
-Verify Gate Results:
-  Convergence: {passed}/{total} tasks verified
-  Build: pass|fail|skipped
-  Lint: pass|fail|skipped
-  Tests: {passed}/{total} ({new_failures} regressions)
-
-  Gate: PASS / WARN (continue with warnings) / FAIL (blocked)
-```
-
-### 4.5.5 Persist Verify Manifest
-
-Write `execution-manifest.json` to session folder:
-
-```json
-{
-  "session_id": "{session-id}",
-  "plan_path": "planning/{slug}/plan.json",
-  "completed_at": "ISO8601",
-  "tasks": [
-    {
-      "task_id": "TASK-001",
-      "status": "completed",
-      "result_file": ".task/TASK-001.result.json"
-    }
-  ],
-  "files_modified": [
-    { "path": "src/services/auth.ts", "action": "modified", "task_id": "TASK-001" },
-    { "path": "src/routes/login.ts", "action": "created", "task_id": "TASK-001" }
-  ],
-  "verify": {
-    "convergence": { "passed": 2, "total": 2 },
-    "build": "pass",
-    "lint": "pass",
-    "tests": { "passed": 42, "total": 42, "regressions": 0 },
-    "gate": "PASS"
-  }
-}
-```
-
-This manifest is the **single source of truth** consumed by `ddd:sync --from-manifest`.
-
----
-
-## Step 5: Post-Completion Doc Sync
-
-After all batches complete (unless `--skip-sync`):
-
-### 5.1 Auto-Trigger ddd:sync
-
-```
-Invoke /ddd:sync [-y] --task-id {session-id} --from-manifest {session}/execution-manifest.json "{plan.summary}"
-```
-
-Note: `/ddd:sync` automatically creates a backup of `doc-index.json` before modifications.
-
-When `--from-manifest` is provided, sync uses the **execution manifest** as its primary data source instead of git diff. This ensures:
-- Precise file-level and symbol-level change tracking (from TASK-*.result.json)
-- Task-to-file attribution (which task modified which file)
-- Convergence verification results carried forward
-- Survives process interruptions (manifest is persisted to disk)
-
-Fallback: If manifest is unavailable (e.g., manual mode), sync falls back to git diff discovery.
-
-### 5.2 Generate Action Log
-
-Create action entry with:
-- All tasks executed and their results
-- Files modified across all batches
-- Features and requirements addressed
-
-### 5.3 Update Feature Status
-
-Based on execution results:
-- Requirements with verified convergence → update status
-- Features with all requirements met → `status: "implemented"`
-
----
-
-## Step 6: Summary & Follow-up
-
-### 6.1 Execution Results
-
-```
-DDD Execute Complete
-
-Tasks: {completed}/{total} ({failed} failed)
-Files modified: {count}
-Batches: {batch_count}
-
-Doc-Index Changes:
-  Features updated: {list}
-  Components updated: {list}
-  New components registered: {list}
-  Requirements addressed: {list}
-
-Convergence:
-  {for each task: task.id — criteria met: X/Y}
-```
-
-### 6.2 Follow-up Suggestions
-
-Based on execution results, suggest:
-- **New issues**: If unexpected scope expansion was detected
-- **Additional tests**: If convergence criteria only partially met
-- **Documentation gaps**: If new components were created without docs
-- **Next tasks**: If plan had tasks marked as future/deferred
-
----
-
-## Flags
-
-| Flag | Effect |
-|------|--------|
-| `-y, --yes` | Auto-confirm, auto-sync |
-| `--skip-sync` | Skip post-completion ddd:sync (Step 5) |
-| `--skip-verify` | Skip per-batch impact verification (Step 4) AND post-execution verify gate (Step 4.5) |
-| `--plan <path>` | Explicit plan.json path |
-| `--in-memory` | Accept executionContext from ddd:plan handoff |
-
-## Integration Points
-
-- **Input from**: `/ddd:plan` output (plan.json + TASK-*.json), `doc-index.json`
-- **Output to**: Updated `doc-index.json` (via ddd:sync), `TASK-*.result.json` (per-task), `execution-manifest.json` (session-level)
-- **Schemas**: `plan-overview-ddd-schema.json` (input), `task-schema.json` + `task-ddd-extension-schema.json` (input), `doc-index.json` (enrichment)
-- **Delegates to**: `/ddd:sync` for post-completion synchronization

.claude/commands/ddd/index-build.md

@@ -1,212 +0,0 @@
----
-name: index-build
-description: Build document index from spec-generator outputs + codebase mapping. Requires existing spec session. For projects without specs, use /ddd:scan instead.
-argument-hint: "[-y|--yes] [-s|--spec <spec-session-id>] [--from-scratch]"
-allowed-tools: TodoWrite(*), Agent(*), AskUserQuestion(*), Read(*), Grep(*), Glob(*), Bash(*), Edit(*), Write(*), mcp__ace-tool__search_context(*)
----
-
-## Auto Mode
-
-When `--yes` or `-y`: Auto-confirm all decisions, use inferred mappings, skip interactive review.
-
-# DDD Index Build Command (/ddd:index-build)
-
-## Purpose
-
-From **spec-generator outputs** (requirements, architecture, epics), construct the central document index and map spec entities to actual code locations.
-
-```
-Spec outputs (REQ, ADR, EPIC) + Codebase → doc-index.json
-```
-
-> **No spec?** Use `/ddd:scan` instead — it reverse-engineers the index from code alone.
-
-## Prerequisite
-
-- At least one spec session in `.workflow/.doc-index/specs/` or `.workflow/.spec/`
-- If no spec found → error with suggestion: "No spec session found. Run /ddd:scan for code-first indexing, or /spec-generator to create specs."
-
-## Storage Location
-
-```
-.workflow/.doc-index/
-├── doc-index.json              ← Central index (primary output)
-├── specs/                      ← Spec-generator outputs
-│   └── SPEC-{slug}-{date}/
-├── feature-maps/               ← Feature documentation (from Epics)
-│   ├── _index.md
-│   └── {feature-slug}.md
-├── tech-registry/              ← Technical component docs (from code mapping)
-│   ├── _index.md
-│   └── {component-slug}.md
-└── action-logs/                ← Change history (initially empty)
-    └── _index.md
-```
-
-## Phase 1: Discover & Parse Spec Sources
-
-### 1.1 Locate Spec Session
-
-```
-IF --spec <id> provided:
-  Load from .workflow/.doc-index/specs/<id>/ OR .workflow/.spec/<id>/
-ELSE:
-  Scan for all SPEC-* directories
-  IF multiple → present list, ask user to select (-y picks latest)
-  IF none → ERROR: "No spec session found. Use /ddd:scan or /spec-generator."
-```
-
-### 1.2 Migrate Specs (if needed)
-
-If spec in `.workflow/.spec/` but not in `.workflow/.doc-index/specs/`:
-- Copy to `.workflow/.doc-index/specs/`
-- Preserve original (backward compatibility)
-
-### 1.3 Extract Structured Entities
-
-| Source File | Extract To |
-|------------|------------|
-| `spec-config.json` | project name, domain, spec_type |
-| `glossary.json` | → index glossary[] |
-| `product-brief.md` | vision, goals |
-| `requirements/REQ-*.md` | → index requirements[] (with MoSCoW priority) |
-| `requirements/NFR-*.md` | → index requirements[] (non-functional) |
-| `architecture/ADR-*.md` | → index architectureDecisions[] |
-| `epics/EPIC-*.md` | → feature grouping seeds |
-
-## Phase 2: Codebase Mapping
-
-Map spec entities to actual code locations using Gemini:
-
-```bash
-ccw cli -p "PURPOSE: Map codebase to specification entities for documentation indexing.
-TASK:
-• Scan the codebase and identify all major modules/components
-• For each component: extract file paths, exported symbols (classes, functions, types)
-• Match components to these specification entities by name/domain similarity:
-  Requirements: {REQ-001: desc, REQ-002: desc, ...extracted from Phase 1}
-  Architecture decisions: {ADR-001: title, ...extracted from Phase 1}
-• Report unmatched components (exist in code but no spec counterpart)
-• Report unmatched requirements (in spec but no code found)
-MODE: analysis
-CONTEXT: @**/*
-EXPECTED: JSON: { components: [{ name, type, files, symbols, matched_req_ids, matched_adr_id, is_orphan }], unmatched_reqs: [REQ-NNN] }
-CONSTRAINTS: Focus on source directories | Ignore node_modules, dist, build" --tool gemini --mode analysis
-```
-
-### 2.1 Generate Component IDs & Link
-
-For each discovered component:
-- ID: `tech-{kebab-case-name}`
-- Link to matched `REQ-NNN` and `ADR-NNN`
-- Flag orphans for user review
-
-## Phase 3: Build Feature Map (from Epics)
-
-### 3.1 Epic → Feature Mapping
-
-```
-Each EPIC-NNN → one feat-{slug}
-  - id: feat-{slug} (from epic slug)
-  - name: from Epic name
-  - epicId: EPIC-NNN
-  - status: inferred from code mapping
-    - all requirements have matched components → "implemented"
-    - some matched → "in-progress"
-    - none matched → "planned"
-  - requirementIds: from Epic's stories → requirement links
-  - tags: from domain keywords
-```
-
-### 3.2 Document Generation (delegated)
-
-Feature-map and tech-registry document generation is handled by `/ddd:doc-generate` in Phase 5.
-Phase 3 only builds the data structures (feature → requirement → component mappings) that doc-generate consumes.
-
-## Phase 4: Assemble doc-index.json
-
-```json
-{
-  "version": "1.0",
-  "project": "{project-name}",
-  "build_path": "spec-first",
-  "spec_session": "SPEC-{slug}-{date}",
-  "last_updated": "ISO8601",
-  "glossary": [
-    { "id": "gloss-{slug}", "term": "Term", "definition": "...", "aliases": [], "category": "core|technical|business" }
-  ],
-  "features": [
-    { "id": "feat-{slug}", "name": "...", "epicId": "EPIC-NNN", "status": "...", "docPath": "feature-maps/{slug}.md", "requirementIds": ["REQ-NNN"], "tags": [] }
-  ],
-  "requirements": [
-    { "id": "REQ-NNN", "title": "...", "source": "spec", "priority": "Must|Should|Could|Won't", "sourcePath": "specs/SPEC-*/requirements/REQ-NNN-*.md", "techComponentIds": ["tech-{slug}"], "featureId": "feat-{slug}" }
-  ],
-  "technicalComponents": [
-    { "id": "tech-{slug}", "name": "...", "type": "...", "responsibility": "...", "adrId": "ADR-NNN|null", "docPath": "tech-registry/{slug}.md", "codeLocations": [{ "path": "...", "symbols": [], "lineRange": [0,0] }], "dependsOn": [], "featureIds": ["feat-{slug}"], "actionIds": [] }
-  ],
-  "architectureDecisions": [
-    { "id": "ADR-NNN", "title": "...", "source": "spec", "sourcePath": "specs/SPEC-*/architecture/ADR-NNN-*.md", "componentIds": ["tech-{slug}"] }
-  ],
-  "actions": []
-}
-```
-
-### Merge with Existing Code-First Index
-
-If a code-first index exists (from prior `/ddd:scan`):
-- Replace `IREQ-NNN` with matching `REQ-NNN` where content overlaps
-- Keep `IREQ-NNN` without spec counterpart (mark `source: "legacy-inferred"`)
-- Replace `IADR-NNN` with `ADR-NNN` where applicable
-- Update `build_path` to `"spec-first"`
-- Preserve existing `tech-*` components (update links only)
-
-## Phase 5: Generate Documents
-
-Delegate all document generation to `/ddd:doc-generate`:
-
-```
-Invoke /ddd:doc-generate [-y]
-```
-
-This generates the complete document tree (Layer 3 → 2 → 1):
-- `tech-registry/{slug}.md` — component docs from Phase 2 mapping (Layer 3)
-- `feature-maps/{slug}.md` — feature docs from Phase 3 mapping (Layer 2)
-- `_index.md`, `README.md`, `ARCHITECTURE.md`, `SCHEMA.md` — index/overview docs (Layer 1)
-
-See `/ddd:doc-generate` for full details on generation strategy and flags.
-
-## Phase 6: Coverage Report
-
-```
-Index Build Report (spec-first)
-
-Spec: {session-id}
-Features: {N} (from {N} Epics)
-Requirements: {N} (REQ: {n}, NFR: {n})
-Components: {N} ({orphan} orphans without spec match)
-ADRs: {N}
-
-Mapping Coverage:
-  Requirements → Components: {%} ({unmapped} unmapped)
-  Components → Features: {%}
-  Epics → Features: 100%
-
-Gaps:
-  - {N} requirements have no matching code component
-  - {N} code components are not linked to any requirement
-```
-
-## Flags
-
-| Flag | Effect |
-|------|--------|
-| `-y, --yes` | Skip all interactive prompts |
-| `-s, --spec <id>` | Use specific spec session |
-| `--from-scratch` | Delete existing index and rebuild |
-
-## Integration Points
-
-- **Input from**: `spec-generator` outputs, codebase, existing `/ddd:scan` index
-- **Delegates to**: `/ddd:doc-generate` (Phase 5, full document generation)
-- **Output to**: `ddd:plan`, `ddd:sync`, `ddd:update`
-- **Upgrades**: Can merge with prior code-first (`/ddd:scan`) index

.claude/commands/ddd/plan.md

@@ -1,611 +0,0 @@
----
-name: plan
-description: Document-driven planning pipeline — queries doc-index, explores codebase with doc-aware angles, clarifies ambiguities, and produces unified plan.json + TASK-*.json artifacts with doc_context traceability.
-argument-hint: "[-y|--yes] [--explore] [--skip-explore] [--skip-clarify] \"task description or feature keyword\""
-allowed-tools: TodoWrite(*), Agent(*), AskUserQuestion(*), Read(*), Grep(*), Glob(*), Bash(*), Write(*), mcp__ace-tool__search_context(*)
----
-
-## Auto Mode
-
-When `--yes` or `-y`: Skip clarification (Phase 3), auto-select ddd:execute (Phase 5), skip interactive refinement.
-
-# DDD Plan Command (/ddd:plan)
-
-## Purpose
-
-Full planning pipeline for document-driven development. Unlike simple context lookup, this command:
-1. **Queries** the doc-index for instant context (features, requirements, components, ADRs)
-2. **Explores** the codebase with doc-index-informed angles (not generic presets)
-3. **Clarifies** ambiguities from exploration results and doc-index gaps
-4. **Plans** with unified schema output (plan.json + TASK-*.json with doc_context)
-5. **Hands off** to ddd:execute or other execution engines
-
-### Key Differentiation from lite-plan
-- Phase 1 provides instant context from doc-index (no cold-start exploration)
-- Exploration angles are doc-index-informed (not generic preset selection)
-- Tasks carry doc_context for traceability (features → requirements → code)
-- Architecture decisions (ADRs) automatically surface as constraints
-
-## Prerequisite
-
-- `doc-index.json` must exist at `.workflow/.doc-index/doc-index.json`
-- If not found → suggest running `/ddd:index-build` or `/ddd:scan` first
-
-## Session Folder
-
-```
-.workflow/.doc-index/planning/{task-slug}-{YYYY-MM-DD}/
-├── exploration-{angle}.json        # Per-angle exploration (Phase 2)
-├── explorations-manifest.json      # Exploration index
-├── plan.json                       # Plan overview (Phase 4)
-├── planning-context.md             # Legacy context package (Phase 0+1 combined)
-├── .process/
-│   └── doc-context-package.json    # Bundled doc_context (Phase 1.8)
-└── .task/
-    ├── TASK-001.json
-    └── TASK-002.json
-```
-
----
-
-## Phase 0: Parse Task Intent (enhanced)
-
-### 0.1 Extract Keywords
-
-From the user's task description, extract:
-- **Domain keywords**: feature names, module names, business terms
-- **Technical keywords**: file paths, class names, function names
-- **Action type**: feature | bugfix | refactor | optimization | migration
-
-### 0.2 Glossary Match
-
-Cross-reference extracted keywords against `doc-index.json.glossary[]`:
-- Match terms and aliases
-- Expand user's vocabulary with canonical terms
-
-### 0.3 Classify Complexity
-
-Assess task complexity based on:
-- Number of features potentially affected (from keyword matching)
-- Whether new components are needed or existing ones modified
-- Cross-feature impact (single feature vs multiple)
-
-| Signal | Complexity |
-|--------|-----------|
-| Single feature, existing components | Low |
-| 1-2 features, some new components | Medium |
-| 3+ features, new architecture needed | High |
-
----
-
-## Phase 1: Doc-Index Query
-
-### 1.0 Schema Version Check (TASK-006)
-
-Before querying doc-index, verify schema compatibility:
-
-```javascript
-const docIndex = JSON.parse(Read('.workflow/.doc-index/doc-index.json'));
-const schemaVersion = docIndex.schema_version || '0.0'; // Default for legacy
-
-if (schemaVersion !== '1.0') {
-  console.warn(`Schema version mismatch: found ${schemaVersion}, expected 1.0`);
-  console.warn('Consider running schema migration or regenerating doc-index with /ddd:scan');
-  // Continue with degraded functionality - may encounter missing fields
-}
-```
-
-**Graceful degradation**: If version mismatch detected → log warning → continue with caution (some features may not work as expected).
-
-### 1.1 Feature Search
-
-```
-Search doc-index.json.features[] where:
-  - name CONTAINS keyword (fuzzy)
-  - tags INTERSECT keywords
-  - requirementIds link to matching requirements
-→ Output: matched feature IDs + names
-```
-
-### 1.2 Requirement Search
-
-```
-Search doc-index.json.requirements[] where:
-  - title CONTAINS keyword
-  - id matches explicit REQ-NNN reference
-  - featureId matches found features
-→ Output: matched requirement IDs + titles + priorities
-```
-
-### 1.3 Component Search
-
-```
-Search doc-index.json.technicalComponents[] where:
-  - name CONTAINS keyword
-  - codeLocations[].path CONTAINS file path keyword
-  - codeLocations[].symbols CONTAINS symbol keyword
-  - featureIds INTERSECT found features
-→ Output: matched component IDs + code locations
-```
-
-### 1.4 ADR Search
-
-```
-Search doc-index.json.architectureDecisions[] where:
-  - componentIds INTERSECT found components
-→ Output: matched ADR IDs + titles
-```
-
-### 1.5 Action History Search
-
-```
-Search doc-index.json.actions[] where:
-  - related to found features or components
-→ Output: recent actions with descriptions
-```
-
-### 1.6 Build Impact Map
-
-Assemble all found references into a structured impact map:
-
-```json
-{
-  "affected_features": ["feat-auth"],
-  "affected_requirements": ["REQ-001", "REQ-002"],
-  "affected_components": ["tech-auth-service", "tech-user-model"],
-  "architecture_constraints": ["ADR-001"],
-  "recent_actions": ["task-123"],
-  "complexity": "Medium"
-}
-```
-
-Save as `planning-context.md` (legacy format for backward compatibility).
-
-### Phase 1.7: Symbol Query (DeepWiki Bridge)
-
-If DeepWiki is available (`deepwiki_feature_to_symbol_index` exists in doc-index.json):
-
-1. Collect all `codeLocations[].path` from matched `technicalComponents[]`
-2. Query DeepWiki: `POST /api/deepwiki/symbols-for-paths { paths: unique_paths }`
-3. Build symbol_docs by component, sorted by type priority (class > function > method)
-4. Populate `doc_context.symbol_docs[]` with Top-5 symbols per component
-
-**Graceful degradation**: If DeepWiki unavailable → log warning → skip symbol injection → continue flow.
-
-### Phase 1.8: Persist Doc Context Package
-
-After building doc_context (including symbol_docs from Phase 1.7), persist it as a reusable context package:
-
-1. Bundle doc_context into JSON structure:
-```json
-{
-  "affected_features": ["feat-auth"],
-  "affected_requirements": ["REQ-001", "REQ-002"],
-  "affected_components": ["tech-auth-service"],
-  "architecture_constraints": ["ADR-001"],
-  "index_path": ".workflow/.doc-index/doc-index.json",
-  "symbol_docs": [...]
-}
-```
-
-2. Write to session folder: `{sessionFolder}/.process/doc-context-package.json`
-3. Store relative path for task.json population: `../.process/doc-context-package.json`
-
-**Error handling**: If write fails → log warning → continue without context package (backward compatible).
-
----
-
-## Phase 2: Doc-Index-Guided Exploration (NEW)
-
-Use Phase 1 results to **SELECT exploration angles intelligently**:
-
-### 2.1 Angle Selection Logic
-
-| Phase 1 Signal | Add Exploration Angle |
-|----------------|----------------------|
-| feat-auth or security-related ADR affected | `security` |
-| Multiple features crossed (2+) | `integration-points` |
-| New component needed (no matching tech-*) | `architecture` |
-| Performance-related requirements | `performance` |
-| Default (always included) | `patterns` + `dependencies` |
-
-Select 1-4 angles total. More angles for higher complexity.
-
-### 2.2 Skip & Trigger Conditions
-
-| Complexity | Default Behavior | Override |
-|-----------|-----------------|---------|
-| **Low** | Auto-skip Phase 2 | `--explore` forces exploration |
-| **Medium** | Ask user (unless `-y` → skip) | `--explore` forces, `--skip-explore` forces skip |
-| **High** | Always run | `--skip-explore` forces skip |
-
-Skip Phase 2 entirely when:
-- Complexity is Low AND `--explore` not set
-- OR `--skip-explore` flag is set
-- OR `-y` flag AND complexity is Medium
-
-### 2.3 Parallel Exploration
-
-Launch 1-4 parallel `cli-explore-agent` runs:
-
-```
-For each selected angle:
-  Agent(subagent_type="cli-explore-agent", prompt="
-    Explore codebase for: {user task description}
-    Angle: {angle}
-
-    ## Doc-Index Context (pre-loaded)
-    Features affected: {feature names + IDs}
-    Components: {component names + code locations}
-    Requirements: {requirement titles}
-    Architecture decisions: {ADR titles + decisions}
-
-    Focus exploration on {angle}-specific concerns.
-    Output: explore-json-schema format.
-  ")
-```
-
-Each agent receives doc-index context (feature-maps, tech-registry docs) to avoid cold-start.
-
-### 2.4 Save Exploration Results
-
-- Each exploration → `exploration-{angle}.json` (explore-json-schema)
-- Manifest → `explorations-manifest.json`:
-
-```json
-{
-  "explorations": [
-    { "angle": "patterns", "path": "exploration-patterns.json", "file_count": 12 },
-    { "angle": "security", "path": "exploration-security.json", "file_count": 8 }
-  ],
-  "total_files_discovered": 18,
-  "timestamp": "ISO8601"
-}
-```
-
----
-
-## Phase 3: Clarification (NEW)
-
-### 3.1 Aggregate Clarification Needs
-
-Collect from three sources:
-1. **Exploration results**: `clarification_needs[]` from each exploration JSON
-2. **Doc-index gaps**: unmapped requirements, orphan components, missing feature coverage
-3. **Conflicting constraints**: contradictory architecture decisions, requirement priority conflicts
-
-### 3.2 Deduplicate & Batch
-
-- Merge duplicate/similar questions across exploration angles
-- Group into rounds (max 4 questions per AskUserQuestion call)
-- Prioritize: blocking questions first, nice-to-have last
-
-### 3.3 Skip Conditions
-
-Skip Phase 3 when:
-- `-y` flag is set
-- `--skip-clarify` flag is set
-- No clarification needs collected from any source
-- Complexity is Low AND Phase 2 was skipped (no exploration results to aggregate)
-
-### 3.4 Execute Clarification
-
-```
-AskUserQuestion(questions=[
-  {
-    question: "Which authentication strategy should the new endpoint use?",
-    header: "Auth strategy",
-    options: [
-      { label: "JWT Bearer (Recommended)", description: "Consistent with ADR-001 and existing auth middleware" },
-      { label: "API Key", description: "Simpler but inconsistent with current architecture" },
-      { label: "OAuth2", description: "Most flexible but higher implementation cost" }
-    ],
-    multiSelect: false
-  }
-])
-```
-
-Feed answers back into Phase 4 as constraints.
-
----
-
-## Phase 4: Task Planning (NEW — produces plan.json + TASK-*.json)
-
-### 4.1 Planning Strategy Selection
-
-| Complexity | Strategy |
-|-----------|---------|
-| Low | Direct Claude planning (inline) |
-| Medium | cli-lite-planning-agent with doc-index context |
-| High | cli-lite-planning-agent with full exploration + doc-index context |
-
-### 4.2 Planning Input Assembly
-
-Combine:
-- User's original task description
-- Phase 1 impact map (features, requirements, components, ADRs)
-- Phase 2 exploration results (if executed)
-- Phase 3 clarification answers (if collected)
-- Relevant feature-map and tech-registry doc excerpts
-
-### 4.3 Execute Planning
-
-For **Low complexity** (direct):
-```
-Generate plan.json + TASK-*.json directly based on assembled context.
-```
-
-For **Medium/High complexity**:
-```
-Agent(subagent_type="cli-lite-planning-agent", prompt="
-  Task: {user task description}
-
-  ## Doc-Index Impact Map
-  {Phase 1 results}
-
-  ## Exploration Context
-  {Phase 2 results summary}
-
-  ## Clarification Answers
-  {Phase 3 answers}
-
-  ## Architecture Constraints
-  {ADR excerpts}
-
-  Generate plan following plan-overview-base-schema.
-  Generate tasks following task-schema.
-  Include doc_context in both plan.json and each TASK-*.json.
-")
-```
-
-### 4.3.1 Populate Task Artifacts (TASK-002)
-
-After task generation, enrich each TASK-*.json with artifacts[] field:
-
-1. Load doc-index.json from `.workflow/.doc-index/doc-index.json`
-2. For each task, extract feature_ids from task.doc_context
-3. Filter doc-index features/requirements matching task scope:
-   - Match by feature_ids in task.doc_context.feature_ids
-   - Include linked requirements via requirementIds
-   - Include linked components via componentIds
-4. Populate task.artifacts[] with filtered references:
-
-```json
-{
-  "artifacts": [
-    {
-      "type": "feature_spec",
-      "source": "doc-index",
-      "path": ".workflow/.doc-index/feature-maps/auth.md",
-      "feature_id": "feat-auth",
-      "usage": "Reference for authentication requirements"
-    },
-    {
-      "type": "requirement",
-      "source": "doc-index",
-      "path": ".workflow/.doc-index/doc-index.json#requirements[0]",
-      "feature_id": "feat-auth",
-      "requirement_id": "REQ-001",
-      "usage": "Acceptance criteria source"
-    },
-    {
-      "type": "component_doc",
-      "source": "doc-index",
-      "path": ".workflow/.doc-index/tech-registry/auth-service.md",
-      "component_id": "tech-auth-service",
-      "usage": "Implementation reference"
-    }
-  ]
-}
-```
-
-**Loading pattern** (following brainstorm pattern from action-planning-agent.md:200-214):
-- Load doc-index.json once for catalog
-- Filter by task-relevant feature IDs (1-3 per task)
-- Only include artifacts directly referenced in task scope
-- Use relative paths from task file location
-
-### 4.3.2 Populate Context Package Path (TASK-001)
-
-Set context_package_path field in each TASK-*.json:
-
-```json
-{
-  "context_package_path": "../.process/doc-context-package.json"
-}
-```
-
-Relative path from `.task/TASK-*.json` to `.process/doc-context-package.json`.
-
-### 4.3.3 Add Navigation Links Block (TASK-003)
-
-Add links{} navigation block to each TASK-*.json for improved discoverability:
-
-```json
-{
-  "links": {
-    "plan": "../plan.json",
-    "doc_index": "../../../doc-index.json",
-    "feature_maps": [
-      "../../../feature-maps/auth.md"
-    ],
-    "related_tasks": [
-      "TASK-002.json",
-      "TASK-003.json"
-    ]
-  }
-}
-```
-
-**Path computation**:
-- `plan`: Relative path from `.task/TASK-*.json` to `plan.json` (sibling of .task/)
-- `doc_index`: Relative path to `.workflow/.doc-index/doc-index.json`
-- `feature_maps`: Paths to feature-map docs from task.doc_context.feature_docs
-- `related_tasks`: Task IDs from task.depends_on or tasks sharing same feature_ids
-
-**Backward compatibility**: links{} is optional field (task-schema allows additionalProperties).
-
-### 4.4 Output Schema: plan.json
-
-Follows `plan-overview-base-schema` with ddd-specific `doc_context` extension:
-
-```json
-{
-  "summary": "...",
-  "approach": "...",
-  "task_ids": ["TASK-001", "TASK-002"],
-  "task_count": 2,
-  "complexity": "Medium",
-  "doc_context": {
-    "affected_features": ["feat-auth"],
-    "affected_requirements": ["REQ-001", "REQ-002"],
-    "affected_components": ["tech-auth-service"],
-    "architecture_constraints": ["ADR-001"],
-    "index_path": ".workflow/.doc-index/doc-index.json",
-    "symbol_docs": [
-      {
-        "symbol_urn": "deepwiki:symbol:<path>#L<start>-L<end>",
-        "name": "SymbolName",
-        "type": "class|function|method",
-        "doc_summary": "Generated documentation summary...",
-        "source_path": "src/path/to/file.ts",
-        "doc_path": ".deepwiki/file.md",
-        "freshness": "fresh|stale|unknown"
-      }
-    ]
-  },
-  "_metadata": {
-    "timestamp": "ISO8601",
-    "source": "cli-lite-planning-agent",
-    "plan_type": "feature",
-    "schema_version": "2.0",
-    "exploration_angles": ["patterns", "security"]
-  }
-}
-```
-
-### 4.5 Output Schema: TASK-*.json
-
-Follows `task-schema` with ddd-specific `doc_context` extension:
-
-```json
-{
-  "id": "TASK-001",
-  "title": "Add rate limiting middleware",
-  "description": "...",
-  "depends_on": [],
-  "convergence": {
-    "criteria": ["Rate limiter middleware exists and is registered", "Tests pass"],
-    "verification": "npm test -- --grep rate-limit",
-    "definition_of_done": "API endpoints enforce rate limits per ADR-001 specifications"
-  },
-  "doc_context": {
-    "feature_ids": ["feat-auth"],
-    "requirement_ids": ["REQ-001"],
-    "component_ids": ["tech-auth-service"],
-    "adr_ids": ["ADR-001"],
-    "feature_docs": ["feature-maps/auth.md"],
-    "component_docs": ["tech-registry/auth-service.md"],
-    "symbol_docs": [
-      {
-        "symbol_urn": "deepwiki:symbol:<path>#L<start>-L<end>",
-        "name": "SymbolName",
-        "type": "class|function|method",
-        "doc_summary": "Generated documentation summary...",
-        "source_path": "src/path/to/file.ts",
-        "doc_path": ".deepwiki/file.md",
-        "freshness": "fresh|stale|unknown"
-      }
-    ]
-  },
-  "files": [...],
-  "implementation": [...]
-}
-```
-
-### 4.6 Enrichment Rules
-
-Each task is enriched with:
-- `feature_ids`, `requirement_ids`, `component_ids`, `adr_ids` — traced from Phase 1
-- Relevant feature-map and tech-registry doc paths
-- Requirement acceptance criteria as convergence criteria source
-- ADR decisions as implementation constraints
-
----
-
-## Phase 5: Confirmation & Handoff Selection
-
-### 5.1 Display Plan Summary
-
-Show:
-- Plan overview (summary, approach, complexity)
-- Task list with dependencies
-- Doc-index impact: which features/requirements/components will be affected
-- Estimated scope
-
-### 5.2 Handoff Options
-
-| Option | Description | When |
-|--------|-------------|------|
-| **ddd:execute** | Document-aware execution (recommended) | Default for ddd workflow |
-| **lite-execute** | Standard execution (no doc awareness) | When doc traceability not needed |
-| **direct** | Output context, manual work | User prefers manual coding |
-| **stop** | Planning only, no execution | Research/analysis tasks |
-
-### 5.3 Auto-Selection
-
-With `-y`: auto-select `ddd:execute`.
-
-Without `-y`: present options via AskUserQuestion.
-
----
-
-## Phase 6: Handoff
-
-### 6.1 Build Execution Context
-
-Build `executionContext` compatible with lite-execute format:
-
-```json
-{
-  "plan_path": ".workflow/.doc-index/planning/{slug}/plan.json",
-  "task_dir": ".workflow/.doc-index/planning/{slug}/.task/",
-  "doc_index_path": ".workflow/.doc-index/doc-index.json",
-  "exploration_manifest": ".workflow/.doc-index/planning/{slug}/explorations-manifest.json",
-  "original_input": "user's task description"
-}
-```
-
-### 6.2 Invoke Selected Engine
-
-| Selection | Action |
-|-----------|--------|
-| `ddd:execute` | Invoke `/ddd:execute --in-memory` with executionContext |
-| `lite-execute` | Invoke `/workflow:lite-execute` with plan.json path |
-| `direct` | Display context package + file list for manual work |
-| `stop` | Output plan summary, end here |
-
----
-
-## Flags
-
-| Flag | Effect |
-|------|--------|
-| `-y, --yes` | Skip clarification, auto-select ddd:execute |
-| `--explore` | Force Phase 2 exploration even for Low complexity |
-| `--skip-explore` | Skip Phase 2 (doc-index-guided exploration) |
-| `--skip-clarify` | Skip Phase 3 (clarification) only |
-
-## Output
-
-- **Primary**: plan.json + TASK-*.json in session folder
-- **Secondary**: planning-context.md (legacy format)
-- **Exploration**: exploration-{angle}.json files (if Phase 2 ran)
-- **Console**: Plan summary with doc-index impact
-
-## Integration Points
-
-- **Input from**: `doc-index.json` (built by `/ddd:index-build` or `/ddd:scan`)
-- **Output to**: `/ddd:execute`, `/workflow:lite-execute`, `/ddd:sync` post-task
-- **Schemas**: `plan-overview-ddd-schema.json` (plan output), `task-schema.json` + `task-ddd-extension-schema.json` (task output), `explore-json-schema.json`
-- **Triggers**: Before any development task in ddd workflow

.claude/commands/ddd/scan.md

@@ -1,365 +0,0 @@
----
-name: scan
-description: Scan existing codebase to build document index without specs. Analyzes code structure, infers features, discovers components, and reverse-engineers project knowledge graph.
-argument-hint: "[-y|--yes] [--from-scratch] [--scope <dir>] \"optional project description\""
-allowed-tools: TodoWrite(*), Agent(*), AskUserQuestion(*), Read(*), Grep(*), Glob(*), Bash(*), Edit(*), Write(*), mcp__ace-tool__search_context(*)
----
-
-## Auto Mode
-
-When `--yes` or `-y`: Auto-confirm feature groupings, component naming, skip interactive review.
-
-# DDD Scan Command (/ddd:scan)
-
-## Purpose
-
-For **existing projects without specifications**: analyze codebase to construct the document index by reverse-engineering project structure. This is the code-first entry point — no spec-generator required.
-
-```
-Codebase → Components → Features (inferred) → Requirements (inferred) → doc-index.json
-```
-
-## When to Use
-
-- Existing project, no spec-generator outputs
-- Want to start using doc-driven workflow on a legacy codebase
-- Quick project mapping for onboarding or audit
-
-## Prerequisite
-
-- A codebase must exist (src/, lib/, app/, or similar source directories)
-- Git repository recommended (for action history seeding)
-
-## Storage Location
-
-```
-.workflow/.doc-index/
-├── doc-index.json              ← Central index (primary output)
-├── feature-maps/               ← Inferred feature documentation
-│   ├── _index.md
-│   └── {feature-slug}.md
-├── tech-registry/              ← Discovered component documentation
-│   ├── _index.md
-│   └── {component-slug}.md
-└── action-logs/                ← Git history seeds
-    ├── _index.md
-    └── {act-hash}.md
-```
-
-## Phase 1: Project Structure Analysis
-
-### 1.1 Framework & Stack Detection
-
-```bash
-ccw cli -p "PURPOSE: Analyze project structure, tech stack, and architecture for documentation indexing.
-TASK:
-• Detect language/framework from manifest files (package.json, go.mod, Cargo.toml, requirements.txt, etc.)
-• Map directory structure: source dirs, test dirs, config dirs, entry points
-• Identify architectural pattern: monolith, microservices, monorepo, library, CLI tool
-• Detect key dependencies and their roles (ORM, HTTP framework, auth library, etc.)
-• List all major source directories with brief purpose description
-MODE: analysis
-CONTEXT: @**/*
-EXPECTED: JSON with: {
-  project_name, language, framework, architecture_pattern,
-  source_dirs: [{ path, purpose, file_count }],
-  dependencies: [{ name, role }],
-  entry_points: [{ path, description }]
-}
-CONSTRAINTS: Prioritize source directories | Ignore node_modules, dist, build, vendor" --tool gemini --mode analysis
-```
-
-### 1.2 Merge with project-tech.json
-
-If `.workflow/project-tech.json` exists, merge to reduce redundant analysis.
-
-## Phase 2: Component Discovery
-
-### 2.1 Deep Module Scan
-
-```bash
-ccw cli -p "PURPOSE: Discover all significant code components/modules for documentation indexing.
-TASK:
-• For each source directory, identify distinct modules/components
-• For each component extract:
-  - Name (class name, module name, or logical group)
-  - Type: service | controller | model | util | hook | route | config | middleware | component
-  - File paths (primary file + related files)
-  - Exported symbols (public API: classes, functions, types, constants)
-  - Internal dependencies: what other modules it imports from within the project
-  - Responsibility: one-line description of what it does
-• Group small utility files under parent module when they share domain
-MODE: analysis
-CONTEXT: @{source_dirs from Phase 1}
-EXPECTED: JSON array: [{ name, type, files, symbols, depends_on, responsibility }]
-CONSTRAINTS: Focus on business logic | Min threshold: components with 2+ exports or clear domain purpose | Group utilities under parent domain" --tool gemini --mode analysis
-```
-
-### 2.2 Generate Component IDs
-
-For each discovered component:
-- ID: `tech-{kebab-case-name}` (e.g., `tech-auth-service`, `tech-user-model`)
-- Validate uniqueness, append counter on collision
-
-### 2.3 Build Dependency Graph
-
-From `depends_on` fields, construct internal dependency edges:
-```
-tech-auth-service → tech-user-model
-tech-auth-service → tech-jwt-util
-tech-order-controller → tech-auth-service
-```
-
-## Phase 3: Feature Inference
-
-**Key step: group components into logical features without formal specs.**
-
-### 3.1 Inference Strategy (priority order)
-
-```
-Strategy 1 — Directory grouping:
-  src/auth/**       → feat-auth
-  src/orders/**     → feat-orders
-  src/payments/**   → feat-payments
-
-Strategy 2 — Route/endpoint grouping (web apps):
-  /api/users/*      → feat-user-management
-  /api/orders/*     → feat-order-management
-
-Strategy 3 — Dependency clustering:
-  Components that heavily import each other → same feature
-
-Strategy 4 — Domain keyword extraction:
-  Class names + file names → domain terms → feature names
-```
-
-### 3.2 Gemini Feature Synthesis
-
-```bash
-ccw cli -p "PURPOSE: Infer high-level features from discovered code components. This project has no formal specification.
-TASK:
-Given these discovered components:
-{component list from Phase 2: names, types, files, responsibilities, dependencies}
-
-• Group them into logical features (3-10 features for a typical project)
-• For each feature:
-  - name: human-readable (Chinese OK)
-  - component_ids: which components belong
-  - description: what the feature does (inferred from code)
-  - inferred_requirements: what this feature needs to accomplish (1-3 per feature)
-  - status: 'implemented' (code complete) or 'partial' (incomplete patterns)
-  - tags: search keywords
-• Identify cross-cutting concerns (logging, auth middleware, error handling) as separate features
-MODE: analysis
-CONTEXT: {component list JSON}
-EXPECTED: JSON: { features: [{ name, description, component_ids, inferred_requirements: [{ id, title }], status, tags }] }
-CONSTRAINTS: Every component must belong to at least 1 feature | Prefer fewer broad features over many narrow ones" --tool gemini --mode analysis
-```
-
-### 3.3 Interactive Feature Review (unless -y)
-
-Present inferred features to user:
-- Allow renaming, merging, splitting
-- Allow reassigning components between features
-- Confirm final feature list
-
-## Phase 4: Implicit Requirement & Architecture Extraction
-
-### 4.1 Inferred Requirements
-
-For each feature, generate lightweight requirement entries from its components:
-
-```
-Feature: feat-auth (User Authentication)
-  → IREQ-001: "Users can log in with email and password"     (from LoginController)
-  → IREQ-002: "JWT tokens for session management"            (from AuthMiddleware + jwt dep)
-  → IREQ-003: "Password reset via email"                     (from PasswordResetService)
-```
-
-**ID Convention**: `IREQ-NNN` — distinguishes inferred from formal `REQ-NNN`.
-
-### 4.2 Inferred Architecture Decisions
-
-Detect patterns from code + dependencies:
-
-```
-Express.js + JWT middleware    → IADR-001: "REST API with JWT authentication"
-Prisma ORM + PostgreSQL        → IADR-002: "PostgreSQL via Prisma ORM"
-React + Redux                  → IADR-003: "React frontend with Redux state"
-```
-
-**ID Convention**: `IADR-NNN` — distinguishes inferred from formal `ADR-NNN`.
-
-### 4.3 Glossary Generation
-
-Extract domain terms from:
-- Class/function names (CamelCase → terms)
-- Key business terms in comments and strings
-- Framework-specific terminology
-
-Write to `.workflow/.doc-index/glossary.json`.
-
-## Phase 5: Git History Seeds
-
-```bash
-git log --oneline --since="3 months ago" --no-merges --format="%H|%s|%ai" | head -30
-```
-
-For each significant commit:
-- Match changed files to discovered components
-- Create action entry with `type: "historical"`
-
-## Phase 6: Assemble doc-index.json
-
-Write the index with code-first markers:
-
-```json
-{
-  "version": "1.0",
-  "project": "{project-name}",
-  "build_path": "code-first",
-  "spec_session": null,
-  "last_updated": "ISO8601",
-  "glossary": [...],
-  "features": [{
-    "id": "feat-{slug}",
-    "name": "Feature Name",
-    "epicId": null,
-    "status": "implemented|partial",
-    "docPath": "feature-maps/{slug}.md",
-    "requirementIds": ["IREQ-NNN"],
-    "tags": ["tag"]
-  }],
-  "requirements": [{
-    "id": "IREQ-NNN",
-    "title": "Inferred requirement",
-    "source": "inferred",
-    "priority": "inferred",
-    "sourcePath": null,
-    "techComponentIds": ["tech-{slug}"],
-    "featureId": "feat-{slug}"
-  }],
-  "technicalComponents": [{
-    "id": "tech-{slug}",
-    "name": "ComponentName",
-    "type": "service|controller|model|...",
-    "responsibility": "One-line description",
-    "adrId": "IADR-NNN|null",
-    "docPath": "tech-registry/{slug}.md",
-    "codeLocations": [{ "path": "src/...", "symbols": [...] }],
-    "dependsOn": ["tech-{other}"],
-    "featureIds": ["feat-{slug}"],
-    "actionIds": []
-  }],
-  "architectureDecisions": [{
-    "id": "IADR-NNN",
-    "title": "Inferred decision",
-    "source": "inferred",
-    "sourcePath": null,
-    "componentIds": ["tech-{slug}"]
-  }],
-  "actions": [{
-    "id": "act-{short-hash}",
-    "description": "Commit message",
-    "type": "historical",
-    "status": "historical",
-    "affectedComponents": ["tech-{slug}"],
-    "relatedCommit": "full-hash",
-    "timestamp": "ISO8601"
-  }],
-  "freshness": {
-    "thresholds": { "warning": 0.3, "stale": 0.7 },
-    "weights": { "time": 0.1, "churn": 0.4, "symbol": 0.5 },
-    "time_decay_k": 0.05,
-    "auto_regenerate": false
-  },
-  "deepwiki_feature_to_symbol_index": {}
-}
-```
-
-
-## Phase 7: Build DeepWiki Feature-to-Symbol Index
-
-If DeepWiki is available (`.codexlens/deepwiki_index.db` exists):
-
-1. Collect all `codeLocations[].path` from `technicalComponents[]`
-2. Query DeepWiki: `POST /api/deepwiki/symbols-for-paths { paths: [...] }`
-3. Build `deepwiki_feature_to_symbol_index` by traversing:
-   `feature → requirementIds → techComponentIds → codeLocations → symbols`
-
-```json
-"deepwiki_feature_to_symbol_index": {
-  "feat-auth": [
-    "deepwiki:symbol:src/auth/jwt.ts#L30-L55",
-    "deepwiki:symbol:src/models/user.ts#L12-L40"
-  ]
-}
-```
-
-**Symbol URN format**: `deepwiki:symbol:<file_path>#L<start>-L<end>`
-
-**Graceful degradation**: If DeepWiki is unavailable, set `deepwiki_feature_to_symbol_index: {}` and log warning.
-
-## Phase 8: Generate Documents
-
-Delegate all document generation to `/ddd:doc-generate`:
-
-```
-Invoke /ddd:doc-generate [-y]
-```
-
-This generates the complete document tree (Layer 3 → 2 → 1):
-- `tech-registry/{slug}.md` — component docs (Layer 3)
-- `feature-maps/{slug}.md` — feature docs (Layer 2)
-- `_index.md`, `README.md`, `ARCHITECTURE.md`, `SCHEMA.md` — index/overview docs (Layer 1)
-
-See `/ddd:doc-generate` for full details on generation strategy and flags.
-
-## Phase 9: Validation & Report
-
-```
-Scan Report
-
-Project: {name} ({language}/{framework})
-Architecture: {pattern}
-Source dirs: {N}
-
-Discovered:
-  Components: {N} ({by type breakdown})
-  Features: {N} (inferred)
-  Requirements: {N} (IREQ, inferred)
-  Architecture Decisions: {N} (IADR, inferred)
-  Historical Actions: {N} (from git)
-
-Coverage:
-  Components → Features: {%}
-  Dependencies mapped: {%}
-
-Recommendations:
-  - Run /spec-generator to formalize {N} inferred requirements
-  - {N} components have unclear responsibility — review tech-registry docs
-  - Use /ddd:plan to start planning tasks with this index
-```
-
-## Flags
-
-| Flag | Effect |
-|------|--------|
-| `-y, --yes` | Auto-confirm all decisions |
-| `--from-scratch` | Delete existing index and rebuild |
-| `--scope <dir>` | Limit scan to specific directory (e.g., `--scope src/auth`) |
-
-## Upgrade Path: scan → spec
-
-When a scanned project later runs `spec-generator` + `/ddd:index-build`:
-- `/ddd:index-build` detects existing code-first index
-- Merges: `IREQ-NNN` → `REQ-NNN`, `IADR-NNN` → `ADR-NNN` where content overlaps
-- Updates `build_path` to `"spec-first"`
-- Preserves all `tech-*` and `feat-*` entries (updates links only)
-
-## Integration Points
-
-- **Input from**: Codebase, git history, `project-tech.json`
-- **Delegates to**: `/ddd:doc-generate` (Phase 8, full document generation)
-- **Output to**: `ddd:plan`, `ddd:sync`, `ddd:update`, `ddd:index-build` (upgrade)
-- **Standalone**: Can be used independently on any project

.claude/commands/ddd/sync.md

@@ -1,353 +0,0 @@
----
-name: sync
-description: Post-task synchronization - update document index, generate action log, and refresh feature/component docs after completing a development task.
-argument-hint: "[-y|--yes] [--dry-run] [--from-manifest <path>] [--task-id <id>] [--commit <hash>] \"task summary\""
-allowed-tools: TodoWrite(*), Agent(*), AskUserQuestion(*), Read(*), Grep(*), Glob(*), Bash(*), Edit(*), Write(*), mcp__ace-tool__search_context(*)
----
-
-## Auto Mode
-
-When `--yes` or `-y`: Auto-detect changes, auto-update all docs, skip review prompts.
-
-# DDD Sync Command (/ddd:sync)
-
-## Purpose
-
-After completing a development task, synchronize the document index with actual code changes:
-1. **Analyze** what changed (git diff)
-2. **Trace** which features/requirements/components are affected
-3. **Update** index entries (status, code locations, links)
-4. **Generate** action log entry
-5. **Refresh** feature-map and tech-registry documents
-
-## When to Use: sync vs update
-
-| Scenario | Use |
-|----------|-----|
-| Task completed, ready to commit | **ddd:sync** — full post-task reconciliation |
-| Mid-development, quick impact check | ddd:update |
-| Pre-commit validation | ddd:update --check-only |
-| Auto-triggered after ddd:execute | **ddd:sync** (automatic) |
-| Periodic index refresh during refactoring | ddd:update |
-
-**Rule of thumb**: `sync` = task boundary (done something), `update` = development pulse (doing something).
-
-## Prerequisite
-
-- `doc-index.json` must exist
-- Git repository with committed or staged changes
-
-## Phase 0: Consistency Validation
-
-Before processing changes, verify that `doc-index.json` entries are consistent with actual code state.
-
-### 0.1 Validate Code Locations
-
-For each `technicalComponents[].codeLocations[]`:
-- Verify file exists on disk
-- If file was deleted/moved → flag for removal or update
-- If file exists → verify listed `symbols[]` still exist (quick grep/AST check)
-
-### 0.2 Validate Symbols
-
-For components with `codeLocations[].symbols[]`:
-- Check each symbol still exists in the referenced file
-- Detect new exported symbols not yet tracked
-- Report: `{N} stale symbols, {N} untracked symbols`
-
-### 0.3 Validation Report
-
-```
-Consistency Check:
-  Components validated: {N}
-  Files verified: {N}
-  Stale references: {N} (files missing or symbols removed)
-  Untracked symbols: {N} (new exports not in index)
-```
-
-If stale references found: warn and auto-fix during Phase 3 updates.
-If `--dry-run`: report only, no fixes.
-
-## Phase 1: Change Detection
-
-### 1.0.1 Schema Version Check
-
-Before processing changes, verify doc-index.json schema compatibility:
-
-```javascript
-const docIndex = JSON.parse(Read('.workflow/.doc-index/doc-index.json'));
-const schemaVersion = docIndex.schema_version || '0.0'; // Default for legacy
-
-if (schemaVersion !== '1.0') {
-  console.warn(`Schema version mismatch: found ${schemaVersion}, expected 1.0`);
-  console.warn('Consider running schema migration or regenerating doc-index with /ddd:scan');
-  // Continue with degraded functionality - may encounter missing fields
-}
-```
-
-**Graceful degradation**: If version mismatch detected → log warning → continue with caution (some features may not work as expected).
-
-### 1.0 Data Source Selection
-
-```
-IF --from-manifest <path>:
-  Load execution-manifest.json
-  → files_modified[] provides precise file list + action type + task attribution
-  → TASK-*.result.json provides symbol-level changes + convergence results
-  → Skip Phase 1.1/1.2 (already classified by execute)
-  → Proceed directly to Phase 2 with manifest data
-ELSE:
-  → Fall through to Phase 1.1 (git-based discovery)
-```
-
-**`--from-manifest` advantages** (used automatically by ddd:execute):
-- Precise file → task attribution (which task modified which file)
-- Symbol-level change tracking (not just file-level)
-- Convergence verification results carried forward to action-log
-- Survives process interruptions (manifest is persisted to disk)
-
-### 1.1 Identify Changes (git-based fallback)
-
-```bash
-# If --commit provided:
-git diff --name-only {commit}^..{commit}
-git diff --stat {commit}^..{commit}
-
-# If --task-id provided, find related commits:
-git log --oneline --grep="task-{id}" | head -10
-
-# Otherwise: changes since last ddd:sync
-git diff --name-only HEAD~1..HEAD
-```
-
-### 1.2 Classify Changes (git-based fallback)
-
-For each changed file, determine:
-- **Type**: added | modified | deleted | renamed
-- **Category**: source | test | config | docs | other
-- **Symbols affected**: parse diff for changed functions/classes (use Gemini if complex)
-
-## Phase 2: Impact Tracing (Layer-Based, TASK-004)
-
-**Strategy**: Trace impact through layers (files → components → features → indexes) following memory-manage pattern.
-
-### 2.1 Match to Index
-
-For each changed file path:
-
-```
-Search doc-index.json.technicalComponents[].codeLocations[].path
-→ Find matching component IDs (Layer 3)
-→ From components, find linked featureIds (Layer 2)
-→ From features, find linked requirementIds (Layer 2)
-```
-
-### 2.2 Discover New Components
-
-If changed files don't match any existing component:
-- Flag as potential new component
-- Ask user if it should be registered (or auto-register with `-y`)
-
-### 2.3 Build Impact Report
-
-```markdown
-## Impact Summary
-
-### Changed Files (5)
-- src/services/auth.ts (modified) → tech-auth-service → feat-auth
-- src/models/user.ts (modified) → tech-user-model → feat-auth
-- src/routes/login.ts (added) → NEW COMPONENT → feat-auth
-- src/tests/auth.test.ts (modified) → [test file, skip]
-- package.json (modified) → [config, skip]
-
-### Affected Features
-- feat-auth: User Authentication (2 components modified, 1 new)
-
-### Affected Requirements
-- REQ-001: Email login (implementation updated)
-- REQ-002: JWT token generation (implementation updated)
-```
-
-## Phase 2.4: DeepWiki Freshness Check
-
-If DeepWiki integration is configured (`doc-index.json.freshness` exists):
-
-### 2.4.1 Identify Modified Files
-From `execution-manifest.json` or git diff, collect `files_modified[]` with `action == "modified"`.
-
-### 2.4.2 Check Staleness
-Query DeepWiki: `POST /api/deepwiki/stale-files { files: [{path, hash}] }`
-
-For each stale file's symbols, calculate staleness score:
-```
-S(symbol) = min(1.0, w_t × T + w_c × C + w_s × M)
-```
-Where weights come from `doc-index.json.freshness.weights`.
-
-### 2.4.3 Score Propagation (max aggregation)
-```
-S_file      = max(S_symbol_1, S_symbol_2, ...)
-S_component = max(S_file_1, S_file_2, ...)
-S_feature   = max(S_component_1, S_component_2, ...)
-```
-
-### 2.4.4 Status Assignment
-Using thresholds from `doc-index.json.freshness.thresholds`:
-- `fresh`: score in [0, warning_threshold)
-- `warning`: score in [warning_threshold, stale_threshold)
-- `stale`: score in [stale_threshold, 1.0]
-
-### 2.4.5 Update Records
-- Update `deepwiki_symbols.staleness_score` and `deepwiki_files.staleness_score` in DeepWiki SQLite
-- Update `tech-registry/{slug}.md` YAML frontmatter with freshness block
-- Update `feature-maps/{slug}.md` YAML frontmatter with freshness block
-- Update `deepwiki_feature_to_symbol_index` in doc-index.json
-
-### 2.4.6 Staleness Report
-Add to action-log:
-- Number of stale symbols/files/components
-- Top-5 most stale items with scores
-- Auto-regeneration candidates (if `auto_regenerate: true` and score >= stale threshold)
-
-## Phase 3: Update Index
-
-### 3.0 Dry-Run Gate
-
-If `--dry-run` is set:
-- Execute Phase 3 analysis (determine what would change)
-- Display planned modifications as a preview report
-- Skip all file writes (Phase 3.1-3.5 and Phase 4)
-- Output: "Dry-run complete. Run without --dry-run to apply changes."
-
-### 3.0.1 Backup Index
-
-Before any modifications, create backup:
-- Copy `doc-index.json` → `doc-index.json.bak`
-- On failure: restore from `.bak` and report error
-- On success: remove `.bak`
-
-### 3.1 Update Technical Components
-
-For each affected component in `doc-index.json`:
-- Update `codeLocations` if file paths or line ranges changed
-- Update `symbols` if new exports were added
-- Add new `actionIds` entry
-- **Auto-update `responsibility`**: If symbols changed (new methods/exports added or removed), re-infer responsibility from current symbols list using Gemini analysis. This prevents stale descriptions (e.g., responsibility still says "登录、注册" after adding logout support)
-
-### 3.2 Register New Components
-
-For newly discovered components:
-- Generate `tech-{slug}` ID
-- Create entry in `technicalComponents[]`
-- Link to appropriate features
-- Generate new `tech-registry/{slug}.md` document
-
-### 3.3 Update Feature Status
-
-For each affected feature:
-- If all requirements now have mapped components → `status: "implemented"`
-- If some requirements still unmapped → `status: "in-progress"`
-
-### 3.4 Add Action Entry
-
-```json
-{
-  "id": "task-{id}",
-  "description": "{task summary from user}",
-  "type": "feature|bugfix|refactor",
-  "status": "completed",
-  "affectedFeatures": ["feat-auth"],
-  "affectedComponents": ["tech-auth-service", "tech-user-model"],
-  "changedFiles": [
-    { "path": "src/services/auth.ts", "action": "modified", "task_id": "TASK-001" },
-    { "path": "src/models/user.ts", "action": "modified", "task_id": "TASK-001" }
-  ],
-  "symbolsChanged": ["AuthService.validate", "UserModel.toJSON"],
-  "convergenceResults": {
-    "passed": 2,
-    "total": 2,
-    "details": ["Rate limiter middleware exists", "Config accepts per-route limits"]
-  },
-  "verifyGate": "PASS|WARN|FAIL|skipped",
-  "relatedCommit": "{commit hash}",
-  "manifestPath": "{execution-manifest.json path | null}",
-  "timestamp": "ISO8601"
-}
-```
-
-### 3.5 Update Timestamp
-
-Set `doc-index.json.last_updated` to current time.
-
-## Phase 4: Refresh Documents & Action Log
-
-### 4.1 Delegate Document Refresh to /ddd:doc-refresh
-
-From Phase 2 impact tracing, collect affected component and feature IDs, then delegate:
-
-```
-Invoke /ddd:doc-refresh [-y] --components {affected_component_ids} --features {affected_feature_ids}
-```
-
-This handles Layer 3 → 2 → 1 selective document refresh. See `/ddd:doc-refresh` for full details.
-
-### 4.2 Generate Action Log Entry
-
-Create `.workflow/.doc-index/action-logs/{task-id}.md`:
-
-```markdown
----
-id: task-{id}
-type: feature|bugfix|refactor
-status: completed
-features: [feat-auth]
-components: [tech-auth-service, tech-user-model]
-commit: {hash}
-timestamp: ISO8601
----
-
-# Task: {summary}
-
-## Changes
-| File | Type | Component |
-|------|------|-----------|
-| src/services/auth.ts | modified | tech-auth-service |
-
-## Impact
-- Features affected: feat-auth
-- Requirements addressed: REQ-001, REQ-002
-
-## Staleness (if DeepWiki freshness enabled)
-| Item | Type | Score | Status |
-|------|------|-------|--------|
-| {symbol/file/component} | {type} | {score} | {fresh/warning/stale} |
-
-## Notes
-{any user-provided notes}
-```
-
-## Phase 5: Confirmation (unless -y)
-
-Present update summary to user:
-- Files updated in doc-index
-- New documents created
-- Status changes
-- Ask for confirmation before writing
-
-## Flags
-
-| Flag | Effect |
-|------|--------|
-| `-y, --yes` | Auto-confirm all updates |
-| `--dry-run` | Preview all changes without modifying any files |
-| `--from-manifest <path>` | Use execution-manifest.json as data source (auto-set by ddd:execute) |
-| `--task-id <id>` | Associate with specific task ID |
-| `--commit <hash>` | Analyze specific commit |
-
-## Integration Points
-
-- **Input from**: `execution-manifest.json` (preferred, from ddd:execute) OR Git history (fallback), `doc-index.json`, `/ddd:plan` output
-- **Delegates to**: `/ddd:doc-refresh` (Phase 4.1, selective document refresh)
-- **Output to**: Updated `doc-index.json`, feature-maps/, tech-registry/, action-logs/
-- **Triggers**: After completing any development task
-- **Data source priority**: `--from-manifest` > `--commit` > `--task-id` > git diff HEAD~1

.claude/commands/ddd/update.md

@@ -1,160 +0,0 @@
----
-name: update
-description: Incremental index update - detect code changes and trace impact to related features/requirements. Lightweight alternative to full sync.
-argument-hint: "[-y|--yes] [--files <file1,file2,...>] [--staged] [--check-only]"
-allowed-tools: TodoWrite(*), AskUserQuestion(*), Read(*), Grep(*), Glob(*), Bash(*), Edit(*), Write(*), mcp__ace-tool__search_context(*)
----
-
-## Auto Mode
-
-When `--yes` or `-y`: Auto-update index without confirmation prompts.
-
-# DDD Update Command (/ddd:update)
-
-## Purpose
-
-Lightweight incremental update: given a set of changed files, trace their impact through the document index and update affected entries. Unlike `/ddd:sync` (full post-task sync), this command focuses on keeping the index fresh during development.
-
-## When to Use: update vs sync
-
-| Scenario | Use |
-|----------|-----|
-| Quick impact check during development | **ddd:update** |
-| Preview what sync would change | **ddd:update --check-only** |
-| Task completed, full reconciliation | ddd:sync |
-| Register new components + update all docs | ddd:sync |
-
-**Rule of thumb**: `update` = lightweight pulse (during work), `sync` = full checkpoint (after work).
-
-## Use Cases
-
-1. **During development**: Quick check which docs are affected by current changes
-2. **Pre-commit check**: Ensure index is up-to-date before committing
-3. **Periodic refresh**: Update stale code locations after refactoring
-
-## Prerequisite
-
-- `doc-index.json` must exist at `.workflow/.doc-index/doc-index.json`
-
-## Phase 1: Identify Changed Files
-
-### Source Priority
-
-```
-1. --files <list>      → Explicit file list
-2. --staged            → git diff --cached --name-only
-3. (default)           → git diff --name-only (unstaged changes)
-```
-
-### Output
-
-List of changed file paths with change type (added/modified/deleted/renamed).
-
-## Phase 2: Trace Impact
-
-### 2.1 Forward Lookup (Code → Components → Features)
-
-For each changed file:
-
-```
-doc-index.json.technicalComponents[]
-  .codeLocations[].path MATCH changed_file
-  → component_ids[]
-
-doc-index.json.technicalComponents[component_ids]
-  .featureIds[]
-  → feature_ids[]
-
-doc-index.json.features[feature_ids]
-  .requirementIds[]
-  → requirement_ids[]
-```
-
-### 2.2 Orphan Detection
-
-Files not matching any component → flag as:
-- **Potential new component**: if in src/ directory
-- **Ignorable**: if in test/, docs/, config/ directories
-
-### 2.3 Impact Report
-
-```
-Impact Analysis for 3 changed files:
-
-  src/services/auth.ts (modified)
-    → Component: tech-auth-service (AuthService)
-    → Feature: feat-auth (User Authentication)
-    → Requirements: REQ-001, REQ-002
-
-  src/middleware/rate-limit.ts (added)
-    → No matching component (new file)
-    → Suggested: Register as new component
-
-  src/utils/hash.ts (modified)
-    → Component: tech-hash-util
-    → Features: feat-auth, feat-password-reset
-    → Requirements: REQ-001, REQ-005
-```
-
-## Phase 3: Update Index (unless --check-only)
-
-### 3.1 Update Code Locations
-
-For matched components:
-- If file was renamed → update `codeLocations[].path`
-- If file was deleted → remove code location entry
-- If symbols changed → update `symbols` list (requires AST or Gemini analysis)
-
-### 3.2 Register New Components (interactive unless -y)
-
-For orphan files in src/:
-- Prompt user for component name and type
-- Or auto-generate with `-y`: derive name from file path
-- Create `technicalComponents[]` entry
-- Ask which feature it belongs to (or auto-link by directory structure)
-
-### 3.3 Update Timestamps
-
-- Update `technicalComponents[].docPath` last_updated in corresponding .md
-- Update `doc-index.json.last_updated`
-
-## Phase 4: Refresh Documents (if updates were made)
-
-### 4.1 Delegate to /ddd:doc-refresh
-
-From Phase 2 impact tracing, collect affected component and feature IDs, then delegate:
-
-```
-Invoke /ddd:doc-refresh [-y] --minimal --components {affected_component_ids} --features {affected_feature_ids}
-```
-
-The `--minimal` flag ensures only metadata/frontmatter is updated (code locations, timestamps), skipping full content regeneration. This keeps the update lightweight.
-
-See `/ddd:doc-refresh` for full details.
-
-### 4.2 Skip If --check-only
-
-With `--check-only`, skip Phase 3 and Phase 4 entirely — only output the impact report.
-
-## Flags
-
-| Flag | Effect |
-|------|--------|
-| `-y, --yes` | Auto-confirm updates |
-| `--files <list>` | Explicit comma-separated file list |
-| `--staged` | Analyze staged (git cached) files |
-| `--check-only` | Report impact without modifying index |
-
-## Output
-
-- **Console**: Impact report showing affected features/requirements
-- **Updated**: `doc-index.json` (if not --check-only)
-- **Updated**: Affected tech-registry/ and feature-maps/ docs
-
-## Integration Points
-
-- **Input from**: Git working tree, `doc-index.json`
-- **Delegates to**: `/ddd:doc-refresh` (Phase 4.1, incremental document refresh with --minimal)
-- **Output to**: Updated `doc-index.json`, impact report
-- **Triggers**: During development, pre-commit, or periodic refresh
-- **Can chain to**: `/ddd:sync` for full post-task synchronization

.claude/commands/idaw/add.md

@@ -1,287 +0,0 @@
----
-name: add
-description: Add IDAW tasks - manual creation or import from ccw issue
-argument-hint: "[-y|--yes] [--from-issue <id>[,<id>,...]] \"description\" [--type <task_type>] [--priority <1-5>]"
-allowed-tools: AskUserQuestion(*), Read(*), Bash(*), Write(*), Glob(*)
----
-
-# IDAW Add Command (/idaw:add)
-
-## Auto Mode
-
-When `--yes` or `-y`: Skip clarification questions, create task with inferred details.
-
-## IDAW Task Schema
-
-```json
-{
-  "id": "IDAW-001",
-  "title": "string",
-  "description": "string",
-  "status": "pending",
-  "priority": 2,
-  "task_type": null,
-  "skill_chain": null,
-  "context": {
-    "affected_files": [],
-    "acceptance_criteria": [],
-    "constraints": [],
-    "references": []
-  },
-  "source": {
-    "type": "manual|import-issue",
-    "issue_id": null,
-    "issue_snapshot": null
-  },
-  "execution": {
-    "session_id": null,
-    "started_at": null,
-    "completed_at": null,
-    "skill_results": [],
-    "git_commit": null,
-    "error": null
-  },
-  "created_at": "ISO",
-  "updated_at": "ISO"
-}
-```
-
-**Valid task_type values**: `bugfix|bugfix-hotfix|feature|feature-complex|refactor|tdd|test|test-fix|review|docs`
-
-## Implementation
-
-### Phase 1: Parse Arguments
-
-```javascript
-const args = $ARGUMENTS;
-const autoYes = /(-y|--yes)\b/.test(args);
-const fromIssue = args.match(/--from-issue\s+([\w,-]+)/)?.[1];
-const typeFlag = args.match(/--type\s+([\w-]+)/)?.[1];
-const priorityFlag = args.match(/--priority\s+(\d)/)?.[1];
-
-// Extract description: content inside quotes (preferred), or fallback to stripping flags
-const quotedMatch = args.match(/(?:^|\s)["']([^"']+)["']/);
-const description = quotedMatch
-  ? quotedMatch[1].trim()
-  : args.replace(/(-y|--yes|--from-issue\s+[\w,-]+|--type\s+[\w-]+|--priority\s+\d)/g, '').trim();
-```
-
-### Phase 2: Route — Import or Manual
-
-```
---from-issue present?
-  ├─ YES → Import Mode (Phase 3A)
-  └─ NO  → Manual Mode (Phase 3B)
-```
-
-### Phase 3A: Import Mode (from ccw issue)
-
-```javascript
-const issueIds = fromIssue.split(',');
-
-// Fetch all issues once (outside loop)
-let issues = [];
-try {
-  const issueJson = Bash(`ccw issue list --json`);
-  issues = JSON.parse(issueJson).issues || [];
-} catch (e) {
-  console.log(`Error fetching CCW issues: ${e.message || e}`);
-  console.log('Ensure ccw is installed and issues exist. Use /issue:new to create issues first.');
-  return;
-}
-
-for (const issueId of issueIds) {
-  // 1. Find issue data
-  const issue = issues.find(i => i.id === issueId.trim());
-  if (!issue) {
-    console.log(`Warning: Issue ${issueId} not found, skipping`);
-    continue;
-  }
-
-  // 2. Check duplicate (same issue_id already imported)
-  const existing = Glob('.workflow/.idaw/tasks/IDAW-*.json');
-  for (const f of existing) {
-    const data = JSON.parse(Read(f));
-    if (data.source?.issue_id === issueId.trim()) {
-      console.log(`Warning: Issue ${issueId} already imported as ${data.id}, skipping`);
-      continue; // skip to next issue
-    }
-  }
-
-  // 3. Generate next IDAW ID
-  const nextId = generateNextId();
-
-  // 4. Map issue → IDAW task
-  const task = {
-    id: nextId,
-    title: issue.title,
-    description: issue.context || issue.title,
-    status: 'pending',
-    priority: parseInt(priorityFlag) || issue.priority || 3,
-    task_type: typeFlag || inferTaskType(issue.title, issue.context || ''),
-    skill_chain: null,
-    context: {
-      affected_files: issue.affected_components || [],
-      acceptance_criteria: [],
-      constraints: [],
-      references: issue.source_url ? [issue.source_url] : []
-    },
-    source: {
-      type: 'import-issue',
-      issue_id: issue.id,
-      issue_snapshot: {
-        id: issue.id,
-        title: issue.title,
-        status: issue.status,
-        context: issue.context,
-        priority: issue.priority,
-        created_at: issue.created_at
-      }
-    },
-    execution: {
-      session_id: null,
-      started_at: null,
-      completed_at: null,
-      skill_results: [],
-      git_commit: null,
-      error: null
-    },
-    created_at: new Date().toISOString(),
-    updated_at: new Date().toISOString()
-  };
-
-  // 5. Write task file
-  Bash('mkdir -p .workflow/.idaw/tasks');
-  Write(`.workflow/.idaw/tasks/${nextId}.json`, JSON.stringify(task, null, 2));
-  console.log(`Created ${nextId} from issue ${issueId}: ${issue.title}`);
-}
-```
-
-### Phase 3B: Manual Mode
-
-```javascript
-// 1. Validate description
-if (!description && !autoYes) {
-  const answer = AskUserQuestion({
-    questions: [{
-      question: 'Please provide a task description:',
-      header: 'Task',
-      multiSelect: false,
-      options: [
-        { label: 'Provide description', description: 'What needs to be done?' }
-      ]
-    }]
-  });
-  // Use custom text from "Other"
-  description = answer.customText || '';
-}
-
-if (!description) {
-  console.log('Error: No description provided. Usage: /idaw:add "task description"');
-  return;
-}
-
-// 2. Generate next IDAW ID
-const nextId = generateNextId();
-
-// 3. Build title from first sentence
-const title = description.split(/[.\n]/)[0].substring(0, 80).trim();
-
-// 4. Determine task_type
-const taskType = typeFlag || null; // null → inferred at run time
-
-// 5. Create task
-const task = {
-  id: nextId,
-  title: title,
-  description: description,
-  status: 'pending',
-  priority: parseInt(priorityFlag) || 3,
-  task_type: taskType,
-  skill_chain: null,
-  context: {
-    affected_files: [],
-    acceptance_criteria: [],
-    constraints: [],
-    references: []
-  },
-  source: {
-    type: 'manual',
-    issue_id: null,
-    issue_snapshot: null
-  },
-  execution: {
-    session_id: null,
-    started_at: null,
-    completed_at: null,
-    skill_results: [],
-    git_commit: null,
-    error: null
-  },
-  created_at: new Date().toISOString(),
-  updated_at: new Date().toISOString()
-};
-
-Bash('mkdir -p .workflow/.idaw/tasks');
-Write(`.workflow/.idaw/tasks/${nextId}.json`, JSON.stringify(task, null, 2));
-console.log(`Created ${nextId}: ${title}`);
-```
-
-## Helper Functions
-
-### ID Generation
-
-```javascript
-function generateNextId() {
-  const files = Glob('.workflow/.idaw/tasks/IDAW-*.json') || [];
-  if (files.length === 0) return 'IDAW-001';
-
-  const maxNum = files
-    .map(f => parseInt(f.match(/IDAW-(\d+)/)?.[1] || '0'))
-    .reduce((max, n) => Math.max(max, n), 0);
-
-  return `IDAW-${String(maxNum + 1).padStart(3, '0')}`;
-}
-```
-
-### Task Type Inference (deferred — used at run time if task_type is null)
-
-```javascript
-function inferTaskType(title, description) {
-  const text = `${title} ${description}`.toLowerCase();
-  if (/urgent|production|critical/.test(text) && /fix|bug/.test(text)) return 'bugfix-hotfix';
-  if (/refactor|重构|tech.*debt/.test(text)) return 'refactor';
-  if (/tdd|test-driven|test first/.test(text)) return 'tdd';
-  if (/test fail|fix test|failing test/.test(text)) return 'test-fix';
-  if (/generate test|写测试|add test/.test(text)) return 'test';
-  if (/review|code review/.test(text)) return 'review';
-  if (/docs|documentation|readme/.test(text)) return 'docs';
-  if (/fix|bug|error|crash|fail/.test(text)) return 'bugfix';
-  if (/complex|multi-module|architecture/.test(text)) return 'feature-complex';
-  return 'feature';
-}
-```
-
-## Examples
-
-```bash
-# Manual creation
-/idaw:add "Fix login timeout bug" --type bugfix --priority 2
-/idaw:add "Add rate limiting to API endpoints" --priority 1
-/idaw:add "Refactor auth module to use strategy pattern"
-
-# Import from ccw issue
-/idaw:add --from-issue ISS-20260128-001
-/idaw:add --from-issue ISS-20260128-001,ISS-20260128-002 --priority 1
-
-# Auto mode (skip clarification)
-/idaw:add -y "Quick fix for typo in header"
-```
-
-## Output
-
-```
-Created IDAW-001: Fix login timeout bug
-  Type: bugfix | Priority: 2 | Source: manual
-  → Next: /idaw:run or /idaw:status
-```

.claude/commands/idaw/resume.md

@@ -1,442 +0,0 @@
----
-name: resume
-description: Resume interrupted IDAW session from last checkpoint
-argument-hint: "[-y|--yes] [session-id]"
-allowed-tools: Skill(*), TodoWrite(*), AskUserQuestion(*), Read(*), Write(*), Bash(*), Glob(*)
----
-
-# IDAW Resume Command (/idaw:resume)
-
-## Auto Mode
-
-When `--yes` or `-y`: Auto-skip interrupted task, continue with remaining.
-
-## Skill Chain Mapping
-
-```javascript
-const SKILL_CHAIN_MAP = {
-  'bugfix':          ['workflow-lite-plan', 'workflow-test-fix'],
-  'bugfix-hotfix':   ['workflow-lite-plan'],
-  'feature':         ['workflow-lite-plan', 'workflow-test-fix'],
-  'feature-complex': ['workflow-plan', 'workflow-execute', 'workflow-test-fix'],
-  'refactor':        ['workflow:refactor-cycle'],
-  'tdd':             ['workflow-tdd-plan', 'workflow-execute'],
-  'test':            ['workflow-test-fix'],
-  'test-fix':        ['workflow-test-fix'],
-  'review':          ['review-cycle'],
-  'docs':            ['workflow-lite-plan']
-};
-```
-
-## Task Type Inference
-
-```javascript
-function inferTaskType(title, description) {
-  const text = `${title} ${description}`.toLowerCase();
-  if (/urgent|production|critical/.test(text) && /fix|bug/.test(text)) return 'bugfix-hotfix';
-  if (/refactor|重构|tech.*debt/.test(text)) return 'refactor';
-  if (/tdd|test-driven|test first/.test(text)) return 'tdd';
-  if (/test fail|fix test|failing test/.test(text)) return 'test-fix';
-  if (/generate test|写测试|add test/.test(text)) return 'test';
-  if (/review|code review/.test(text)) return 'review';
-  if (/docs|documentation|readme/.test(text)) return 'docs';
-  if (/fix|bug|error|crash|fail/.test(text)) return 'bugfix';
-  if (/complex|multi-module|architecture/.test(text)) return 'feature-complex';
-  return 'feature';
-}
-```
-
-## Implementation
-
-### Phase 1: Find Resumable Session
-
-```javascript
-const args = $ARGUMENTS;
-const autoYes = /(-y|--yes)/.test(args);
-const targetSessionId = args.replace(/(-y|--yes)/g, '').trim();
-
-let session = null;
-let sessionDir = null;
-
-if (targetSessionId) {
-  // Load specific session
-  sessionDir = `.workflow/.idaw/sessions/${targetSessionId}`;
-  try {
-    session = JSON.parse(Read(`${sessionDir}/session.json`));
-  } catch {
-    console.log(`Session "${targetSessionId}" not found.`);
-    console.log('Use /idaw:status to list sessions, or /idaw:run to start a new one.');
-    return;
-  }
-} else {
-  // Find most recent running session
-  const sessionFiles = Glob('.workflow/.idaw/sessions/IDA-*/session.json') || [];
-
-  for (const f of sessionFiles) {
-    try {
-      const s = JSON.parse(Read(f));
-      if (s.status === 'running') {
-        session = s;
-        sessionDir = f.replace(/\/session\.json$/, '').replace(/\\session\.json$/, '');
-        break;
-      }
-    } catch {
-      // Skip malformed
-    }
-  }
-
-  if (!session) {
-    console.log('No running sessions found to resume.');
-    console.log('Use /idaw:run to start a new execution.');
-    return;
-  }
-}
-
-console.log(`Resuming session: ${session.session_id}`);
-```
-
-### Phase 2: Handle Interrupted Task
-
-```javascript
-// Find the task that was in_progress when interrupted
-let currentTaskId = session.current_task;
-let currentTask = null;
-
-if (currentTaskId) {
-  try {
-    currentTask = JSON.parse(Read(`.workflow/.idaw/tasks/${currentTaskId}.json`));
-  } catch {
-    console.log(`Warning: Could not read task ${currentTaskId}`);
-    currentTaskId = null;
-  }
-}
-
-if (currentTask && currentTask.status === 'in_progress') {
-  if (autoYes) {
-    // Auto: skip interrupted task
-    currentTask.status = 'skipped';
-    currentTask.execution.error = 'Skipped on resume (auto mode)';
-    currentTask.execution.completed_at = new Date().toISOString();
-    currentTask.updated_at = new Date().toISOString();
-    Write(`.workflow/.idaw/tasks/${currentTaskId}.json`, JSON.stringify(currentTask, null, 2));
-    session.skipped.push(currentTaskId);
-    console.log(`Skipped interrupted task: ${currentTaskId}`);
-  } else {
-    const answer = AskUserQuestion({
-      questions: [{
-        question: `Task ${currentTaskId} was interrupted: "${currentTask.title}". How to proceed?`,
-        header: 'Resume',
-        multiSelect: false,
-        options: [
-          { label: 'Retry', description: 'Reset to pending, re-execute from beginning' },
-          { label: 'Skip', description: 'Mark as skipped, move to next task' }
-        ]
-      }]
-    });
-
-    if (answer.answers?.Resume === 'Skip') {
-      currentTask.status = 'skipped';
-      currentTask.execution.error = 'Skipped on resume (user choice)';
-      currentTask.execution.completed_at = new Date().toISOString();
-      currentTask.updated_at = new Date().toISOString();
-      Write(`.workflow/.idaw/tasks/${currentTaskId}.json`, JSON.stringify(currentTask, null, 2));
-      session.skipped.push(currentTaskId);
-    } else {
-      // Retry: reset to pending
-      currentTask.status = 'pending';
-      currentTask.execution.started_at = null;
-      currentTask.execution.completed_at = null;
-      currentTask.execution.skill_results = [];
-      currentTask.execution.error = null;
-      currentTask.updated_at = new Date().toISOString();
-      Write(`.workflow/.idaw/tasks/${currentTaskId}.json`, JSON.stringify(currentTask, null, 2));
-    }
-  }
-}
-```
-
-### Phase 3: Build Remaining Task Queue
-
-```javascript
-// Collect remaining tasks (pending, or the retried current task)
-const allTaskIds = session.tasks;
-const completedSet = new Set([...session.completed, ...session.failed, ...session.skipped]);
-
-const remainingTasks = [];
-for (const taskId of allTaskIds) {
-  if (completedSet.has(taskId)) continue;
-  try {
-    const task = JSON.parse(Read(`.workflow/.idaw/tasks/${taskId}.json`));
-    if (task.status === 'pending') {
-      remainingTasks.push(task);
-    }
-  } catch {
-    console.log(`Warning: Could not read task ${taskId}, skipping`);
-  }
-}
-
-if (remainingTasks.length === 0) {
-  console.log('No remaining tasks to execute. Session complete.');
-  session.status = 'completed';
-  session.current_task = null;
-  session.updated_at = new Date().toISOString();
-  Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-  return;
-}
-
-// Sort: priority ASC, then ID ASC
-remainingTasks.sort((a, b) => {
-  if (a.priority !== b.priority) return a.priority - b.priority;
-  return a.id.localeCompare(b.id);
-});
-
-console.log(`Remaining tasks: ${remainingTasks.length}`);
-
-// Append resume marker to progress.md
-const progressFile = `${sessionDir}/progress.md`;
-try {
-  const currentProgress = Read(progressFile);
-  Write(progressFile, currentProgress + `\n---\n**Resumed**: ${new Date().toISOString()}\n\n`);
-} catch {
-  Write(progressFile, `# IDAW Progress — ${session.session_id}\n\n---\n**Resumed**: ${new Date().toISOString()}\n\n`);
-}
-
-// Update TodoWrite
-TodoWrite({
-  todos: remainingTasks.map((t, i) => ({
-    content: `IDAW:[${i + 1}/${remainingTasks.length}] ${t.title}`,
-    status: i === 0 ? 'in_progress' : 'pending',
-    activeForm: `Executing ${t.title}`
-  }))
-});
-```
-
-### Phase 4-6: Execute Remaining (reuse run.md main loop)
-
-Execute remaining tasks using the same Phase 4-6 logic from `/idaw:run`:
-
-```javascript
-// Phase 4: Main Loop — identical to run.md Phase 4
-for (let taskIdx = 0; taskIdx < remainingTasks.length; taskIdx++) {
-  const task = remainingTasks[taskIdx];
-
-  // Resolve skill chain
-  const resolvedType = task.task_type || inferTaskType(task.title, task.description);
-  const chain = task.skill_chain || SKILL_CHAIN_MAP[resolvedType] || SKILL_CHAIN_MAP['feature'];
-
-  // Update task → in_progress
-  task.status = 'in_progress';
-  task.task_type = resolvedType;
-  task.execution.started_at = new Date().toISOString();
-  Write(`.workflow/.idaw/tasks/${task.id}.json`, JSON.stringify(task, null, 2));
-
-  session.current_task = task.id;
-  session.updated_at = new Date().toISOString();
-  Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-
-  console.log(`\n--- [${taskIdx + 1}/${remainingTasks.length}] ${task.id}: ${task.title} ---`);
-  console.log(`Chain: ${chain.join(' → ')}`);
-
-  // ━━━ Pre-Task CLI Context Analysis (for complex/bugfix tasks) ━━━
-  if (['bugfix', 'bugfix-hotfix', 'feature-complex'].includes(resolvedType)) {
-    console.log(`  Pre-analysis: gathering context for ${resolvedType} task...`);
-    const affectedFiles = (task.context?.affected_files || []).join(', ');
-    const preAnalysisPrompt = `PURPOSE: Pre-analyze codebase context for IDAW task before execution.
-TASK: • Understand current state of: ${affectedFiles || 'files related to: ' + task.title} • Identify dependencies and risk areas • Note existing patterns to follow
-MODE: analysis
-CONTEXT: @**/*
-EXPECTED: Brief context summary (affected modules, dependencies, risk areas) in 3-5 bullet points
-CONSTRAINTS: Keep concise | Focus on execution-relevant context`;
-    const preAnalysis = Bash(`ccw cli -p '${preAnalysisPrompt.replace(/'/g, "'\\''")}' --tool gemini --mode analysis 2>&1 || echo "Pre-analysis skipped"`);
-    task.execution.skill_results.push({
-      skill: 'cli-pre-analysis',
-      status: 'completed',
-      context_summary: preAnalysis?.substring(0, 500),
-      timestamp: new Date().toISOString()
-    });
-  }
-
-  // Execute skill chain
-  let previousResult = null;
-  let taskFailed = false;
-
-  for (let skillIdx = 0; skillIdx < chain.length; skillIdx++) {
-    const skillName = chain[skillIdx];
-    const skillArgs = assembleSkillArgs(skillName, task, previousResult, autoYes, skillIdx === 0);
-
-    console.log(`  [${skillIdx + 1}/${chain.length}] ${skillName}`);
-
-    try {
-      const result = Skill({ skill: skillName, args: skillArgs });
-      previousResult = result;
-      task.execution.skill_results.push({
-        skill: skillName,
-        status: 'completed',
-        timestamp: new Date().toISOString()
-      });
-    } catch (error) {
-      // ━━━ CLI-Assisted Error Recovery ━━━
-      console.log(`  Diagnosing failure: ${skillName}...`);
-      const diagnosisPrompt = `PURPOSE: Diagnose why skill "${skillName}" failed during IDAW task execution.
-TASK: • Analyze error: ${String(error).substring(0, 300)} • Check affected files: ${(task.context?.affected_files || []).join(', ') || 'unknown'} • Identify root cause • Suggest fix strategy
-MODE: analysis
-CONTEXT: @**/* | Memory: IDAW task ${task.id}: ${task.title}
-EXPECTED: Root cause + actionable fix recommendation (1-2 sentences)
-CONSTRAINTS: Focus on actionable diagnosis`;
-      const diagnosisResult = Bash(`ccw cli -p '${diagnosisPrompt.replace(/'/g, "'\\''")}' --tool gemini --mode analysis --rule analysis-diagnose-bug-root-cause 2>&1 || echo "CLI diagnosis unavailable"`);
-
-      task.execution.skill_results.push({
-        skill: `cli-diagnosis:${skillName}`,
-        status: 'completed',
-        diagnosis: diagnosisResult?.substring(0, 500),
-        timestamp: new Date().toISOString()
-      });
-
-      // Retry with diagnosis context
-      console.log(`  Retry with diagnosis: ${skillName}`);
-      try {
-        const retryResult = Skill({ skill: skillName, args: skillArgs });
-        previousResult = retryResult;
-        task.execution.skill_results.push({
-          skill: skillName,
-          status: 'completed-retry-with-diagnosis',
-          timestamp: new Date().toISOString()
-        });
-      } catch (retryError) {
-        task.execution.skill_results.push({
-          skill: skillName,
-          status: 'failed',
-          error: String(retryError).substring(0, 200),
-          timestamp: new Date().toISOString()
-        });
-
-        if (autoYes) {
-          taskFailed = true;
-          break;
-        }
-
-        const answer = AskUserQuestion({
-          questions: [{
-            question: `${skillName} failed after CLI diagnosis + retry: ${String(retryError).substring(0, 100)}`,
-            header: 'Error',
-            multiSelect: false,
-            options: [
-              { label: 'Skip task', description: 'Mark as failed, continue' },
-              { label: 'Abort', description: 'Stop run' }
-            ]
-          }]
-        });
-
-        if (answer.answers?.Error === 'Abort') {
-          task.status = 'failed';
-          task.execution.error = String(retryError).substring(0, 200);
-          Write(`.workflow/.idaw/tasks/${task.id}.json`, JSON.stringify(task, null, 2));
-          session.failed.push(task.id);
-          session.status = 'failed';
-          session.updated_at = new Date().toISOString();
-          Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-          return;
-        }
-        taskFailed = true;
-        break;
-      }
-    }
-  }
-
-  // Phase 5: Checkpoint
-  if (taskFailed) {
-    task.status = 'failed';
-    task.execution.error = 'Skill chain failed after retry';
-    task.execution.completed_at = new Date().toISOString();
-    session.failed.push(task.id);
-  } else {
-    // Git commit
-    const commitMsg = `feat(idaw): ${task.title} [${task.id}]`;
-    const diffCheck = Bash('git diff --stat HEAD 2>/dev/null || echo ""');
-    const untrackedCheck = Bash('git ls-files --others --exclude-standard 2>/dev/null || echo ""');
-
-    if (diffCheck?.trim() || untrackedCheck?.trim()) {
-      Bash('git add -A');
-      Bash(`git commit -m "$(cat <<'EOF'\n${commitMsg}\nEOF\n)"`);
-      const commitHash = Bash('git rev-parse --short HEAD 2>/dev/null')?.trim();
-      task.execution.git_commit = commitHash;
-    } else {
-      task.execution.git_commit = 'no-commit';
-    }
-
-    task.status = 'completed';
-    task.execution.completed_at = new Date().toISOString();
-    session.completed.push(task.id);
-  }
-
-  task.updated_at = new Date().toISOString();
-  Write(`.workflow/.idaw/tasks/${task.id}.json`, JSON.stringify(task, null, 2));
-  session.updated_at = new Date().toISOString();
-  Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-
-  // Append progress
-  const chain_str = chain.join(' → ');
-  const progressEntry = `## ${task.id} — ${task.title}\n- Status: ${task.status}\n- Chain: ${chain_str}\n- Commit: ${task.execution.git_commit || '-'}\n\n`;
-  const currentProgress = Read(`${sessionDir}/progress.md`);
-  Write(`${sessionDir}/progress.md`, currentProgress + progressEntry);
-}
-
-// Phase 6: Report
-session.status = session.failed.length > 0 && session.completed.length === 0 ? 'failed' : 'completed';
-session.current_task = null;
-session.updated_at = new Date().toISOString();
-Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-
-const summary = `\n---\n## Summary (Resumed)\n- Completed: ${session.completed.length}\n- Failed: ${session.failed.length}\n- Skipped: ${session.skipped.length}\n`;
-const finalProgress = Read(`${sessionDir}/progress.md`);
-Write(`${sessionDir}/progress.md`, finalProgress + summary);
-
-console.log('\n=== IDAW Resume Complete ===');
-console.log(`Session: ${session.session_id}`);
-console.log(`Completed: ${session.completed.length} | Failed: ${session.failed.length} | Skipped: ${session.skipped.length}`);
-```
-
-## Helper Functions
-
-### assembleSkillArgs
-
-```javascript
-function assembleSkillArgs(skillName, task, previousResult, autoYes, isFirst) {
-  let args = '';
-
-  if (isFirst) {
-    // Sanitize for shell safety
-    const goal = `${task.title}\n${task.description}`
-      .replace(/\\/g, '\\\\')
-      .replace(/"/g, '\\"')
-      .replace(/\$/g, '\\$')
-      .replace(/`/g, '\\`');
-    args = `"${goal}"`;
-    if (task.task_type === 'bugfix-hotfix') args += ' --hotfix';
-  } else if (previousResult?.session_id) {
-    args = `--session="${previousResult.session_id}"`;
-  }
-
-  if (autoYes && !args.includes('-y') && !args.includes('--yes')) {
-    args = args ? `${args} -y` : '-y';
-  }
-
-  return args;
-}
-```
-
-## Examples
-
-```bash
-# Resume most recent running session (interactive)
-/idaw:resume
-
-# Resume specific session
-/idaw:resume IDA-auth-fix-20260301
-
-# Resume with auto mode (skip interrupted, continue)
-/idaw:resume -y
-
-# Resume specific session with auto mode
-/idaw:resume -y IDA-auth-fix-20260301
-```

.claude/commands/idaw/run-coordinate.md

@@ -1,648 +0,0 @@
----
-name: run-coordinate
-description: IDAW coordinator - execute task skill chains via external CLI with hook callbacks and git checkpoints
-argument-hint: "[-y|--yes] [--task <id>[,<id>,...]] [--dry-run] [--tool <tool>]"
-allowed-tools: Agent(*), AskUserQuestion(*), Read(*), Write(*), Bash(*), Glob(*), Grep(*)
----
-
-# IDAW Run Coordinate Command (/idaw:run-coordinate)
-
-Coordinator variant of `/idaw:run`: external CLI execution with background tasks and hook callbacks.
-
-**Execution Model**: `ccw cli -p "..." --tool <tool> --mode write` in background → hook callback → next step.
-
-**vs `/idaw:run`**: Direct `Skill()` calls (blocking, main process) vs `ccw cli` (background, external process).
-
-## When to Use
-
-| Scenario | Use |
-|----------|-----|
-| Standard IDAW execution (main process) | `/idaw:run` |
-| External CLI execution (background, hook-driven) | `/idaw:run-coordinate` |
-| Need `claude` or `gemini` as execution tool | `/idaw:run-coordinate --tool claude` |
-| Long-running tasks, avoid context window pressure | `/idaw:run-coordinate` |
-
-## Skill Chain Mapping
-
-```javascript
-const SKILL_CHAIN_MAP = {
-  'bugfix':          ['workflow-lite-plan', 'workflow-test-fix'],
-  'bugfix-hotfix':   ['workflow-lite-plan'],
-  'feature':         ['workflow-lite-plan', 'workflow-test-fix'],
-  'feature-complex': ['workflow-plan', 'workflow-execute', 'workflow-test-fix'],
-  'refactor':        ['workflow:refactor-cycle'],
-  'tdd':             ['workflow-tdd-plan', 'workflow-execute'],
-  'test':            ['workflow-test-fix'],
-  'test-fix':        ['workflow-test-fix'],
-  'review':          ['review-cycle'],
-  'docs':            ['workflow-lite-plan']
-};
-```
-
-## Task Type Inference
-
-```javascript
-function inferTaskType(title, description) {
-  const text = `${title} ${description}`.toLowerCase();
-  if (/urgent|production|critical/.test(text) && /fix|bug/.test(text)) return 'bugfix-hotfix';
-  if (/refactor|重构|tech.*debt/.test(text)) return 'refactor';
-  if (/tdd|test-driven|test first/.test(text)) return 'tdd';
-  if (/test fail|fix test|failing test/.test(text)) return 'test-fix';
-  if (/generate test|写测试|add test/.test(text)) return 'test';
-  if (/review|code review/.test(text)) return 'review';
-  if (/docs|documentation|readme/.test(text)) return 'docs';
-  if (/fix|bug|error|crash|fail/.test(text)) return 'bugfix';
-  if (/complex|multi-module|architecture/.test(text)) return 'feature-complex';
-  return 'feature';
-}
-```
-
-## 6-Phase Execution (Coordinator Model)
-
-### Phase 1: Load Tasks
-
-```javascript
-const args = $ARGUMENTS;
-const autoYes = /(-y|--yes)/.test(args);
-const dryRun = /--dry-run/.test(args);
-const taskFilter = args.match(/--task\s+([\w,-]+)/)?.[1]?.split(',') || null;
-const cliTool = args.match(/--tool\s+(\w+)/)?.[1] || 'claude';
-
-// Load task files
-const taskFiles = Glob('.workflow/.idaw/tasks/IDAW-*.json') || [];
-
-if (taskFiles.length === 0) {
-  console.log('No IDAW tasks found. Use /idaw:add to create tasks.');
-  return;
-}
-
-// Parse and filter
-let tasks = taskFiles.map(f => JSON.parse(Read(f)));
-
-if (taskFilter) {
-  tasks = tasks.filter(t => taskFilter.includes(t.id));
-} else {
-  tasks = tasks.filter(t => t.status === 'pending');
-}
-
-if (tasks.length === 0) {
-  console.log('No pending tasks to execute. Use /idaw:add to add tasks or --task to specify IDs.');
-  return;
-}
-
-// Sort: priority ASC (1=critical first), then ID ASC
-tasks.sort((a, b) => {
-  if (a.priority !== b.priority) return a.priority - b.priority;
-  return a.id.localeCompare(b.id);
-});
-```
-
-### Phase 2: Session Setup
-
-```javascript
-// Generate session ID: IDA-{slug}-YYYYMMDD
-const slug = tasks[0].title
-  .toLowerCase()
-  .replace(/[^a-z0-9]+/g, '-')
-  .substring(0, 20)
-  .replace(/-$/, '');
-const dateStr = new Date().toISOString().slice(0, 10).replace(/-/g, '');
-let sessionId = `IDA-${slug}-${dateStr}`;
-
-// Check collision
-const existingSession = Glob(`.workflow/.idaw/sessions/${sessionId}/session.json`);
-if (existingSession?.length > 0) {
-  sessionId = `${sessionId}-2`;
-}
-
-const sessionDir = `.workflow/.idaw/sessions/${sessionId}`;
-Bash(`mkdir -p "${sessionDir}"`);
-
-const session = {
-  session_id: sessionId,
-  mode: 'coordinate',  // ★ Marks this as coordinator-mode session
-  cli_tool: cliTool,
-  status: 'running',
-  created_at: new Date().toISOString(),
-  updated_at: new Date().toISOString(),
-  tasks: tasks.map(t => t.id),
-  current_task: null,
-  current_skill_index: 0,
-  completed: [],
-  failed: [],
-  skipped: [],
-  prompts_used: []
-};
-
-Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-
-// Initialize progress.md
-const progressHeader = `# IDAW Progress — ${sessionId} (coordinate mode)\nStarted: ${session.created_at}\nCLI Tool: ${cliTool}\n\n`;
-Write(`${sessionDir}/progress.md`, progressHeader);
-```
-
-### Phase 3: Startup Protocol
-
-```javascript
-// Check for existing running sessions
-const runningSessions = Glob('.workflow/.idaw/sessions/IDA-*/session.json')
-  ?.map(f => { try { return JSON.parse(Read(f)); } catch { return null; } })
-  .filter(s => s && s.status === 'running' && s.session_id !== sessionId) || [];
-
-if (runningSessions.length > 0 && !autoYes) {
-  const answer = AskUserQuestion({
-    questions: [{
-      question: `Found running session: ${runningSessions[0].session_id}. How to proceed?`,
-      header: 'Conflict',
-      multiSelect: false,
-      options: [
-        { label: 'Resume existing', description: 'Use /idaw:resume instead' },
-        { label: 'Start fresh', description: 'Continue with new session' },
-        { label: 'Abort', description: 'Cancel this run' }
-      ]
-    }]
-  });
-  if (answer.answers?.Conflict === 'Resume existing') {
-    console.log(`Use: /idaw:resume ${runningSessions[0].session_id}`);
-    return;
-  }
-  if (answer.answers?.Conflict === 'Abort') return;
-}
-
-// Check git status
-const gitStatus = Bash('git status --porcelain 2>/dev/null');
-if (gitStatus?.trim() && !autoYes) {
-  const answer = AskUserQuestion({
-    questions: [{
-      question: 'Working tree has uncommitted changes. How to proceed?',
-      header: 'Git',
-      multiSelect: false,
-      options: [
-        { label: 'Continue', description: 'Proceed with dirty tree' },
-        { label: 'Stash', description: 'git stash before running' },
-        { label: 'Abort', description: 'Stop and handle manually' }
-      ]
-    }]
-  });
-  if (answer.answers?.Git === 'Stash') Bash('git stash push -m "idaw-pre-run"');
-  if (answer.answers?.Git === 'Abort') return;
-}
-
-// Dry run
-if (dryRun) {
-  console.log(`# Dry Run — ${sessionId} (coordinate mode, tool: ${cliTool})\n`);
-  for (const task of tasks) {
-    const taskType = task.task_type || inferTaskType(task.title, task.description);
-    const chain = task.skill_chain || SKILL_CHAIN_MAP[taskType] || SKILL_CHAIN_MAP['feature'];
-    console.log(`## ${task.id}: ${task.title}`);
-    console.log(`  Type: ${taskType} | Priority: ${task.priority}`);
-    console.log(`  Chain: ${chain.join(' → ')}`);
-    console.log(`  CLI: ccw cli --tool ${cliTool} --mode write\n`);
-  }
-  console.log(`Total: ${tasks.length} tasks`);
-  return;
-}
-```
-
-### Phase 4: Launch First Task (then wait for hook)
-
-```javascript
-// Start with the first task, first skill
-const firstTask = tasks[0];
-const resolvedType = firstTask.task_type || inferTaskType(firstTask.title, firstTask.description);
-const chain = firstTask.skill_chain || SKILL_CHAIN_MAP[resolvedType] || SKILL_CHAIN_MAP['feature'];
-
-// Update task → in_progress
-firstTask.status = 'in_progress';
-firstTask.task_type = resolvedType;
-firstTask.execution.started_at = new Date().toISOString();
-Write(`.workflow/.idaw/tasks/${firstTask.id}.json`, JSON.stringify(firstAgent, null, 2));
-
-// Update session
-session.current_task = firstTask.id;
-session.current_skill_index = 0;
-session.updated_at = new Date().toISOString();
-Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-
-// ━━━ Pre-Task CLI Context Analysis (for complex/bugfix tasks) ━━━
-if (['bugfix', 'bugfix-hotfix', 'feature-complex'].includes(resolvedType)) {
-  console.log(`Pre-analysis: gathering context for ${resolvedType} task...`);
-  const affectedFiles = (firstTask.context?.affected_files || []).join(', ');
-  const preAnalysisPrompt = `PURPOSE: Pre-analyze codebase context for IDAW task.
-TASK: • Understand current state of: ${affectedFiles || 'files related to: ' + firstTask.title} • Identify dependencies and risk areas
-MODE: analysis
-CONTEXT: @**/*
-EXPECTED: Brief context summary in 3-5 bullet points
-CONSTRAINTS: Keep concise`;
-  Bash(`ccw cli -p '${preAnalysisPrompt.replace(/'/g, "'\\''")}' --tool gemini --mode analysis 2>&1 || echo "Pre-analysis skipped"`);
-}
-
-// Assemble prompt for first skill
-const skillName = chain[0];
-const prompt = assembleCliPrompt(skillName, firstAgent, null, autoYes);
-
-session.prompts_used.push({
-  task_id: firstTask.id,
-  skill_index: 0,
-  skill: skillName,
-  prompt: prompt,
-  timestamp: new Date().toISOString()
-});
-session.updated_at = new Date().toISOString();
-Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-
-// Launch via ccw cli in background
-console.log(`[1/${tasks.length}] ${firstTask.id}: ${firstTask.title}`);
-console.log(`  Chain: ${chain.join(' → ')}`);
-console.log(`  Launching: ${skillName} via ccw cli --tool ${cliTool}`);
-
-Bash(
-  `ccw cli -p "${escapeForShell(prompt)}" --tool ${cliTool} --mode write`,
-  { run_in_background: true }
-);
-
-// ★ STOP HERE — wait for hook callback
-// Hook callback will trigger handleStepCompletion() below
-```
-
-### Phase 5: Hook Callback Handler (per-step completion)
-
-```javascript
-// Called by hook when background CLI completes
-async function handleStepCompletion(sessionId, cliOutput) {
-  const sessionDir = `.workflow/.idaw/sessions/${sessionId}`;
-  const session = JSON.parse(Read(`${sessionDir}/session.json`));
-
-  const taskId = session.current_task;
-  const task = JSON.parse(Read(`.workflow/.idaw/tasks/${taskId}.json`));
-
-  const resolvedType = task.task_type || inferTaskType(task.title, task.description);
-  const chain = task.skill_chain || SKILL_CHAIN_MAP[resolvedType] || SKILL_CHAIN_MAP['feature'];
-  const skillIdx = session.current_skill_index;
-  const skillName = chain[skillIdx];
-
-  // Parse CLI output for session ID
-  const parsedOutput = parseCliOutput(cliOutput);
-
-  // Record skill result
-  task.execution.skill_results.push({
-    skill: skillName,
-    status: parsedOutput.success ? 'completed' : 'failed',
-    session_id: parsedOutput.sessionId,
-    timestamp: new Date().toISOString()
-  });
-
-  // ━━━ Handle failure with CLI diagnosis ━━━
-  if (!parsedOutput.success) {
-    console.log(`  ${skillName} failed. Running CLI diagnosis...`);
-    const diagnosisPrompt = `PURPOSE: Diagnose why skill "${skillName}" failed during IDAW task.
-TASK: • Analyze error output • Check affected files: ${(task.context?.affected_files || []).join(', ') || 'unknown'}
-MODE: analysis
-CONTEXT: @**/* | Memory: IDAW task ${task.id}: ${task.title}
-EXPECTED: Root cause + fix recommendation
-CONSTRAINTS: Actionable diagnosis`;
-    Bash(`ccw cli -p '${diagnosisPrompt.replace(/'/g, "'\\''")}' --tool gemini --mode analysis --rule analysis-diagnose-bug-root-cause 2>&1 || true`);
-
-    task.execution.skill_results.push({
-      skill: `cli-diagnosis:${skillName}`,
-      status: 'completed',
-      timestamp: new Date().toISOString()
-    });
-
-    // Retry once
-    console.log(`  Retrying: ${skillName}`);
-    const retryPrompt = assembleCliPrompt(skillName, task, parsedOutput, true);
-    session.prompts_used.push({
-      task_id: taskId,
-      skill_index: skillIdx,
-      skill: `${skillName}-retry`,
-      prompt: retryPrompt,
-      timestamp: new Date().toISOString()
-    });
-    Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-    Write(`.workflow/.idaw/tasks/${taskId}.json`, JSON.stringify(task, null, 2));
-
-    Bash(
-      `ccw cli -p "${escapeForShell(retryPrompt)}" --tool ${session.cli_tool} --mode write`,
-      { run_in_background: true }
-    );
-    return; // Wait for retry hook
-  }
-
-  // ━━━ Skill succeeded — advance ━━━
-  const nextSkillIdx = skillIdx + 1;
-
-  if (nextSkillIdx < chain.length) {
-    // More skills in this task's chain → launch next skill
-    session.current_skill_index = nextSkillIdx;
-    session.updated_at = new Date().toISOString();
-
-    const nextSkill = chain[nextSkillIdx];
-    const nextPrompt = assembleCliPrompt(nextSkill, task, parsedOutput, true);
-
-    session.prompts_used.push({
-      task_id: taskId,
-      skill_index: nextSkillIdx,
-      skill: nextSkill,
-      prompt: nextPrompt,
-      timestamp: new Date().toISOString()
-    });
-    Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-    Write(`.workflow/.idaw/tasks/${taskId}.json`, JSON.stringify(task, null, 2));
-
-    console.log(`  Next skill: ${nextSkill}`);
-    Bash(
-      `ccw cli -p "${escapeForShell(nextPrompt)}" --tool ${session.cli_tool} --mode write`,
-      { run_in_background: true }
-    );
-    return; // Wait for next hook
-  }
-
-  // ━━━ Task chain complete — git checkpoint ━━━
-  const commitMsg = `feat(idaw): ${task.title} [${task.id}]`;
-  const diffCheck = Bash('git diff --stat HEAD 2>/dev/null || echo ""');
-  const untrackedCheck = Bash('git ls-files --others --exclude-standard 2>/dev/null || echo ""');
-
-  if (diffCheck?.trim() || untrackedCheck?.trim()) {
-    Bash('git add -A');
-    Bash(`git commit -m "$(cat <<'EOF'\n${commitMsg}\nEOF\n)"`);
-    const commitHash = Bash('git rev-parse --short HEAD 2>/dev/null')?.trim();
-    task.execution.git_commit = commitHash;
-  } else {
-    task.execution.git_commit = 'no-commit';
-  }
-
-  task.status = 'completed';
-  task.execution.completed_at = new Date().toISOString();
-  task.updated_at = new Date().toISOString();
-  Write(`.workflow/.idaw/tasks/${taskId}.json`, JSON.stringify(task, null, 2));
-
-  session.completed.push(taskId);
-
-  // Append progress
-  const progressEntry = `## ${task.id} — ${task.title}\n` +
-    `- Status: completed\n` +
-    `- Type: ${task.task_type}\n` +
-    `- Chain: ${chain.join(' → ')}\n` +
-    `- Commit: ${task.execution.git_commit || '-'}\n` +
-    `- Mode: coordinate (${session.cli_tool})\n\n`;
-  const currentProgress = Read(`${sessionDir}/progress.md`);
-  Write(`${sessionDir}/progress.md`, currentProgress + progressEntry);
-
-  // ━━━ Advance to next task ━━━
-  const allTaskIds = session.tasks;
-  const completedSet = new Set([...session.completed, ...session.failed, ...session.skipped]);
-  const nextTaskId = allTaskIds.find(id => !completedSet.has(id));
-
-  if (nextTaskId) {
-    // Load next task
-    const nextTask = JSON.parse(Read(`.workflow/.idaw/tasks/${nextTaskId}.json`));
-    const nextType = nextTask.task_type || inferTaskType(nextTask.title, nextTask.description);
-    const nextChain = nextTask.skill_chain || SKILL_CHAIN_MAP[nextType] || SKILL_CHAIN_MAP['feature'];
-
-    nextTask.status = 'in_progress';
-    nextTask.task_type = nextType;
-    nextTask.execution.started_at = new Date().toISOString();
-    Write(`.workflow/.idaw/tasks/${nextTaskId}.json`, JSON.stringify(nextAgent, null, 2));
-
-    session.current_task = nextTaskId;
-    session.current_skill_index = 0;
-    session.updated_at = new Date().toISOString();
-    Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-
-    // Pre-analysis for complex tasks
-    if (['bugfix', 'bugfix-hotfix', 'feature-complex'].includes(nextType)) {
-      const affectedFiles = (nextTask.context?.affected_files || []).join(', ');
-      Bash(`ccw cli -p 'PURPOSE: Pre-analyze context for ${nextTask.title}. TASK: Check ${affectedFiles || "related files"}. MODE: analysis. EXPECTED: 3-5 bullet points.' --tool gemini --mode analysis 2>&1 || true`);
-    }
-
-    const nextSkillName = nextChain[0];
-    const nextPrompt = assembleCliPrompt(nextSkillName, nextAgent, null, true);
-
-    session.prompts_used.push({
-      task_id: nextTaskId,
-      skill_index: 0,
-      skill: nextSkillName,
-      prompt: nextPrompt,
-      timestamp: new Date().toISOString()
-    });
-    Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-
-    const taskNum = session.completed.length + 1;
-    const totalTasks = session.tasks.length;
-    console.log(`\n[${taskNum}/${totalTasks}] ${nextTaskId}: ${nextTask.title}`);
-    console.log(`  Chain: ${nextChain.join(' → ')}`);
-
-    Bash(
-      `ccw cli -p "${escapeForShell(nextPrompt)}" --tool ${session.cli_tool} --mode write`,
-      { run_in_background: true }
-    );
-    return; // Wait for hook
-  }
-
-  // ━━━ All tasks complete — Phase 6: Report ━━━
-  session.status = session.failed.length > 0 && session.completed.length === 0 ? 'failed' : 'completed';
-  session.current_task = null;
-  session.updated_at = new Date().toISOString();
-  Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-
-  const summary = `\n---\n## Summary (coordinate mode)\n` +
-    `- CLI Tool: ${session.cli_tool}\n` +
-    `- Completed: ${session.completed.length}\n` +
-    `- Failed: ${session.failed.length}\n` +
-    `- Skipped: ${session.skipped.length}\n` +
-    `- Total: ${session.tasks.length}\n`;
-  const finalProgress = Read(`${sessionDir}/progress.md`);
-  Write(`${sessionDir}/progress.md`, finalProgress + summary);
-
-  console.log('\n=== IDAW Coordinate Complete ===');
-  console.log(`Session: ${sessionId}`);
-  console.log(`Completed: ${session.completed.length}/${session.tasks.length}`);
-  if (session.failed.length > 0) console.log(`Failed: ${session.failed.join(', ')}`);
-}
-```
-
-## Helper Functions
-
-### assembleCliPrompt
-
-```javascript
-function assembleCliPrompt(skillName, task, previousResult, autoYes) {
-  let prompt = '';
-  const yFlag = autoYes ? ' -y' : '';
-
-  // Map skill to command invocation
-  if (skillName === 'workflow-lite-plan') {
-    const goal = sanitize(`${task.title}\n${task.description}`);
-    prompt = `/workflow-lite-plan${yFlag} "${goal}"`;
-    if (task.task_type === 'bugfix') prompt = `/workflow-lite-plan${yFlag} --bugfix "${goal}"`;
-    if (task.task_type === 'bugfix-hotfix') prompt = `/workflow-lite-plan${yFlag} --hotfix "${goal}"`;
-
-  } else if (skillName === 'workflow-plan') {
-    prompt = `/workflow-plan${yFlag} "${sanitize(task.title)}"`;
-
-  } else if (skillName === 'workflow-execute') {
-    if (previousResult?.sessionId) {
-      prompt = `/workflow-execute${yFlag} --resume-session="${previousResult.sessionId}"`;
-    } else {
-      prompt = `/workflow-execute${yFlag}`;
-    }
-
-  } else if (skillName === 'workflow-test-fix') {
-    if (previousResult?.sessionId) {
-      prompt = `/workflow-test-fix${yFlag} "${previousResult.sessionId}"`;
-    } else {
-      prompt = `/workflow-test-fix${yFlag} "${sanitize(task.title)}"`;
-    }
-
-  } else if (skillName === 'workflow-tdd-plan') {
-    prompt = `/workflow-tdd-plan${yFlag} "${sanitize(task.title)}"`;
-
-  } else if (skillName === 'workflow:refactor-cycle') {
-    prompt = `/workflow:refactor-cycle${yFlag} "${sanitize(task.title)}"`;
-
-  } else if (skillName === 'review-cycle') {
-    if (previousResult?.sessionId) {
-      prompt = `/review-cycle${yFlag} --session="${previousResult.sessionId}"`;
-    } else {
-      prompt = `/review-cycle${yFlag}`;
-    }
-
-  } else {
-    // Generic fallback
-    prompt = `/${skillName}${yFlag} "${sanitize(task.title)}"`;
-  }
-
-  // Append task context
-  prompt += `\n\nTask: ${task.title}\nDescription: ${task.description}`;
-  if (task.context?.affected_files?.length > 0) {
-    prompt += `\nAffected files: ${task.context.affected_files.join(', ')}`;
-  }
-  if (task.context?.acceptance_criteria?.length > 0) {
-    prompt += `\nAcceptance criteria: ${task.context.acceptance_criteria.join('; ')}`;
-  }
-
-  return prompt;
-}
-```
-
-### sanitize & escapeForShell
-
-```javascript
-function sanitize(text) {
-  return text
-    .replace(/\\/g, '\\\\')
-    .replace(/"/g, '\\"')
-    .replace(/\$/g, '\\$')
-    .replace(/`/g, '\\`');
-}
-
-function escapeForShell(prompt) {
-  return prompt.replace(/'/g, "'\\''");
-}
-```
-
-### parseCliOutput
-
-```javascript
-function parseCliOutput(output) {
-  // Extract session ID from CLI output (e.g., WFS-xxx, session-xxx)
-  const sessionMatch = output.match(/(?:session|WFS|Session ID)[:\s]*([\w-]+)/i);
-  const success = !/(?:error|failed|fatal)/i.test(output) || /completed|success/i.test(output);
-
-  return {
-    success,
-    sessionId: sessionMatch?.[1] || null,
-    raw: output?.substring(0, 500)
-  };
-}
-```
-
-## CLI-Assisted Analysis
-
-Same as `/idaw:run` — integrated at two points:
-
-### Pre-Task Context Analysis
-For `bugfix`, `bugfix-hotfix`, `feature-complex` tasks: auto-invoke `ccw cli --tool gemini --mode analysis` before launching skill chain.
-
-### Error Recovery with CLI Diagnosis
-When a skill's CLI execution fails: invoke diagnosis → retry once → if still fails, mark failed and advance.
-
-```
-Skill CLI fails → CLI diagnosis (gemini) → Retry CLI → Still fails → mark failed → next task
-```
-
-## State Flow
-
-```
-Phase 4: Launch first skill
-    ↓
-  ccw cli --tool claude --mode write (background)
-    ↓
-  ★ STOP — wait for hook callback
-    ↓
-Phase 5: handleStepCompletion()
-    ├─ Skill succeeded + more in chain → launch next skill → STOP
-    ├─ Skill succeeded + chain complete → git checkpoint → next task → STOP
-    ├─ Skill failed → CLI diagnosis → retry → STOP
-    └─ All tasks done → Phase 6: Report
-```
-
-## Session State (session.json)
-
-```json
-{
-  "session_id": "IDA-fix-login-20260301",
-  "mode": "coordinate",
-  "cli_tool": "claude",
-  "status": "running|waiting|completed|failed",
-  "created_at": "ISO",
-  "updated_at": "ISO",
-  "tasks": ["IDAW-001", "IDAW-002"],
-  "current_task": "IDAW-001",
-  "current_skill_index": 0,
-  "completed": [],
-  "failed": [],
-  "skipped": [],
-  "prompts_used": [
-    {
-      "task_id": "IDAW-001",
-      "skill_index": 0,
-      "skill": "workflow-lite-plan",
-      "prompt": "/workflow-lite-plan -y \"Fix login timeout\"",
-      "timestamp": "ISO"
-    }
-  ]
-}
-```
-
-## Differences from /idaw:run
-
-| Aspect | /idaw:run | /idaw:run-coordinate |
-|--------|-----------|---------------------|
-| Execution | `Skill()` blocking in main process | `ccw cli` background + hook callback |
-| Context window | Shared (each skill uses main context) | Isolated (each CLI gets fresh context) |
-| Concurrency | Sequential blocking | Sequential non-blocking (hook-driven) |
-| State tracking | session.json + task.json | session.json + task.json + prompts_used |
-| Tool selection | N/A (Skill native) | `--tool claude\|gemini\|qwen` |
-| Resume | Via `/idaw:resume` (same) | Via `/idaw:resume` (same, detects mode) |
-| Best for | Short chains, interactive | Long chains, autonomous, context-heavy |
-
-## Examples
-
-```bash
-# Execute all pending tasks via claude CLI
-/idaw:run-coordinate -y
-
-# Use specific CLI tool
-/idaw:run-coordinate -y --tool gemini
-
-# Execute specific tasks
-/idaw:run-coordinate --task IDAW-001,IDAW-003 --tool claude
-
-# Dry run (show plan without executing)
-/idaw:run-coordinate --dry-run
-
-# Interactive mode
-/idaw:run-coordinate
-```

.claude/commands/idaw/run.md

@@ -1,539 +0,0 @@
----
-name: run
-description: IDAW orchestrator - execute task skill chains serially with git checkpoints
-argument-hint: "[-y|--yes] [--task <id>[,<id>,...]] [--dry-run]"
-allowed-tools: Skill(*), TodoWrite(*), AskUserQuestion(*), Read(*), Write(*), Bash(*), Glob(*)
----
-
-# IDAW Run Command (/idaw:run)
-
-## Auto Mode
-
-When `--yes` or `-y`: Skip all confirmations, auto-skip on failure, proceed with dirty git.
-
-## Skill Chain Mapping
-
-```javascript
-const SKILL_CHAIN_MAP = {
-  'bugfix':          ['workflow-lite-plan', 'workflow-test-fix'],
-  'bugfix-hotfix':   ['workflow-lite-plan'],
-  'feature':         ['workflow-lite-plan', 'workflow-test-fix'],
-  'feature-complex': ['workflow-plan', 'workflow-execute', 'workflow-test-fix'],
-  'refactor':        ['workflow:refactor-cycle'],
-  'tdd':             ['workflow-tdd-plan', 'workflow-execute'],
-  'test':            ['workflow-test-fix'],
-  'test-fix':        ['workflow-test-fix'],
-  'review':          ['review-cycle'],
-  'docs':            ['workflow-lite-plan']
-};
-```
-
-## Task Type Inference
-
-```javascript
-function inferTaskType(title, description) {
-  const text = `${title} ${description}`.toLowerCase();
-  if (/urgent|production|critical/.test(text) && /fix|bug/.test(text)) return 'bugfix-hotfix';
-  if (/refactor|重构|tech.*debt/.test(text)) return 'refactor';
-  if (/tdd|test-driven|test first/.test(text)) return 'tdd';
-  if (/test fail|fix test|failing test/.test(text)) return 'test-fix';
-  if (/generate test|写测试|add test/.test(text)) return 'test';
-  if (/review|code review/.test(text)) return 'review';
-  if (/docs|documentation|readme/.test(text)) return 'docs';
-  if (/fix|bug|error|crash|fail/.test(text)) return 'bugfix';
-  if (/complex|multi-module|architecture/.test(text)) return 'feature-complex';
-  return 'feature';
-}
-```
-
-## 6-Phase Execution
-
-### Phase 1: Load Tasks
-
-```javascript
-const args = $ARGUMENTS;
-const autoYes = /(-y|--yes)/.test(args);
-const dryRun = /--dry-run/.test(args);
-const taskFilter = args.match(/--task\s+([\w,-]+)/)?.[1]?.split(',') || null;
-
-// Load task files
-const taskFiles = Glob('.workflow/.idaw/tasks/IDAW-*.json') || [];
-
-if (taskFiles.length === 0) {
-  console.log('No IDAW tasks found. Use /idaw:add to create tasks.');
-  return;
-}
-
-// Parse and filter
-let tasks = taskFiles.map(f => JSON.parse(Read(f)));
-
-if (taskFilter) {
-  tasks = tasks.filter(t => taskFilter.includes(t.id));
-} else {
-  tasks = tasks.filter(t => t.status === 'pending');
-}
-
-if (tasks.length === 0) {
-  console.log('No pending tasks to execute. Use /idaw:add to add tasks or --task to specify IDs.');
-  return;
-}
-
-// Sort: priority ASC (1=critical first), then ID ASC
-tasks.sort((a, b) => {
-  if (a.priority !== b.priority) return a.priority - b.priority;
-  return a.id.localeCompare(b.id);
-});
-```
-
-### Phase 2: Session Setup
-
-```javascript
-// Generate session ID: IDA-{slug}-YYYYMMDD
-const slug = tasks[0].title
-  .toLowerCase()
-  .replace(/[^a-z0-9]+/g, '-')
-  .substring(0, 20)
-  .replace(/-$/, '');
-const dateStr = new Date().toISOString().slice(0, 10).replace(/-/g, '');
-let sessionId = `IDA-${slug}-${dateStr}`;
-
-// Check collision
-const existingSession = Glob(`.workflow/.idaw/sessions/${sessionId}/session.json`);
-if (existingSession?.length > 0) {
-  sessionId = `${sessionId}-2`;
-}
-
-const sessionDir = `.workflow/.idaw/sessions/${sessionId}`;
-Bash(`mkdir -p "${sessionDir}"`);
-
-const session = {
-  session_id: sessionId,
-  status: 'running',
-  created_at: new Date().toISOString(),
-  updated_at: new Date().toISOString(),
-  tasks: tasks.map(t => t.id),
-  current_task: null,
-  completed: [],
-  failed: [],
-  skipped: []
-};
-
-Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-
-// Initialize progress.md
-const progressHeader = `# IDAW Progress — ${sessionId}\nStarted: ${session.created_at}\n\n`;
-Write(`${sessionDir}/progress.md`, progressHeader);
-
-// TodoWrite
-TodoWrite({
-  todos: tasks.map((t, i) => ({
-    content: `IDAW:[${i + 1}/${tasks.length}] ${t.title}`,
-    status: i === 0 ? 'in_progress' : 'pending',
-    activeForm: `Executing ${t.title}`
-  }))
-});
-```
-
-### Phase 3: Startup Protocol
-
-```javascript
-// Check for existing running sessions
-const runningSessions = Glob('.workflow/.idaw/sessions/IDA-*/session.json')
-  ?.map(f => JSON.parse(Read(f)))
-  .filter(s => s.status === 'running' && s.session_id !== sessionId) || [];
-
-if (runningSessions.length > 0) {
-  if (!autoYes) {
-    const answer = AskUserQuestion({
-      questions: [{
-        question: `Found running session: ${runningSessions[0].session_id}. How to proceed?`,
-        header: 'Conflict',
-        multiSelect: false,
-        options: [
-          { label: 'Resume existing', description: 'Use /idaw:resume instead' },
-          { label: 'Start fresh', description: 'Continue with new session' },
-          { label: 'Abort', description: 'Cancel this run' }
-        ]
-      }]
-    });
-    if (answer.answers?.Conflict === 'Resume existing') {
-      console.log(`Use: /idaw:resume ${runningSessions[0].session_id}`);
-      return;
-    }
-    if (answer.answers?.Conflict === 'Abort') return;
-  }
-  // autoYes or "Start fresh": proceed
-}
-
-// Check git status
-const gitStatus = Bash('git status --porcelain 2>/dev/null');
-if (gitStatus?.trim()) {
-  if (!autoYes) {
-    const answer = AskUserQuestion({
-      questions: [{
-        question: 'Working tree has uncommitted changes. How to proceed?',
-        header: 'Git',
-        multiSelect: false,
-        options: [
-          { label: 'Continue', description: 'Proceed with dirty tree' },
-          { label: 'Stash', description: 'git stash before running' },
-          { label: 'Abort', description: 'Stop and handle manually' }
-        ]
-      }]
-    });
-    if (answer.answers?.Git === 'Stash') {
-      Bash('git stash push -m "idaw-pre-run"');
-    }
-    if (answer.answers?.Git === 'Abort') return;
-  }
-  // autoYes: proceed silently
-}
-
-// Dry run: show plan and exit
-if (dryRun) {
-  console.log(`# Dry Run — ${sessionId}\n`);
-  for (const task of tasks) {
-    const taskType = task.task_type || inferTaskType(task.title, task.description);
-    const chain = task.skill_chain || SKILL_CHAIN_MAP[taskType] || SKILL_CHAIN_MAP['feature'];
-    console.log(`## ${task.id}: ${task.title}`);
-    console.log(`  Type: ${taskType} | Priority: ${task.priority}`);
-    console.log(`  Chain: ${chain.join(' → ')}\n`);
-  }
-  console.log(`Total: ${tasks.length} tasks`);
-  return;
-}
-```
-
-### Phase 4: Main Loop (serial, one task at a time)
-
-```javascript
-for (let taskIdx = 0; taskIdx < tasks.length; taskIdx++) {
-  const task = tasks[taskIdx];
-
-  // Skip completed/failed/skipped
-  if (['completed', 'failed', 'skipped'].includes(task.status)) continue;
-
-  // Resolve skill chain
-  const resolvedType = task.task_type || inferTaskType(task.title, task.description);
-  const chain = task.skill_chain || SKILL_CHAIN_MAP[resolvedType] || SKILL_CHAIN_MAP['feature'];
-
-  // Update task status → in_progress
-  task.status = 'in_progress';
-  task.task_type = resolvedType; // persist inferred type
-  task.execution.started_at = new Date().toISOString();
-  Write(`.workflow/.idaw/tasks/${task.id}.json`, JSON.stringify(task, null, 2));
-
-  // Update session
-  session.current_task = task.id;
-  session.updated_at = new Date().toISOString();
-  Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-
-  console.log(`\n--- [${taskIdx + 1}/${tasks.length}] ${task.id}: ${task.title} ---`);
-  console.log(`Chain: ${chain.join(' → ')}`);
-
-  // ━━━ Pre-Task CLI Context Analysis (for complex/bugfix tasks) ━━━
-  if (['bugfix', 'bugfix-hotfix', 'feature-complex'].includes(resolvedType)) {
-    console.log(`  Pre-analysis: gathering context for ${resolvedType} task...`);
-    const affectedFiles = (task.context?.affected_files || []).join(', ');
-    const preAnalysisPrompt = `PURPOSE: Pre-analyze codebase context for IDAW task before execution.
-TASK: • Understand current state of: ${affectedFiles || 'files related to: ' + task.title} • Identify dependencies and risk areas • Note existing patterns to follow
-MODE: analysis
-CONTEXT: @**/*
-EXPECTED: Brief context summary (affected modules, dependencies, risk areas) in 3-5 bullet points
-CONSTRAINTS: Keep concise | Focus on execution-relevant context`;
-    const preAnalysis = Bash(`ccw cli -p '${preAnalysisPrompt.replace(/'/g, "'\\''")}' --tool gemini --mode analysis 2>&1 || echo "Pre-analysis skipped"`);
-    task.execution.skill_results.push({
-      skill: 'cli-pre-analysis',
-      status: 'completed',
-      context_summary: preAnalysis?.substring(0, 500),
-      timestamp: new Date().toISOString()
-    });
-  }
-
-  // Execute each skill in chain
-  let previousResult = null;
-  let taskFailed = false;
-
-  for (let skillIdx = 0; skillIdx < chain.length; skillIdx++) {
-    const skillName = chain[skillIdx];
-    const skillArgs = assembleSkillArgs(skillName, task, previousResult, autoYes, skillIdx === 0);
-
-    console.log(`  [${skillIdx + 1}/${chain.length}] ${skillName}`);
-
-    try {
-      const result = Skill({ skill: skillName, args: skillArgs });
-      previousResult = result;
-      task.execution.skill_results.push({
-        skill: skillName,
-        status: 'completed',
-        timestamp: new Date().toISOString()
-      });
-    } catch (error) {
-      // ━━━ CLI-Assisted Error Recovery ━━━
-      // Step 1: Invoke CLI diagnosis (auto-invoke trigger: self-repair fails)
-      console.log(`  Diagnosing failure: ${skillName}...`);
-      const diagnosisPrompt = `PURPOSE: Diagnose why skill "${skillName}" failed during IDAW task execution.
-TASK: • Analyze error: ${String(error).substring(0, 300)} • Check affected files: ${(task.context?.affected_files || []).join(', ') || 'unknown'} • Identify root cause • Suggest fix strategy
-MODE: analysis
-CONTEXT: @**/* | Memory: IDAW task ${task.id}: ${task.title}
-EXPECTED: Root cause + actionable fix recommendation (1-2 sentences)
-CONSTRAINTS: Focus on actionable diagnosis`;
-      const diagnosisResult = Bash(`ccw cli -p '${diagnosisPrompt.replace(/'/g, "'\\''")}' --tool gemini --mode analysis --rule analysis-diagnose-bug-root-cause 2>&1 || echo "CLI diagnosis unavailable"`);
-
-      task.execution.skill_results.push({
-        skill: `cli-diagnosis:${skillName}`,
-        status: 'completed',
-        diagnosis: diagnosisResult?.substring(0, 500),
-        timestamp: new Date().toISOString()
-      });
-
-      // Step 2: Retry with diagnosis context
-      console.log(`  Retry with diagnosis: ${skillName}`);
-      try {
-        const retryResult = Skill({ skill: skillName, args: skillArgs });
-        previousResult = retryResult;
-        task.execution.skill_results.push({
-          skill: skillName,
-          status: 'completed-retry-with-diagnosis',
-          timestamp: new Date().toISOString()
-        });
-      } catch (retryError) {
-        // Step 3: Failed after CLI-assisted retry
-        task.execution.skill_results.push({
-          skill: skillName,
-          status: 'failed',
-          error: String(retryError).substring(0, 200),
-          timestamp: new Date().toISOString()
-        });
-
-        if (autoYes) {
-          taskFailed = true;
-          break;
-        } else {
-          const answer = AskUserQuestion({
-            questions: [{
-              question: `${skillName} failed after CLI diagnosis + retry: ${String(retryError).substring(0, 100)}. How to proceed?`,
-              header: 'Error',
-              multiSelect: false,
-              options: [
-                { label: 'Skip task', description: 'Mark task as failed, continue to next' },
-                { label: 'Abort', description: 'Stop entire run' }
-              ]
-            }]
-          });
-          if (answer.answers?.Error === 'Abort') {
-            task.status = 'failed';
-            task.execution.error = String(retryError).substring(0, 200);
-            Write(`.workflow/.idaw/tasks/${task.id}.json`, JSON.stringify(task, null, 2));
-            session.failed.push(task.id);
-            session.status = 'failed';
-            session.updated_at = new Date().toISOString();
-            Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-            return;
-          }
-          taskFailed = true;
-          break;
-        }
-      }
-    }
-  }
-
-  // Phase 5: Checkpoint (per task) — inline
-  if (taskFailed) {
-    task.status = 'failed';
-    task.execution.error = 'Skill chain failed after retry';
-    task.execution.completed_at = new Date().toISOString();
-    session.failed.push(task.id);
-  } else {
-    // Git commit checkpoint
-    const commitMsg = `feat(idaw): ${task.title} [${task.id}]`;
-    const diffCheck = Bash('git diff --stat HEAD 2>/dev/null || echo ""');
-    const untrackedCheck = Bash('git ls-files --others --exclude-standard 2>/dev/null || echo ""');
-
-    if (diffCheck?.trim() || untrackedCheck?.trim()) {
-      Bash('git add -A');
-      const commitResult = Bash(`git commit -m "$(cat <<'EOF'\n${commitMsg}\nEOF\n)"`);
-      const commitHash = Bash('git rev-parse --short HEAD 2>/dev/null')?.trim();
-      task.execution.git_commit = commitHash;
-    } else {
-      task.execution.git_commit = 'no-commit';
-    }
-
-    task.status = 'completed';
-    task.execution.completed_at = new Date().toISOString();
-    session.completed.push(task.id);
-  }
-
-  // Write task + session state
-  task.updated_at = new Date().toISOString();
-  Write(`.workflow/.idaw/tasks/${task.id}.json`, JSON.stringify(task, null, 2));
-
-  session.updated_at = new Date().toISOString();
-  Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-
-  // Append to progress.md
-  const duration = task.execution.started_at && task.execution.completed_at
-    ? formatDuration(new Date(task.execution.completed_at) - new Date(task.execution.started_at))
-    : 'unknown';
-
-  const progressEntry = `## ${task.id} — ${task.title}\n` +
-    `- Status: ${task.status}\n` +
-    `- Type: ${task.task_type}\n` +
-    `- Chain: ${chain.join(' → ')}\n` +
-    `- Commit: ${task.execution.git_commit || '-'}\n` +
-    `- Duration: ${duration}\n\n`;
-
-  const currentProgress = Read(`${sessionDir}/progress.md`);
-  Write(`${sessionDir}/progress.md`, currentProgress + progressEntry);
-
-  // Update TodoWrite
-  if (taskIdx + 1 < tasks.length) {
-    TodoWrite({
-      todos: tasks.map((t, i) => ({
-        content: `IDAW:[${i + 1}/${tasks.length}] ${t.title}`,
-        status: i < taskIdx + 1 ? 'completed' : (i === taskIdx + 1 ? 'in_progress' : 'pending'),
-        activeForm: `Executing ${t.title}`
-      }))
-    });
-  }
-}
-```
-
-### Phase 6: Report
-
-```javascript
-session.status = session.failed.length > 0 && session.completed.length === 0 ? 'failed' : 'completed';
-session.current_task = null;
-session.updated_at = new Date().toISOString();
-Write(`${sessionDir}/session.json`, JSON.stringify(session, null, 2));
-
-// Final progress summary
-const summary = `\n---\n## Summary\n` +
-  `- Completed: ${session.completed.length}\n` +
-  `- Failed: ${session.failed.length}\n` +
-  `- Skipped: ${session.skipped.length}\n` +
-  `- Total: ${tasks.length}\n`;
-
-const finalProgress = Read(`${sessionDir}/progress.md`);
-Write(`${sessionDir}/progress.md`, finalProgress + summary);
-
-// Display report
-console.log('\n=== IDAW Run Complete ===');
-console.log(`Session: ${sessionId}`);
-console.log(`Completed: ${session.completed.length}/${tasks.length}`);
-if (session.failed.length > 0) console.log(`Failed: ${session.failed.join(', ')}`);
-if (session.skipped.length > 0) console.log(`Skipped: ${session.skipped.join(', ')}`);
-
-// List git commits
-for (const taskId of session.completed) {
-  const t = JSON.parse(Read(`.workflow/.idaw/tasks/${taskId}.json`));
-  if (t.execution.git_commit && t.execution.git_commit !== 'no-commit') {
-    console.log(`  ${t.execution.git_commit} ${t.title}`);
-  }
-}
-```
-
-## Helper Functions
-
-### assembleSkillArgs
-
-```javascript
-function assembleSkillArgs(skillName, task, previousResult, autoYes, isFirst) {
-  let args = '';
-
-  if (isFirst) {
-    // First skill: pass task goal — sanitize for shell safety
-    const goal = `${task.title}\n${task.description}`
-      .replace(/\\/g, '\\\\')
-      .replace(/"/g, '\\"')
-      .replace(/\$/g, '\\$')
-      .replace(/`/g, '\\`');
-    args = `"${goal}"`;
-
-    // bugfix-hotfix: add --hotfix
-    if (task.task_type === 'bugfix-hotfix') {
-      args += ' --hotfix';
-    }
-  } else if (previousResult?.session_id) {
-    // Subsequent skills: chain session
-    args = `--session="${previousResult.session_id}"`;
-  }
-
-  // Propagate -y
-  if (autoYes && !args.includes('-y') && !args.includes('--yes')) {
-    args = args ? `${args} -y` : '-y';
-  }
-
-  return args;
-}
-```
-
-### formatDuration
-
-```javascript
-function formatDuration(ms) {
-  const seconds = Math.floor(ms / 1000);
-  const minutes = Math.floor(seconds / 60);
-  const remainingSeconds = seconds % 60;
-  if (minutes > 0) return `${minutes}m ${remainingSeconds}s`;
-  return `${seconds}s`;
-}
-```
-
-## CLI-Assisted Analysis
-
-IDAW integrates `ccw cli` (Gemini) for intelligent analysis at two key points:
-
-### Pre-Task Context Analysis
-
-For `bugfix`, `bugfix-hotfix`, and `feature-complex` tasks, IDAW automatically invokes CLI analysis **before** executing the skill chain to gather codebase context:
-
-```
-Task starts → CLI pre-analysis (gemini) → Context gathered → Skill chain executes
-```
-
-- Identifies dependencies and risk areas
-- Notes existing patterns to follow
-- Results stored in `task.execution.skill_results` as `cli-pre-analysis`
-
-### Error Recovery with CLI Diagnosis
-
-When a skill fails, instead of blind retry, IDAW uses CLI-assisted diagnosis:
-
-```
-Skill fails → CLI diagnosis (gemini, analysis-diagnose-bug-root-cause)
-           → Root cause identified → Retry with diagnosis context
-           → Still fails → Skip (autoYes) or Ask user (interactive)
-```
-
-- Uses `--rule analysis-diagnose-bug-root-cause` template
-- Diagnosis results stored in `task.execution.skill_results` as `cli-diagnosis:{skill}`
-- Follows CLAUDE.md auto-invoke trigger pattern: "self-repair fails → invoke CLI analysis"
-
-### Execution Flow (with CLI analysis)
-
-```
-Phase 4 Main Loop (per task):
-  ├─ [bugfix/complex only] CLI pre-analysis → context summary
-  ├─ Skill 1: execute
-  │   ├─ Success → next skill
-  │   └─ Failure → CLI diagnosis → retry → success/fail
-  ├─ Skill 2: execute ...
-  └─ Phase 5: git checkpoint
-```
-
-## Examples
-
-```bash
-# Execute all pending tasks
-/idaw:run -y
-
-# Execute specific tasks
-/idaw:run --task IDAW-001,IDAW-003
-
-# Dry run (show plan without executing)
-/idaw:run --dry-run
-
-# Interactive mode (confirm at each step)
-/idaw:run
-```

.claude/commands/idaw/status.md

@@ -1,182 +0,0 @@
----
-name: status
-description: View IDAW task and session progress
-argument-hint: "[session-id]"
-allowed-tools: Read(*), Glob(*), Bash(*)
----
-
-# IDAW Status Command (/idaw:status)
-
-## Overview
-
-Read-only command to view IDAW task queue and execution session progress.
-
-## Implementation
-
-### Phase 1: Determine View Mode
-
-```javascript
-const sessionId = $ARGUMENTS?.trim();
-
-if (sessionId) {
-  // Specific session view
-  showSession(sessionId);
-} else {
-  // Overview: pending tasks + latest session
-  showOverview();
-}
-```
-
-### Phase 2: Show Overview
-
-```javascript
-function showOverview() {
-  // 1. Load all tasks
-  const taskFiles = Glob('.workflow/.idaw/tasks/IDAW-*.json') || [];
-
-  if (taskFiles.length === 0) {
-    console.log('No IDAW tasks found. Use /idaw:add to create tasks.');
-    return;
-  }
-
-  const tasks = taskFiles.map(f => JSON.parse(Read(f)));
-
-  // 2. Group by status
-  const byStatus = {
-    pending: tasks.filter(t => t.status === 'pending'),
-    in_progress: tasks.filter(t => t.status === 'in_progress'),
-    completed: tasks.filter(t => t.status === 'completed'),
-    failed: tasks.filter(t => t.status === 'failed'),
-    skipped: tasks.filter(t => t.status === 'skipped')
-  };
-
-  // 3. Display task summary table
-  console.log('# IDAW Tasks\n');
-  console.log('| ID | Title | Type | Priority | Status |');
-  console.log('|----|-------|------|----------|--------|');
-
-  // Sort: priority ASC, then ID ASC
-  const sorted = [...tasks].sort((a, b) => {
-    if (a.priority !== b.priority) return a.priority - b.priority;
-    return a.id.localeCompare(b.id);
-  });
-
-  for (const t of sorted) {
-    const type = t.task_type || '(infer)';
-    console.log(`| ${t.id} | ${t.title.substring(0, 40)} | ${type} | ${t.priority} | ${t.status} |`);
-  }
-
-  console.log(`\nTotal: ${tasks.length} | Pending: ${byStatus.pending.length} | Completed: ${byStatus.completed.length} | Failed: ${byStatus.failed.length}`);
-
-  // 4. Show latest session (if any)
-  const sessionDirs = Glob('.workflow/.idaw/sessions/IDA-*/session.json') || [];
-  if (sessionDirs.length > 0) {
-    // Sort by modification time (newest first) — Glob returns sorted by mtime
-    const latestSessionFile = sessionDirs[0];
-    const session = JSON.parse(Read(latestSessionFile));
-    console.log(`\n## Latest Session: ${session.session_id}`);
-    console.log(`Status: ${session.status} | Tasks: ${session.tasks?.length || 0}`);
-    console.log(`Completed: ${session.completed?.length || 0} | Failed: ${session.failed?.length || 0} | Skipped: ${session.skipped?.length || 0}`);
-  }
-}
-```
-
-### Phase 3: Show Specific Session
-
-```javascript
-function showSession(sessionId) {
-  const sessionFile = `.workflow/.idaw/sessions/${sessionId}/session.json`;
-  const progressFile = `.workflow/.idaw/sessions/${sessionId}/progress.md`;
-
-  // Try reading session
-  try {
-    const session = JSON.parse(Read(sessionFile));
-
-    console.log(`# IDAW Session: ${session.session_id}\n`);
-    console.log(`Status: ${session.status}`);
-    console.log(`Created: ${session.created_at}`);
-    console.log(`Updated: ${session.updated_at}`);
-    console.log(`Current Task: ${session.current_task || 'none'}\n`);
-
-    // Task detail table
-    console.log('| ID | Title | Status | Commit |');
-    console.log('|----|-------|--------|--------|');
-
-    for (const taskId of session.tasks) {
-      const taskFile = `.workflow/.idaw/tasks/${taskId}.json`;
-      try {
-        const task = JSON.parse(Read(taskFile));
-        const commit = task.execution?.git_commit?.substring(0, 7) || '-';
-        console.log(`| ${task.id} | ${task.title.substring(0, 40)} | ${task.status} | ${commit} |`);
-      } catch {
-        console.log(`| ${taskId} | (file not found) | unknown | - |`);
-      }
-    }
-
-    console.log(`\nCompleted: ${session.completed?.length || 0} | Failed: ${session.failed?.length || 0} | Skipped: ${session.skipped?.length || 0}`);
-
-    // Show progress.md if exists
-    try {
-      const progress = Read(progressFile);
-      console.log('\n---\n');
-      console.log(progress);
-    } catch {
-      // No progress file yet
-    }
-
-  } catch {
-    // Session not found — try listing all sessions
-    console.log(`Session "${sessionId}" not found.\n`);
-    listSessions();
-  }
-}
-```
-
-### Phase 4: List All Sessions
-
-```javascript
-function listSessions() {
-  const sessionFiles = Glob('.workflow/.idaw/sessions/IDA-*/session.json') || [];
-
-  if (sessionFiles.length === 0) {
-    console.log('No IDAW sessions found. Use /idaw:run to start execution.');
-    return;
-  }
-
-  console.log('# IDAW Sessions\n');
-  console.log('| Session ID | Status | Tasks | Completed | Failed |');
-  console.log('|------------|--------|-------|-----------|--------|');
-
-  for (const f of sessionFiles) {
-    try {
-      const session = JSON.parse(Read(f));
-      console.log(`| ${session.session_id} | ${session.status} | ${session.tasks?.length || 0} | ${session.completed?.length || 0} | ${session.failed?.length || 0} |`);
-    } catch {
-      // Skip malformed
-    }
-  }
-
-  console.log('\nUse /idaw:status <session-id> for details.');
-}
-```
-
-## Examples
-
-```bash
-# Show overview (pending tasks + latest session)
-/idaw:status
-
-# Show specific session details
-/idaw:status IDA-auth-fix-20260301
-
-# Output example:
-# IDAW Tasks
-#
-# | ID       | Title                              | Type   | Priority | Status    |
-# |----------|------------------------------------|--------|----------|-----------|
-# | IDAW-001 | Fix auth token refresh             | bugfix | 1        | completed |
-# | IDAW-002 | Add rate limiting                  | feature| 2        | pending   |
-# | IDAW-003 | Refactor payment module            | refact | 3        | pending   |
-#
-# Total: 3 | Pending: 2 | Completed: 1 | Failed: 0
-```

.claude/commands/workflow-tune.md

@@ -0,0 +1,811 @@
+---
+name: workflow-tune
+description: Workflow tuning - extract commands from reference docs or natural language, execute each via ccw cli --tool claude --mode write, then analyze artifacts via gemini. For testing how commands execute in Claude.
+argument-hint: "<file-path> <intent> | \"step1 | step2 | step3\" | \"skill-a,skill-b\" | --file workflow.json [--depth quick|standard|deep] [-y|--yes] [--auto-fix]"
+allowed-tools: Agent(*), AskUserQuestion(*), TaskCreate(*), TaskUpdate(*), TaskList(*), Read(*), Write(*), Edit(*), Bash(*), Glob(*), Grep(*)
+---
+
+# Workflow Tune
+
+测试 Claude command/skill 的执行效果并优化。提取可执行命令，逐步通过 `ccw cli --tool claude` 执行，分析产物质量，生成优化建议。
+
+## Tool Assignment
+
+| Phase | Tool | Mode | Rule |
+|-------|------|------|------|
+| Execute | `claude` | `write` | `universal-rigorous-style` |
+| Analyze | `gemini` | `analysis` | `analysis-review-code-quality` |
+| Synthesize | `gemini` | `analysis` | `analysis-review-architecture` |
+
+## Architecture
+
+```
+Input → Parse → GenTestTask → Confirm → Setup → [resolveCmd → readMeta → assemblePrompt → Execute → STOP → Analyze → STOP]×N → Synthesize → STOP → Report
+                    ↑                                       ↑
+          Claude 直接生成测试任务            prompt 中注入 test_task
+          (无需 CLI 调用)                  作为命令的执行输入
+```
+
+## Input Formats
+
+```
+1. --file workflow.json               → JSON definition
+2. "cmd1 | cmd2 | cmd3"              → pipe-separated commands
+3. "skill-a,skill-b,skill-c"         → comma-separated skills
+4. natural language                   → semantic decomposition
+   4a: <file-path> <intent>           → extract commands from reference doc via LLM
+   4b: <pure intent text>             → intent-verb matching → ccw cli command assembly
+```
+
+**ANTI-PATTERN**: Steps like `{ command: "分析 Phase 管线" }` are WRONG — descriptions, not commands. Correct: `{ command: "/workflow-lite-plan analyze auth module" }` or `{ command: "ccw cli -p '...' --tool claude --mode write" }`
+
+## Utility: Shell Escaping
+
+```javascript
+function escapeForShell(str) {
+  // Replace single quotes with escaped version, wrap in single quotes
+  return "'" + str.replace(/'/g, "'\\''") + "'";
+}
+```
+
+## Phase 1: Setup
+
+### Step 1.1: Parse Input + Preference Collection
+
+```javascript
+const args = $ARGUMENTS.trim();
+const autoYes = /\b(-y|--yes)\b/.test(args);
+
+// Preference collection (skip if -y)
+if (autoYes) {
+  workflowPreferences = { autoYes: true, analysisDepth: 'standard', autoFix: false };
+} else {
+  const prefResponse = AskUserQuestion({
+    questions: [
+      { question: "选择调优配置：", header: "Tune Config", multiSelect: false,
+        options: [
+          { label: "Quick (轻量分析)", description: "每步简要检查" },
+          { label: "Standard (标准分析) (Recommended)", description: "每步详细分析" },
+          { label: "Deep (深度分析)", description: "深度审查含架构建议" }
+        ]
+      },
+      { question: "是否自动应用优化建议？", header: "Auto Fix", multiSelect: false,
+        options: [
+          { label: "No (仅报告) (Recommended)", description: "只分析不修改" },
+          { label: "Yes (自动应用)", description: "自动应用高优先级建议" }
+        ]
+      }
+    ]
+  });
+  const depthMap = { "Quick": "quick", "Standard": "standard", "Deep": "deep" };
+  const selectedDepth = Object.keys(depthMap).find(k => prefResponse["Tune Config"].startsWith(k)) || "Standard";
+  workflowPreferences = {
+    autoYes: false,
+    analysisDepth: depthMap[selectedDepth],
+    autoFix: prefResponse["Auto Fix"].startsWith("Yes")
+  };
+}
+
+// Parse --depth override
+const depthMatch = args.match(/--depth\s+(quick|standard|deep)/);
+if (depthMatch) workflowPreferences.analysisDepth = depthMatch[1];
+
+// ── Format Detection ──
+let steps = [], workflowName = 'unnamed-workflow', inputFormat = '';
+let projectScenario = '';  // ★ 统一虚构项目场景，所有步骤共享（在 Step 1.1a 生成）
+
+const fileMatch = args.match(/--file\s+"?([^\s"]+)"?/);
+if (fileMatch) {
+  const wfDef = JSON.parse(Read(fileMatch[1]));
+  workflowName = wfDef.name || 'unnamed-workflow';
+  projectScenario = wfDef.project_scenario || wfDef.description || '';
+  steps = wfDef.steps;
+  inputFormat = 'json';
+}
+else if (args.includes('|')) {
+  const rawSteps = args.split(/(?:--context|--depth|-y|--yes|--auto-fix)\s+("[^"]*"|\S+)/)[0];
+  steps = rawSteps.split('|').map((cmd, i) => ({
+    name: `step-${i + 1}`,
+    command: cmd.trim(),
+    expected_artifacts: [], success_criteria: ''
+  }));
+  inputFormat = 'pipe';
+}
+else if (/^[\w-]+(,[\w-]+)+/.test(args.split(/\s/)[0])) {
+  const skillNames = args.match(/^([^\s]+)/)[1].split(',');
+  steps = skillNames.map(name => ({
+    name, command: `/${name}`,
+    expected_artifacts: [], success_criteria: ''
+  }));
+  inputFormat = 'skills';
+}
+else {
+  inputFormat = 'natural-language';
+  let naturalLanguageInput = args.replace(/--\w+\s+"[^"]*"/g, '').replace(/--\w+\s+\S+/g, '').replace(/-y|--yes/g, '').trim();
+  const filePathPattern = /(?:[A-Za-z]:[\\\/][^\s,;]+|\/[^\s,;]+\.(?:md|txt|json|yaml|yml|toml)|\.\/?[^\s,;]+\.(?:md|txt|json|yaml|yml|toml))/g;
+  const detectedPaths = naturalLanguageInput.match(filePathPattern) || [];
+  let referenceDocContent = null, referenceDocPath = null;
+  if (detectedPaths.length > 0) {
+    referenceDocPath = detectedPaths[0];
+    try {
+      referenceDocContent = Read(referenceDocPath);
+      naturalLanguageInput = naturalLanguageInput.replace(referenceDocPath, '').trim();
+    } catch (e) { referenceDocContent = null; }
+  }
+  // → Mode 4a/4b in Step 1.1b
+}
+
+// workflowContext 已移除 — 统一使用 projectScenario（在 Step 1.1a 生成）
+```
+
+### Step 1.1a: Generate Test Task (测试任务直接生成)
+
+> **核心概念**: 所有步骤共享一个**统一虚构项目场景**（如"在线书店网站"），每个命令根据自身能力获得该场景下的一个子任务。由当前 Claude 直接生成，不需要额外 CLI 调用。所有执行在独立沙箱目录中进行，不影响真实项目。
+
+```javascript
+// ★ 测试任务直接生成 — 无需 CLI 调用
+// 来源优先级：
+//   1. JSON 定义中的 step.test_task 字段 (已有则跳过)
+//   2. 当前 Claude 直接生成
+
+const stepsNeedTask = steps.filter(s => !s.test_task);
+
+if (stepsNeedTask.length > 0) {
+  // ── Step A: 生成统一项目场景 ──
+  // 根据命令链的整体复杂度，选一个虚构项目作为测试场景
+  // 场景必须：完全虚构、与当前工作空间无关、足够支撑所有步骤
+  //
+  // 场景池示例（根据步骤数量和类型选择合适规模）：
+  //   1-2 步: 小型项目 — "命令行 TODO 工具" "Markdown 转 HTML 工具" "天气查询 CLI"
+  //   3-4 步: 中型项目 — "在线书店网站" "团队任务看板" "博客系统"
+  //   5+ 步:  大型项目 — "多租户 SaaS 平台" "电商系统" "在线教育平台"
+
+  projectScenario = /* Claude 从上述池中选择或自创一个场景 */;
+  // 例如: "在线书店网站 — 支持用户注册登录、书籍搜索浏览、购物车、订单管理、评论系统"
+
+  // ── Step B: 为每步生成子任务 ──
+  for (const step of stepsNeedTask) {
+    const cmdFile = resolveCommandFile(step.command);
+    const cmdMeta = readCommandMeta(cmdFile);
+    const cmdDesc = (cmdMeta?.description || step.command).toLowerCase();
+
+    // 根据命令类型分配场景下的子任务
+    // 每个子任务必须按以下模板生成：
+    //
+    // ┌─────────────────────────────────────────────────┐
+    // │ 项目: {projectScenario}                          │
+    // │ 任务: {具体子任务描述}                            │
+    // │ 功能点:                                          │
+    // │   1. {功能点1 — 具体到接口/组件/模块}             │
+    // │   2. {功能点2}                                   │
+    // │   3. {功能点3}                                   │
+    // │ 技术约束: {语言/框架/架构要求}                    │
+    // │ 验收标准:                                        │
+    // │   1. {可验证的标准1}                              │
+    // │   2. {可验证的标准2}                              │
+    // └─────────────────────────────────────────────────┘
+    //
+    // 命令类型 → 子任务映射：
+    //   plan/design   → 架构设计任务: "为{场景}设计技术架构，包含模块划分、数据模型、API 设计"
+    //   implement     → 功能实现任务: "实现{场景}的{某模块}，包含{具体功能点}"
+    //   analyze/review→ 代码分析任务: "先在沙箱创建{场景}的{某模块}示例代码，然后分析其质量"
+    //   test          → 测试任务:     "为{场景}的{某模块}编写测试，覆盖{具体场景}"
+    //   fix/debug     → 修复任务:     "先在沙箱创建含已知 bug 的代码，然后诊断修复"
+    //   refactor      → 重构任务:     "先在沙箱创建可工作但需重构的代码，然后重构"
+
+    step.test_task = /* 按上述模板生成，必须包含：项目、任务、功能点、技术约束、验收标准 */;
+    step.acceptance_criteria = /* 从 test_task 中提取 2-4 条可验证标准 */;
+    step.complexity_level = /plan|design|architect/i.test(cmdDesc) ? 'high'
+      : /test|lint|format/i.test(cmdDesc) ? 'low' : 'medium';
+  }
+}
+```
+
+**模拟示例** — 输入 `workflow-lite-plan,workflow-lite-execute`:
+
+```
+场景: 在线书店网站 — 支持用户注册登录、书籍搜索、购物车、订单管理
+
+Step 1 (workflow-lite-plan → plan 类, high):
+  项目: 在线书店网站
+  任务: 为在线书店设计技术架构和实现计划
+  功能点:
+    1. 用户模块 — 注册、登录、个人信息管理
+    2. 书籍模块 — 搜索、分类浏览、详情页
+    3. 交易模块 — 购物车、下单、支付状态
+    4. 数据模型 — User, Book, Order, CartItem 表结构设计
+  技术约束: TypeScript + Express + SQLite, REST API
+  验收标准:
+    1. 输出包含模块划分和依赖关系
+    2. 包含数据模型定义
+    3. 包含 API 路由清单
+    4. 包含实现步骤分解
+
+Step 2 (workflow-lite-execute → implement 类, medium):
+  项目: 在线书店网站
+  任务: 根据 Step 1 的计划，实现书籍搜索和浏览模块
+  功能点:
+    1. GET /api/books — 分页列表，支持按标题/作者搜索
+    2. GET /api/books/:id — 书籍详情
+    3. GET /api/categories — 分类列表
+    4. Book 数据模型 + seed 数据
+  技术约束: TypeScript + Express + SQLite, 沿用 Step 1 架构
+  验收标准:
+    1. API 可正常调用返回 JSON
+    2. 搜索支持模糊匹配
+    3. 包含至少 5 条 seed 数据
+```
+
+### Step 1.1b: Semantic Decomposition (Format 4 only)
+
+#### Mode 4a: Reference Document → LLM Extraction
+
+```javascript
+if (inputFormat === 'natural-language' && referenceDocContent) {
+  const extractPrompt = `PURPOSE: Extract ACTUAL EXECUTABLE COMMANDS from the reference document. The user wants to TEST these commands by running them.
+
+USER INTENT: ${naturalLanguageInput}
+REFERENCE DOCUMENT: ${referenceDocPath}
+
+DOCUMENT CONTENT:
+${referenceDocContent}
+
+CRITICAL RULES:
+- "command" field MUST be a real executable: slash command (/skill-name args), ccw cli call, or shell command
+- CORRECT: { "command": "/workflow-lite-plan analyze auth module" }
+- CORRECT: { "command": "ccw cli -p 'review code' --tool claude --mode write" }
+- WRONG:  { "command": "分析 Phase 管线" } ← DESCRIPTION, not command
+- Default mode to "write"
+
+EXPECTED OUTPUT (strict JSON):
+{
+  "workflow_name": "<name>",
+  "project_scenario": "<虚构项目场景>",
+  "steps": [{ "name": "", "command": "<executable>", "expected_artifacts": [], "success_criteria": "" }]
+}`;
+
+  Bash({
+    command: `ccw cli -p ${escapeForShell(extractPrompt)} --tool claude --mode write --rule universal-rigorous-style`,
+    run_in_background: true, timeout: 300000
+  });
+  // ■ STOP — wait for hook callback, parse JSON → steps[]
+}
+```
+
+#### Mode 4b: Pure Intent → Command Assembly
+
+```javascript
+if (inputFormat === 'natural-language' && !referenceDocContent) {
+  // Intent → rule mapping for ccw cli command generation
+  const intentMap = [
+    { pattern: /分析|analyze|审查|inspect|scan/i, name: 'analyze', rule: 'analysis-analyze-code-patterns' },
+    { pattern: /评审|review|code.?review/i, name: 'review', rule: 'analysis-review-code-quality' },
+    { pattern: /诊断|debug|排查|diagnose/i, name: 'diagnose', rule: 'analysis-diagnose-bug-root-cause' },
+    { pattern: /安全|security|漏洞/i, name: 'security-audit', rule: 'analysis-assess-security-risks' },
+    { pattern: /性能|performance|perf/i, name: 'perf-analysis', rule: 'analysis-analyze-performance' },
+    { pattern: /架构|architecture/i, name: 'arch-review', rule: 'analysis-review-architecture' },
+    { pattern: /修复|fix|repair|解决/i, name: 'fix', rule: 'development-debug-runtime-issues' },
+    { pattern: /实现|implement|开发|create|新增/i, name: 'implement', rule: 'development-implement-feature' },
+    { pattern: /重构|refactor/i, name: 'refactor', rule: 'development-refactor-codebase' },
+    { pattern: /测试|test/i, name: 'test', rule: 'development-generate-tests' },
+    { pattern: /规划|plan|设计|design/i, name: 'plan', rule: 'planning-plan-architecture-design' },
+  ];
+
+  const segments = naturalLanguageInput
+    .split(/[，,；;、]|(?:然后|接着|之后|最后|再|并|and then|then|finally|next)\s*/i)
+    .map(s => s.trim()).filter(Boolean);
+
+  // ★ 将意图文本转化为完整的 ccw cli 命令
+  steps = segments.map((segment, i) => {
+    const matched = intentMap.find(m => m.pattern.test(segment));
+    const rule = matched?.rule || 'universal-rigorous-style';
+    // 组装真正可执行的命令
+    const command = `ccw cli -p ${escapeForShell('PURPOSE: ' + segment + '\\nTASK: Execute based on intent\\nCONTEXT: @**/*')} --tool claude --mode write --rule ${rule}`;
+    return {
+      name: matched?.name || `step-${i + 1}`,
+      command,
+      original_intent: segment,  // 保留原始意图用于分析
+      expected_artifacts: [], success_criteria: ''
+    };
+  });
+}
+```
+
+### Step 1.1c: Execution Plan Confirmation
+
+```javascript
+function generateCommandDoc(steps, workflowName, projectScenario, analysisDepth) {
+  const stepTable = steps.map((s, i) => {
+    const cmdPreview = s.command.length > 60 ? s.command.substring(0, 57) + '...' : s.command;
+    const taskPreview = (s.test_task || '-').length > 40 ? s.test_task.substring(0, 37) + '...' : (s.test_task || '-');
+    return `| ${i + 1} | ${s.name} | \`${cmdPreview}\` | ${taskPreview} |`;
+  }).join('\n');
+
+  return `# Workflow Tune — Execution Plan\n\n**Workflow**: ${workflowName}\n**Test Project**: ${projectScenario}\n**Steps**: ${steps.length}\n**Depth**: ${analysisDepth}\n\n| # | Name | Command | Test Task |\n|---|------|---------|-----------|\n${stepTable}`;
+}
+
+const commandDoc = generateCommandDoc(steps, workflowName, projectScenario, workflowPreferences.analysisDepth);
+
+if (!workflowPreferences.autoYes) {
+  const confirmation = AskUserQuestion({
+    questions: [{
+      question: commandDoc + "\n\n确认执行以上 Workflow 调优计划？", header: "Confirm Execution", multiSelect: false,
+      options: [
+        { label: "Execute (确认执行)", description: "按计划开始执行" },
+        { label: "Cancel (取消)", description: "取消" }
+      ]
+    }]
+  });
+  if (confirmation["Confirm Execution"].startsWith("Cancel")) return;
+}
+```
+
+### Step 1.2: (Merged into Step 1.1a)
+
+> Test requirements (acceptance_criteria) are now generated together with test_task in Step 1.1a, avoiding an extra CLI call.
+
+### Step 1.3: Create Workspace + Sandbox Project
+
+```javascript
+const ts = Date.now();
+const workDir = `.workflow/.scratchpad/workflow-tune-${ts}`;
+
+// ★ 创建独立沙箱项目目录 — 所有命令执行在此目录中，不影响真实项目
+const sandboxDir = `${workDir}/sandbox`;
+Bash(`mkdir -p "${workDir}/steps" "${sandboxDir}"`);
+// 初始化沙箱为独立 git 仓库（部分命令依赖 git 环境）
+Bash(`cd "${sandboxDir}" && git init && echo "# Sandbox Project" > README.md && git add . && git commit -m "init sandbox"`);
+
+for (let i = 0; i < steps.length; i++) Bash(`mkdir -p "${workDir}/steps/step-${i + 1}/artifacts"`);
+
+Write(`${workDir}/command-doc.md`, commandDoc);
+
+const initialState = {
+  status: 'running', started_at: new Date().toISOString(),
+  workflow_name: workflowName, project_scenario: projectScenario,
+  analysis_depth: workflowPreferences.analysisDepth, auto_fix: workflowPreferences.autoFix,
+  sandbox_dir: sandboxDir,  // ★ 独立沙箱项目目录
+  current_step: 0,  // ★ State machine cursor
+  current_phase: 'execute',  // 'execute' | 'analyze'
+  steps: steps.map((s, i) => ({
+    ...s, index: i, status: 'pending',
+    test_task: s.test_task || '',  // ★ 每步的测试任务
+    execution: null, analysis: null,
+    test_requirements: s.test_requirements || null
+  })),
+  gemini_session_id: null,  // ★ Updated after each gemini callback
+  work_dir: workDir,
+  errors: [], error_count: 0, max_errors: 3
+};
+
+Write(`${workDir}/workflow-state.json`, JSON.stringify(initialState, null, 2));
+Write(`${workDir}/process-log.md`, `# Process Log\n\n**Workflow**: ${workflowName}\n**Test Project**: ${projectScenario}\n**Steps**: ${steps.length}\n**Started**: ${new Date().toISOString()}\n\n---\n\n`);
+```
+
+## Phase 2: Execute Step
+
+### resolveCommandFile — Slash command → file path
+
+```javascript
+function resolveCommandFile(command) {
+  const cmdMatch = command.match(/^\/?([^\s]+)/);
+  if (!cmdMatch) return null;
+  const cmdName = cmdMatch[1];
+  const cmdPath = cmdName.replace(/:/g, '/');
+
+  const searchRoots = ['.claude', '~/.claude'];
+
+  for (const root of searchRoots) {
+    const candidates = [
+      `${root}/commands/${cmdPath}.md`,
+      `${root}/commands/${cmdPath}/index.md`,
+    ];
+    for (const candidate of candidates) {
+      try { Read(candidate, { limit: 1 }); return candidate; } catch {}
+    }
+  }
+
+  for (const root of searchRoots) {
+    const candidates = [
+      `${root}/skills/${cmdName}/SKILL.md`,
+      `${root}/skills/${cmdPath.replace(/\//g, '-')}/SKILL.md`,
+    ];
+    for (const candidate of candidates) {
+      try { Read(candidate, { limit: 1 }); return candidate; } catch {}
+    }
+  }
+
+  return null;
+}
+```
+
+### readCommandMeta — Read YAML frontmatter + body summary
+
+```javascript
+function readCommandMeta(filePath) {
+  if (!filePath) return null;
+
+  const content = Read(filePath);
+  const meta = { filePath, name: '', description: '', argumentHint: '', allowedTools: '', bodySummary: '' };
+
+  const yamlMatch = content.match(/^---\n([\s\S]*?)\n---/);
+  if (yamlMatch) {
+    const yaml = yamlMatch[1];
+    const nameMatch = yaml.match(/^name:\s*(.+)$/m);
+    const descMatch = yaml.match(/^description:\s*(.+)$/m);
+    const hintMatch = yaml.match(/^argument-hint:\s*"?(.+?)"?\s*$/m);
+    const toolsMatch = yaml.match(/^allowed-tools:\s*(.+)$/m);
+
+    if (nameMatch) meta.name = nameMatch[1].trim();
+    if (descMatch) meta.description = descMatch[1].trim();
+    if (hintMatch) meta.argumentHint = hintMatch[1].trim();
+    if (toolsMatch) meta.allowedTools = toolsMatch[1].trim();
+  }
+
+  const bodyStart = content.indexOf('---', content.indexOf('---') + 3);
+  if (bodyStart !== -1) {
+    const body = content.substring(bodyStart + 3).trim();
+    meta.bodySummary = body.split('\n').slice(0, 30).join('\n');
+  }
+
+  return meta;
+}
+```
+
+### assembleStepPrompt — Build execution prompt from command metadata
+
+```javascript
+function assembleStepPrompt(step, stepIdx, state) {
+  // ── 1. Resolve command file + metadata ──
+  const isSlashCmd = step.command.startsWith('/');
+  const cmdFile = isSlashCmd ? resolveCommandFile(step.command) : null;
+  const cmdMeta = readCommandMeta(cmdFile);
+  const cmdArgs = isSlashCmd ? step.command.replace(/^\/?[^\s]+\s*/, '').trim() : '';
+
+  // ── 2. Prior/next step context ──
+  const prevStep = stepIdx > 0 ? state.steps[stepIdx - 1] : null;
+  const nextStep = stepIdx < state.steps.length - 1 ? state.steps[stepIdx + 1] : null;
+
+  const priorContext = prevStep
+    ? `PRIOR STEP: "${prevStep.name}" — ${prevStep.command}\n  Status: ${prevStep.status} | Artifacts: ${prevStep.execution?.artifact_count || 0}`
+    : 'PRIOR STEP: None (first step)';
+
+  const nextContext = nextStep
+    ? `NEXT STEP: "${nextStep.name}" — ${nextStep.command}\n  Ensure output is consumable by next step`
+    : 'NEXT STEP: None (last step)';
+
+  // ── 3. Acceptance criteria (from test_task generation) ──
+  const criteria = step.acceptance_criteria || [];
+  const testReqSection = criteria.length > 0
+    ? `ACCEPTANCE CRITERIA:\n${criteria.map((c, i) => `  ${i + 1}. ${c}`).join('\n')}`
+    : '';
+
+  // ── 4. Test task — the concrete scenario to drive execution ──
+  const testTask = step.test_task || '';
+  const testTaskSection = testTask
+    ? `TEST TASK (用此任务驱动命令执行):\n  ${testTask}`
+    : '';
+
+  // ── 5. Build prompt based on whether command has metadata ──
+  if (cmdMeta) {
+    // Slash command with resolved file — rich context prompt
+    return `PURPOSE: Execute workflow step "${step.name}" (${stepIdx + 1}/${state.steps.length}).
+
+COMMAND DEFINITION:
+  Name: ${cmdMeta.name}
+  Description: ${cmdMeta.description}
+  Argument Format: ${cmdMeta.argumentHint || 'none'}
+  Allowed Tools: ${cmdMeta.allowedTools || 'default'}
+  Source: ${cmdMeta.filePath}
+
+COMMAND TO EXECUTE: ${step.command}
+ARGUMENTS: ${cmdArgs || '(no arguments)'}
+
+${testTaskSection}
+
+COMMAND REFERENCE (first 30 lines):
+${cmdMeta.bodySummary}
+
+PROJECT: ${state.project_scenario}
+SANDBOX PROJECT: ${state.sandbox_dir}
+OUTPUT DIR: ${state.work_dir}/steps/step-${stepIdx + 1}
+
+${priorContext}
+${nextContext}
+${testReqSection}
+
+TASK: Execute the command as described in COMMAND DEFINITION, using TEST TASK as the input/scenario. Use the COMMAND REFERENCE to understand expected behavior. All work happens in the SANDBOX PROJECT directory (an isolated empty project, NOT the real workspace). Auto-confirm all prompts.
+CONSTRAINTS: Stay scoped to this step only. Follow the command's own execution flow. The TEST TASK is the real work — treat it as the $ARGUMENTS input to the command. Do NOT read/modify files outside SANDBOX PROJECT.`;
+
+  } else {
+    // Shell command, ccw cli command, or unresolved command
+    return `PURPOSE: Execute workflow step "${step.name}" (${stepIdx + 1}/${state.steps.length}).
+COMMAND: ${step.command}
+${testTaskSection}
+PROJECT: ${state.project_scenario}
+SANDBOX PROJECT: ${state.sandbox_dir}
+OUTPUT DIR: ${state.work_dir}/steps/step-${stepIdx + 1}
+
+${priorContext}
+${nextContext}
+${testReqSection}
+
+TASK: Execute the COMMAND above with TEST TASK as the input scenario. All work happens in the SANDBOX PROJECT directory (an isolated empty project). Auto-confirm all prompts.
+CONSTRAINTS: Stay scoped to this step only. The TEST TASK is the real work to execute. Do NOT read/modify files outside SANDBOX PROJECT.`;
+  }
+}
+```
+
+### Step Execution
+
+```javascript
+const stepIdx = state.current_step;
+const step = state.steps[stepIdx];
+const stepDir = `${state.work_dir}/steps/step-${stepIdx + 1}`;
+
+// Pre-execution: snapshot sandbox directory files
+const preFiles = Bash(`find "${state.sandbox_dir}" -type f 2>/dev/null | sort`).stdout.trim();
+Write(`${stepDir}/pre-exec-snapshot.txt`, preFiles || '(empty)');
+
+const startTime = Date.now();
+const prompt = assembleStepPrompt(step, stepIdx, state);
+
+// ★ All steps execute via ccw cli --tool claude --mode write
+// ★ --cd 指向沙箱目录（独立项目），不影响真实工作空间
+Bash({
+  command: `ccw cli -p ${escapeForShell(prompt)} --tool claude --mode write --rule universal-rigorous-style --cd "${state.sandbox_dir}"`,
+  run_in_background: true, timeout: 600000
+});
+// ■ STOP — wait for hook callback
+```
+
+### Post-Execute Callback Handler
+
+```javascript
+// ★ This runs after receiving the ccw cli callback
+
+const duration = Date.now() - startTime;
+
+// Collect artifacts by scanning sandbox (not git diff — sandbox is an independent project)
+const postFiles = Bash(`find "${state.sandbox_dir}" -type f -newer "${stepDir}/pre-exec-snapshot.txt" 2>/dev/null | sort`).stdout.trim();
+const newArtifacts = postFiles ? postFiles.split('\n').filter(f => !f.endsWith('.git/')) : [];
+
+const artifactManifest = {
+  step: step.name, step_index: stepIdx,
+  success: true, duration_ms: duration,
+  artifacts: newArtifacts.map(f => ({
+    path: f,
+    type: f.endsWith('.md') ? 'markdown' : f.endsWith('.json') ? 'json' : 'other'
+  })),
+  collected_at: new Date().toISOString()
+};
+Write(`${stepDir}/artifacts-manifest.json`, JSON.stringify(artifactManifest, null, 2));
+
+// Update state
+state.steps[stepIdx].status = 'executed';
+state.steps[stepIdx].execution = {
+  success: true, duration_ms: duration,
+  artifact_count: newArtifacts.length
+};
+state.current_phase = 'analyze';
+Write(`${state.work_dir}/workflow-state.json`, JSON.stringify(state, null, 2));
+
+// → Proceed to Phase 3 for this step
+```
+
+## Phase 3: Analyze Step (per step, via gemini)
+
+```javascript
+const manifest = JSON.parse(Read(`${stepDir}/artifacts-manifest.json`));
+
+// Build artifact content for analysis
+let artifactSummary = '';
+if (state.analysis_depth === 'quick') {
+  artifactSummary = manifest.artifacts.map(a => `- ${a.path} (${a.type})`).join('\n');
+} else {
+  const maxLines = state.analysis_depth === 'deep' ? 300 : 150;
+  artifactSummary = manifest.artifacts.map(a => {
+    try { return `--- ${a.path} ---\n${Read(a.path, { limit: maxLines })}`; }
+    catch { return `--- ${a.path} --- [unreadable]`; }
+  }).join('\n\n');
+}
+
+const criteria = step.acceptance_criteria || [];
+const testTaskDesc = step.test_task ? `TEST TASK: ${step.test_task}` : '';
+const criteriaSection = criteria.length > 0
+  ? `ACCEPTANCE CRITERIA:\n${criteria.map((c, i) => `  ${i + 1}. ${c}`).join('\n')}`
+  : '';
+
+const analysisPrompt = `PURPOSE: Evaluate execution quality of step "${step.name}" (${stepIdx + 1}/${state.steps.length}).
+WORKFLOW: ${state.workflow_name} — ${state.project_scenario}
+COMMAND: ${step.command}
+${testTaskDesc}
+${criteriaSection}
+EXECUTION: Duration ${step.execution.duration_ms}ms | Artifacts: ${manifest.artifacts.length}
+ARTIFACTS:\n${artifactSummary}
+EXPECTED OUTPUT (strict JSON):
+{ "quality_score": <0-100>, "requirement_match": { "pass": <bool>, "criteria_met": [], "criteria_missed": [], "fail_signals_detected": [] }, "execution_assessment": { "success": <bool>, "completeness": "", "notes": "" }, "artifact_assessment": { "count": <n>, "quality": "", "key_outputs": [], "missing_outputs": [] }, "issues": [{ "severity": "critical|high|medium|low", "description": "", "suggestion": "" }], "optimization_opportunities": [{ "area": "", "description": "", "impact": "high|medium|low" }], "step_summary": "" }`;
+
+let cliCommand = `ccw cli -p ${escapeForShell(analysisPrompt)} --tool gemini --mode analysis --rule analysis-review-code-quality`;
+if (state.gemini_session_id) cliCommand += ` --resume ${state.gemini_session_id}`;
+Bash({ command: cliCommand, run_in_background: true, timeout: 300000 });
+// ■ STOP — wait for hook callback
+```
+
+### Post-Analyze Callback Handler
+
+```javascript
+// ★ Parse analysis result JSON from callback
+const analysisResult = /* parsed from callback output */;
+
+// ★ Capture gemini session ID for resume chain
+// Session ID is in stderr: [CCW_EXEC_ID=gem-xxxxxx-xxxx]
+state.gemini_session_id = /* captured from callback exec_id */;
+
+Write(`${stepDir}/step-${stepIdx + 1}-analysis.json`, JSON.stringify(analysisResult, null, 2));
+
+// Update state
+state.steps[stepIdx].analysis = {
+  quality_score: analysisResult.quality_score,
+  requirement_pass: analysisResult.requirement_match?.pass,
+  issue_count: (analysisResult.issues || []).length
+};
+state.steps[stepIdx].status = 'completed';
+
+// Append to process log
+const logEntry = `## Step ${stepIdx + 1}: ${step.name}\n- Score: ${analysisResult.quality_score}/100\n- Req: ${analysisResult.requirement_match?.pass ? 'PASS' : 'FAIL'}\n- Issues: ${(analysisResult.issues || []).length}\n- Summary: ${analysisResult.step_summary}\n\n`;
+Edit(`${state.work_dir}/process-log.md`, /* append logEntry */);
+
+// ★ Advance state machine
+state.current_step = stepIdx + 1;
+state.current_phase = 'execute';
+Write(`${state.work_dir}/workflow-state.json`, JSON.stringify(state, null, 2));
+
+// ★ Decision: advance or synthesize
+if (state.current_step < state.steps.length) {
+  // → Back to Phase 2 for next step
+} else {
+  // → Phase 4: Synthesize
+}
+```
+
+## Step Loop — State Machine
+
+```
+NOT a sync for-loop. Each step follows this state machine:
+
+  ┌─────────────────────────────────────────────────────┐
+  │ state.current_step = N, state.current_phase = X     │
+  ├─────────────────────────────────────────────────────┤
+  │ phase='execute' → Phase 2 → ccw cli claude → STOP  │
+  │   callback → collect artifacts → phase='analyze'    │
+  │ phase='analyze' → Phase 3 → ccw cli gemini → STOP  │
+  │   callback → save analysis → current_step++         │
+  │   if current_step < total → phase='execute' (loop)  │
+  │   else → Phase 4 (synthesize)                       │
+  └─────────────────────────────────────────────────────┘
+
+Error handling:
+  - Execute timeout → retry once, then mark failed, advance
+  - Analyze failure → retry without --resume, then skip analysis
+  - 3+ consecutive errors → terminate, jump to Phase 5 partial report
+```
+
+## Phase 4: Synthesize (via gemini)
+
+```javascript
+const stepAnalyses = state.steps.map((step, i) => {
+  try { return { step: step.name, content: Read(`${state.work_dir}/steps/step-${i + 1}/step-${i + 1}-analysis.json`) }; }
+  catch { return { step: step.name, content: '[Not available]' }; }
+});
+
+const scores = state.steps.map(s => s.analysis?.quality_score).filter(Boolean);
+const avgScore = scores.length > 0 ? Math.round(scores.reduce((a, b) => a + b, 0) / scores.length) : 0;
+
+const synthesisPrompt = `PURPOSE: Synthesize all step analyses into holistic workflow assessment with actionable optimization plan.
+WORKFLOW: ${state.workflow_name} — ${state.project_scenario}
+Steps: ${state.steps.length} | Avg Quality: ${avgScore}/100
+STEP ANALYSES:\n${stepAnalyses.map(a => `### ${a.step}\n${a.content}`).join('\n\n---\n\n')}
+Evaluate: coherence across steps, handoff quality, redundancy, bottlenecks.
+EXPECTED OUTPUT (strict JSON):
+{ "workflow_score": <0-100>, "coherence": { "score": <0-100>, "assessment": "", "gaps": [] }, "bottlenecks": [{ "step": "", "issue": "", "suggestion": "" }], "per_step_improvements": [{ "step": "", "priority": "high|medium|low", "action": "" }], "workflow_improvements": [{ "area": "", "description": "", "impact": "high|medium|low" }], "summary": "" }`;
+
+let cliCommand = `ccw cli -p ${escapeForShell(synthesisPrompt)} --tool gemini --mode analysis --rule analysis-review-architecture`;
+if (state.gemini_session_id) cliCommand += ` --resume ${state.gemini_session_id}`;
+Bash({ command: cliCommand, run_in_background: true, timeout: 300000 });
+// ■ STOP — wait for hook callback → parse JSON, write synthesis.json, update state
+```
+
+## Phase 5: Report
+
+```javascript
+const synthesis = JSON.parse(Read(`${state.work_dir}/synthesis.json`));
+const scores = state.steps.map(s => s.analysis?.quality_score).filter(Boolean);
+const avgScore = scores.length > 0 ? Math.round(scores.reduce((a, b) => a + b, 0) / scores.length) : 0;
+const totalIssues = state.steps.reduce((sum, s) => sum + (s.analysis?.issue_count || 0), 0);
+
+const stepTable = state.steps.map((s, i) => {
+  const reqStr = s.analysis?.requirement_pass === true ? 'PASS' : s.analysis?.requirement_pass === false ? 'FAIL' : '-';
+  return `| ${i + 1} | ${s.name} | ${s.execution?.success ? 'OK' : 'FAIL'} | ${reqStr} | ${s.analysis?.quality_score || '-'} | ${s.analysis?.issue_count || 0} |`;
+}).join('\n');
+
+const improvements = (synthesis.per_step_improvements || [])
+  .filter(imp => imp.priority === 'high')
+  .map(imp => `- **${imp.step}**: ${imp.action}`)
+  .join('\n');
+
+const report = `# Workflow Tune Report
+
+| Field | Value |
+|---|---|
+| Workflow | ${state.workflow_name} |
+| Test Project | ${state.project_scenario} |
+| Workflow Score | ${synthesis.workflow_score || avgScore}/100 |
+| Avg Step Score | ${avgScore}/100 |
+| Total Issues | ${totalIssues} |
+| Coherence | ${synthesis.coherence?.score || '-'}/100 |
+
+## Step Results
+
+| # | Step | Exec | Req | Quality | Issues |
+|---|------|------|-----|---------|--------|
+${stepTable}
+
+## High Priority Improvements
+
+${improvements || 'None'}
+
+## Workflow-Level Improvements
+
+${(synthesis.workflow_improvements || []).map(w => `- **${w.area}** (${w.impact}): ${w.description}`).join('\n') || 'None'}
+
+## Bottlenecks
+
+${(synthesis.bottlenecks || []).map(b => `- **${b.step}**: ${b.issue} → ${b.suggestion}`).join('\n') || 'None'}
+
+## Summary
+
+${synthesis.summary || 'N/A'}
+`;
+
+Write(`${state.work_dir}/final-report.md`, report);
+state.status = 'completed';
+Write(`${state.work_dir}/workflow-state.json`, JSON.stringify(state, null, 2));
+
+// Output report to user
+```
+
+## Resume Chain
+
+```
+Step 1 Execute → ccw cli claude --mode write --rule universal-rigorous-style --cd step-1/ → STOP → callback → artifacts
+Step 1 Analyze → ccw cli gemini --mode analysis --rule analysis-review-code-quality         → STOP → callback → gemini_session_id = exec_id
+Step 2 Execute → ccw cli claude --mode write --rule universal-rigorous-style --cd step-2/ → STOP → callback → artifacts
+Step 2 Analyze → ccw cli gemini --mode analysis --resume gemini_session_id                 → STOP → callback → gemini_session_id = exec_id
+  ...
+Synthesize   → ccw cli gemini --mode analysis --resume gemini_session_id                   → STOP → callback → synthesis
+Report       → local generation (no CLI call)
+```
+
+## Error Handling
+
+| Phase | Error | Recovery |
+|-------|-------|----------|
+| Execute | CLI timeout | Retry once, then mark step failed and advance |
+| Execute | Command not found | Skip step, note in process-log |
+| Analyze | CLI fails | Retry without --resume, then skip analysis |
+| Synthesize | CLI fails | Generate report from step analyses only |
+| Any | 3+ consecutive errors | Terminate, produce partial report |
+
+## Core Rules
+
+1. **STOP After Each CLI Call**: Every `ccw cli` call runs in background — STOP output immediately, wait for hook callback
+2. **State Machine**: Advance via `current_step` + `current_phase`, never use sync loops for async operations
+3. **Test Task Drives Execution**: 每个命令必须有 test_task（完整需求说明），作为命令的 $ARGUMENTS 输入。test_task 由当前 Claude 直接根据命令链复杂度生成，不需要额外 CLI 调用
+4. **All Execution via claude**: `ccw cli --tool claude --mode write --rule universal-rigorous-style`
+5. **All Analysis via gemini**: `ccw cli --tool gemini --mode analysis`, chained via `--resume`
+6. **Session Capture**: After each gemini callback, capture exec_id → `gemini_session_id` for resume chain
+7. **Sandbox Isolation**: 所有命令在独立沙箱目录（`sandbox/`）中执行，使用虚构测试任务，不影响真实项目
+8. **Artifact Collection**: Scan sandbox filesystem (not git diff), compare pre/post snapshots
+9. **Prompt Assembly**: Every step goes through `assembleStepPrompt()` — resolves command file, reads YAML metadata, injects test_task, builds rich context
+10. **Auto-Confirm**: All prompts auto-confirmed, no blocking interactions during execution

.claude/commands/workflow/analyze-with-file.md

@@ -10,11 +10,11 @@ allowed-tools: TodoWrite(*), Agent(*), AskUserQuestion(*), Read(*), Grep(*), Glo
 When `--yes` or `-y`: Auto-confirm exploration decisions, use recommended analysis angles.
 
 <purpose>
-Interactive collaborative analysis workflow combining codebase exploration (cli-explore-agent) with CLI-assisted analysis (Gemini/Codex). Produces a documented discussion timeline with evolving understanding, decision trails, and actionable conclusions.
+Interactive collaborative analysis workflow combining codebase exploration (cli-explore-agent), external research (workflow-research-agent), and CLI-assisted analysis (Gemini/Codex). Produces a documented discussion timeline with evolving understanding, decision trails, and actionable conclusions.
 
 Invoked when user needs deep, multi-perspective analysis of a topic or codebase question — e.g., architecture review, implementation analysis, concept exploration, or decision evaluation.
 
-Produces: `discussion.md` (evolving analysis document with TOC, rounds, narrative synthesis), `explorations.json`/`perspectives.json` (structured findings), `conclusions.json` (final synthesis with recommendations). All artifacts stored in `.workflow/.analysis/{session-id}/`.
+Produces: `discussion.md` (evolving analysis document with TOC, rounds, narrative synthesis), `explorations.json`/`perspectives.json` (structured findings), `research.json` (external research findings), `conclusions.json` (final synthesis with recommendations). All artifacts stored in `.workflow/.analysis/{session-id}/`.
 </purpose>
 
 <conventions>
@@ -72,16 +72,23 @@ All `AskUserQuestion` calls MUST comply:
 
 **Principles**: Immediacy (record as-it-happens), Completeness (context+options+chosen+reason+rejected), Traceability (later phases trace back), Depth (capture reasoning, not just outcomes)
 
+**Technical Solution Triggers** — record using Technical Solution Record Format when ANY of:
+- An implementation approach is described with specific files/patterns/code changes
+- Two or more alternatives are compared with trade-offs
+- User confirms, modifies, or rejects a proposed approach
+- A concrete code change strategy emerges (what to modify, how, why)
+
 ### Output Artifacts
 
 | Phase | Artifact | Description |
 |-------|----------|-------------|
 | 1 | `discussion.md` | Initialized with TOC, Current Understanding block, timeline, metadata |
 | 1 | Session variables | Dimensions, focus areas, analysis depth |
-| 2 | `exploration-codebase.json` | Single codebase context from cli-explore-agent |
-| 2 | `explorations/*.json` | Multi-perspective codebase explorations (parallel, up to 4) |
-| 2 | `explorations.json` | Single perspective aggregated findings |
-| 2 | `perspectives.json` | Multi-perspective findings (up to 4) with synthesis |
+| 2 | `exploration-codebase.json` | Shared Layer 1 discovery (files, modules, patterns) — always created |
+| 2 | `explorations/*.json` | Per-perspective Layer 2-3 deep-dives (multi-perspective only, max 4) |
+| 2 | `research.json` | External research findings (best practices, API details, known issues) — from workflow-research-agent |
+| 2 | `explorations.json` | Single perspective aggregated findings (Layer 1 + CLI analysis + research) |
+| 2 | `perspectives.json` | Multi-perspective findings (Layer 1 shared + per-perspective deep-dives + research) with synthesis |
 | 2 | Updated `discussion.md` | Round 1 + Initial Intent Coverage Check + Current Understanding replaced |
 | 3 | Updated `discussion.md` | Round 2-N: feedback, insights, narrative synthesis; TOC + Current Understanding updated each round |
 | 4 | `conclusions.json` | Final synthesis with recommendations (incl. steps[] + review_status) |
@@ -141,98 +148,192 @@ All `AskUserQuestion` calls MUST comply:
 <step name="cli_exploration">
 **Phase 2: Codebase exploration FIRST, then CLI analysis.**
 
-**Step 1: Codebase Exploration** (cli-explore-agent, parallel up to 6)
+**Step 1: Codebase Exploration** (cli-explore-agent, 1 shared + N perspective-specific)
 
-- **Single**: General codebase analysis -> `{sessionFolder}/exploration-codebase.json`
-- **Multi-perspective**: Parallel per-perspective -> `{sessionFolder}/explorations/{perspective}.json`
-- **Common tasks**: `ccw tool exec get_modules_by_depth '{}'`, keyword searches, read `.workflow/project-tech.json`
+Two-phase approach to avoid redundant file discovery:
+
+**Phase A — Shared Discovery** (1 agent, always runs):
+One cli-explore-agent performs Layer 1 (breadth) for ALL perspectives -> `{sessionFolder}/exploration-codebase.json`
 
 ```javascript
-// Template for cli-explore-agent (single or per-perspective)
+// Shared Layer 1 discovery — runs ONCE regardless of perspective count
 Agent({
   subagent_type: "cli-explore-agent",
   run_in_background: false,
-  description: `Explore codebase: ${topicSlug}`,
+  description: `Discover codebase: ${topicSlug}`,
   prompt: `
 ## Analysis Context
 Topic: ${topic_or_question}
 Dimensions: ${dimensions.join(', ')}
-// For multi-perspective, add: Perspective: ${perspective.name} - ${perspective.focus}
 Session: ${sessionFolder}
 
 ## MANDATORY FIRST STEPS
 1. Run: ccw tool exec get_modules_by_depth '{}'
 2. Read: .workflow/project-tech.json (if exists)
 
-## Layered Exploration (MUST follow all 3 layers)
-
-### Layer 1 — Module Discovery (Breadth)
-- Search by topic keywords, identify ALL relevant files
-- Map module boundaries and entry points -> relevant_files[] with annotations
-
-### Layer 2 — Structure Tracing (Depth)
-- Top 3-5 key files: trace call chains 2-3 levels deep
-- Identify data flow paths and dependencies -> call_chains[], data_flows[]
-
-### Layer 3 — Code Anchor Extraction (Detail)
-- Each key finding: extract code snippet (20-50 lines) with file:line
-- Annotate WHY this matters -> code_anchors[]
+## Layer 1 — Module Discovery (Breadth ONLY)
+- Search by topic keywords across ALL dimensions: ${dimensions.join(', ')}
+- Identify ALL relevant files, map module boundaries and entry points
+- Categorize files by dimension/perspective relevance
+- Output: relevant_files[] with annotations + dimension tags, initial patterns[]
 
 ## Output
 Write to: ${sessionFolder}/exploration-codebase.json
-// Multi-perspective: ${sessionFolder}/explorations/${perspective.name}.json
-
-Schema: {relevant_files, patterns, key_findings, code_anchors: [{file, lines, snippet, significance}], call_chains: [{entry, chain, files}], questions_for_user, _metadata}
+Schema: {relevant_files: [{path, annotation, dimensions[]}], patterns[], module_map: {}, questions_for_user, _metadata}
 `
 })
 ```
 
-**Step 2: CLI Analysis** (AFTER exploration)
+**Phase A2 — External Research** (parallel with Phase A, runs when topic involves technologies/patterns/APIs):
 
-- **Single**: Comprehensive CLI analysis with exploration context
-- **Multi (up to 4)**: Parallel CLI calls per perspective
+Determine if external research would add value — skip for purely internal codebase questions (e.g., "how does module X work"), run for topics involving technology choices, best practices, architecture patterns, API usage, or comparison with industry standards.
+
+```javascript
+// External research — runs in PARALLEL with Phase A codebase exploration
+// Skip if topic is purely internal codebase navigation
+const needsResearch = dimensions.some(d =>
+  ['architecture', 'comparison', 'decision', 'performance', 'security'].includes(d)
+) || topic_or_question.match(/best practice|pattern|vs|compare|approach|standard|library|framework/i)
+
+if (needsResearch) {
+  Agent({
+    subagent_type: "workflow-research-agent",
+    run_in_background: false,
+    description: `Research: ${topicSlug}`,
+    prompt: `
+## Research Objective
+Topic: ${topic_or_question}
+Mode: detail-verification
+Dimensions: ${dimensions.join(', ')}
+
+## Focus
+${dimensions.includes('architecture') ? '- Architecture patterns and best practices for this domain' : ''}
+${dimensions.includes('performance') ? '- Performance benchmarks and optimization patterns' : ''}
+${dimensions.includes('security') ? '- Security best practices and known vulnerabilities' : ''}
+${dimensions.includes('comparison') ? '- Technology comparison and trade-off analysis' : ''}
+${dimensions.includes('decision') ? '- Decision frameworks and industry recommendations' : ''}
+- Verify assumptions about technologies/patterns involved
+- Known issues and pitfalls in this area
+- Recommended approaches with evidence
+
+## Codebase Context (from Phase A if available)
+Tech stack: ${techStack || 'detect from project files'}
+Key patterns observed: ${sharedDiscovery?.patterns?.join(', ') || 'pending Phase A results'}
+
+## Output
+Return structured markdown per your output format.
+Do NOT write files.
+`
+  })
+  // Parse research agent output → save to ${sessionFolder}/research.json
+  // Schema: {topic, mode, findings[], best_practices[], alternatives[], pitfalls[], sources[], _metadata}
+}
+```
+
+**Phase B — Perspective Deep-Dive** (PARALLEL, only for multi-perspective, max 4):
+Each perspective agent receives shared Layer 1 results, performs only Layer 2-3 on its relevant subset.
+Skip if single-perspective (single mode proceeds directly to Step 2 CLI analysis with Layer 1 results).
+
+**CRITICAL — Parallel Execution**: Launch ALL perspective Agent() calls in the SAME response block so Claude Code executes them concurrently. Do NOT use a loop that waits for each agent before starting the next.
+
+```javascript
+// Per-perspective Layer 2-3 — receives shared discovery, avoids re-scanning
+// Only runs in multi-perspective mode
+// PARALLEL: All Agent() calls MUST appear in ONE response — Claude Code runs them concurrently
+const sharedDiscovery = readJSON(`${sessionFolder}/exploration-codebase.json`)
+
+// Prepare per-perspective file lists
+const perspectiveFileLists = Object.fromEntries(
+  selectedPerspectives.map(p => [
+    p.name,
+    sharedDiscovery.relevant_files.filter(f => f.dimensions.includes(p.dimension))
+  ])
+)
+
+// Launch ALL agents in a SINGLE response block (not sequentially):
+// Agent({ ..perspective1.. })  ← call 1
+// Agent({ ..perspective2.. })  ← call 2 (same response)
+// Agent({ ..perspective3.. })  ← call 3 (same response)
+
+// Each agent call follows this template:
+Agent({
+  subagent_type: "cli-explore-agent",
+  run_in_background: false,
+  description: `Deep-dive: ${perspective.name}`,
+  prompt: `
+## Analysis Context
+Topic: ${topic_or_question}
+Perspective: ${perspective.name} - ${perspective.focus}
+Session: ${sessionFolder}
+
+## SHARED DISCOVERY (Layer 1 already completed — DO NOT re-scan)
+Relevant files for this perspective:
+${perspectiveFileLists[perspective.name].map(f => `- ${f.path}: ${f.annotation}`).join('\n')}
+Patterns found: ${sharedDiscovery.patterns.join(', ')}
+
+## Layer 2 — Structure Tracing (Depth)
+- From the relevant files above, pick top 3-5 key files for this perspective
+- Trace call chains 2-3 levels deep
+- Identify data flow paths and dependencies -> call_chains[], data_flows[]
+
+## Layer 3 — Code Anchor Extraction (Detail)
+- Each key finding: extract code snippet (20-50 lines) with file:line
+- Annotate WHY this matters for ${perspective.name} -> code_anchors[]
+
+## Output
+Write to: ${sessionFolder}/explorations/${perspective.name}.json
+Schema: {perspective, relevant_files, key_findings, code_anchors: [{file, lines, snippet, significance}], call_chains: [{entry, chain, files}], questions_for_user, _metadata}
+`
+})
+```
+
+**Step 2: CLI Deep Analysis** (AFTER exploration, single-perspective ONLY)
+
+- **Single-perspective**: CLI does Layer 2-3 depth analysis (explore agent only did Layer 1)
+- **Multi-perspective**: SKIP this step — perspective agents in Step 1 Phase B already did Layer 2-3
 - Execution: `Bash` with `run_in_background: true`
 
 ```javascript
-// Build shared exploration context for CLI prompts
-const explorationContext = `
-PRIOR EXPLORATION CONTEXT:
-- Key files: ${explorationResults.relevant_files.slice(0,5).map(f => f.path).join(', ')}
-- Patterns: ${explorationResults.patterns.slice(0,3).join(', ')}
-- Findings: ${explorationResults.key_findings.slice(0,3).join(', ')}
-- Code anchors:
-${(explorationResults.code_anchors || []).slice(0,5).map(a => `  [${a.file}:${a.lines}] ${a.significance}\n  \`\`\`\n  ${a.snippet}\n  \`\`\``).join('\n')}
-- Call chains: ${(explorationResults.call_chains || []).slice(0,3).map(c => `${c.entry} -> ${c.chain.join(' -> ')}`).join('; ')}`
+// ONLY for single-perspective mode — multi-perspective already has deep-dive agents
+if (selectedPerspectives.length <= 1) {
+  const sharedDiscovery = readJSON(`${sessionFolder}/exploration-codebase.json`)
+  const explorationContext = `
+PRIOR EXPLORATION (Layer 1 discovery):
+- Key files: ${sharedDiscovery.relevant_files.slice(0,8).map(f => `${f.path} (${f.annotation})`).join(', ')}
+- Patterns: ${sharedDiscovery.patterns.slice(0,5).join(', ')}
+- Module map: ${JSON.stringify(sharedDiscovery.module_map || {})}`
 
-// Single perspective (for multi: loop selectedPerspectives with perspective.purpose/tasks/constraints)
-Bash({
-  command: `ccw cli -p "
-PURPOSE: Analyze '${topic_or_question}' from ${dimensions.join(', ')} perspectives
-Success: Actionable insights with clear reasoning
+  Bash({
+    command: `ccw cli -p "
+PURPOSE: Deep analysis of '${topic_or_question}' — build on prior file discovery
+Success: Actionable insights with code evidence (anchors + call chains)
 
 ${explorationContext}
 
 TASK:
-- Build on exploration findings — reference specific code anchors
-- Analyze common patterns and anti-patterns with code evidence
-- Highlight potential issues/opportunities with file:line references
+- From discovered files, trace call chains 2-3 levels deep for top 3-5 key files
+- Extract code snippets (20-50 lines) for each key finding with file:line
+- Identify patterns, anti-patterns, and potential issues with evidence
 - Generate discussion points for user clarification
 
 MODE: analysis
 CONTEXT: @**/* | Topic: ${topic_or_question}
-EXPECTED: Structured analysis with sections, insights tied to evidence, questions, recommendations
-CONSTRAINTS: Focus on ${dimensions.join(', ')}
+EXPECTED: Structured analysis with: key_findings[], code_anchors[{file,lines,snippet,significance}], call_chains[{entry,chain,files}], discussion_points[]
+CONSTRAINTS: Focus on ${dimensions.join(', ')} | Do NOT re-discover files — use provided file list
 " --tool gemini --mode analysis`,
-  run_in_background: true
-})
-// STOP: Wait for hook callback before continuing
-// Multi-perspective: Same pattern per perspective with perspective.purpose/tasks/constraints/tool
+    run_in_background: true
+  })
+  // STOP: Wait for hook callback before continuing
+}
 ```
 
 **Step 3: Aggregate Findings**
-- Consolidate explorations + CLI results
+- Consolidate explorations + CLI results + research findings (if research.json exists)
+- Merge research best_practices[] and pitfalls[] into discussion points
+- Cross-reference: flag gaps where codebase patterns diverge from research best practices
 - Multi: Extract synthesis (convergent themes, conflicting views, unique contributions)
 - Write to `explorations.json` (single) or `perspectives.json` (multi)
+- If research.json exists, add `external_research` section to explorations/perspectives with: key findings, best practices, codebase gaps
 
 **Step 4: Update discussion.md** — Append Round 1 with sources, key findings, discussion points, open questions
 
@@ -243,18 +344,7 @@ CONSTRAINTS: Focus on ${dimensions.join(', ')}
 - Present to user at beginning of Phase 3: "初始探索完成后，以下意图的覆盖情况：[list]。接下来的讨论将重点关注未覆盖的部分。"
 - Purpose: Early course correction — catch drift before spending multiple interactive rounds
 
-**explorations.json Schema** (single):
-- `session_id`, `timestamp`, `topic`, `dimensions[]`
-- `sources[]`: {type, file/summary}
-- `key_findings[]`, `code_anchors[]`: {file, lines, snippet, significance}
-- `call_chains[]`: {entry, chain, files}
-- `discussion_points[]`, `open_questions[]`
-- `technical_solutions[]`: {round, solution, problem, rationale, alternatives, status: proposed|validated|rejected, evidence_refs[], next_action}
-
-**perspectives.json Schema** (multi — extends explorations.json):
-- `perspectives[]`: [{name, tool, findings, insights, questions}]
-- `synthesis`: {convergent_themes, conflicting_views, unique_contributions}
-- code_anchors/call_chains include `perspective` field
+> All JSON schemas consolidated in `<schemas>` section below.
 
 | Condition | Action |
 |-----------|--------|
@@ -270,6 +360,22 @@ CONSTRAINTS: Focus on ${dimensions.join(', ')}
 
 **Guideline**: Delegate complex tasks to agents (cli-explore-agent) or CLI calls. Avoid direct analysis in main process.
 
+**Cumulative Context Rule**: Every agent/CLI call in Phase 3 MUST include a summary of ALL prior exploration results to avoid re-discovering known information. Build `priorContext` before each call:
+```javascript
+// Build cumulative context from all prior explorations (Phase 2 + previous rounds)
+const allFindings = readJSON(`${sessionFolder}/explorations.json`) // or perspectives.json
+const priorContext = `
+## KNOWN FINDINGS (DO NOT re-discover)
+- Established files: ${allFindings.sources.map(s => s.file).join(', ')}
+- Key findings: ${allFindings.key_findings.join('; ')}
+- Code anchors: ${allFindings.code_anchors.slice(0,5).map(a => `${a.file}:${a.lines}`).join(', ')}
+- Call chains: ${allFindings.call_chains.slice(0,3).map(c => c.entry).join(', ')}
+- Open questions: ${allFindings.open_questions.join('; ')}
+
+## NEW TASK: Focus ONLY on unexplored areas below.
+`
+```
+
 **Loop** (max 5 rounds):
 
 1. **Current Understanding Summary** (Round >= 2, BEFORE presenting new findings):
@@ -280,28 +386,42 @@ CONSTRAINTS: Focus on ${dimensions.join(', ')}
 
 3. **Gather Feedback** (AskUserQuestion, single-select, header: "分析反馈"):
    - **继续深入**: Direction correct — deepen automatically or user specifies direction (combines agree+deepen and agree+suggest)
+   - **外部研究**: Need external research on specific technology/pattern/best practice (spawns workflow-research-agent)
    - **调整方向**: Different focus or specific questions to address
-   - **补充信息**: User has additional context, constraints, or corrections to provide
    - **分析完成**: Sufficient -> exit to Phase 4
 
 4. **Process Response** (always record user choice + impact to discussion.md):
 
+   **Record-Before-Continue Rule**: Each path below MUST write findings and discussion synthesis to `discussion.md` BEFORE proceeding to Step 5. Specifically, after agent/CLI returns results:
+   - Append the exploration results, reasoning, and any technical approaches discussed to the current round section
+   - Apply **Technical Solution Triggers** (see Decision Recording Protocol) — if triggered, record using Technical Solution Record Format
+   - **Ambiguity Check**: For each Technical Solution with Status `Proposed`, verify no unresolved alternatives remain. If a solution lists 2+ options without a chosen one (e.g., "A or B"), record as:
+     ```markdown
+     > **⚠️ Ambiguity**: [Solution] has [N] unresolved alternatives: [list]
+     > - **Needs**: [Decision criteria or exploration to resolve]
+     ```
+     Surface unresolved ambiguities to user in the next feedback round.
+   - Only THEN proceed to Step 5 for Current Understanding replacement and TOC update
+
    **继续深入** -> Sub-question to choose direction (AskUserQuestion, single-select, header: "深入方向"):
    - Dynamically generate **max 3** context-driven options from: unresolved questions, low-confidence findings, unexplored dimensions, user-highlighted areas
    - Add **1** heuristic option that breaks current frame (e.g., "compare with best practices", "review from security perspective", "explore simpler alternatives")
    - Total: **max 4 options**. Each specifies: label, description, tool (cli-explore-agent for code-level / Gemini CLI for pattern-level), scope
    - **"Other" is auto-provided** by AskUserQuestion — covers user-specified custom direction (no need for separate "suggest next step" option)
-   - Execute selected direction -> merge new code_anchors/call_chains -> record confirmed assumptions + deepen angle
+   - Execute selected direction -> merge new code_anchors/call_chains into explorations.json -> **write exploration results, analysis reasoning, and any proposed approaches to discussion.md** -> record confirmed assumptions + deepen angle
+
+   **外部研究** -> Spawn workflow-research-agent for targeted research:
+   - AskUserQuestion (header: "研究主题", freetext via "Other"): What specific technology/pattern/approach needs external research?
+   - Spawn research agent with topic + current codebase context (from explorations.json)
+   - Merge research findings into explorations.json `external_research` section
+   - Update research.json with new findings (append, don't overwrite)
+   - Record research findings as Key Findings in discussion.md
 
    **调整方向** -> AskUserQuestion (header: "新方向", user selects or provides custom via "Other") -> new CLI exploration -> Record Decision (old vs new direction, reason, impact)
 
-   **补充信息** -> Capture user input, integrate into context, answer questions via CLI/analysis if needed -> Record corrections/additions + updated understanding
-
    **分析完成** -> Exit loop -> Record why concluding
 
-5. **Update discussion.md**:
-   - **Append** Round N: user input, direction adjustment, Q&A, corrections, new insights
-   - **Append Technical Solutions** — for every solution proposed, validated, or rejected this round, record immediately using Technical Solution Record Format in `#### Technical Solutions`
+5. **Update discussion.md** (after Record-Before-Continue writes are done):
    - **Replace** `## Current Understanding` block with latest consolidated understanding (follow Consolidation Rules)
    - **Update** `## Table of Contents` with links to new Round N sections
 
@@ -352,26 +472,50 @@ CONSTRAINTS: Focus on ${dimensions.join(', ')}
    - **Gate**: ❌ Missed items must be either (a) addressed in additional round or (b) confirmed deferred by user
    - Add `intent_coverage[]` to conclusions.json
 
-2. **Consolidate Insights**:
+2. **Findings-to-Recommendations Traceability** (MANDATORY before consolidation):
+   - **Collect ALL actionable findings** from every round: key findings with actionable implications, technical solutions (proposed/validated), identified gaps (API-frontend gaps, missing features, design issues), corrected assumptions that imply fixes
+   - **Map each finding → disposition**:
+     | Disposition | Meaning |
+     |-------------|---------|
+     | `recommendation` | Converted to a numbered recommendation |
+     | `absorbed` | Covered by another recommendation (specify which) |
+     | `deferred` | Explicitly out-of-scope with reason |
+     | `informational` | Pure insight, no action needed |
+   - **Findings Coverage Matrix** (append to discussion.md):
+     ```markdown
+     ### Findings Coverage Matrix
+     | # | Finding (Round) | Disposition | Target |
+     |---|----------------|-------------|--------|
+     | 1 | [finding summary] (R1) | recommendation | Rec #1 |
+     | 2 | [finding summary] (R2) | absorbed | → Rec #1 |
+     | 3 | [finding summary] (R2) | deferred | Reason: [why] |
+     | 4 | [finding summary] (R1) | informational | — |
+     ```
+   - **Gate**: Findings with `disposition = null` (unmapped) MUST be either assigned a disposition or added as new recommendations. Do NOT proceed to step 3 with unmapped findings.
+   - Add `findings_coverage[]` to conclusions.json
+
+3. **Consolidate Insights**:
    - Compile Decision Trail from all phases
    - Key conclusions with evidence + confidence (high/medium/low)
-   - Recommendations with rationale + priority (high/medium/low) — **merge validated `technical_solutions[]` from explorations.json as high-priority recommendations**
+   - Recommendations with rationale + priority (high/medium/low) — **merge validated `technical_solutions[]` from explorations.json as high-priority recommendations** — **ensure all `disposition = recommendation` findings from step 2 are represented**
+   - **Solution Readiness Gate**: For each recommendation, check if all key choices are resolved. Flag `ambiguity_resolved: false` on any recommendation that still contains unresolved alternatives. Present unresolved items to user before proceeding to Step 4.
    - Open questions, follow-up suggestions
    - Decision summary linking conclusions back to decisions
    - Write to conclusions.json
 
-3. **Final discussion.md Update**:
+4. **Final discussion.md Update**:
    - **Conclusions**: Summary, ranked key conclusions, prioritized recommendations, remaining questions
    - **Current Understanding (Final)**: What established, what clarified/corrected, key insights
    - **Decision Trail**: Critical decisions, direction changes timeline, trade-offs
+   - **Findings Coverage Matrix**: From step 2 (already appended)
    - Session statistics: rounds, duration, sources, artifacts, decision count
 
-4. **Display Conclusions Summary** — Present to user:
+5. **Display Conclusions Summary** — Present to user:
    - **Analysis Report**: summary, key conclusions (numbered, with confidence), recommendations (numbered, with priority + rationale + steps)
    - Open questions if any
    - Link to full report: `{sessionFolder}/discussion.md`
 
-5. **Interactive Recommendation Review** (skip in auto mode):
+6. **Interactive Recommendation Review** (skip in auto mode):
 
    Present all recommendations, then batch-confirm via **single AskUserQuestion call** (up to 4 questions):
 
@@ -392,7 +536,7 @@ CONSTRAINTS: Focus on ${dimensions.join(', ')}
    - Accepted: N items | Modified: N items | Rejected: N items
    - Only accepted/modified recommendations proceed to next step
 
-6. **MANDATORY GATE: Next Step Selection** — workflow MUST NOT end without executing this step.
+7. **MANDATORY GATE: Next Step Selection** — workflow MUST NOT end without executing this step.
 
    **TodoWrite**: Update `phase-4` -> `"completed"`, `next-step` -> `"in_progress"`
 
@@ -500,7 +644,45 @@ ${implScope.map((item, i) => `${i+1}. **${item.objective}** [${item.priority}]
 
    **TodoWrite**: Update `next-step` -> `"completed"` after user selection is handled
 
-**conclusions.json Schema**:
+> conclusions.json schema: see `<schemas>` section below.
+</step>
+
+</process>
+
+<schemas>
+
+**exploration-codebase.json** (shared Layer 1):
+- `session_id`, `timestamp`, `topic`, `dimensions[]`
+- `relevant_files[]`: {path, annotation, dimensions[]}
+- `patterns[]`, `module_map`: {}
+- `questions_for_user[]`, `_metadata`
+
+**research.json** (external research findings):
+- `topic`, `mode` (detail-verification|api-research|design-research), `timestamp`
+- `findings[]`: {finding, detail, confidence, source_url}
+- `best_practices[]`: {practice, rationale, source}
+- `alternatives[]`: {option, pros, cons, verdict}
+- `pitfalls[]`: {issue, mitigation, source}
+- `codebase_gaps[]`: {gap, current_approach, recommended_approach}
+- `sources[]`: {title, url, key_takeaway}
+- `_metadata`: {queries_executed, results_found}
+
+**explorations.json** (single — Layer 1 + CLI analysis + research merged):
+- `session_id`, `timestamp`, `topic`, `dimensions[]`
+- `sources[]`: {type, file/summary}
+- `key_findings[]`, `code_anchors[]`: {file, lines, snippet, significance}
+- `call_chains[]`: {entry, chain, files}
+- `discussion_points[]`, `open_questions[]`
+- `technical_solutions[]`: {round, solution, problem, rationale, alternatives, status: proposed|validated|rejected, evidence_refs[], next_action}
+- `external_research`: {findings[], best_practices[], codebase_gaps[], sources[]} — merged from research.json if available
+
+**perspectives.json** (multi — Layer 1 shared + per-perspective Layer 2-3 + research):
+- `shared_discovery`: {relevant_files[], patterns[], module_map}
+- `perspectives[]`: [{name, tool, findings, insights, questions, code_anchors[], call_chains[]}]
+- `external_research`: {findings[], best_practices[], codebase_gaps[], sources[]} — merged from research.json if available
+- `synthesis`: {convergent_themes, conflicting_views, unique_contributions}
+
+**conclusions.json**:
 - `session_id`, `topic`, `completed`, `total_rounds`, `summary`
 - `key_conclusions[]`: {point, evidence, confidence, code_anchor_refs[]}
 - `code_anchors[]`: {file, lines, snippet, significance}
@@ -510,9 +692,9 @@ ${implScope.map((item, i) => `${i+1}. **${item.objective}** [${item.priority}]
 - `decision_trail[]`: {round, decision, context, options_considered, chosen, rejected_reasons, reason, impact}
 - `narrative_trail[]`: {round, starting_point, key_progress, hypothesis_impact, updated_understanding, remaining_questions}
 - `intent_coverage[]`: {intent, status, where_addressed, notes}
-</step>
+- `findings_coverage[]`: {finding, round, disposition: recommendation|absorbed|deferred|informational, target, reason}
 
-</process>
+</schemas>
 
 <error_codes>
 
@@ -525,6 +707,8 @@ ${implScope.map((item, i) => `${i+1}. **${item.objective}** [${item.priority}]
 | E005 | error | No relevant findings from exploration — broaden search, ask user for clarification | cli_exploration |
 | E006 | warning | Session folder conflict — append timestamp suffix | session_init |
 | E007 | error | Gemini unavailable — fallback to Codex or manual analysis | cli_exploration |
+| E008 | warning | Research agent WebSearch failed — continue with codebase-only analysis, note limitation | cli_exploration |
+| E009 | warning | Research findings conflict with codebase patterns — flag as codebase_gaps for user review | cli_exploration |
 
 </error_codes>
 
@@ -534,13 +718,16 @@ ${implScope.map((item, i) => `${i+1}. **${item.objective}** [${item.priority}]
 - [ ] Dimensions identified and user preferences captured (Phase 1)
 - [ ] discussion.md initialized with TOC, Current Understanding, metadata
 - [ ] Codebase exploration completed with code_anchors and call_chains (Phase 2)
+- [ ] External research executed if topic warrants it (architecture/comparison/decision/performance/security dimensions)
+- [ ] Research findings merged into explorations/perspectives with codebase_gaps flagged
 - [ ] CLI analysis executed and findings aggregated
 - [ ] Initial Intent Coverage Check appended to discussion.md
 - [ ] Interactive discussion rounds documented with narrative synthesis (Phase 3)
 - [ ] Intent Drift Check performed each round >= 2
 - [ ] All decisions recorded per Decision Recording Protocol
 - [ ] Intent Coverage Matrix verified in Phase 4
-- [ ] conclusions.json created with key_conclusions, recommendations, decision_trail
+- [ ] Findings Coverage Matrix completed — all actionable findings mapped to disposition (recommendation/absorbed/deferred/informational)
+- [ ] conclusions.json created with key_conclusions, recommendations, decision_trail, findings_coverage
 - [ ] discussion.md finalized with conclusions, Decision Trail, session statistics
 - [ ] Recommendation review completed (non-auto mode)
 - [ ] Next Step terminal gate executed — `next-step` todo is `"completed"`
@@ -557,7 +744,7 @@ ${implScope.map((item, i) => `${i+1}. **${item.objective}** [${item.priority}]
 | **Business** | Codex | Value, ROI, stakeholder impact | Business implications |
 | **Domain Expert** | Gemini | Domain patterns, best practices, standards | Industry knowledge |
 
-User multi-selects up to 4 in Phase 1, default: single comprehensive view.
+User multi-selects up to 4 in Phase 1. Default: if dimensions >= 2, pre-select Technical + Architectural; if dimensions == 1, single comprehensive view.
 
 ### Dimension-Direction Mapping
 
@@ -596,9 +783,6 @@ Present 2-3 top directions per dimension, allow multi-select + custom.
 | Preserve key learnings | Keep insights valuable for future reference |
 
 </configuration>
-
-> **Lite-plan handoff**: Phase 4「执行任务」builds structured `handoff-spec` JSON (implementation_scope with acceptance_criteria, code_anchors, key_findings) embedded in `## Prior Analysis` block. lite-plan parses `json:handoff-spec` to directly map scope items → tasks, skipping exploration and using acceptance_criteria as convergence.criteria.
-
 ---
 
 **Now execute analyze-with-file for**: $ARGUMENTS

.claude/commands/workflow/spec/setup.md

@@ -129,7 +129,7 @@ Task(
 Analyze project for workflow initialization and generate .workflow/project-tech.json.
 
 ## MANDATORY FIRST STEPS
-1. Execute: cat ~/.ccw/workflows/cli-templates/schemas/project-tech-schema.json (get schema reference)
+1. Execute: ccw tool exec json_builder '{"cmd":"info","schema":"tech"}' (get schema summary)
 2. Execute: ccw tool exec get_modules_by_depth '{}' (get project structure)
 
 ## Task

.claude/skills/brainstorm/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: brainstorm
-description: Unified brainstorming skill with dual-mode operation - auto pipeline and single role analysis. Triggers on "brainstorm", "头脑风暴".
+description: Unified brainstorming skill with dual-mode operation — auto mode (framework generation, parallel multi-role analysis, cross-role synthesis) and single role analysis. Triggers on "brainstorm", "头脑风暴".
 allowed-tools: Skill(*), Agent(conceptual-planning-agent, context-search-agent), AskUserQuestion(*), TodoWrite(*), Read(*), Write(*), Edit(*), Glob(*), Bash(*)
 ---
 

.claude/skills/review-code/SKILL.md

@@ -40,6 +40,8 @@ Multi-dimensional code review skill that analyzes code across 6 key dimensions a
 └─────────────────────────────────────────────────────────────────┘
 ```
 
+**Project Context**: Run `ccw spec load --category review` for review standards, checklists, and approval gates.
+
 ## Key Design Principles
 
 1. **多维度审查**: 覆盖正确性、可读性、性能、安全性、测试覆盖、架构一致性六大维度

.claude/skills/review-cycle/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: review-cycle
-description: Unified multi-dimensional code review with automated fix orchestration. Routes to session-based (git changes), module-based (path patterns), or fix mode. Triggers on "workflow:review-cycle", "workflow:review-session-cycle", "workflow:review-module-cycle", "workflow:review-cycle-fix".
+description: "Unified multi-dimensional code review with automated fix orchestration. Routes to session-based (git changes), module-based (path patterns), or fix mode. Triggers on \"workflow:review-cycle\", \"workflow:review-session-cycle\", \"workflow:review-module-cycle\", \"workflow:review-cycle-fix\"."
 allowed-tools: Agent, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, Read, Write, Edit, Bash, Glob, Grep, Skill
 ---
 
@@ -98,6 +98,10 @@ Skill(skill="review-cycle", args="-y src/auth/**")
 | module | [phases/review-module.md](phases/review-module.md) | review-module-cycle.md | Module-based review: path patterns → 7-dimension parallel analysis → aggregation → deep-dive → completion |
 | fix | [phases/review-fix.md](phases/review-fix.md) | review-cycle-fix.md | Automated fix: export file → intelligent batching → parallel planning → execution → completion |
 
+## Project Context
+
+Run `ccw spec load --category review` for review standards, checklists, and approval gates.
+
 ## Core Rules
 
 1. **Mode Detection First**: Parse input to determine session/module/fix mode before anything else

.claude/skills/review-cycle/phases/review-module.md

@@ -401,7 +401,7 @@ Task(
     1. Read review state: ${reviewStateJsonPath}
     2. Get target files: Read resolved_files from review-state.json
     3. Validate file access: bash(ls -la ${targetFiles.join(' ')})
-    4. Execute: cat ~/.ccw/workflows/cli-templates/schemas/review-dimension-results-schema.json (get output schema reference)
+    4. Execute: ccw tool exec json_builder '{"cmd":"info","schema":"review-dim"}' (get output schema summary)
     5. Read: .workflow/project-tech.json (technology stack and architecture context)
     6. Read: .workflow/specs/*.md (user-defined constraints and conventions to validate against)
 
@@ -456,7 +456,7 @@ Task(
     ${getDimensionGuidance(dimension)}
 
     ## Success Criteria
-    - [ ] Schema obtained via cat review-dimension-results-schema.json
+    - [ ] Schema obtained via json_builder info
     - [ ] All target files analyzed for ${dimension} concerns
     - [ ] All findings include file:line references with code snippets
     - [ ] Severity assessment follows established criteria (see reference)
@@ -505,7 +505,7 @@ Task(
     2. Read affected file: ${file}
     3. Identify related code: bash(grep -r "import.*${basename(file)}" ${projectDir}/src --include="*.ts")
     4. Read test files: bash(find ${projectDir}/tests -name "*${basename(file, '.ts')}*" -type f)
-    5. Execute: cat ~/.ccw/workflows/cli-templates/schemas/review-deep-dive-results-schema.json (get output schema reference)
+    5. Execute: ccw tool exec json_builder '{"cmd":"info","schema":"review-deep"}' (get output schema summary)
     6. Read: .workflow/project-tech.json (technology stack and architecture context)
     7. Read: .workflow/specs/*.md (user-defined constraints for remediation compliance)
 
@@ -538,7 +538,7 @@ Task(
        - Impact assessment and rollback strategy
 
     ## Success Criteria
-    - [ ] Schema obtained via cat review-deep-dive-results-schema.json
+    - [ ] Schema obtained via json_builder info
     - [ ] Root cause clearly identified with supporting evidence
     - [ ] Remediation plan is step-by-step actionable with exact file:line references
     - [ ] Each step includes specific commands and validation tests

.claude/skills/review-cycle/phases/review-session.md

@@ -412,7 +412,7 @@ Task(
     2. Read completed task summaries: bash(find ${summariesDir} -name "IMPL-*.md" -type f)
     3. Get changed files: bash(cd ${workflowDir} && git log --since="${sessionCreatedAt}" --name-only --pretty=format: | sort -u)
     4. Read review state: ${reviewStateJsonPath}
-    5. Execute: cat ~/.ccw/workflows/cli-templates/schemas/review-dimension-results-schema.json (get output schema reference)
+    5. Execute: ccw tool exec json_builder '{"cmd":"info","schema":"review-dim"}' (get output schema summary)
     6. Read: .workflow/project-tech.json (technology stack and architecture context)
     7. Read: .workflow/specs/*.md (user-defined constraints and conventions to validate against)
 
@@ -467,7 +467,7 @@ Task(
     ${getDimensionGuidance(dimension)}
 
     ## Success Criteria
-    - [ ] Schema obtained via cat review-dimension-results-schema.json
+    - [ ] Schema obtained via json_builder info
     - [ ] All changed files analyzed for ${dimension} concerns
     - [ ] All findings include file:line references with code snippets
     - [ ] Severity assessment follows established criteria (see reference)
@@ -516,7 +516,7 @@ Task(
     2. Read affected file: ${file}
     3. Identify related code: bash(grep -r "import.*${basename(file)}" ${workflowDir}/src --include="*.ts")
     4. Read test files: bash(find ${workflowDir}/tests -name "*${basename(file, '.ts')}*" -type f)
-    5. Execute: cat ~/.ccw/workflows/cli-templates/schemas/review-deep-dive-results-schema.json (get output schema reference)
+    5. Execute: ccw tool exec json_builder '{"cmd":"info","schema":"review-deep"}' (get output schema summary)
     6. Read: .workflow/project-tech.json (technology stack and architecture context)
     7. Read: .workflow/specs/*.md (user-defined constraints for remediation compliance)
 
@@ -550,7 +550,7 @@ Task(
        - Impact assessment and rollback strategy
 
     ## Success Criteria
-    - [ ] Schema obtained via cat review-deep-dive-results-schema.json
+    - [ ] Schema obtained via json_builder info
     - [ ] Root cause clearly identified with supporting evidence
     - [ ] Remediation plan is step-by-step actionable with exact file:line references
     - [ ] Each step includes specific commands and validation tests

.claude/skills/skill-simplify/phases/02-optimize.md

@@ -9,6 +9,10 @@ Apply simplification rules from analysisResult to produce optimized content. Wri
 - Fix pseudo-code format issues
 - Write optimized content back to target file
 
+## Pre-Step: Load Context
+
+Run `ccw spec load --category validation` for verification rules and acceptance criteria to validate optimization preserves functional integrity.
+
 ## Execution
 
 ### Step 2.1: Apply Operations in Order

.claude/skills/spec-generator/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: spec-generator
-description: Specification generator - 6 phase document chain producing product brief, PRD, architecture, and epics. Triggers on "generate spec", "create specification", "spec generator", "workflow:spec".
+description: "Specification generator - 7 phase document chain producing product brief, PRD, architecture, epics, and issues with Codex review gates. Triggers on generate spec, create specification, spec generator, workflow:spec."
 allowed-tools: Agent, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, Read, Write, Edit, Bash, Glob, Grep, Skill
 ---
 

.claude/skills/spec-generator/phases/05-epics-stories.md

@@ -19,6 +19,10 @@ Decompose the specification into executable Epics and Stories with dependency ma
 
 ## Execution Steps
 
+### Step 0: Load Validation Context
+
+Run `ccw spec load --category validation` for verification rules and acceptance criteria to validate epic decomposition.
+
 ### Step 1: Load Phase 2-4 Context
 
 ```javascript

.claude/skills/team-arch-opt/specs/team-config.json

@@ -23,7 +23,7 @@
       "name": "analyzer",
       "type": "orchestration",
       "description": "Analyzes architecture: dependency graphs, coupling/cohesion, layering violations, God Classes, dead code",
-      "role_spec": "role-specs/analyzer.md",
+      "role_spec": "roles/analyzer/role.md",
       "inner_loop": false,
       "frontmatter": {
         "prefix": "ANALYZE",
@@ -43,7 +43,7 @@
       "name": "designer",
       "type": "orchestration",
       "description": "Designs refactoring strategies from architecture analysis, produces prioritized refactoring plan with discrete REFACTOR-IDs",
-      "role_spec": "role-specs/designer.md",
+      "role_spec": "roles/designer/role.md",
       "inner_loop": false,
       "frontmatter": {
         "prefix": "DESIGN",
@@ -63,7 +63,7 @@
       "name": "refactorer",
       "type": "code_generation",
       "description": "Implements architecture refactoring changes following the design plan",
-      "role_spec": "role-specs/refactorer.md",
+      "role_spec": "roles/refactorer/role.md",
       "inner_loop": true,
       "frontmatter": {
         "prefix": "REFACTOR",
@@ -84,7 +84,7 @@
       "name": "validator",
       "type": "validation",
       "description": "Validates refactoring: build checks, test suites, dependency metrics, API compatibility",
-      "role_spec": "role-specs/validator.md",
+      "role_spec": "roles/validator/role.md",
       "inner_loop": false,
       "frontmatter": {
         "prefix": "VALIDATE",
@@ -105,7 +105,7 @@
       "name": "reviewer",
       "type": "read_only_analysis",
       "description": "Reviews refactoring code for correctness, pattern consistency, completeness, migration safety, and best practices",
-      "role_spec": "role-specs/reviewer.md",
+      "role_spec": "roles/reviewer/role.md",
       "inner_loop": false,
       "frontmatter": {
         "prefix": "REVIEW",

.claude/skills/team-designer/phases/02-scaffold-generation.md

@@ -37,7 +37,7 @@ The SKILL.md follows a strict template. Every generated SKILL.md contains these
 ```yaml
 ---
 name: ${teamConfig.skillName}
-description: ${teamConfig.domain}. Triggers on "${teamConfig.skillName}".
+description: "${teamConfig.domain}. Triggers on ${teamConfig.skillName}."
 allowed-tools: TeamCreate(*), TeamDelete(*), SendMessage(*), TaskCreate(*), TaskUpdate(*), TaskList(*), TaskGet(*), Agent(*), AskUserQuestion(*), Read(*), Write(*), Edit(*), Bash(*), Glob(*), Grep(*)
 ---
 ```

.claude/skills/team-frontend-debug/roles/analyzer/role.md

@@ -31,8 +31,9 @@ Root cause analysis from debug evidence.
 
 ## Phase 2: Load Evidence
 
-1. Read upstream artifacts via team_msg(operation="get_state", role="reproducer")
-2. Extract evidence paths from reproducer's state_update ref
+1. Load debug specs: Run `ccw spec load --category debug` for known issues, workarounds, and root-cause notes
+2. Read upstream artifacts via team_msg(operation="get_state", role="reproducer")
+3. Extract evidence paths from reproducer's state_update ref
 3. Load evidence-summary.json from session evidence/
 4. Load all evidence files:
    - Read screenshot files (visual inspection)

.claude/skills/team-iterdev/SKILL.md

@@ -1,127 +0,0 @@
----
-name: team-iterdev
-description: Unified team skill for iterative development team. Pure router — all roles read this file. Beat model is coordinator-only in monitor.md. Generator-Critic loops (developer<->reviewer, max 3 rounds). Triggers on "team iterdev".
-allowed-tools: TeamCreate(*), TeamDelete(*), SendMessage(*), TaskCreate(*), TaskUpdate(*), TaskList(*), TaskGet(*), Agent(*), AskUserQuestion(*), Read(*), Write(*), Edit(*), Bash(*), Glob(*), Grep(*)
----
-
-# Team IterDev
-
-Iterative development team skill. Generator-Critic loops (developer<->reviewer, max 3 rounds), task ledger (task-ledger.json) for real-time progress, shared memory (cross-sprint learning), and dynamic pipeline selection for incremental delivery.
-
-## Architecture
-
-```
-Skill(skill="team-iterdev", args="task description")
-                    |
-         SKILL.md (this file) = Router
-                    |
-     +--------------+--------------+
-     |                             |
-  no --role flag              --role <name>
-     |                             |
-  Coordinator                  Worker
-  roles/coordinator/role.md    roles/<name>/role.md
-     |
-     +-- analyze -> dispatch -> spawn workers -> STOP
-                                    |
-                    +-------+-------+-------+
-                    v       v       v       v
-               [architect] [developer] [tester] [reviewer]
-              (team-worker agents, each loads roles/<role>/role.md)
-```
-
-## Role Registry
-
-| Role | Path | Prefix | Inner Loop |
-|------|------|--------|------------|
-| coordinator | [roles/coordinator/role.md](roles/coordinator/role.md) | — | — |
-| architect | [roles/architect/role.md](roles/architect/role.md) | DESIGN-* | false |
-| developer | [roles/developer/role.md](roles/developer/role.md) | DEV-* | true |
-| tester | [roles/tester/role.md](roles/tester/role.md) | VERIFY-* | false |
-| reviewer | [roles/reviewer/role.md](roles/reviewer/role.md) | REVIEW-* | false |
-
-## Role Router
-
-Parse `$ARGUMENTS`:
-- Has `--role <name>` → Read `roles/<name>/role.md`, execute Phase 2-4
-- No `--role` → `@roles/coordinator/role.md`, execute entry router
-
-## Shared Constants
-
-- **Session prefix**: `IDS`
-- **Session path**: `.workflow/.team/IDS-<slug>-<date>/`
-- **CLI tools**: `ccw cli --mode analysis` (read-only), `ccw cli --mode write` (modifications)
-- **Message bus**: `mcp__ccw-tools__team_msg(session_id=<session-id>, ...)`
-
-## Worker Spawn Template
-
-Coordinator spawns workers using this template:
-
-```
-Agent({
-  subagent_type: "team-worker",
-  description: "Spawn <role> worker",
-  team_name: "iterdev",
-  name: "<role>",
-  run_in_background: true,
-  prompt: `## Role Assignment
-role: <role>
-role_spec: <skill_root>/roles/<role>/role.md
-session: <session-folder>
-session_id: <session-id>
-team_name: iterdev
-requirement: <task-description>
-inner_loop: <true|false>
-
-Read role_spec file (@<skill_root>/roles/<role>/role.md) to load Phase 2-4 domain instructions.
-Execute built-in Phase 1 (task discovery) -> role Phase 2-4 -> built-in Phase 5 (report).`
-})
-```
-
-## User Commands
-
-| Command | Action |
-|---------|--------|
-| `check` / `status` | View execution status graph |
-| `resume` / `continue` | Advance to next step |
-
-## Session Directory
-
-```
-.workflow/.team/IDS-<slug>-<YYYY-MM-DD>/
-├── .msg/
-│   ├── messages.jsonl          # Team message bus
-│   └── meta.json               # Session state
-├── task-analysis.json          # Coordinator analyze output
-├── task-ledger.json            # Real-time task progress ledger
-├── wisdom/                     # Cross-task knowledge accumulation
-│   ├── learnings.md
-│   ├── decisions.md
-│   ├── conventions.md
-│   └── issues.md
-├── design/                     # Architect output
-│   ├── design-001.md
-│   └── task-breakdown.json
-├── code/                       # Developer tracking
-│   └── dev-log.md
-├── verify/                     # Tester output
-│   └── verify-001.json
-└── review/                     # Reviewer output
-    └── review-001.md
-```
-
-## Specs Reference
-
-- [specs/pipelines.md](specs/pipelines.md) — Pipeline definitions and task registry
-
-## Error Handling
-
-| Scenario | Resolution |
-|----------|------------|
-| Unknown command | Error with available command list |
-| Role not found | Error with role registry |
-| GC loop exceeds 3 rounds | Accept with warning, record in shared memory |
-| Sprint velocity drops below 50% | Coordinator alerts user, suggests scope reduction |
-| Task ledger corrupted | Rebuild from TaskList state |
-| Conflict detected | Update conflict_info, notify coordinator, create DEV-fix task |
-| Pipeline deadlock | Check blockedBy chain, report blocking point |

.claude/skills/team-iterdev/role-specs/architect.md

@@ -1,64 +0,0 @@
----
-prefix: DESIGN
-inner_loop: false
-message_types:
-  success: design_ready
-  revision: design_revision
-  error: error
----
-
-# Architect
-
-Technical design, task decomposition, and architecture decision records for iterative development.
-
-## Phase 2: Context Loading + Codebase Exploration
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Task description | From task subject/description | Yes |
-| Session path | Extracted from task description | Yes |
-| .msg/meta.json | <session>/.msg/meta.json | No |
-| Wisdom files | <session>/wisdom/ | No |
-
-1. Extract session path and requirement from task description
-2. Read .msg/meta.json for shared context (architecture_decisions, implementation_context)
-3. Read wisdom files if available (learnings.md, decisions.md, conventions.md)
-4. Explore codebase for existing patterns, module structure, dependencies:
-   - Use mcp__ace-tool__search_context for semantic discovery
-   - Identify similar implementations and integration points
-
-## Phase 3: Technical Design + Task Decomposition
-
-**Design strategy selection**:
-
-| Condition | Strategy |
-|-----------|----------|
-| Single module change | Direct inline design |
-| Cross-module change | Multi-component design with integration points |
-| Large refactoring | Phased approach with milestones |
-
-**Outputs**:
-
-1. **Design Document** (`<session>/design/design-<num>.md`):
-   - Architecture decision: approach, rationale, alternatives
-   - Component design: responsibility, dependencies, files, complexity
-   - Task breakdown: files, estimated complexity, dependencies, acceptance criteria
-   - Integration points and risks with mitigations
-
-2. **Task Breakdown JSON** (`<session>/design/task-breakdown.json`):
-   - Array of tasks with id, title, files, complexity, dependencies, acceptance_criteria
-   - Execution order for developer to follow
-
-## Phase 4: Design Validation
-
-| Check | Method | Pass Criteria |
-|-------|--------|---------------|
-| Components defined | Verify component list | At least 1 component |
-| Task breakdown exists | Verify task list | At least 1 task |
-| Dependencies mapped | All components have dependencies field | All present (can be empty) |
-| Integration points | Verify integration section | Key integrations documented |
-
-1. Run validation checks above
-2. Write architecture_decisions entry to .msg/meta.json:
-   - design_id, approach, rationale, components, task_count
-3. Write discoveries to wisdom/decisions.md and wisdom/conventions.md

.claude/skills/team-iterdev/role-specs/developer.md

@@ -1,73 +0,0 @@
----
-prefix: DEV
-inner_loop: true
-message_types:
-  success: dev_complete
-  progress: dev_progress
-  error: error
----
-
-# Developer
-
-Code implementer. Implements code according to design, incremental delivery. Acts as Generator in Generator-Critic loop (paired with reviewer).
-
-## Phase 2: Context Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Task description | From task subject/description | Yes |
-| Session path | Extracted from task description | Yes |
-| .msg/meta.json | <session>/.msg/meta.json | Yes |
-| Design document | <session>/design/design-001.md | For non-fix tasks |
-| Task breakdown | <session>/design/task-breakdown.json | For non-fix tasks |
-| Review feedback | <session>/review/*.md | For fix tasks |
-| Wisdom files | <session>/wisdom/ | No |
-
-1. Extract session path from task description
-2. Read .msg/meta.json for shared context
-3. Detect task type:
-
-| Task Type | Detection | Loading |
-|-----------|-----------|---------|
-| Fix task | Subject contains "fix" | Read latest review file for feedback |
-| Normal task | No "fix" in subject | Read design document + task breakdown |
-
-4. Load previous implementation_context from .msg/meta.json
-5. Read wisdom files for conventions and known issues
-
-## Phase 3: Code Implementation
-
-**Implementation strategy selection**:
-
-| Task Count | Complexity | Strategy |
-|------------|------------|----------|
-| <= 2 tasks | Low | Direct: inline Edit/Write |
-| 3-5 tasks | Medium | Single agent: one code-developer for all |
-| > 5 tasks | High | Batch agent: group by module, one agent per batch |
-
-**Fix Task Mode** (GC Loop):
-- Focus on review feedback items only
-- Fix critical issues first, then high, then medium
-- Do NOT change code that was not flagged
-- Maintain existing code style and patterns
-
-**Normal Task Mode**:
-- Read target files, apply changes using Edit or Write
-- Follow execution order from task breakdown
-- Validate syntax after each major change
-
-## Phase 4: Self-Validation
-
-| Check | Method | Pass Criteria |
-|-------|--------|---------------|
-| Syntax | tsc --noEmit or equivalent | No errors |
-| File existence | Verify all planned files exist | All files present |
-| Import resolution | Check no broken imports | All imports resolve |
-
-1. Run syntax check: `tsc --noEmit` / `python -m py_compile` / equivalent
-2. Auto-fix if validation fails (max 2 attempts)
-3. Write dev log to `<session>/code/dev-log.md`:
-   - Changed files count, syntax status, fix task flag, file list
-4. Update implementation_context in .msg/meta.json:
-   - task, changed_files, is_fix, syntax_clean
-5. Write discoveries to wisdom/learnings.md

.claude/skills/team-iterdev/role-specs/reviewer.md

@@ -1,65 +0,0 @@
----
-prefix: REVIEW
-inner_loop: false
-message_types:
-  success: review_passed
-  revision: review_revision
-  critical: review_critical
-  error: error
----
-
-# Reviewer
-
-Code reviewer. Multi-dimensional review, quality scoring, improvement suggestions. Acts as Critic in Generator-Critic loop (paired with developer).
-
-## Phase 2: Context Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Task description | From task subject/description | Yes |
-| Session path | Extracted from task description | Yes |
-| .msg/meta.json | <session>/.msg/meta.json | Yes |
-| Design document | <session>/design/design-001.md | For requirements alignment |
-| Changed files | Git diff | Yes |
-
-1. Extract session path from task description
-2. Read .msg/meta.json for shared context and previous review_feedback_trends
-3. Read design document for requirements alignment
-4. Get changed files via git diff, read file contents (limit 20 files)
-
-## Phase 3: Multi-Dimensional Review
-
-**Review dimensions**:
-
-| Dimension | Weight | Focus Areas |
-|-----------|--------|-------------|
-| Correctness | 30% | Logic correctness, boundary handling |
-| Completeness | 25% | Coverage of design requirements |
-| Maintainability | 25% | Readability, code style, DRY |
-| Security | 20% | Vulnerabilities, input validation |
-
-Per-dimension: scan modified files, record findings with severity (CRITICAL/HIGH/MEDIUM/LOW), include file:line references and suggestions.
-
-**Scoring**: Weighted average of dimension scores (1-10 each).
-
-**Output review report** (`<session>/review/review-<num>.md`):
-- Files reviewed count, quality score, issue counts by severity
-- Per-finding: severity, file:line, dimension, description, suggestion
-- Scoring breakdown by dimension
-- Signal: CRITICAL / REVISION_NEEDED / APPROVED
-- Design alignment notes
-
-## Phase 4: Trend Analysis + Verdict
-
-1. Compare with previous review_feedback_trends from .msg/meta.json
-2. Identify recurring issues, improvement areas, new issues
-
-| Verdict Condition | Message Type |
-|-------------------|--------------|
-| criticalCount > 0 | review_critical |
-| score < 7 | review_revision |
-| else | review_passed |
-
-3. Update review_feedback_trends in .msg/meta.json:
-   - review_id, score, critical count, high count, dimensions, gc_round
-4. Write discoveries to wisdom/learnings.md

.claude/skills/team-iterdev/role-specs/tester.md

@@ -1,87 +0,0 @@
----
-prefix: VERIFY
-inner_loop: false
-message_types:
-  success: verify_passed
-  failure: verify_failed
-  fix: fix_required
-  error: error
----
-
-# Tester
-
-Test validator. Test execution, fix cycles, and regression detection.
-
-## Phase 2: Environment Detection
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Task description | From task subject/description | Yes |
-| Session path | Extracted from task description | Yes |
-| .msg/meta.json | <session>/.msg/meta.json | Yes |
-| Changed files | Git diff | Yes |
-
-1. Extract session path from task description
-2. Read .msg/meta.json for shared context
-3. Get changed files via git diff
-4. Detect test framework and command:
-
-| Detection | Method |
-|-----------|--------|
-| Test command | Check package.json scripts, pytest.ini, Makefile |
-| Coverage tool | Check for nyc, coverage.py, jest --coverage config |
-
-Common commands: npm test, pytest, go test ./..., cargo test
-
-## Phase 3: Execution + Fix Cycle
-
-**Iterative test-fix cycle** (max 5 iterations):
-
-| Step | Action |
-|------|--------|
-| 1 | Run test command |
-| 2 | Parse results, check pass rate |
-| 3 | Pass rate >= 95% -> exit loop (success) |
-| 4 | Extract failing test details |
-| 5 | Apply fix using CLI tool |
-| 6 | Increment iteration counter |
-| 7 | iteration >= MAX (5) -> exit loop (report failures) |
-| 8 | Go to Step 1 |
-
-**Fix delegation**: Use CLI tool to fix failing tests:
-
-```bash
-ccw cli -p "PURPOSE: Fix failing tests; success = all listed tests pass
-TASK: • Analyze test failure output • Identify root cause in changed files • Apply minimal fix
-MODE: write
-CONTEXT: @<changed-files> | Memory: Test output from current iteration
-EXPECTED: Code fixes that make failing tests pass without breaking other tests
-CONSTRAINTS: Only modify files in changed list | Minimal changes
-Test output: <test-failure-details>
-Changed files: <file-list>" --tool gemini --mode write --rule development-debug-runtime-issues
-```
-
-Wait for CLI completion before re-running tests.
-
-## Phase 4: Regression Check + Report
-
-1. Run full test suite for regression: `<test-command> --all`
-
-| Check | Method | Pass Criteria |
-|-------|--------|---------------|
-| Regression | Run full test suite | No FAIL in output |
-| Coverage | Run coverage tool | >= 80% (if configured) |
-
-2. Write verification results to `<session>/verify/verify-<num>.json`:
-   - verify_id, pass_rate, iterations, passed, timestamp, regression_passed
-
-3. Determine message type:
-
-| Condition | Message Type |
-|-----------|--------------|
-| passRate >= 0.95 | verify_passed |
-| passRate < 0.95 && iterations >= MAX | fix_required |
-| passRate < 0.95 | verify_failed |
-
-4. Update .msg/meta.json with test_patterns entry
-5. Write discoveries to wisdom/issues.md

.claude/skills/team-iterdev/roles/architect/role.md

@@ -1,65 +0,0 @@
----
-role: architect
-prefix: DESIGN
-inner_loop: false
-message_types:
-  success: design_ready
-  revision: design_revision
-  error: error
----
-
-# Architect
-
-Technical design, task decomposition, and architecture decision records for iterative development.
-
-## Phase 2: Context Loading + Codebase Exploration
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Task description | From task subject/description | Yes |
-| Session path | Extracted from task description | Yes |
-| .msg/meta.json | <session>/.msg/meta.json | No |
-| Wisdom files | <session>/wisdom/ | No |
-
-1. Extract session path and requirement from task description
-2. Read .msg/meta.json for shared context (architecture_decisions, implementation_context)
-3. Read wisdom files if available (learnings.md, decisions.md, conventions.md)
-4. Explore codebase for existing patterns, module structure, dependencies:
-   - Use mcp__ace-tool__search_context for semantic discovery
-   - Identify similar implementations and integration points
-
-## Phase 3: Technical Design + Task Decomposition
-
-**Design strategy selection**:
-
-| Condition | Strategy |
-|-----------|----------|
-| Single module change | Direct inline design |
-| Cross-module change | Multi-component design with integration points |
-| Large refactoring | Phased approach with milestones |
-
-**Outputs**:
-
-1. **Design Document** (`<session>/design/design-<num>.md`):
-   - Architecture decision: approach, rationale, alternatives
-   - Component design: responsibility, dependencies, files, complexity
-   - Task breakdown: files, estimated complexity, dependencies, acceptance criteria
-   - Integration points and risks with mitigations
-
-2. **Task Breakdown JSON** (`<session>/design/task-breakdown.json`):
-   - Array of tasks with id, title, files, complexity, dependencies, acceptance_criteria
-   - Execution order for developer to follow
-
-## Phase 4: Design Validation
-
-| Check | Method | Pass Criteria |
-|-------|--------|---------------|
-| Components defined | Verify component list | At least 1 component |
-| Task breakdown exists | Verify task list | At least 1 task |
-| Dependencies mapped | All components have dependencies field | All present (can be empty) |
-| Integration points | Verify integration section | Key integrations documented |
-
-1. Run validation checks above
-2. Write architecture_decisions entry to .msg/meta.json:
-   - design_id, approach, rationale, components, task_count
-3. Write discoveries to wisdom/decisions.md and wisdom/conventions.md

.claude/skills/team-iterdev/roles/coordinator/commands/analyze.md

@@ -1,62 +0,0 @@
-# Analyze Task
-
-Parse iterative development task -> detect capabilities -> assess pipeline complexity -> design roles.
-
-**CONSTRAINT**: Text-level analysis only. NO source code reading, NO codebase exploration.
-
-## Signal Detection
-
-| Keywords | Capability | Role |
-|----------|------------|------|
-| design, architect, restructure, refactor plan | architect | architect |
-| implement, build, code, fix, develop | developer | developer |
-| test, verify, validate, coverage | tester | tester |
-| review, audit, quality, check | reviewer | reviewer |
-
-## Pipeline Selection
-
-| Signal | Score |
-|--------|-------|
-| Changed files > 10 | +3 |
-| Changed files 3-10 | +2 |
-| Structural change (refactor, architect, restructure) | +3 |
-| Cross-cutting (multiple, across, cross) | +2 |
-| Simple fix (fix, bug, typo, patch) | -2 |
-
-| Score | Pipeline |
-|-------|----------|
-| >= 5 | multi-sprint |
-| 2-4 | sprint |
-| 0-1 | patch |
-
-## Dependency Graph
-
-Natural ordering tiers:
-- Tier 0: architect (design must come first)
-- Tier 1: developer (implementation requires design)
-- Tier 2: tester, reviewer (validation requires artifacts, can run parallel)
-
-## Complexity Assessment
-
-| Factor | Points |
-|--------|--------|
-| Cross-module changes | +2 |
-| Serial depth > 3 | +1 |
-| Multiple developers needed | +2 |
-| GC loop likely needed | +1 |
-
-## Output
-
-Write <session>/task-analysis.json:
-```json
-{
-  "task_description": "<original>",
-  "pipeline_type": "<patch|sprint|multi-sprint>",
-  "capabilities": [{ "name": "<cap>", "role": "<role>", "keywords": ["..."] }],
-  "roles": [{ "name": "<role>", "prefix": "<PREFIX>", "inner_loop": false }],
-  "complexity": { "score": 0, "level": "Low|Medium|High" },
-  "needs_architecture": true,
-  "needs_testing": true,
-  "needs_review": true
-}
-```

.claude/skills/team-iterdev/roles/coordinator/commands/dispatch.md

@@ -1,234 +0,0 @@
-# Command: Dispatch
-
-Create the iterative development task chain with correct dependencies and structured task descriptions.
-
-## Phase 2: Context Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| User requirement | From coordinator Phase 1 | Yes |
-| Session folder | From coordinator Phase 2 | Yes |
-| Pipeline definition | From SKILL.md Pipeline Definitions | Yes |
-| Pipeline mode | From session.json `pipeline` | Yes |
-
-1. Load user requirement and scope from session.json
-2. Load pipeline stage definitions from SKILL.md Task Metadata Registry
-3. Read `pipeline` mode from session.json (patch / sprint / multi-sprint)
-
-## Phase 3: Task Chain Creation
-
-### Task Description Template
-
-Every task description uses structured format for clarity:
-
-```
-TaskCreate({
-  subject: "<TASK-ID>",
-  description: "PURPOSE: <what this task achieves> | Success: <measurable completion criteria>
-TASK:
-  - <step 1: specific action>
-  - <step 2: specific action>
-  - <step 3: specific action>
-CONTEXT:
-  - Session: <session-folder>
-  - Scope: <task-scope>
-  - Upstream artifacts: <artifact-1>, <artifact-2>
-  - Shared memory: <session>/.msg/meta.json
-EXPECTED: <deliverable path> + <quality criteria>
-CONSTRAINTS: <scope limits, focus areas>
----
-InnerLoop: <true|false>"
-})
-TaskUpdate({ taskId: "<TASK-ID>", addBlockedBy: [<dependency-list>], owner: "<role>" })
-```
-
-### Mode Router
-
-| Mode | Action |
-|------|--------|
-| `patch` | Create DEV-001 + VERIFY-001 |
-| `sprint` | Create DESIGN-001 + DEV-001 + VERIFY-001 + REVIEW-001 |
-| `multi-sprint` | Create Sprint 1 chain, subsequent sprints created dynamically |
-
----
-
-### Patch Pipeline
-
-**DEV-001** (developer):
-```
-TaskCreate({
-  subject: "DEV-001",
-  description: "PURPOSE: Implement fix | Success: Fix applied, syntax clean
-TASK:
-  - Load target files and understand context
-  - Apply fix changes
-  - Validate syntax
-CONTEXT:
-  - Session: <session-folder>
-  - Scope: <task-scope>
-  - Shared memory: <session>/.msg/meta.json
-EXPECTED: Modified source files + <session>/code/dev-log.md | Syntax clean
-CONSTRAINTS: Minimal changes | Preserve existing behavior
----
-InnerLoop: true"
-})
-TaskUpdate({ taskId: "DEV-001", owner: "developer" })
-```
-
-**VERIFY-001** (tester):
-```
-TaskCreate({
-  subject: "VERIFY-001",
-  description: "PURPOSE: Verify fix correctness | Success: Tests pass, no regressions
-TASK:
-  - Detect test framework
-  - Run targeted tests for changed files
-  - Run regression test suite
-CONTEXT:
-  - Session: <session-folder>
-  - Scope: <task-scope>
-  - Upstream artifacts: code/dev-log.md
-  - Shared memory: <session>/.msg/meta.json
-EXPECTED: <session>/verify/verify-001.json | Pass rate >= 95%
-CONSTRAINTS: Focus on changed files | Report any regressions
----
-InnerLoop: false"
-})
-TaskUpdate({ taskId: "VERIFY-001", addBlockedBy: ["DEV-001"], owner: "tester" })
-```
-
----
-
-### Sprint Pipeline
-
-**DESIGN-001** (architect):
-```
-TaskCreate({
-  subject: "DESIGN-001",
-  description: "PURPOSE: Technical design and task breakdown | Success: Design document + task breakdown ready
-TASK:
-  - Explore codebase for patterns and dependencies
-  - Create component design with integration points
-  - Break down into implementable tasks with acceptance criteria
-CONTEXT:
-  - Session: <session-folder>
-  - Scope: <task-scope>
-  - Shared memory: <session>/.msg/meta.json
-EXPECTED: <session>/design/design-001.md + <session>/design/task-breakdown.json | Components defined, tasks actionable
-CONSTRAINTS: Focus on <task-scope> | Risk assessment required
----
-InnerLoop: false"
-})
-TaskUpdate({ taskId: "DESIGN-001", owner: "architect" })
-```
-
-**DEV-001** (developer):
-```
-TaskCreate({
-  subject: "DEV-001",
-  description: "PURPOSE: Implement design | Success: All design tasks implemented, syntax clean
-TASK:
-  - Load design and task breakdown
-  - Implement tasks in execution order
-  - Validate syntax after changes
-CONTEXT:
-  - Session: <session-folder>
-  - Scope: <task-scope>
-  - Upstream artifacts: design/design-001.md, design/task-breakdown.json
-  - Shared memory: <session>/.msg/meta.json
-EXPECTED: Modified source files + <session>/code/dev-log.md | Syntax clean, all tasks done
-CONSTRAINTS: Follow design | Preserve existing behavior | Follow code conventions
----
-InnerLoop: true"
-})
-TaskUpdate({ taskId: "DEV-001", addBlockedBy: ["DESIGN-001"], owner: "developer" })
-```
-
-**VERIFY-001** (tester, parallel with REVIEW-001):
-```
-TaskCreate({
-  subject: "VERIFY-001",
-  description: "PURPOSE: Verify implementation | Success: Tests pass, no regressions
-TASK:
-  - Detect test framework
-  - Run tests for changed files
-  - Run regression test suite
-CONTEXT:
-  - Session: <session-folder>
-  - Scope: <task-scope>
-  - Upstream artifacts: code/dev-log.md
-  - Shared memory: <session>/.msg/meta.json
-EXPECTED: <session>/verify/verify-001.json | Pass rate >= 95%
-CONSTRAINTS: Focus on changed files | Report regressions
----
-InnerLoop: false"
-})
-TaskUpdate({ taskId: "VERIFY-001", addBlockedBy: ["DEV-001"], owner: "tester" })
-```
-
-**REVIEW-001** (reviewer, parallel with VERIFY-001):
-```
-TaskCreate({
-  subject: "REVIEW-001",
-  description: "PURPOSE: Code review for correctness and quality | Success: All dimensions reviewed, verdict issued
-TASK:
-  - Load changed files and design document
-  - Review across 4 dimensions: correctness, completeness, maintainability, security
-  - Score quality (1-10) and issue verdict
-CONTEXT:
-  - Session: <session-folder>
-  - Scope: <task-scope>
-  - Upstream artifacts: design/design-001.md, code/dev-log.md
-  - Shared memory: <session>/.msg/meta.json
-EXPECTED: <session>/review/review-001.md | Per-dimension findings with severity
-CONSTRAINTS: Focus on implementation changes | Provide file:line references
----
-InnerLoop: false"
-})
-TaskUpdate({ taskId: "REVIEW-001", addBlockedBy: ["DEV-001"], owner: "reviewer" })
-```
-
----
-
-### Multi-Sprint Pipeline
-
-Sprint 1: DESIGN-001 -> DEV-001 -> DEV-002(incremental) -> VERIFY-001 -> DEV-fix -> REVIEW-001
-
-Create Sprint 1 tasks using sprint templates above, plus:
-
-**DEV-002** (developer, incremental):
-```
-TaskCreate({
-  subject: "DEV-002",
-  description: "PURPOSE: Incremental implementation | Success: Remaining tasks implemented
-TASK:
-  - Load remaining tasks from breakdown
-  - Implement incrementally
-  - Validate syntax
-CONTEXT:
-  - Session: <session-folder>
-  - Scope: <task-scope>
-  - Upstream artifacts: design/task-breakdown.json, code/dev-log.md
-  - Shared memory: <session>/.msg/meta.json
-EXPECTED: Modified source files + updated dev-log.md
-CONSTRAINTS: Incremental delivery | Follow existing patterns
----
-InnerLoop: true"
-})
-TaskUpdate({ taskId: "DEV-002", addBlockedBy: ["DEV-001"], owner: "developer" })
-```
-
-Subsequent sprints created dynamically after Sprint N completes.
-
-## Phase 4: Validation
-
-Verify task chain integrity:
-
-| Check | Method | Expected |
-|-------|--------|----------|
-| Task count correct | TaskList count | patch: 2, sprint: 4, multi: 5+ |
-| Dependencies correct | Trace addBlockedBy graph | Acyclic, correct ordering |
-| No circular dependencies | Trace full graph | Acyclic |
-| Structured descriptions | Each has PURPOSE/TASK/CONTEXT/EXPECTED | All present |
-
-If validation fails, fix the specific task and re-validate.

.claude/skills/team-iterdev/roles/coordinator/commands/monitor.md

@@ -1,182 +0,0 @@
-# Command: Monitor
-
-Event-driven pipeline coordination. Beat model: coordinator wake -> process -> spawn -> STOP.
-
-## Constants
-
-- SPAWN_MODE: background
-- ONE_STEP_PER_INVOCATION: true
-- FAST_ADVANCE_AWARE: true
-- WORKER_AGENT: team-worker
-- MAX_GC_ROUNDS: 3
-
-## Handler Router
-
-| Source | Handler |
-|--------|---------|
-| Message contains [architect], [developer], [tester], [reviewer] | handleCallback |
-| "capability_gap" | handleAdapt |
-| "check" or "status" | handleCheck |
-| "resume" or "continue" | handleResume |
-| All tasks completed | handleComplete |
-| Default | handleSpawnNext |
-
-## Phase 2: Context Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Session state | <session>/session.json | Yes |
-| Task list | TaskList() | Yes |
-| Trigger event | From Entry Router detection | Yes |
-| Meta state | <session>/.msg/meta.json | Yes |
-| Task ledger | <session>/task-ledger.json | No |
-
-1. Load session.json for current state, pipeline mode, gc_round, max_gc_rounds
-2. Run TaskList() to get current task statuses
-3. Identify trigger event type from Entry Router
-
-## Phase 3: Event Handlers
-
-### handleCallback
-
-Triggered when a worker sends completion message.
-
-1. Parse message to identify role and task ID:
-
-| Message Pattern | Role Detection |
-|----------------|---------------|
-| `[architect]` or task ID `DESIGN-*` | architect |
-| `[developer]` or task ID `DEV-*` | developer |
-| `[tester]` or task ID `VERIFY-*` | tester |
-| `[reviewer]` or task ID `REVIEW-*` | reviewer |
-
-2. Mark task as completed:
-
-```
-TaskUpdate({ taskId: "<task-id>", status: "completed" })
-```
-
-3. Record completion in session state and update task-ledger.json metrics
-
-4. **Generator-Critic check** (when reviewer completes):
-   - If completed task is REVIEW-* AND pipeline is sprint or multi-sprint:
-   - Read review report for GC signal (critical_count, score)
-   - Read session.json for gc_round
-
-   | GC Signal | gc_round < max | Action |
-   |-----------|----------------|--------|
-   | review.critical_count > 0 OR review.score < 7 | Yes | Increment gc_round, create DEV-fix task blocked by this REVIEW, log `gc_loop_trigger` |
-   | review.critical_count > 0 OR review.score < 7 | No (>= max) | Force convergence, accept with warning, log to wisdom/issues.md |
-   | review.critical_count == 0 AND review.score >= 7 | - | Review passed, proceed to handleComplete check |
-
-   - Log team_msg with type "gc_loop_trigger" or "task_unblocked"
-
-5. Proceed to handleSpawnNext
-
-### handleSpawnNext
-
-Find and spawn the next ready tasks.
-
-1. Scan task list for tasks where:
-   - Status is "pending"
-   - All blockedBy tasks have status "completed"
-
-2. For each ready task, determine role from task prefix:
-
-| Task Prefix | Role | Inner Loop |
-|-------------|------|------------|
-| DESIGN-* | architect | false |
-| DEV-* | developer | true |
-| VERIFY-* | tester | false |
-| REVIEW-* | reviewer | false |
-
-3. Spawn team-worker:
-
-```
-Agent({
-  subagent_type: "team-worker",
-  description: "Spawn <role> worker for <task-id>",
-  team_name: "iterdev",
-  name: "<role>",
-  run_in_background: true,
-  prompt: `## Role Assignment
-role: <role>
-role_spec: ~  or <project>/.claude/skills/team-iterdev/roles/<role>/role.md
-session: <session-folder>
-session_id: <session-id>
-team_name: iterdev
-requirement: <task-description>
-inner_loop: <true|false>
-
-Read role_spec file to load Phase 2-4 domain instructions.
-Execute built-in Phase 1 -> role-spec Phase 2-4 -> built-in Phase 5.`
-})
-```
-
-4. **Parallel spawn rules**:
-
-| Pipeline | Scenario | Spawn Behavior |
-|----------|----------|---------------|
-| Patch | DEV -> VERIFY | One worker at a time |
-| Sprint | VERIFY + REVIEW both unblocked | Spawn BOTH in parallel |
-| Sprint | Other stages | One worker at a time |
-| Multi-Sprint | VERIFY + DEV-fix both unblocked | Spawn BOTH in parallel |
-| Multi-Sprint | Other stages | One worker at a time |
-
-5. STOP after spawning -- wait for next callback
-
-### handleCheck
-
-Output current pipeline status. Do NOT advance pipeline.
-
-```
-Pipeline Status (<pipeline-mode>):
-  [DONE]  DESIGN-001  (architect)   -> design/design-001.md
-  [DONE]  DEV-001     (developer)   -> code/dev-log.md
-  [RUN]   VERIFY-001  (tester)      -> verifying...
-  [RUN]   REVIEW-001  (reviewer)    -> reviewing...
-  [WAIT]  DEV-fix     (developer)   -> blocked by REVIEW-001
-
-GC Rounds: <gc_round>/<max_gc_rounds>
-Sprint: <sprint_id>
-Session: <session-id>
-```
-
-### handleResume
-
-Resume pipeline after user pause or interruption.
-
-1. Audit task list for inconsistencies:
-   - Tasks stuck in "in_progress" -> reset to "pending"
-   - Tasks with completed blockers but still "pending" -> include in spawn list
-2. Proceed to handleSpawnNext
-
-### handleComplete
-
-Triggered when all pipeline tasks are completed.
-
-**Completion check by mode**:
-
-| Mode | Completion Condition |
-|------|---------------------|
-| patch | DEV-001 + VERIFY-001 completed |
-| sprint | DESIGN-001 + DEV-001 + VERIFY-001 + REVIEW-001 (+ any GC tasks) completed |
-| multi-sprint | All sprint tasks (+ any GC tasks) completed |
-
-1. Verify all tasks completed via TaskList()
-2. If any tasks not completed, return to handleSpawnNext
-3. **Multi-sprint check**: If multi-sprint AND more sprints planned:
-   - Record sprint metrics to .msg/meta.json sprint_history
-   - Evaluate downgrade eligibility (velocity >= expected, review avg >= 8)
-   - Pause for user confirmation before Sprint N+1
-4. If all completed, transition to coordinator Phase 5 (Report + Completion Action)
-
-## Phase 4: State Persistence
-
-After every handler execution:
-
-1. Update session.json with current state (gc_round, last event, active tasks)
-2. Update task-ledger.json metrics (completed count, in_progress count, velocity)
-3. Update .msg/meta.json gc_round if changed
-4. Verify task list consistency
-5. STOP and wait for next event

.claude/skills/team-iterdev/roles/coordinator/role.md

@@ -1,153 +0,0 @@
-# Coordinator Role
-
-Orchestrate team-iterdev: analyze -> dispatch -> spawn -> monitor -> report.
-
-## Identity
-- Name: coordinator | Tag: [coordinator]
-- Responsibility: Analyze task -> Create team -> Dispatch tasks -> Monitor progress -> Report results
-
-## Boundaries
-
-### MUST
-- Use `team-worker` agent type for all worker spawns (NOT `general-purpose`)
-- Follow Command Execution Protocol for dispatch and monitor commands
-- Respect pipeline stage dependencies (blockedBy)
-- Stop after spawning workers -- wait for callbacks
-- Handle developer<->reviewer GC loop (max 3 rounds)
-- Maintain task-ledger.json for real-time progress
-- Execute completion action in Phase 5
-
-### MUST NOT
-- Implement domain logic (designing, coding, testing, reviewing) -- workers handle this
-- Spawn workers without creating tasks first
-- Write source code directly
-- Force-advance pipeline past failed review/validation
-- Modify task outputs (workers own their deliverables)
-
-## Command Execution Protocol
-
-When coordinator needs to execute a command:
-1. Read `commands/<command>.md`
-2. Follow the workflow defined in the command
-3. Commands are inline execution guides, NOT separate agents
-4. Execute synchronously, complete before proceeding
-
-## Entry Router
-
-| Detection | Condition | Handler |
-|-----------|-----------|---------|
-| Worker callback | Message contains [architect], [developer], [tester], [reviewer] | -> handleCallback (monitor.md) |
-| Status check | Args contain "check" or "status" | -> handleCheck (monitor.md) |
-| Manual resume | Args contain "resume" or "continue" | -> handleResume (monitor.md) |
-| Pipeline complete | All tasks completed | -> handleComplete (monitor.md) |
-| Interrupted session | Active/paused session in .workflow/.team/IDS-* | -> Phase 0 |
-| New session | None of above | -> Phase 1 |
-
-For callback/check/resume/complete: load @commands/monitor.md, execute handler, STOP.
-
-## Phase 0: Session Resume Check
-
-1. Scan `.workflow/.team/IDS-*/.msg/meta.json` for active/paused sessions
-2. No sessions -> Phase 1
-3. Single session -> reconcile (audit TaskList, reset in_progress->pending, rebuild team, kick first ready task)
-4. Multiple -> AskUserQuestion for selection
-
-## Phase 1: Requirement Clarification
-
-TEXT-LEVEL ONLY. No source code reading.
-
-1. Parse user task description from $ARGUMENTS
-2. Delegate to @commands/analyze.md
-3. Assess complexity for pipeline selection:
-
-| Signal | Weight |
-|--------|--------|
-| Changed files > 10 | +3 |
-| Changed files 3-10 | +2 |
-| Structural change (refactor, architect, restructure) | +3 |
-| Cross-cutting (multiple, across, cross) | +2 |
-| Simple fix (fix, bug, typo, patch) | -2 |
-
-| Score | Pipeline |
-|-------|----------|
-| >= 5 | multi-sprint |
-| 2-4 | sprint |
-| 0-1 | patch |
-
-4. Ask for missing parameters via AskUserQuestion (mode selection)
-5. Record requirement with scope, pipeline mode
-6. CRITICAL: Always proceed to Phase 2, never skip team workflow
-
-## Phase 2: Session & Team Setup
-
-1. Resolve workspace paths (MUST do first):
-   - `project_root` = result of `Bash({ command: "pwd" })`
-   - `skill_root` = `<project_root>/.claude/skills/team-iterdev`
-2. Generate session ID: `IDS-<slug>-<YYYY-MM-DD>`
-3. Create session folder structure:
-```
-mkdir -p .workflow/.team/<session-id>/{design,code,verify,review,wisdom}
-```
-4. Create team: `TeamCreate({ team_name: "iterdev" })`
-5. Read specs/pipelines.md -> select pipeline based on complexity
-6. Initialize wisdom directory (learnings.md, decisions.md, conventions.md, issues.md)
-7. Write session.json
-8. Initialize task-ledger.json
-9. Initialize meta.json with pipeline metadata:
-```typescript
-mcp__ccw-tools__team_msg({
-  operation: "log", session_id: "<id>", from: "coordinator",
-  type: "state_update", summary: "Session initialized",
-  data: {
-    pipeline_mode: "<patch|sprint|multi-sprint>",
-    pipeline_stages: ["architect", "developer", "tester", "reviewer"],
-    roles: ["coordinator", "architect", "developer", "tester", "reviewer"],
-    team_name: "iterdev"
-  }
-})
-```
-
-## Phase 3: Task Chain Creation
-
-Delegate to @commands/dispatch.md:
-1. Read specs/pipelines.md for selected pipeline task registry
-2. Create tasks via TaskCreate, then TaskUpdate with addBlockedBy
-3. Update task-ledger.json
-
-## Phase 4: Spawn-and-Stop
-
-Delegate to @commands/monitor.md#handleSpawnNext:
-1. Find ready tasks (pending + all addBlockedBy dependencies resolved)
-2. Spawn team-worker agents (see SKILL.md Spawn Template)
-3. Output status summary
-4. STOP
-
-## Phase 5: Report + Completion Action
-
-1. Load session state -> count completed tasks, calculate duration
-2. Record sprint learning to .msg/meta.json sprint_history
-3. List deliverables:
-
-| Deliverable | Path |
-|-------------|------|
-| Design Document | <session>/design/design-001.md |
-| Task Breakdown | <session>/design/task-breakdown.json |
-| Dev Log | <session>/code/dev-log.md |
-| Verification Results | <session>/verify/verify-001.json |
-| Review Report | <session>/review/review-001.md |
-
-4. Execute completion action per session.completion_action:
-   - interactive -> AskUserQuestion (Archive/Keep/Export)
-   - auto_archive -> Archive & Clean (status=completed, TeamDelete)
-   - auto_keep -> Keep Active (status=paused)
-
-## Error Handling
-
-| Error | Resolution |
-|-------|------------|
-| Task too vague | AskUserQuestion for clarification |
-| Session corruption | Attempt recovery, fallback to manual |
-| Worker crash | Reset task to pending, respawn |
-| GC loop exceeds 3 rounds | Accept with warning, record in shared memory |
-| Sprint velocity drops below 50% | Alert user, suggest scope reduction |
-| Task ledger corrupted | Rebuild from TaskList state |

.claude/skills/team-iterdev/roles/developer/role.md

@@ -1,74 +0,0 @@
----
-role: developer
-prefix: DEV
-inner_loop: true
-message_types:
-  success: dev_complete
-  progress: dev_progress
-  error: error
----
-
-# Developer
-
-Code implementer. Implements code according to design, incremental delivery. Acts as Generator in Generator-Critic loop (paired with reviewer).
-
-## Phase 2: Context Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Task description | From task subject/description | Yes |
-| Session path | Extracted from task description | Yes |
-| .msg/meta.json | <session>/.msg/meta.json | Yes |
-| Design document | <session>/design/design-001.md | For non-fix tasks |
-| Task breakdown | <session>/design/task-breakdown.json | For non-fix tasks |
-| Review feedback | <session>/review/*.md | For fix tasks |
-| Wisdom files | <session>/wisdom/ | No |
-
-1. Extract session path from task description
-2. Read .msg/meta.json for shared context
-3. Detect task type:
-
-| Task Type | Detection | Loading |
-|-----------|-----------|---------|
-| Fix task | Subject contains "fix" | Read latest review file for feedback |
-| Normal task | No "fix" in subject | Read design document + task breakdown |
-
-4. Load previous implementation_context from .msg/meta.json
-5. Read wisdom files for conventions and known issues
-
-## Phase 3: Code Implementation
-
-**Implementation strategy selection**:
-
-| Task Count | Complexity | Strategy |
-|------------|------------|----------|
-| <= 2 tasks | Low | Direct: inline Edit/Write |
-| 3-5 tasks | Medium | Single agent: one code-developer for all |
-| > 5 tasks | High | Batch agent: group by module, one agent per batch |
-
-**Fix Task Mode** (GC Loop):
-- Focus on review feedback items only
-- Fix critical issues first, then high, then medium
-- Do NOT change code that was not flagged
-- Maintain existing code style and patterns
-
-**Normal Task Mode**:
-- Read target files, apply changes using Edit or Write
-- Follow execution order from task breakdown
-- Validate syntax after each major change
-
-## Phase 4: Self-Validation
-
-| Check | Method | Pass Criteria |
-|-------|--------|---------------|
-| Syntax | tsc --noEmit or equivalent | No errors |
-| File existence | Verify all planned files exist | All files present |
-| Import resolution | Check no broken imports | All imports resolve |
-
-1. Run syntax check: `tsc --noEmit` / `python -m py_compile` / equivalent
-2. Auto-fix if validation fails (max 2 attempts)
-3. Write dev log to `<session>/code/dev-log.md`:
-   - Changed files count, syntax status, fix task flag, file list
-4. Update implementation_context in .msg/meta.json:
-   - task, changed_files, is_fix, syntax_clean
-5. Write discoveries to wisdom/learnings.md

.claude/skills/team-iterdev/roles/reviewer/role.md

@@ -1,66 +0,0 @@
----
-role: reviewer
-prefix: REVIEW
-inner_loop: false
-message_types:
-  success: review_passed
-  revision: review_revision
-  critical: review_critical
-  error: error
----
-
-# Reviewer
-
-Code reviewer. Multi-dimensional review, quality scoring, improvement suggestions. Acts as Critic in Generator-Critic loop (paired with developer).
-
-## Phase 2: Context Loading
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Task description | From task subject/description | Yes |
-| Session path | Extracted from task description | Yes |
-| .msg/meta.json | <session>/.msg/meta.json | Yes |
-| Design document | <session>/design/design-001.md | For requirements alignment |
-| Changed files | Git diff | Yes |
-
-1. Extract session path from task description
-2. Read .msg/meta.json for shared context and previous review_feedback_trends
-3. Read design document for requirements alignment
-4. Get changed files via git diff, read file contents (limit 20 files)
-
-## Phase 3: Multi-Dimensional Review
-
-**Review dimensions**:
-
-| Dimension | Weight | Focus Areas |
-|-----------|--------|-------------|
-| Correctness | 30% | Logic correctness, boundary handling |
-| Completeness | 25% | Coverage of design requirements |
-| Maintainability | 25% | Readability, code style, DRY |
-| Security | 20% | Vulnerabilities, input validation |
-
-Per-dimension: scan modified files, record findings with severity (CRITICAL/HIGH/MEDIUM/LOW), include file:line references and suggestions.
-
-**Scoring**: Weighted average of dimension scores (1-10 each).
-
-**Output review report** (`<session>/review/review-<num>.md`):
-- Files reviewed count, quality score, issue counts by severity
-- Per-finding: severity, file:line, dimension, description, suggestion
-- Scoring breakdown by dimension
-- Signal: CRITICAL / REVISION_NEEDED / APPROVED
-- Design alignment notes
-
-## Phase 4: Trend Analysis + Verdict
-
-1. Compare with previous review_feedback_trends from .msg/meta.json
-2. Identify recurring issues, improvement areas, new issues
-
-| Verdict Condition | Message Type |
-|-------------------|--------------|
-| criticalCount > 0 | review_critical |
-| score < 7 | review_revision |
-| else | review_passed |
-
-3. Update review_feedback_trends in .msg/meta.json:
-   - review_id, score, critical count, high count, dimensions, gc_round
-4. Write discoveries to wisdom/learnings.md

.claude/skills/team-iterdev/roles/tester/role.md

@@ -1,88 +0,0 @@
----
-role: tester
-prefix: VERIFY
-inner_loop: false
-message_types:
-  success: verify_passed
-  failure: verify_failed
-  fix: fix_required
-  error: error
----
-
-# Tester
-
-Test validator. Test execution, fix cycles, and regression detection.
-
-## Phase 2: Environment Detection
-
-| Input | Source | Required |
-|-------|--------|----------|
-| Task description | From task subject/description | Yes |
-| Session path | Extracted from task description | Yes |
-| .msg/meta.json | <session>/.msg/meta.json | Yes |
-| Changed files | Git diff | Yes |
-
-1. Extract session path from task description
-2. Read .msg/meta.json for shared context
-3. Get changed files via git diff
-4. Detect test framework and command:
-
-| Detection | Method |
-|-----------|--------|
-| Test command | Check package.json scripts, pytest.ini, Makefile |
-| Coverage tool | Check for nyc, coverage.py, jest --coverage config |
-
-Common commands: npm test, pytest, go test ./..., cargo test
-
-## Phase 3: Execution + Fix Cycle
-
-**Iterative test-fix cycle** (max 5 iterations):
-
-| Step | Action |
-|------|--------|
-| 1 | Run test command |
-| 2 | Parse results, check pass rate |
-| 3 | Pass rate >= 95% -> exit loop (success) |
-| 4 | Extract failing test details |
-| 5 | Apply fix using CLI tool |
-| 6 | Increment iteration counter |
-| 7 | iteration >= MAX (5) -> exit loop (report failures) |
-| 8 | Go to Step 1 |
-
-**Fix delegation**: Use CLI tool to fix failing tests:
-
-```bash
-ccw cli -p "PURPOSE: Fix failing tests; success = all listed tests pass
-TASK: • Analyze test failure output • Identify root cause in changed files • Apply minimal fix
-MODE: write
-CONTEXT: @<changed-files> | Memory: Test output from current iteration
-EXPECTED: Code fixes that make failing tests pass without breaking other tests
-CONSTRAINTS: Only modify files in changed list | Minimal changes
-Test output: <test-failure-details>
-Changed files: <file-list>" --tool gemini --mode write --rule development-debug-runtime-issues
-```
-
-Wait for CLI completion before re-running tests.
-
-## Phase 4: Regression Check + Report
-
-1. Run full test suite for regression: `<test-command> --all`
-
-| Check | Method | Pass Criteria |
-|-------|--------|---------------|
-| Regression | Run full test suite | No FAIL in output |
-| Coverage | Run coverage tool | >= 80% (if configured) |
-
-2. Write verification results to `<session>/verify/verify-<num>.json`:
-   - verify_id, pass_rate, iterations, passed, timestamp, regression_passed
-
-3. Determine message type:
-
-| Condition | Message Type |
-|-----------|--------------|
-| passRate >= 0.95 | verify_passed |
-| passRate < 0.95 && iterations >= MAX | fix_required |
-| passRate < 0.95 | verify_failed |
-
-4. Update .msg/meta.json with test_patterns entry
-5. Write discoveries to wisdom/issues.md

.claude/skills/team-iterdev/specs/pipelines.md

@@ -1,94 +0,0 @@
-# IterDev Pipeline Definitions
-
-## Three-Pipeline Architecture
-
-### Patch Pipeline (2 beats, serial)
-
-```
-DEV-001 -> VERIFY-001
-[developer]  [tester]
-```
-
-### Sprint Pipeline (4 beats, with parallel window)
-
-```
-DESIGN-001 -> DEV-001 -> [VERIFY-001 + REVIEW-001] (parallel)
-[architect]   [developer]  [tester]       [reviewer]
-```
-
-### Multi-Sprint Pipeline (N beats, iterative)
-
-```
-Sprint 1: DESIGN-001 -> DEV-001 -> DEV-002(incremental) -> VERIFY-001 -> DEV-fix -> REVIEW-001
-Sprint 2: DESIGN-002(refined) -> DEV-003 -> VERIFY-002 -> REVIEW-002
-...
-```
-
-## Generator-Critic Loop (developer <-> reviewer)
-
-```
-DEV -> REVIEW -> (if review.critical_count > 0 || review.score < 7)
-              -> DEV-fix -> REVIEW-2 -> (if still issues) -> DEV-fix-2 -> REVIEW-3
-              -> (max 3 rounds, then accept with warning)
-```
-
-## Pipeline Selection Logic
-
-| Signal | Score |
-|--------|-------|
-| Changed files > 10 | +3 |
-| Changed files 3-10 | +2 |
-| Structural change | +3 |
-| Cross-cutting concern | +2 |
-| Simple fix | -2 |
-
-| Score | Pipeline |
-|-------|----------|
-| >= 5 | multi-sprint |
-| 2-4 | sprint |
-| 0-1 | patch |
-
-## Task Metadata Registry
-
-| Task ID | Role | Pipeline | Dependencies | Description |
-|---------|------|----------|-------------|-------------|
-| DESIGN-001 | architect | sprint/multi | (none) | Technical design and task breakdown |
-| DEV-001 | developer | all | DESIGN-001 (sprint/multi) or (none for patch) | Code implementation |
-| DEV-002 | developer | multi | DEV-001 | Incremental implementation |
-| DEV-fix | developer | sprint/multi | REVIEW-* (GC loop trigger) | Fix issues from review |
-| VERIFY-001 | tester | all | DEV-001 (or last DEV) | Test execution and fix cycles |
-| REVIEW-001 | reviewer | sprint/multi | DEV-001 (or last DEV) | Code review and quality scoring |
-
-## Checkpoints
-
-| Trigger Condition | Location | Behavior |
-|-------------------|----------|----------|
-| GC loop exceeds max rounds | After REVIEW-3 | Stop iteration, accept with warning, record in wisdom |
-| Sprint transition | End of Sprint N | Pause, retrospective, user confirms `resume` for Sprint N+1 |
-| Pipeline stall | No ready + no running tasks | Check missing tasks, report blockedBy chain to user |
-
-## Multi-Sprint Dynamic Downgrade
-
-If Sprint N metrics are strong (velocity >= expected, review avg >= 8), coordinator may downgrade Sprint N+1 from multi-sprint to sprint pipeline for efficiency.
-
-## Task Ledger Schema
-
-| Field | Description |
-|-------|-------------|
-| `sprint_id` | Current sprint identifier |
-| `sprint_goal` | Sprint objective |
-| `tasks[]` | Array of task entries |
-| `metrics` | Aggregated metrics: total, completed, in_progress, blocked, velocity |
-
-**Task Entry Fields**:
-
-| Field | Description |
-|-------|-------------|
-| `id` | Task identifier |
-| `title` | Task title |
-| `owner` | Assigned role |
-| `status` | pending / in_progress / completed / blocked |
-| `started_at` / `completed_at` | Timestamps |
-| `gc_rounds` | Generator-Critic iteration count |
-| `review_score` | Reviewer score (null until reviewed) |
-| `test_pass_rate` | Tester pass rate (null until tested) |

.claude/skills/team-iterdev/specs/team-config.json

@@ -1,172 +0,0 @@
-{
-  "team_name": "team-iterdev",
-  "team_display_name": "Team IterDev",
-  "description": "Iterative development team with Generator-Critic loop, task ledger, sprint learning, dynamic pipeline, conflict handling, concurrency control, rollback strategy, user feedback loop, and tech debt tracking",
-  "version": "1.2.0",
-
-  "roles": {
-    "coordinator": {
-      "task_prefix": null,
-      "responsibility": "Sprint planning, backlog management, task ledger maintenance, GC loop control, Phase 1: conflict handling, concurrency control, rollback strategy, Phase 3: user feedback loop, tech debt tracking",
-      "message_types": [
-        "sprint_started", "gc_loop_trigger", "sprint_complete", "task_unblocked", "error", "shutdown",
-        "conflict_detected", "conflict_resolved", "resource_locked", "resource_unlocked", "resource_contention",
-        "rollback_initiated", "rollback_completed", "rollback_failed",
-        "user_feedback_received", "tech_debt_identified"
-      ]
-    },
-    "architect": {
-      "task_prefix": "DESIGN",
-      "responsibility": "Technical design, task decomposition, architecture decisions",
-      "message_types": ["design_ready", "design_revision", "error"]
-    },
-    "developer": {
-      "task_prefix": "DEV",
-      "responsibility": "Code implementation, incremental delivery",
-      "message_types": ["dev_complete", "dev_progress", "error"]
-    },
-    "tester": {
-      "task_prefix": "VERIFY",
-      "responsibility": "Test execution, fix cycle, regression detection",
-      "message_types": ["verify_passed", "verify_failed", "fix_required", "error"]
-    },
-    "reviewer": {
-      "task_prefix": "REVIEW",
-      "responsibility": "Code review, quality scoring, improvement suggestions",
-      "message_types": ["review_passed", "review_revision", "review_critical", "error"]
-    }
-  },
-
-  "pipelines": {
-    "patch": {
-      "description": "Simple fix: implement → verify",
-      "task_chain": ["DEV-001", "VERIFY-001"],
-      "gc_loops": 0
-    },
-    "sprint": {
-      "description": "Standard feature: design → implement → verify + review (parallel)",
-      "task_chain": ["DESIGN-001", "DEV-001", "VERIFY-001", "REVIEW-001"],
-      "gc_loops": 3,
-      "parallel_groups": [["VERIFY-001", "REVIEW-001"]]
-    },
-    "multi-sprint": {
-      "description": "Large feature: multiple sprint cycles with incremental delivery",
-      "task_chain": "dynamic — coordinator creates per-sprint chains",
-      "gc_loops": 3,
-      "sprint_count": "dynamic"
-    }
-  },
-
-  "innovation_patterns": {
-    "generator_critic": {
-      "generator": "developer",
-      "critic": "reviewer",
-      "max_rounds": 3,
-      "convergence_trigger": "review.critical_count === 0 && review.score >= 7"
-    },
-    "task_ledger": {
-      "file": "task-ledger.json",
-      "updated_by": "coordinator",
-      "tracks": ["status", "gc_rounds", "review_score", "test_pass_rate", "velocity"],
-      "phase1_extensions": {
-        "conflict_info": {
-          "fields": ["status", "conflicting_files", "resolution_strategy", "resolved_by_task_id"],
-          "default": { "status": "none", "conflicting_files": [], "resolution_strategy": null, "resolved_by_task_id": null }
-        },
-        "rollback_info": {
-          "fields": ["snapshot_id", "rollback_procedure", "last_successful_state_id"],
-          "default": { "snapshot_id": null, "rollback_procedure": null, "last_successful_state_id": null }
-        }
-      }
-    },
-    "shared_memory": {
-      "file": "shared-memory.json",
-      "fields": {
-        "architect": "architecture_decisions",
-        "developer": "implementation_context",
-        "tester": "test_patterns",
-        "reviewer": "review_feedback_trends"
-      },
-      "persistent_fields": ["sprint_history", "what_worked", "what_failed", "patterns_learned"],
-      "phase1_extensions": {
-        "resource_locks": {
-          "description": "Concurrency control: resource locking state",
-          "lock_timeout_ms": 300000,
-          "deadlock_detection": true
-        }
-      }
-    },
-    "dynamic_pipeline": {
-      "selector": "coordinator",
-      "criteria": "file_count + module_count + complexity_assessment",
-      "downgrade_rule": "velocity >= expected && review_avg >= 8 → simplify next sprint"
-    }
-  },
-
-  "phase1_features": {
-    "conflict_handling": {
-      "enabled": true,
-      "detection_strategy": "file_overlap",
-      "resolution_strategies": ["manual", "auto_merge", "abort"]
-    },
-    "concurrency_control": {
-      "enabled": true,
-      "lock_timeout_minutes": 5,
-      "deadlock_detection": true,
-      "resources": ["task-ledger.json", "shared-memory.json"]
-    },
-    "rollback_strategy": {
-      "enabled": true,
-      "snapshot_trigger": "task_complete",
-      "default_procedure": "git revert HEAD"
-    }
-  },
-
-  "phase2_features": {
-    "external_dependency_management": {
-      "enabled": true,
-      "validation_trigger": "task_start",
-      "supported_sources": ["npm", "maven", "pip", "git"],
-      "version_check_command": {
-        "npm": "npm list {name}",
-        "pip": "pip show {name}",
-        "maven": "mvn dependency:tree"
-      }
-    },
-    "state_recovery": {
-      "enabled": true,
-      "checkpoint_trigger": "phase_complete",
-      "max_checkpoints_per_task": 5,
-      "checkpoint_dir": "checkpoints/"
-    }
-  },
-
-  "phase3_features": {
-    "user_feedback_loop": {
-      "enabled": true,
-      "collection_trigger": "sprint_complete",
-      "max_feedback_items": 50,
-      "severity_levels": ["low", "medium", "high", "critical"],
-      "status_flow": ["new", "reviewed", "addressed", "closed"]
-    },
-    "tech_debt_tracking": {
-      "enabled": true,
-      "detection_sources": ["review", "test", "architect"],
-      "categories": ["code", "design", "test", "documentation"],
-      "severity_levels": ["low", "medium", "high", "critical"],
-      "status_flow": ["open", "in_progress", "resolved", "deferred"],
-      "report_trigger": "sprint_retrospective"
-    }
-  },
-
-  "collaboration_patterns": ["CP-1", "CP-3", "CP-5", "CP-6"],
-
-  "session_dirs": {
-    "base": ".workflow/.team/IDS-{slug}-{YYYY-MM-DD}/",
-    "design": "design/",
-    "code": "code/",
-    "verify": "verify/",
-    "review": "review/",
-    "messages": ".workflow/.team-msg/{team-name}/"
-  }
-}

.claude/skills/team-lifecycle-v4/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: team-lifecycle-v4
-description: Full lifecycle team skill with clean architecture. SKILL.md is a universal router — all roles read it. Beat model is coordinator-only. Structure is roles/ + specs/ + templates/. Triggers on "team lifecycle v4".
+description: Full lifecycle team skill — plan, develop, test, review in one coordinated session. Role-based architecture with coordinator-driven beat model. Triggers on "team lifecycle v4".
 allowed-tools: TeamCreate(*), TeamDelete(*), SendMessage(*), TaskCreate(*), TaskUpdate(*), TaskList(*), TaskGet(*), Agent(*), AskUserQuestion(*), Read(*), Write(*), Edit(*), Bash(*), Glob(*), Grep(*)
 ---
 

.claude/skills/team-perf-opt/roles/coordinator/commands/monitor.md

@@ -73,7 +73,7 @@ Agent({
   run_in_background: true,
   prompt: `## Role Assignment
 role: <role>
-role_spec: ~  or <project>/.claude/skills/team-perf-opt/role-specs/<role>.md
+role_spec: ~  or <project>/.claude/skills/team-perf-opt/roles/<role>/role.md
 session: <session-folder>
 session_id: <session-id>
 team_name: perf-opt

.claude/skills/team-perf-opt/specs/team-config.json

@@ -24,7 +24,7 @@
       "name": "profiler",
       "type": "orchestration",
       "description": "Profiles application performance, identifies CPU/memory/IO/network/rendering bottlenecks",
-      "role_spec": "role-specs/profiler.md",
+      "role_spec": "roles/profiler/role.md",
       "inner_loop": false,
       "frontmatter": {
         "prefix": "PROFILE",
@@ -44,7 +44,7 @@
       "name": "strategist",
       "type": "orchestration",
       "description": "Analyzes bottleneck reports, designs prioritized optimization plans with concrete strategies",
-      "role_spec": "role-specs/strategist.md",
+      "role_spec": "roles/strategist/role.md",
       "inner_loop": false,
       "frontmatter": {
         "prefix": "STRATEGY",
@@ -64,7 +64,7 @@
       "name": "optimizer",
       "type": "code_generation",
       "description": "Implements optimization changes following the strategy plan",
-      "role_spec": "role-specs/optimizer.md",
+      "role_spec": "roles/optimizer/role.md",
       "inner_loop": true,
       "frontmatter": {
         "prefix": "IMPL",
@@ -85,7 +85,7 @@
       "name": "benchmarker",
       "type": "validation",
       "description": "Runs benchmarks, compares before/after metrics, validates performance improvements",
-      "role_spec": "role-specs/benchmarker.md",
+      "role_spec": "roles/benchmarker/role.md",
       "inner_loop": false,
       "frontmatter": {
         "prefix": "BENCH",
@@ -106,7 +106,7 @@
       "name": "reviewer",
       "type": "read_only_analysis",
       "description": "Reviews optimization code for correctness, side effects, and regression risks",
-      "role_spec": "role-specs/reviewer.md",
+      "role_spec": "roles/reviewer/role.md",
       "inner_loop": false,
       "frontmatter": {
         "prefix": "REVIEW",

.claude/skills/team-quality-assurance/roles/executor/role.md

@@ -26,7 +26,8 @@ Run test suites, collect coverage data, and perform automatic fix cycles when te
 | Target layer | task description `layer: L1/L2/L3` | Yes |
 
 1. Extract session path and target layer from task description
-2. Read .msg/meta.json for strategy and generated test file list
+2. Load validation specs: Run `ccw spec load --category validation` for verification rules and acceptance criteria
+3. Read .msg/meta.json for strategy and generated test file list
 3. Detect test command by framework:
 
 | Framework | Command |

.claude/skills/team-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: team-review
-description: Unified team skill for code review. 3-role pipeline: scanner, reviewer, fixer. Triggers on "team-review".
+description: "Unified team skill for code review. 3-role pipeline: scanner, reviewer, fixer. Triggers on team-review."
 allowed-tools: TeamCreate(*), TeamDelete(*), SendMessage(*), TaskCreate(*), TaskUpdate(*), TaskList(*), TaskGet(*), Agent(*), AskUserQuestion(*), Read(*), Write(*), Edit(*), Bash(*), Glob(*), Grep(*), mcp__ace-tool__search_context(*)
 ---
 

.claude/skills/team-review/roles/reviewer/role.md

@@ -21,7 +21,8 @@ Deep analysis on scan findings: triage, root cause / impact / optimization enric
 | .msg/meta.json | <session>/.msg/meta.json | No |
 
 1. Extract session path, input path, dimensions from task description
-2. Load scan results. If missing or empty -> report clean, complete immediately
+2. Load review specs: Run `ccw spec load --category review` for review standards, checklists, and approval gates
+3. Load scan results. If missing or empty -> report clean, complete immediately
 3. Load wisdom files from `<session>/wisdom/`
 4. Triage findings into two buckets:
 

.claude/skills/team-tech-debt/roles/scanner/role.md

@@ -18,7 +18,8 @@ Multi-dimension tech debt scanner. Scan codebase across 5 dimensions (code, arch
 | .msg/meta.json | <session>/.msg/meta.json | Yes |
 
 1. Extract session path and scan scope from task description
-2. Read .msg/meta.json for team context
+2. Load debug specs: Run `ccw spec load --category debug` for known issues, workarounds, and root-cause notes
+3. Read .msg/meta.json for team context
 3. Detect project type and framework:
 
 | Signal File | Project Type |

.claude/skills/team-testing/roles/executor/role.md

@@ -24,7 +24,8 @@ Execute tests, collect coverage, attempt auto-fix for failures. Acts as the Crit
 | .msg/meta.json | <session>/wisdom/.msg/meta.json | No |
 
 1. Extract session path and test directory from task description
-2. Extract coverage target (default: 80%)
+2. Load test specs: Run `ccw spec load --category test` for test framework conventions and coverage targets
+3. Extract coverage target (default: 80%)
 3. Read .msg/meta.json for framework info (from strategist namespace)
 4. Determine test framework:
 

.claude/skills/team-testing/roles/generator/role.md

@@ -22,7 +22,8 @@ Generate test code by layer (L1 unit / L2 integration / L3 E2E). Acts as the Gen
 | .msg/meta.json | <session>/wisdom/.msg/meta.json | No |
 
 1. Extract session path and layer from task description
-2. Read test strategy:
+2. Load test specs: Run `ccw spec load --category test` for test framework conventions and coverage targets
+3. Read test strategy:
 
 ```
 Read("<session>/strategy/test-strategy.md")

.claude/skills/team-ultra-analyze/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: team-ultra-analyze
-description: Deep collaborative analysis team skill. All roles route via this SKILL.md. Beat model is coordinator-only (monitor.md). Structure is roles/ + specs/. Triggers on "team ultra-analyze", "team analyze".
+description: Deep collaborative analysis team skill. Multi-role investigation with coordinator-driven synthesis. Triggers on "team ultra-analyze", "team analyze".
 allowed-tools: TeamCreate(*), TeamDelete(*), SendMessage(*), TaskCreate(*), TaskUpdate(*), TaskList(*), TaskGet(*), Agent(*), AskUserQuestion(*), Read(*), Write(*), Edit(*), Bash(*), Glob(*), Grep(*)
 ---
 

.claude/skills/team-ultra-analyze/roles/explorer/role.md

@@ -18,7 +18,8 @@ Explore codebase structure through cli-explore-agent, collecting structured cont
 | Task description | From task subject/description | Yes |
 | Session path | Extracted from task description | Yes |
 
-1. Extract session path, topic, perspective, dimensions from task description:
+1. Load debug specs: Run `ccw spec load --category debug` for known issues and root-cause notes
+2. Extract session path, topic, perspective, dimensions from task description:
 
 | Field | Pattern | Default |
 |-------|---------|---------|

.claude/skills/team-ux-improve/specs/team-config.json

@@ -27,7 +27,7 @@
       "display_name": "UI Scanner",
       "type": "worker",
       "responsibility_type": "read_only_analysis",
-      "role_spec": "role-specs/scanner.md",
+      "role_spec": "roles/scanner/role.md",
       "task_prefix": "SCAN",
       "inner_loop": false,
       "allowed_tools": ["Read", "Grep", "Glob", "Bash", "mcp__ace-tool__search_context", "mcp__ccw-tools__read_file", "mcp__ccw-tools__team_msg", "TaskList", "TaskGet", "TaskUpdate", "SendMessage"],
@@ -46,7 +46,7 @@
       "display_name": "State Diagnoser",
       "type": "worker",
       "responsibility_type": "orchestration",
-      "role_spec": "role-specs/diagnoser.md",
+      "role_spec": "roles/diagnoser/role.md",
       "task_prefix": "DIAG",
       "inner_loop": false,
       "allowed_tools": ["Read", "Grep", "Bash", "mcp__ace-tool__search_context", "mcp__ccw-tools__read_file", "mcp__ccw-tools__team_msg", "TaskList", "TaskGet", "TaskUpdate", "SendMessage"],
@@ -65,7 +65,7 @@
       "display_name": "UX Designer",
       "type": "worker",
       "responsibility_type": "orchestration",
-      "role_spec": "role-specs/designer.md",
+      "role_spec": "roles/designer/role.md",
       "task_prefix": "DESIGN",
       "inner_loop": false,
       "allowed_tools": ["Read", "Write", "Bash", "mcp__ccw-tools__read_file", "mcp__ccw-tools__write_file", "mcp__ccw-tools__team_msg", "TaskList", "TaskGet", "TaskUpdate", "SendMessage"],
@@ -84,7 +84,7 @@
       "display_name": "Code Implementer",
       "type": "worker",
       "responsibility_type": "code_generation",
-      "role_spec": "role-specs/implementer.md",
+      "role_spec": "roles/implementer/role.md",
       "task_prefix": "IMPL",
       "inner_loop": true,
       "allowed_tools": ["Read", "Write", "Edit", "Bash", "mcp__ccw-tools__read_file", "mcp__ccw-tools__write_file", "mcp__ccw-tools__edit_file", "mcp__ccw-tools__team_msg", "TaskList", "TaskGet", "TaskUpdate", "SendMessage"],
@@ -103,7 +103,7 @@
       "display_name": "Test Engineer",
       "type": "worker",
       "responsibility_type": "validation",
-      "role_spec": "role-specs/tester.md",
+      "role_spec": "roles/tester/role.md",
       "task_prefix": "TEST",
       "inner_loop": false,
       "allowed_tools": ["Read", "Write", "Bash", "mcp__ccw-tools__read_file", "mcp__ccw-tools__write_file", "mcp__ccw-tools__team_msg", "TaskList", "TaskGet", "TaskUpdate", "SendMessage"],
@@ -123,7 +123,7 @@
     {
       "name": "explorer",
       "display_name": "Codebase Explorer",
-      "role_spec": "role-specs/explorer.md",
+      "role_spec": "roles/explorer/role.md",
       "callable_by": "coordinator",
       "purpose": "Explore codebase for UI component patterns, state management conventions, and framework-specific patterns",
       "allowed_tools": ["Read", "Grep", "Glob", "Bash", "mcp__ace-tool__search_context", "mcp__ccw-tools__read_file", "mcp__ccw-tools__team_msg"],

.claude/skills/workflow-execute/phases/06-review.md

@@ -93,7 +93,7 @@ rg "password|token|secret|auth" -g "*.{ts,js,py}"
 rg "eval|exec|innerHTML|dangerouslySetInnerHTML" -g "*.{ts,js,tsx}"
 
 # Gemini security analysis
-ccw spec load --category execution
+ccw spec load --category review
 ccw cli -p "
 PURPOSE: Security audit of completed implementation
 TASK: Review code for security vulnerabilities, insecure patterns, auth/authz issues
@@ -105,7 +105,7 @@ RULES: Focus on OWASP Top 10, authentication, authorization, data validation, in
 
 **Architecture Review** (`architecture`):
 ```bash
-ccw spec load --category execution
+ccw spec load --category review
 ccw cli -p "
 PURPOSE: Architecture compliance review
 TASK: Evaluate adherence to architectural patterns, identify technical debt, review design decisions
@@ -117,7 +117,7 @@ RULES: Check for patterns, separation of concerns, modularity, scalability
 
 **Quality Review** (`quality`):
 ```bash
-ccw spec load --category execution
+ccw spec load --category review
 ccw cli -p "
 PURPOSE: Code quality and best practices review
 TASK: Assess code readability, maintainability, adherence to best practices
@@ -139,7 +139,7 @@ for task_file in ${sessionPath}/.task/*.json; do
 done
 
 # Cross-check implementation against requirements
-ccw spec load --category execution
+ccw spec load --category review
 ccw cli -p "
 PURPOSE: Verify all requirements and acceptance criteria are met
 TASK: Cross-check implementation summaries against original requirements

.claude/skills/workflow-lite-execute/SKILL.md

@@ -74,7 +74,7 @@ function selectExecutionOptions() {
   const autoYes = workflowPreferences?.autoYes ?? false
 
   if (autoYes) {
-    return { execution_method: "Auto", code_review_tool: "Skip" }
+    return { execution_method: "Auto", code_review_tool: "Skip", convergence_review_tool: "Skip" }
   }
 
   return AskUserQuestion({
@@ -90,14 +90,25 @@ function selectExecutionOptions() {
         ]
       },
       {
-        question: "Review tool for test-review phase?",
-        header: "Review Tool (passed to lite-test-review)",
+        question: "Code review after execution? (runs here in lite-execute)",
+        header: "Code Review",
         multiSelect: false,
         options: [
-          { label: "Agent Review", description: "Agent review in test-review (default)" },
-          { label: "Gemini Review", description: "Gemini CLI in test-review" },
-          { label: "Codex Review", description: "Codex CLI in test-review" },
-          { label: "Skip", description: "Skip review in test-review" }
+          { label: "Gemini Review", description: "Gemini CLI: git diff quality review" },
+          { label: "Codex Review", description: "Codex CLI: git-aware code review (--mode review)" },
+          { label: "Agent Review", description: "@code-reviewer agent" },
+          { label: "Skip", description: "No code review" }
+        ]
+      },
+      {
+        question: "Convergence review in test-review phase?",
+        header: "Convergence Review",
+        multiSelect: false,
+        options: [
+          { label: "Agent", description: "Agent: verify convergence criteria" },
+          { label: "Gemini", description: "Gemini CLI: convergence verification" },
+          { label: "Codex", description: "Codex CLI: convergence verification" },
+          { label: "Skip", description: "Skip convergence review, run tests only" }
         ]
       }
     ]
@@ -117,7 +128,8 @@ if (executionContext) {
   console.log(`
   Execution Strategy (from lite-plan):
    Method: ${executionContext.executionMethod}
-   Review: ${executionContext.codeReviewTool}
+   Code Review: ${executionContext.codeReviewTool}
+   Convergence Review: ${executionContext.convergenceReviewTool}
    Tasks: ${getTasks(executionContext.planObject).length}
    Complexity: ${executionContext.planObject.complexity}
 ${executionContext.executorAssignments ? `   Assignments: ${JSON.stringify(executionContext.executorAssignments)}` : ''}
@@ -367,18 +379,97 @@ ${(t.test?.success_metrics || []).length > 0 ? `**Success metrics**: ${t.test.su
 }
 ```
 
-### Step 4: Chain to Test Review & Post-Completion
+### Step 4: Code Review
 
-> **Note**: Spec sync (session:sync) is handled by lite-test-review's TR-Phase 5, not here. This avoids duplicate sync and ensures test fix changes are also captured.
+**Skip if**: `codeReviewTool === 'Skip'`
 
-**Map review tool**: Convert lite-execute's `codeReviewTool` to test-review tool name.
+**Resolve review tool**: From `executionContext.codeReviewTool` (Mode 1) or `userSelection.code_review_tool` (Mode 2/3).
 
 ```javascript
-function mapReviewTool(codeReviewTool) {
+const codeReviewTool = executionContext?.codeReviewTool || userSelection?.code_review_tool || 'Skip'
+const resolvedTool = (() => {
   if (!codeReviewTool || codeReviewTool === 'Skip') return 'skip'
   if (/gemini/i.test(codeReviewTool)) return 'gemini'
   if (/codex/i.test(codeReviewTool)) return 'codex'
   return 'agent'
+})()
+
+if (resolvedTool === 'skip') {
+  console.log('[Code Review] Skipped')
+} else {
+  // proceed with review
+}
+```
+
+**Agent Code Review** (resolvedTool === 'agent'):
+
+```javascript
+Agent({
+  subagent_type: "code-reviewer",
+  run_in_background: false,
+  description: `Code review: ${planObject.summary}`,
+  prompt: `## Code Review — Post-Execution Quality Check
+
+**Goal**: ${originalUserInput}
+**Plan Summary**: ${planObject.summary}
+
+### Changed Files
+Run \`git diff --name-only HEAD~${getTasks(planObject).length}..HEAD\` to identify changes.
+
+### Review Focus
+1. **Code quality**: Readability, naming, structure, dead code
+2. **Correctness**: Logic errors, off-by-one, null handling, edge cases
+3. **Patterns**: Consistency with existing codebase conventions
+4. **Security**: Injection, XSS, auth bypass, secrets exposure
+5. **Performance**: Unnecessary loops, N+1 queries, missing indexes
+
+### Instructions
+1. Run git diff to see actual changes
+2. Read changed files for full context
+3. For each issue found: severity (Critical/High/Medium/Low) + file:line + description + fix suggestion
+4. Return structured review: issues[], summary, overall verdict (PASS/WARN/FAIL)`
+})
+```
+
+**CLI Code Review — Codex** (resolvedTool === 'codex'):
+
+```javascript
+const reviewId = `${sessionId}-code-review`
+Bash(`ccw cli -p "Review code changes for quality, correctness, security, and pattern compliance. Focus: ${planObject.summary}" --tool codex --mode review --id ${reviewId}`, { run_in_background: true })
+// STOP - wait for hook callback
+```
+
+**CLI Code Review — Gemini** (resolvedTool === 'gemini'):
+
+```javascript
+const reviewId = `${sessionId}-code-review`
+Bash(`ccw cli -p "PURPOSE: Post-execution code quality review for: ${planObject.summary}
+TASK: • Run git diff to identify all changes • Review each changed file for quality, correctness, security • Check pattern compliance with existing codebase • Identify potential bugs, edge cases, performance issues
+MODE: analysis
+CONTEXT: @**/* | Memory: lite-execute completed, reviewing code quality
+EXPECTED: Per-file review with severity levels (Critical/High/Medium/Low), file:line references, fix suggestions, overall verdict
+CONSTRAINTS: Read-only | Focus on code quality not convergence" --tool gemini --mode analysis --rule analysis-review-code-quality --id ${reviewId}`, { run_in_background: true })
+// STOP - wait for hook callback
+```
+
+**Write review artifact** (if session folder exists):
+```javascript
+if (executionContext?.session?.folder) {
+  Write(`${executionContext.session.folder}/code-review.md`, codeReviewOutput)
+}
+```
+
+### Step 5: Chain to Test Review & Post-Completion
+
+**Resolve convergence review tool**: From `executionContext.convergenceReviewTool` (Mode 1) or `userSelection.convergence_review_tool` (Mode 2/3).
+
+```javascript
+function resolveConvergenceTool(ctx, selection) {
+  const raw = ctx?.convergenceReviewTool || selection?.convergence_review_tool || 'skip'
+  if (!raw || raw === 'Skip') return 'skip'
+  if (/gemini/i.test(raw)) return 'gemini'
+  if (/codex/i.test(raw)) return 'codex'
+  return 'agent'
 }
 ```
 
@@ -389,7 +480,7 @@ testReviewContext = {
   planObject: planObject,
   taskFiles: executionContext?.taskFiles
     || getTasks(planObject).map(t => ({ id: t.id, path: `${executionContext?.session?.folder}/.task/${t.id}.json` })),
-  reviewTool: mapReviewTool(executionContext?.codeReviewTool),
+  convergenceReviewTool: resolveConvergenceTool(executionContext, userSelection),
   executionResults: previousExecutionResults,
   originalUserInput: originalUserInput,
   session: executionContext?.session || {
@@ -442,7 +533,8 @@ Skill("lite-test-review")
   explorationManifest: {...} | null,
   clarificationContext: {...} | null,
   executionMethod: "Agent" | "Codex" | "Auto",
-  codeReviewTool: "Skip" | "Gemini Review" | "Agent Review" | string,
+  codeReviewTool: "Skip" | "Gemini Review" | "Codex Review" | "Agent Review",
+  convergenceReviewTool: "Skip" | "Agent" | "Gemini" | "Codex",
   originalUserInput: string,
   executorAssignments: {            // per-task override, priority over executionMethod
     [taskId]: { executor: "gemini" | "codex" | "agent", reason: string }

.claude/skills/workflow-lite-plan/SKILL.md

@@ -40,7 +40,7 @@ Produces exploration results, a structured plan (plan.json), independent task fi
 
 **Output Directory**: `.workflow/.lite-plan/{task-slug}-{YYYY-MM-DD}/`
 
-**Agent Usage**: Low → Direct Claude planning (no agent) | Medium/High → `cli-lite-planning-agent`
+**Agent Usage**: All complexities → `cli-lite-planning-agent`
 
 **Schema Reference**: `~/.ccw/workflows/cli-templates/schemas/plan-overview-base-schema.json`
 
@@ -51,7 +51,7 @@ Produces exploration results, a structured plan (plan.json), independent task fi
 | LP-0 | Initialize workflowPreferences | autoYes, forceExplore |
 | LP-1 | Complexity assessment → parallel cli-explore-agents (1-4) | exploration-*.json + manifest |
 | LP-2 | Aggregate + dedup clarification_needs → multi-round AskUserQuestion | clarificationContext (in-memory) |
-| LP-3 | Low: Direct Claude planning / Medium+High: cli-lite-planning-agent | plan.json + .task/TASK-*.json |
+| LP-3 | cli-lite-planning-agent | plan.json + .task/TASK-*.json |
 | LP-4 | Display plan → AskUserQuestion (Confirm + Execution + Review) | userSelection |
 | LP-5 | Build executionContext → Skill("lite-execute") | handoff (Mode 1) |
 
@@ -85,7 +85,7 @@ bash(`mkdir -p ${sessionFolder} && test -d ${sessionFolder} && echo "SUCCESS: ${
 TodoWrite({ todos: [
   { content: `LP-Phase 1: Exploration [${complexity}] ${selectedAngles.length} angles`, status: "in_progress", activeForm: `Exploring: ${selectedAngles.join(', ')}` },
   { content: "LP-Phase 2: Clarification", status: "pending" },
-  { content: `LP-Phase 3: Planning [${planningStrategy}]`, status: "pending" },
+  { content: "LP-Phase 3: Planning [cli-lite-planning-agent]", status: "pending" },
   { content: "LP-Phase 4: Confirmation", status: "pending" },
   { content: "LP-Phase 5: Execution", status: "pending" }
 ]})
@@ -154,12 +154,7 @@ function selectAngles(taskDescription, count) {
 
 const selectedAngles = selectAngles(task_description, complexity === 'High' ? 4 : (complexity === 'Medium' ? 3 : 1))
 
-// Direct Claude planning ONLY for: Low + no prior analysis + single angle
-const planningStrategy = (
-  complexity === 'Low' && !hasPriorAnalysis && selectedAngles.length <= 1
-) ? 'Direct Claude Planning' : 'cli-lite-planning-agent'
-
-console.log(`Exploration Plan: ${complexity} | ${selectedAngles.join(', ')} | ${planningStrategy}`)
+console.log(`Exploration Plan: ${complexity} | ${selectedAngles.join(', ')} | cli-lite-planning-agent`)
 ```
 
 **Launch Parallel Explorations**:
@@ -328,56 +323,7 @@ taskFiles.forEach(taskPath => {
 })
 ```
 
-**Low Complexity** — Direct planning by Claude:
-```javascript
-const schema = Bash(`cat ~/.ccw/workflows/cli-templates/schemas/plan-overview-base-schema.json`)
-
-const manifest = file_exists(`${sessionFolder}/explorations-manifest.json`)
-  ? JSON.parse(Read(`${sessionFolder}/explorations-manifest.json`))
-  : { explorations: [] }
-manifest.explorations.forEach(exp => {
-  console.log(`\n### Exploration: ${exp.angle}\n${Read(exp.path)}`)
-})
-
-// When handoffSpec exists, use it as primary planning input
-// implementation_scope[].acceptance_criteria -> convergence.criteria
-// implementation_scope[].target_files -> files[]
-// implementation_scope[].objective -> task title/description
-if (handoffSpec) {
-  console.log(`\n### Handoff Spec from ${handoffSpec.source}`)
-  console.log(`Scope items: ${handoffSpec.implementation_scope.length}`)
-  handoffSpec.implementation_scope.forEach((item, i) => {
-    console.log(`  ${i+1}. ${item.objective} [${item.priority}] — Done when: ${item.acceptance_criteria.join('; ')}`)
-  })
-}
-
-// Generate tasks — MUST incorporate exploration insights OR handoff spec
-// When handoffSpec: map implementation_scope[] → tasks[] (1:1 or group by context)
-// Field names: convergence.criteria (not acceptance), files[].change (not modification_points), test (not verification)
-const tasks = [
-  {
-    id: "TASK-001", title: "...", description: "...", depends_on: [],
-    convergence: { criteria: ["..."] },  // From handoffSpec: item.acceptance_criteria
-    files: [{ path: "...", change: "..." }],  // From handoffSpec: item.target_files + item.change_summary
-    implementation: ["..."], test: "..."
-  }
-]
-
-const taskDir = `${sessionFolder}/.task`
-Bash(`mkdir -p "${taskDir}"`)
-tasks.forEach(task => Write(`${taskDir}/${task.id}.json`, JSON.stringify(task, null, 2)))
-
-const plan = {
-  summary: "...", approach: "...",
-  task_ids: tasks.map(t => t.id), task_count: tasks.length,
-  complexity: "Low", estimated_time: "...", recommended_execution: "Agent",
-  _metadata: { timestamp: getUtc8ISOString(), source: "direct-planning", planning_mode: "direct", plan_type: "feature" }
-}
-Write(`${sessionFolder}/plan.json`, JSON.stringify(plan, null, 2))
-// MUST continue to LP-Phase 4 — DO NOT execute code here
-```
-
-**Medium/High Complexity** — Invoke cli-lite-planning-agent:
+**Invoke cli-lite-planning-agent**:
 
 ```javascript
 Task(
@@ -394,9 +340,6 @@ Generate implementation plan and write plan.json.
 - ${sessionFolder}/plan.json (plan overview — NO embedded tasks[])
 - ${sessionFolder}/.task/TASK-*.json (independent task files, one per task)
 
-## Schema Reference
-Execute: cat ~/.ccw/workflows/cli-templates/schemas/plan-overview-base-schema.json
-
 ## Project Context (MANDATORY)
 Execute: ccw spec load --category planning
 **CRITICAL**: All generated tasks MUST comply with constraints in specs/*.md
@@ -446,7 +389,6 @@ ${complexity}
 ## Requirements
 - _metadata.exploration_angles: ${JSON.stringify(manifest.explorations.map(e => e.angle))}
 - Two-layer output: plan.json (task_ids[], NO tasks[]) + .task/TASK-*.json
-- Follow plan-overview-base-schema.json for plan.json, task-schema.json for .task/*.json
 - Field names: files[].change (not modification_points), convergence.criteria (not acceptance)
 
 ## Task Grouping Rules
@@ -459,9 +401,9 @@ ${complexity}
 7. **Prefer parallel**: Most tasks should be independent
 
 ## Execution
-1. Read schema → 2. ccw spec load → 3. Read ALL exploration files → 4. Synthesize + generate
-5. Write: planning-context.md, .task/TASK-*.json, plan.json (task_ids[], NO tasks[])
-6. Return brief completion summary
+1. ccw spec load → 2. Read ALL exploration files → 3. Synthesize + generate
+4. Write: planning-context.md, .task/TASK-*.json, plan.json (task_ids[], NO tasks[])
+5. Return brief completion summary
 `
 )
 ```
@@ -492,8 +434,8 @@ ${tasks.map((t, i) => `${i+1}. ${t.title} (${t.scope || t.files?.[0]?.path || ''
 let userSelection
 
 if (workflowPreferences.autoYes) {
-  console.log(`[Auto] Allow & Execute | Auto | Skip`)
-  userSelection = { confirmation: "Allow", execution_method: "Auto", code_review_tool: "Skip" }
+  console.log(`[Auto] Allow & Execute | Auto | Skip + Skip`)
+  userSelection = { confirmation: "Allow", execution_method: "Auto", code_review_tool: "Skip", convergence_review_tool: "Skip" }
 } else {
   // "Other" in Execution allows specifying CLI tools from ~/.claude/cli-tools.json
   userSelection = AskUserQuestion({
@@ -519,14 +461,25 @@ if (workflowPreferences.autoYes) {
         ]
       },
       {
-        question: "Code review after execution?",
-        header: "Review",
+        question: "Code review after execution? (runs in lite-execute)",
+        header: "Code Review",
         multiSelect: false,
         options: [
-          { label: "Gemini Review", description: "Gemini CLI review" },
-          { label: "Codex Review", description: "Git-aware review (prompt OR --uncommitted)" },
+          { label: "Gemini Review", description: "Gemini CLI: git diff quality review" },
+          { label: "Codex Review", description: "Codex CLI: git-aware code review (--mode review)" },
           { label: "Agent Review", description: "@code-reviewer agent" },
-          { label: "Skip", description: "No review" }
+          { label: "Skip", description: "No code review" }
+        ]
+      },
+      {
+        question: "Convergence review in test-review phase?",
+        header: "Convergence Review",
+        multiSelect: false,
+        options: [
+          { label: "Agent", description: "Agent: verify convergence criteria against implementation" },
+          { label: "Gemini", description: "Gemini CLI: convergence verification" },
+          { label: "Codex", description: "Codex CLI: convergence verification" },
+          { label: "Skip", description: "Skip convergence review, run tests only" }
         ]
       }
     ]
@@ -534,7 +487,7 @@ if (workflowPreferences.autoYes) {
 }
 ```
 
-// TodoWrite: Phase 4 → completed `[${userSelection.execution_method} + ${userSelection.code_review_tool}]`, Phase 5 → in_progress
+// TodoWrite: Phase 4 → completed `[${userSelection.execution_method} | CR:${userSelection.code_review_tool} | CVR:${userSelection.convergence_review_tool}]`, Phase 5 → in_progress
 
 ## 10. LP-Phase 5: Handoff to Execution
 
@@ -561,6 +514,7 @@ executionContext = {
   clarificationContext: clarificationContext || null,
   executionMethod: userSelection.execution_method,
   codeReviewTool: userSelection.code_review_tool,
+  convergenceReviewTool: userSelection.convergence_review_tool,
   originalUserInput: task_description,
   executorAssignments: executorAssignments,  // { taskId: { executor, reason } } — overrides executionMethod
   session: {
@@ -588,7 +542,7 @@ TodoWrite({ todos: [
   { content: "LP-Phase 1: Exploration", status: "completed" },
   { content: "LP-Phase 2: Clarification", status: "completed" },
   { content: "LP-Phase 3: Planning", status: "completed" },
-  { content: `LP-Phase 4: Confirmed [${userSelection.execution_method}]`, status: "completed" },
+  { content: `LP-Phase 4: Confirmed [${userSelection.execution_method} | CR:${userSelection.code_review_tool} | CVR:${userSelection.convergence_review_tool}]`, status: "completed" },
   { content: `LP-Phase 5: Handoff → lite-execute`, status: "completed" },
   { content: `LE-Phase 1: Task Loading [${taskCount} tasks]`, status: "in_progress", activeForm: "Loading tasks" }
 ]})
@@ -605,6 +559,7 @@ Skill("lite-execute")
 ├── explorations-manifest.json        # Exploration index
 ├── planning-context.md               # Evidence paths + understanding
 ├── plan.json                         # Plan overview (task_ids[])
+├── code-review.md                    # Generated by lite-execute Step 4
 ├── test-checklist.json               # Generated by lite-test-review
 ├── test-review.md                    # Generated by lite-test-review
 └── .task/
@@ -618,9 +573,12 @@ Skill("lite-execute")
 ```
 lite-plan (LP-Phase 1-5)
   └─ Skill("lite-execute")     ← executionContext (global)
-       ├─ Step 1-4: Execute + Review
+       ├─ Step 1-3: Task Execution
+       ├─ Step 4: Code Review (quality/correctness/security)
        └─ Step 5: Skill("lite-test-review")  ← testReviewContext (global)
-            ├─ TR-Phase 1-4: Test + Fix
+            ├─ TR-Phase 1: Detect test framework
+            ├─ TR-Phase 2: Convergence verification (plan criteria)
+            ├─ TR-Phase 3-4: Run tests + Auto-fix
             └─ TR-Phase 5: Report + Sync specs
 ```
 
@@ -629,7 +587,7 @@ lite-plan (LP-Phase 1-5)
 | Error | Resolution |
 |-------|------------|
 | Exploration agent failure | Skip exploration, continue with task description only |
-| Planning agent failure | Fallback to direct planning by Claude |
+| Planning agent failure | Retry with reduced complexity or suggest breaking task |
 | Clarification timeout | Use exploration findings as-is |
 | Confirmation timeout | Save context, display resume instructions |
 | Modify loop > 3 times | Suggest breaking task or using /workflow-plan |
@@ -649,7 +607,7 @@ Auto mode authorizes the complete plan-and-execute workflow with a single confir
 - [ ] Parallel exploration agents launched with run_in_background=false
 - [ ] Explorations manifest built from auto-discovered files
 - [ ] Clarification needs aggregated, deduped, and presented in batches of 4
-- [ ] Plan generated via direct Claude (Low) or cli-lite-planning-agent (Medium/High)
+- [ ] Plan generated via cli-lite-planning-agent
 - [ ] Plan output as two-layer: plan.json (task_ids[]) + .task/TASK-*.json
 - [ ] User confirmation collected (or auto-approved in auto mode)
 - [ ] executionContext fully built with all artifacts and session references

.claude/skills/workflow-lite-test-review/SKILL.md

@@ -8,6 +8,8 @@ allowed-tools: Skill, Agent, AskUserQuestion, TodoWrite, Read, Write, Edit, Bash
 
 Test review and fix engine for lite-execute chain or standalone invocation.
 
+**Project Context**: Run `ccw spec load --category test` for test framework conventions, coverage targets, and fixtures.
+
 ---
 
 ## Usage
@@ -29,31 +31,31 @@ Test review and fix engine for lite-execute chain or standalone invocation.
 
 **Input Source**: `testReviewContext` global variable set by lite-execute Step 4
 
-**Behavior**: Skip session discovery, inherit reviewTool from execution chain, proceed directly to TR-Phase 1.
+**Behavior**: Skip session discovery, inherit convergenceReviewTool from execution chain, proceed directly to TR-Phase 1.
 
-> **Note**: lite-execute Step 4 is the chain gate. Mode 1 invocation means execution is complete — proceed with test review.
+> **Note**: lite-execute Step 5 is the chain gate. Mode 1 invocation means execution + code review are complete — proceed with convergence verification + tests.
 
 ### Mode 2: Standalone
 
 **Trigger**: User calls with session path or `--last`
 
-**Behavior**: Discover session → load plan + tasks → `reviewTool = 'agent'` → proceed to TR-Phase 1.
+**Behavior**: Discover session → load plan + tasks → `convergenceReviewTool = 'agent'` → proceed to TR-Phase 1.
 
 ```javascript
-let sessionPath, plan, taskFiles, reviewTool
+let sessionPath, plan, taskFiles, convergenceReviewTool
 
 if (testReviewContext) {
   // Mode 1: from lite-execute chain
   sessionPath = testReviewContext.session.folder
   plan = testReviewContext.planObject
   taskFiles = testReviewContext.taskFiles.map(tf => JSON.parse(Read(tf.path)))
-  reviewTool = testReviewContext.reviewTool || 'agent'
+  convergenceReviewTool = testReviewContext.convergenceReviewTool || 'agent'
 } else {
   // Mode 2: standalone — find last session or use provided path
   sessionPath = resolveSessionPath($ARGUMENTS)  // Glob('.workflow/.lite-plan/*/plan.json'), take last
   plan = JSON.parse(Read(`${sessionPath}/plan.json`))
   taskFiles = plan.task_ids.map(id => JSON.parse(Read(`${sessionPath}/.task/${id}.json`)))
-  reviewTool = 'agent'
+  convergenceReviewTool = 'agent'
 }
 
 const skipFix = $ARGUMENTS?.includes('--skip-fix') || false
@@ -64,7 +66,7 @@ const skipFix = $ARGUMENTS?.includes('--skip-fix') || false
 | Phase | Core Action | Output |
 |-------|-------------|--------|
 | TR-Phase 1 | Detect test framework + gather changes | testConfig, changedFiles |
-| TR-Phase 2 | Review implementation against convergence criteria | reviewResults[] |
+| TR-Phase 2 | Convergence verification against plan criteria | reviewResults[] |
 | TR-Phase 3 | Run tests + generate checklist | test-checklist.json |
 | TR-Phase 4 | Auto-fix failures (iterative, max 3 rounds) | Fixed code + updated checklist |
 | TR-Phase 5 | Output report + chain to session:sync | test-review.md |
@@ -91,32 +93,45 @@ Output: `testConfig = { command, framework, type }` + `changedFiles[]`
 
 // TodoWrite: Phase 1 → completed, Phase 2 → in_progress
 
-## TR-Phase 2: Review Implementation Against Plan
+## TR-Phase 2: Convergence Verification
 
-**Skip if**: `reviewTool === 'skip'`  — set all tasks to PASS, proceed to Phase 3.
+**Skip if**: `convergenceReviewTool === 'skip'`  — set all tasks to PASS, proceed to Phase 3.
 
-For each task, verify convergence criteria and identify test gaps.
+Verify each task's convergence criteria are met in the implementation and identify test gaps.
 
-**Agent Review** (reviewTool === 'agent', default):
+**Agent Convergence Review** (convergenceReviewTool === 'agent', default):
 
 For each task in taskFiles:
-1. Extract `convergence.criteria[]` and `test` requirements
-2. Find changed files matching `task.files[].path` against `changedFiles`
-3. Read matched files, evaluate each criterion against implementation
-4. Check test coverage: if `task.test.unit` exists but no test files in changedFiles → mark as test gap
-5. Same for `task.test.integration`
-6. Build `reviewResult = { taskId, title, criteria_met[], criteria_unmet[], test_gaps[], files_reviewed[] }`
+1. Extract `convergence.criteria[]` from the task
+2. Match `task.files[].path` against `changedFiles` to find actually-changed files
+3. Read each matched file, verify each convergence criterion with file:line evidence
+4. Check test coverage gaps:
+   - If `task.test.unit` defined but no matching test files in changedFiles → mark as test gap
+   - If `task.test.integration` defined but no integration test in changedFiles → mark as test gap
+5. Build `reviewResult = { taskId, title, criteria_met[], criteria_unmet[], test_gaps[], files_reviewed[] }`
 
-**CLI Review** (reviewTool === 'gemini' or 'codex'):
+**Verdict logic**:
+- PASS = all `convergence.criteria` met + no test gaps
+- PARTIAL = some criteria met OR has test gaps
+- FAIL = no criteria met
+
+**CLI Convergence Review** (convergenceReviewTool === 'gemini' or 'codex'):
 
 ```javascript
-const reviewId = `${sessionId}-tr-review`
-Bash(`ccw cli -p "PURPOSE: Post-execution test review — verify convergence criteria met and identify test gaps
-TASK: • Read plan.json and .task/*.json convergence criteria • For each criterion, check implementation in changed files • Identify missing unit/integration tests • List unmet criteria with file:line evidence
+const reviewId = `${sessionId}-convergence`
+const taskCriteria = taskFiles.map(t => `${t.id}: [${(t.convergence?.criteria || []).join(' | ')}]`).join('\n')
+Bash(`ccw cli -p "PURPOSE: Convergence verification — check each task's completion criteria against actual implementation
+TASK: • For each task below, verify every convergence criterion is satisfied in the changed files • Mark each criterion as MET (with file:line evidence) or UNMET (with what's missing) • Identify test coverage gaps (planned tests not found in changes)
+
+TASK CRITERIA:
+${taskCriteria}
+
+CHANGED FILES: ${changedFiles.join(', ')}
+
 MODE: analysis
-CONTEXT: @${sessionPath}/plan.json @${sessionPath}/.task/*.json @**/* | Memory: lite-execute completed, reviewing convergence
-EXPECTED: Per-task verdict table (PASS/PARTIAL/FAIL) + unmet criteria list + test gap list
-CONSTRAINTS: Read-only | Focus on convergence verification" --tool ${reviewTool} --mode analysis --id ${reviewId}`, { run_in_background: true })
+CONTEXT: @${sessionPath}/plan.json @${sessionPath}/.task/*.json @**/* | Memory: lite-execute completed
+EXPECTED: Per-task verdict (PASS/PARTIAL/FAIL) with per-criterion evidence + test gap list
+CONSTRAINTS: Read-only | Focus strictly on convergence criteria verification, NOT code quality (code review already done in lite-execute)" --tool ${convergenceReviewTool} --mode analysis --id ${reviewId}`, { run_in_background: true })
 // STOP - wait for hook callback, then parse CLI output into reviewResults format
 ```
 
@@ -205,13 +220,13 @@ Skill({ skill: "workflow:session:sync", args: `-y "Test review: ${testChecklist.
 
 ## Data Structures
 
-### testReviewContext (Input - Mode 1, set by lite-execute)
+### testReviewContext (Input - Mode 1, set by lite-execute Step 5)
 
 ```javascript
 {
   planObject: { /* same as executionContext.planObject */ },
   taskFiles: [{ id: string, path: string }],
-  reviewTool: "skip" | "agent" | "gemini" | "codex",
+  convergenceReviewTool: "skip" | "agent" | "gemini" | "codex",
   executionResults: [...],
   originalUserInput: string,
   session: {

.claude/skills/workflow-multi-cli-plan/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: workflow-multi-cli-plan
-description: Multi-CLI collaborative planning with ACE context gathering, iterative cross-verification, and execution handoff
+description: Multi-CLI collaborative planning with codebase context gathering, iterative cross-verification, and execution handoff.
 allowed-tools: Skill, Agent, AskUserQuestion, TodoWrite, Read, Write, Edit, Bash, Glob, Grep
 ---
 
@@ -246,8 +246,8 @@ Agent({
   description: "Generate implementation plan",
   prompt: `
 ## Schema Reference
-Execute: cat ~/.ccw/workflows/cli-templates/schemas/plan-overview-base-schema.json
-Execute: cat ~/.ccw/workflows/cli-templates/schemas/task-schema.json
+Execute: ccw tool exec json_builder '{"cmd":"info","schema":"plan"}'
+Execute: ccw tool exec json_builder '{"cmd":"info","schema":"task"}'
 
 ## Output Format: Two-Layer Structure
 - plan.json: Overview with task_ids[] referencing .task/ files (NO tasks[] array)

.claude/skills/workflow-plan/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: workflow-plan
-description: Unified planning skill - 4-phase planning workflow, plan verification, and interactive replanning. Triggers on "workflow-plan", "workflow-plan-verify", "workflow:replan".
+description: "Unified planning skill - 4-phase planning workflow, plan verification, and interactive replanning. Triggers on \"workflow-plan\", \"workflow-plan-verify\", \"workflow:replan\"."
 allowed-tools: Skill, Agent, AskUserQuestion, TodoWrite, Read, Write, Edit, Bash, Glob, Grep
 ---
 

.claude/skills/workflow-plan/phases/03-conflict-resolution.md

@@ -70,7 +70,7 @@ Task(subagent_type="cli-execution-agent", run_in_background=false, prompt=`
   ## Analysis Steps
 
   ### 0. Load Output Schema (MANDATORY)
-  Execute: cat ~/.ccw/workflows/cli-templates/schemas/conflict-resolution-schema.json
+  Execute: ccw tool exec json_builder '{"cmd":"info","schema":"conflict"}' (get schema summary)
 
   ### 1. Load Context
   - Read existing files from conflict_detection.existing_files
@@ -119,7 +119,7 @@ Task(subagent_type="cli-execution-agent", run_in_background=false, prompt=`
 
   Output to conflict-resolution.json (generated in Phase 4)
 
-  **Schema Reference**: Execute cat ~/.ccw/workflows/cli-templates/schemas/conflict-resolution-schema.json to get full schema
+  **Schema Reference**: Execute ccw tool exec json_builder '{"cmd":"info","schema":"conflict"}' to get schema summary
 
   Return JSON following the schema. Key requirements:
   - Minimum 2 strategies per conflict, max 4

.claude/skills/workflow-plan/phases/05-plan-verify.md

@@ -34,6 +34,10 @@ You **MUST** consider the user input before proceeding (if not empty).
 
 ## Execution
 
+### Step 5.0: Load Validation Context
+
+Run `ccw spec load --category validation` for verification rules and acceptance criteria.
+
 ### Step 5.1: Initialize Analysis Context
 
 ```bash
@@ -191,8 +195,8 @@ Task(
 ## Plan Verification Task
 
 ### MANDATORY FIRST STEPS
-1. Read: ~/.ccw/workflows/cli-templates/schemas/plan-verify-agent-schema.json (dimensions & rules)
-2. Read: ~/.ccw/workflows/cli-templates/schemas/verify-json-schema.json (output schema)
+1. Execute: ccw tool exec json_builder '{"cmd":"info","schema":"plan-verify"}' (dimensions & rules)
+2. Execute: ccw tool exec json_builder '{"cmd":"info","schema":"verify"}' (output schema)
 3. Read: ${session_file} (user intent)
 4. Read: ${PLANNING_NOTES} (constraints & N+1 context)
 5. Read: ${IMPL_PLAN} (implementation plan)

.claude/skills/workflow-tdd-plan/phases/02-context-gathering.md

@@ -99,7 +99,7 @@ Execute **${angle}** exploration for TDD task planning context. Analyze codebase
 ## MANDATORY FIRST STEPS (Execute by Agent)
 1. Run: ccw tool exec get_modules_by_depth '{}' (project structure)
 2. Run: rg -l "{keyword_from_task}" --type ts (locate relevant files)
-3. Execute: cat ~/.ccw/workflows/cli-templates/schemas/explore-json-schema.json (get output schema reference)
+3. Execute: ccw tool exec json_builder '{"cmd":"init","schema":"explore","output":"${sessionFolder}/exploration-${angle}.json"}' (init output + get schema info)
 
 ## Exploration Strategy (${angle} focus)
 
@@ -121,7 +121,7 @@ Execute **${angle}** exploration for TDD task planning context. Analyze codebase
 
 **File**: ${sessionFolder}/exploration-${angle}.json
 
-**Schema Reference**: Schema obtained in MANDATORY FIRST STEPS step 3, follow schema exactly
+**Schema Reference**: Skeleton initialized via json_builder in step 3. Use `set` to populate fields, `validate` before returning.
 
 **Required Fields** (all ${angle} focused):
 - project_structure: Modules/architecture relevant to ${angle}
@@ -141,7 +141,7 @@ Execute **${angle}** exploration for TDD task planning context. Analyze codebase
 - _metadata.exploration_angle: "${angle}"
 
 ## Success Criteria
-- [ ] Schema obtained via cat explore-json-schema.json
+- [ ] Schema initialized via json_builder init
 - [ ] get_modules_by_depth.sh executed
 - [ ] At least 3 relevant files identified with ${angle} rationale
 - [ ] Patterns are actionable (code examples, not generic advice)
@@ -222,6 +222,7 @@ Execute complete context-search-agent workflow for TDD implementation planning:
 ### Phase 1: Initialization & Pre-Analysis
 1. **Project State Loading**:
    - Run: \`ccw spec load --category execution\` to load project context, tech stack, and guidelines.
+   - Run: \`ccw spec load --category test\` to load test framework conventions, coverage targets, and fixtures.
    - If files don't exist, proceed with fresh analysis.
 2. **Detection**: Check for existing context-package (early exit if valid)
 3. **Foundation**: Initialize CodexLens, get project structure, load docs

.claude/skills/workflow-tdd-plan/phases/04-conflict-resolution.md

@@ -70,7 +70,7 @@ Task(subagent_type="cli-execution-agent", run_in_background=false, prompt=`
   ## Analysis Steps
 
   ### 0. Load Output Schema (MANDATORY)
-  Execute: cat ~/.ccw/workflows/cli-templates/schemas/conflict-resolution-schema.json
+  Execute: ccw tool exec json_builder '{"cmd":"info","schema":"conflict"}'
 
   ### 1. Load Context
   - Read existing files from conflict_detection.existing_files
@@ -119,7 +119,7 @@ Task(subagent_type="cli-execution-agent", run_in_background=false, prompt=`
 
   Output to conflict-resolution.json (generated in Phase 4)
 
-  **Schema Reference**: Execute cat ~/.ccw/workflows/cli-templates/schemas/conflict-resolution-schema.json to get full schema
+  **Schema Reference**: Execute ccw tool exec json_builder '{"cmd":"info","schema":"conflict"}' to get schema summary
 
   Return JSON following the schema. Key requirements:
   - Minimum 2 strategies per conflict, max 4

.claude/skills/workflow-tdd-plan/phases/05-tdd-task-generation.md

@@ -237,13 +237,14 @@ MCP Capabilities: {exa_code, exa_web, code_index}
 These files provide project-level constraints that apply to ALL tasks:
 
 1. **ccw spec load --category execution** (project specs and tech analysis)
+2. **ccw spec load --category test** (test framework, coverage targets, conventions)
    - Contains: tech_stack, architecture_type, key_components, build_system, test_framework, coding_conventions, naming_rules, forbidden_patterns, quality_gates, custom_constraints
    - Usage: Populate plan.json shared_context, align task tech choices, set correct test commands
    - Apply as HARD CONSTRAINTS on all generated tasks — task implementation steps,
      acceptance criteria, and convergence.verification MUST respect these guidelines
    - If empty/missing: No additional constraints (proceed normally)
 
-Loading order: \`ccw spec load --category execution\` → planning-notes.md → context-package.json
+Loading order: \`ccw spec load --category execution\` → \`ccw spec load --category test\` → planning-notes.md → context-package.json
 
 ## USER CONFIGURATION (from Phase 0)
 Execution Method: ${userConfig.executionMethod}  // agent|hybrid|cli

.claude/skills/workflow-test-fix/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: workflow-test-fix
-description: Unified test-fix pipeline combining test generation (session, context, analysis, task gen) with iterative test-cycle execution (adaptive strategy, progressive testing, CLI fallback). Triggers on "workflow-test-fix", "workflow-test-fix", "test fix workflow".
+description: Unified test-fix pipeline combining test generation (session, context, analysis, task gen) with iterative test-cycle execution (adaptive strategy, progressive testing, CLI fallback). Triggers on "workflow-test-fix", "test fix workflow".
 allowed-tools: Skill, Agent, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, Read, Write, Edit, Bash, Glob, Grep
 ---
 

.claude/skills/workflow-test-fix/phases/02-test-context-gather.md

@@ -223,7 +223,7 @@ Execute **${angle}** exploration for task planning context. Analyze codebase fro
 ## MANDATORY FIRST STEPS (Execute by Agent)
 1. Run: ccw tool exec get_modules_by_depth '{}' (project structure)
 2. Run: rg -l "{keyword_from_task}" --type ts (locate relevant files)
-3. Execute: cat ~/.ccw/workflows/cli-templates/schemas/explore-json-schema.json (get output schema reference)
+3. Execute: ccw tool exec json_builder '{"cmd":"init","schema":"explore","output":"${sessionFolder}/exploration-${angle}.json"}' (init output + get schema info)
 
 ## Exploration Strategy (${angle} focus)
 
@@ -265,7 +265,7 @@ Execute **${angle}** exploration for task planning context. Analyze codebase fro
 - _metadata.exploration_angle: "${angle}"
 
 ## Success Criteria
-- [ ] Schema obtained via cat explore-json-schema.json
+- [ ] Schema initialized via json_builder init
 - [ ] get_modules_by_depth.sh executed
 - [ ] At least 3 relevant files identified with ${angle} rationale
 - [ ] Patterns are actionable (code examples, not generic advice)
@@ -346,6 +346,7 @@ Execute complete context-search-agent workflow for implementation planning:
 ### Phase 1: Initialization & Pre-Analysis
 1. **Project State Loading**:
    - Run: \`ccw spec load --category execution\` to load project context, tech stack, and guidelines.
+   - Run: \`ccw spec load --category test\` to load test framework conventions, coverage targets, and fixtures.
    - If files don't exist, proceed with fresh analysis.
 2. **Detection**: Check for existing context-package (early exit if valid)
 3. **Foundation**: Initialize CodexLens, get project structure, load docs

.claude/skills/workflow-test-fix/phases/05-test-cycle-execute.md

@@ -249,7 +249,8 @@ Task(
     ${selectedStrategy} - ${strategyDescription}
 
     ## PROJECT CONTEXT (MANDATORY)
-    1. Run: \`ccw spec load --category execution\` (tech stack, test framework, build system, constraints)
+    1. Run: \`ccw spec load --category execution\` (tech stack, build system, constraints)
+    2. Run: \`ccw spec load --category test\` (test framework, coverage targets, conventions)
 
     ## MANDATORY FIRST STEPS
     1. Read test results: ${session.test_results_path}

.codex/AGENTS.md

@@ -105,6 +105,22 @@ ACE search_context (semantic) → smart_search (structured) → read_file (batch
 
 **NEVER** use shell commands (`cat`, `find`, `grep`) when MCP tools are available.
 
+## Workflow Session Awareness
+
+| Workflow | Directory | Summary File |
+|----------|-----------|-------------|
+| `workflow-plan` | `.workflow/active/WFS-*/` | `workflow-session.json` |
+| `workflow-lite-plan` | `.workflow/.lite-plan/{slug}-{date}/` | `plan.json` |
+| `analyze-with-file` | `.workflow/.analysis/ANL-*/` | `conclusions.json` |
+| `multi-cli-plan` | `.workflow/.multi-cli-plan/*/` | `session-state.json` |
+| `lite-fix` | `.workflow/.lite-fix/*/` | `fix-plan.json` |
+| Other | `.workflow/.debug/`, `.workflow/.scratchpad/`, `.workflow/archives/` | — |
+
+Before starting work, scan recent sessions (7 days) to avoid conflicts and reuse prior work:
+- Overlapping file scope → warn, suggest referencing prior session
+- Complementary findings → feed into current task context
+
+
 ## Execution Checklist
 
 **Before**:

.codex/agents/action-planning-agent.toml

@@ -1,20 +1,10 @@
----
-name: action-planning-agent
-description: |
-  Pure execution agent for creating implementation plans based on provided requirements and control flags. This agent executes planning tasks without complex decision logic - it receives context and flags from command layer and produces actionable development plans.
+name = "action_planning_agent"
+description = "Pure execution agent for creating implementation plans based on provided requirements and control flags. This agent executes planning tasks without complex decision logic - it receives context and flags from command layer and produces actionable development plans."
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode = "workspace-write"
 
-  Examples:
-  - Context: Command provides requirements with flags
-    user: "EXECUTION_MODE: DEEP_ANALYSIS_REQUIRED - Implement OAuth2 authentication system"
-    assistant: "I'll execute deep analysis and create a staged implementation plan"
-    commentary: Agent receives flags from command layer and executes accordingly
-
-  - Context: Standard planning execution
-    user: "Create implementation plan for: real-time notifications system"
-    assistant: "I'll create a staged implementation plan using provided context"
-    commentary: Agent executes planning based on provided requirements and context
-color: yellow
----
+developer_instructions = """
 
 ## Overview
 
@@ -878,3 +868,4 @@ Use `analysis_results.complexity` or task count to determine structure:
 - Skip artifact integration when artifacts_inventory is provided
 - Ignore MCP capabilities when available
 - Use fixed pre-analysis steps without task-specific adaptation
+"""

.codex/agents/cli-discuss-agent.toml

@@ -1,11 +1,10 @@
----
-name: cli-discuss-agent
-description: |
-  Multi-CLI collaborative discussion agent with cross-verification and solution synthesis.
-  Orchestrates 5-phase workflow: Context Prep → CLI Execution → Cross-Verify → Synthesize → Output
-color: magenta
-allowed-tools: mcp__ace-tool__search_context(*), Bash(*), Read(*), Write(*), Glob(*), Grep(*)
----
+name = "cli_discuss_agent"
+description = "Multi-CLI collaborative discussion agent with cross-verification and solution synthesis."
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode = "read-only"
+
+developer_instructions = """
 
 You are a specialized CLI discussion agent that orchestrates multiple CLI tools to analyze tasks, cross-verify findings, and synthesize structured solutions.
 
@@ -389,3 +388,4 @@ Write({
 4. Generate more than 4 clarification questions
 5. Ignore previous round context
 6. Assume solution without multi-CLI validation
+"""

.codex/agents/cli-execution-agent.toml

@@ -1,10 +1,10 @@
----
-name: cli-execution-agent
-description: |
-  Intelligent CLI execution agent with automated context discovery and smart tool selection.
-  Orchestrates 5-phase workflow: Task Understanding → Context Discovery → Prompt Enhancement → Tool Execution → Output Routing
-color: purple
----
+name = "cli_execution_agent"
+description = "Intelligent CLI execution agent with automated context discovery and smart tool selection."
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode = "workspace-write"
+
+developer_instructions = '''
 
 You are an intelligent CLI execution specialist that autonomously orchestrates context discovery and optimal tool execution.
 
@@ -330,4 +330,5 @@ Codex unavailable → Gemini/Qwen write mode
 **Memory** (`memory/`):
 - `claude-module-unified.txt` - Universal module/file documentation
 
----
+---
+'''

.codex/agents/cli-explore-agent.toml

@@ -1,10 +1,10 @@
----
-name: cli-explore-agent
-description: |
-  Read-only code exploration agent with dual-source analysis strategy (Bash + Gemini CLI).
-  Orchestrates 4-phase workflow: Task Understanding → Analysis Execution → Schema Validation → Output Generation
-color: yellow
----
+name = "cli_explore_agent"
+description = "Read-only code exploration agent with dual-source analysis strategy (Bash + Gemini CLI)."
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode = "read-only"
+
+developer_instructions = '''
 
 You are a specialized CLI exploration agent that autonomously analyzes codebases and generates structured outputs.
 
@@ -229,3 +229,4 @@ Brief summary:
 **Consumption Pattern**:
 - Plan phase: Fully consumes `exploration-notes.md`
 - Execute phase: Consumes `exploration-notes-refined.md`, reduced noise, improved efficiency
+'''

.codex/agents/cli-lite-planning-agent.toml

@@ -1,16 +1,10 @@
----
-name: cli-lite-planning-agent
-description: |
-  Generic planning agent for lite-plan, collaborative-plan, and lite-fix workflows. Generates structured plan JSON based on provided schema reference.
+name = "cli_lite_planning_agent"
+description = "Generic planning agent for lite-plan, collaborative-plan, and lite-fix workflows. Generates structured plan JSON based on provided schema reference."
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode = "workspace-write"
 
-  Core capabilities:
-  - Schema-driven output (plan-json-schema or fix-plan-json-schema)
-  - Task decomposition with dependency analysis
-  - CLI execution ID assignment for fork/merge strategies
-  - Multi-angle context integration (explorations or diagnoses)
-  - Process documentation (planning-context.md) for collaborative workflows
-color: cyan
----
+developer_instructions = '''
 
 You are a generic planning agent that generates structured plan JSON for lite workflows. Output format is determined by the schema reference provided in the prompt. You execute CLI planning tools (Gemini/Qwen), parse results, and generate planObject conforming to the specified schema.
 
@@ -904,3 +898,4 @@ After Phase 4 planObject generation:
 5. **Return** → Plan with `_metadata.quality_check` containing execution result
 
 **CLI Fallback**: Gemini → Qwen → Skip with warning (if both fail)
+'''

.codex/agents/cli-planning-agent.toml

@@ -1,20 +1,10 @@
----
-name: cli-planning-agent
-description: |
-  Specialized agent for executing CLI analysis tools (Gemini/Qwen) and dynamically generating task JSON files based on analysis results. Primary use case: test failure diagnosis and fix task generation in test-cycle-execute workflow.
+name = "cli_planning_agent"
+description = "Specialized agent for executing CLI analysis tools (Gemini/Qwen) and dynamically generating task JSON files based on analysis results. Primary use case: test failure diagnosis and fix task generation in test-cycle-execute workflow."
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode = "workspace-write"
 
-  Examples:
-  - Context: Test failures detected (pass rate < 95%)
-    user: "Analyze test failures and generate fix task for iteration 1"
-    assistant: "Executing Gemini CLI analysis → Parsing fix strategy → Generating IMPL-fix-1.json"
-    commentary: Agent encapsulates CLI execution + result parsing + task generation
-
-  - Context: Coverage gap analysis
-    user: "Analyze coverage gaps and generate supplement test task"
-    assistant: "Executing CLI analysis for uncovered code paths → Generating test supplement task"
-    commentary: Agent handles both analysis and task JSON generation autonomously
-color: purple
----
+developer_instructions = '''
 
 You are a specialized execution agent that bridges CLI analysis tools with task generation. You execute Gemini/Qwen CLI commands for failure diagnosis, parse structured results, and dynamically generate task JSON files for downstream execution.
 
@@ -560,3 +550,4 @@ See: `.process/iteration-{iteration}-cli-output.txt`
      estimated_complexity: "medium"
    }
    ```
+'''

.codex/agents/code-developer.toml

@@ -1,20 +1,10 @@
----
-name: code-developer
-description: |
-  Pure code execution agent for implementing programming tasks and writing corresponding tests. Focuses on writing, implementing, and developing code with provided context. Executes code implementation using incremental progress, test-driven development, and strict quality standards.
+name = "code_developer"
+description = "Pure code execution agent for implementing programming tasks and writing corresponding tests. Focuses on writing, implementing, and developing code with provided context. Executes code implementation using incremental progress, test-driven development, and strict quality standards."
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode = "workspace-write"
 
-  Examples:
-  - Context: User provides task with sufficient context
-    user: "Implement email validation function following these patterns: [context]"
-    assistant: "I'll implement the email validation function using the provided patterns"
-    commentary: Execute code implementation directly with user-provided context
-
-  - Context: User provides insufficient context
-    user: "Add user authentication"
-    assistant: "I need to analyze the codebase first to understand the patterns"
-    commentary: Use Gemini to gather implementation context, then execute
-color: blue
----
+developer_instructions = '''
 
 You are a code execution specialist focused on implementing high-quality, production-ready code. You receive tasks with context and execute them efficiently using strict development standards.
 
@@ -514,4 +504,5 @@ Before completing any task, verify:
 - Generate detailed summary documents with complete component/method listings
 - Document all new interfaces, types, and constants for dependent task reference
 ### Windows Path Format Guidelines
-- **Quick Ref**: `C:\Users` → MCP: `C:\\Users` | Bash: `/c/Users` or `C:/Users`
+- **Quick Ref**: `C:\Users` → MCP: `C:\\Users` | Bash: `/c/Users` or `C:/Users`
+'''

.codex/agents/conceptual-planning-agent.toml

@@ -1,27 +1,10 @@
----
-name: conceptual-planning-agent
-description: |
-  Specialized agent for dedicated single-role conceptual planning and brainstorming analysis. This agent executes assigned planning role perspective (system-architect, ui-designer, product-manager, etc.) with comprehensive role-specific analysis and structured documentation generation for brainstorming workflows.
+name = "conceptual_planning_agent"
+description = "Specialized agent for dedicated single-role conceptual planning and brainstorming analysis. This agent executes assigned planning role perspective (system-architect, ui-designer, product-manager, etc.) with comprehensive role-specific analysis and structured documentation generation for brainstorming workflows."
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode = "workspace-write"
 
-  Use this agent for:
-  - Dedicated single-role brainstorming analysis (one agent = one role)
-  - Role-specific conceptual planning with user context integration
-  - Strategic analysis from assigned domain expert perspective
-  - Structured documentation generation in brainstorming workflow format
-  - Template-driven role analysis with planning role templates
-  - Comprehensive recommendations within assigned role expertise
-
-  Examples:
-  - Context: Auto brainstorm assigns system-architect role
-    auto.md: Assigns dedicated agent with ASSIGNED_ROLE: system-architect
-    agent: "I'll execute system-architect analysis for this topic, creating architecture-focused conceptual analysis in OUTPUT_LOCATION"
-
-  - Context: Auto brainstorm assigns ui-designer role
-    auto.md: Assigns dedicated agent with ASSIGNED_ROLE: ui-designer
-    agent: "I'll execute ui-designer analysis for this topic, creating UX-focused conceptual analysis in OUTPUT_LOCATION"
-
-color: purple
----
+developer_instructions = """
 
 You are a conceptual planning specialist focused on **dedicated single-role** strategic thinking and requirement analysis for brainstorming workflows. Your expertise lies in executing **one assigned planning role** (system-architect, ui-designer, product-manager, etc.) with comprehensive analysis and structured documentation.
 
@@ -318,4 +301,4 @@ When analysis is complete, ensure:
 **Strategies**: Be concise, use bullet points, reference don't repeat, prioritize top 3-5 items, defer details
 
 **If exceeded**: Split essential vs nice-to-have, move extras to `analysis-appendix.md` (counts toward limit), use executive summary style
-
+"""

.codex/agents/context-search-agent.toml

@@ -1,20 +1,10 @@
----
-name: context-search-agent
-description: |
-  Intelligent context collector for development tasks. Executes multi-layer file discovery, dependency analysis, and generates standardized context packages with conflict risk assessment.
+name = "context_search_agent"
+description = "Intelligent context collector for development tasks. Executes multi-layer file discovery, dependency analysis, and generates standardized context packages with conflict risk assessment."
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode = "read-only"
 
-  Examples:
-  - Context: Task with session metadata
-    user: "Gather context for implementing user authentication"
-    assistant: "I'll analyze project structure, discover relevant files, and generate context package"
-    commentary: Execute autonomous discovery with 3-source strategy
-
-  - Context: External research needed
-    user: "Collect context for Stripe payment integration"
-    assistant: "I'll search codebase, use Exa for API patterns, and build dependency graph"
-    commentary: Combine local search with external research
-color: green
----
+developer_instructions = '''
 
 You are a context discovery specialist focused on gathering relevant project information for development tasks. Execute multi-layer discovery autonomously to build comprehensive context packages.
 
@@ -587,3 +577,4 @@ Output: .workflow/session/{session}/.process/context-package.json
 ### Windows Path Format Guidelines
 - **Quick Ref**: `C:\Users` → MCP: `C:\\Users` | Bash: `/c/Users` or `C:/Users`
 - **Context Package**: Use project-relative paths (e.g., `src/auth/service.ts`)
+'''

.codex/agents/debug-explore-agent.toml

@@ -1,10 +1,10 @@
----
-name: debug-explore-agent
-description: |
-  Hypothesis-driven debugging agent with NDJSON logging, CLI-assisted analysis, and iterative verification.
-  Orchestrates 5-phase workflow: Bug Analysis → Hypothesis Generation → Instrumentation → Log Analysis → Fix Verification
-color: orange
----
+name = "debug_explore_agent"
+description = "Hypothesis-driven debugging agent with NDJSON logging, CLI-assisted analysis, and iterative verification."
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode = "workspace-write"
+
+developer_instructions = '''
 
 You are an intelligent debugging specialist that autonomously diagnoses bugs through evidence-based hypothesis testing and CLI-assisted analysis.
 
@@ -434,3 +434,4 @@ ${nextSteps}
 - Timeout: Analysis 20min | Fix implementation 40min
 
 ---
+'''

.codex/agents/doc-generator.toml

@@ -1,20 +1,10 @@
----
-name: doc-generator
-description: |
-  Intelligent agent for generating documentation based on a provided task JSON with flow_control. This agent autonomously executes pre-analysis steps, synthesizes context, applies templates, and generates comprehensive documentation.
+name = "doc_generator"
+description = "Intelligent agent for generating documentation based on a provided task JSON with flow_control. This agent autonomously executes pre-analysis steps, synthesizes context, applies templates, and generates comprehensive documentation."
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode = "workspace-write"
 
-  Examples:
-  <example>
-  Context: A task JSON with flow_control is provided to document a module.
-  user: "Execute documentation task DOC-001"
-  assistant: "I will execute the documentation task DOC-001. I'll start by running the pre-analysis steps defined in the flow_control to gather context, then generate the specified documentation files."
-  <commentary>
-  The agent is an intelligent, goal-oriented worker that follows instructions from the task JSON to autonomously generate documentation.
-  </commentary>
-  </example>
-
-color: green
----
+developer_instructions = '''
 
 You are an expert technical documentation specialist. Your responsibility is to autonomously **execute** documentation tasks based on a provided task JSON file. You follow `flow_control` instructions precisely, synthesize context, generate or execute documentation generation, and report completion. You do not make planning decisions.
 
@@ -331,4 +321,5 @@ Before completing the task, you must verify the following:
 - **Assume Context**: Do not guess information; gather it autonomously through the `pre_analysis` steps.
 - **Generate Code**: Your role is to document, not to implement.
 - **Skip Quality Checks**: Always perform the full QA checklist before completing a task.
-- **Mix Modes**: Do not generate content in CLI Mode or execute CLI in Agent Mode - respect the `cli_execute` flag.
+- **Mix Modes**: Do not generate content in CLI Mode or execute CLI in Agent Mode - respect the `cli_execute` flag.
+'''

.codex/agents/issue-plan-agent.toml

@@ -1,10 +1,10 @@
----
-name: issue-plan-agent
-description: |
-  Closed-loop issue planning agent combining ACE exploration and solution generation.
-  Receives issue IDs, explores codebase, generates executable solutions with 5-phase tasks.
-color: green
----
+name = "issue_plan_agent"
+description = "Closed-loop issue planning agent combining ACE exploration and solution generation."
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode = "workspace-write"
+
+developer_instructions = """
 
 ## Overview
 
@@ -415,3 +415,4 @@ Each line is a solution JSON containing tasks. Schema: `cat ~/.ccw/workflows/cli
 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: [...] }`
+"""

.codex/agents/issue-queue-agent.toml

@@ -1,10 +1,10 @@
----
-name: issue-queue-agent
-description: |
-  Solution ordering agent for queue formation with Gemini CLI conflict analysis.
-  Receives solutions from bound issues, uses Gemini for intelligent conflict detection, produces ordered execution queue.
-color: orange
----
+name = "issue_queue_agent"
+description = "Solution ordering agent for queue formation with Gemini CLI conflict analysis."
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode = "workspace-write"
+
+developer_instructions = '''
 
 ## Overview
 
@@ -309,3 +309,4 @@ Return brief summaries; full conflict details in separate files:
 ```
 - `clarifications`: Only present if unresolved high-severity conflicts exist
 - No markdown, no prose - PURE JSON only
+'''

.codex/agents/memory-bridge.toml

@@ -1,8 +1,10 @@
----
-name: memory-bridge
-description: Execute complex project documentation updates using script coordination
-color: purple
----
+name = "memory_bridge"
+description = "Execute complex project documentation updates using script coordination"
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode = "workspace-write"
+
+developer_instructions = """
 
 You are a documentation update coordinator for complex projects. Orchestrate parallel CLAUDE.md updates efficiently and track every module.
 
@@ -93,4 +95,5 @@ Examples:
 - Progress: Update TodoWrite for each depth
 - End: "✅ Updated [count] CLAUDE.md files" + git status
 
-**Do not explain, just execute efficiently.**
+**Do not explain, just execute efficiently.**
+"""

.codex/agents/tdd-developer.toml

@@ -1,23 +1,10 @@
----
-name: tdd-developer
-description: |
-  TDD-aware code execution agent specialized for Red-Green-Refactor workflows. Extends code-developer with TDD cycle awareness, automatic test-fix iteration, and CLI session resumption. Executes TDD tasks with phase-specific logic and test-driven quality gates.
+name = "tdd_developer"
+description = "TDD-aware code execution agent specialized for Red-Green-Refactor workflows. Extends code-developer with TDD cycle awareness, automatic test-fix iteration, and CLI session resumption. Executes TDD tasks with phase-specific logic and test-driven quality gates."
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode = "workspace-write"
 
-  Examples:
-  - Context: TDD task with Red-Green-Refactor phases
-    user: "Execute TDD task IMPL-1 with test-first development"
-    assistant: "I'll execute the Red-Green-Refactor cycle with automatic test-fix iteration"
-    commentary: Parse TDD metadata, execute phases sequentially with test validation
-
-  - Context: Green phase with failing tests
-    user: "Green phase implementation complete but tests failing"
-    assistant: "Starting test-fix cycle (max 3 iterations) with Gemini diagnosis"
-    commentary: Iterative diagnosis and fix until tests pass or max iterations reached
-
-color: green
-extends: code-developer
-tdd_aware: true
----
+developer_instructions = """
 
 You are a TDD-specialized code execution agent focused on implementing high-quality, test-driven code. You receive TDD tasks with Red-Green-Refactor cycles and execute them with phase-specific logic and automatic test validation.
 
@@ -510,3 +497,4 @@ if (taskJson.meta?.tdd_workflow) {
   agent = "code-developer"  // Use generic agent
 }
 ```
+"""