claude-code-workflow 7.2.25 → 7.2.27

package/.claude/CLAUDE.md

@@ -36,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

package/.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**:

package/.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: 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: 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":{...}}
+]}'
+```
 
-**Step 1: Read Schema FIRST**
+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: 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}
+]}'
 ```
-Read(schema_file_path)
+
+**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 2: Extract Schema Requirements**
-
-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
-
-**Step 3: File Rationale Validation** (MANDATORY for relevant_files / affected_files)
-
-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: 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)
-
-**MANDATORY WORKFLOW**:
+### File Output
 
-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>

package/.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)

package/.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")

package/.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

package/.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

package/.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

package/.claude/skills/team-arch-opt/SKILL.md

@@ -78,7 +78,7 @@ Execute built-in Phase 1 (task discovery) -> role Phase 2-4 -> built-in Phase 5
 })
 ```
 
-**Inner Loop roles** (refactorer): Set `inner_loop: true`.
+**Inner Loop roles** (refactorer): Set `inner_loop` dynamically — `true` for single mode, `false` for fan-out/independent (parallel branches).
 **Single-task roles** (analyzer, designer, validator, reviewer): Set `inner_loop: false`.
 
 ## User Commands

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

@@ -82,7 +82,9 @@ Find ready tasks, spawn workers, STOP.
 2. No ready + work in progress -> report waiting, STOP
 3. No ready + nothing in progress -> handleComplete
 4. Has ready -> for each:
-   a. Check if inner loop role with active worker -> skip (worker picks up)
+   a. Check inner_loop: parse task description `InnerLoop:` field (NOT role.md default)
+      - InnerLoop: true AND same-role worker already active -> skip (worker picks up)
+      - InnerLoop: false OR no active same-role worker -> spawn new worker
    b. TaskUpdate -> in_progress
    c. team_msg log -> task_unblocked
    d. Spawn team-worker (see SKILL.md Spawn Template):

package/.claude/skills/team-arch-opt/roles/refactorer/role.md

@@ -1,12 +1,14 @@
 ---
 role: refactorer
 prefix: REFACTOR
-inner_loop: true
+inner_loop: dynamic
 message_types: [state_update]
 ---
 
 # Code Refactorer
 
+> **inner_loop: dynamic** — Dispatch sets per-task: `true` for single mode (one REFACTOR task with iterative fix cycles), `false` for fan-out/independent modes (REFACTOR-B01..N run as separate parallel workers). When false, each branch gets its own worker.
+
 Implement architecture refactoring changes following the design plan. For FIX tasks, apply targeted corrections based on review/validation feedback.
 
 ## Modes

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

@@ -64,10 +64,10 @@
       "type": "code_generation",
       "description": "Implements architecture refactoring changes following the design plan",
       "role_spec": "roles/refactorer/role.md",
-      "inner_loop": true,
+      "inner_loop": "dynamic",
       "frontmatter": {
         "prefix": "REFACTOR",
-        "inner_loop": true,
+        "inner_loop": "dynamic",
         "additional_prefixes": ["FIX"],
         "discuss_rounds": [],
         "cli_tools": ["explore"],

package/.claude/skills/team-coordinate/SKILL.md

@@ -130,9 +130,10 @@ Execute built-in Phase 1 (task discovery) -> role-spec Phase 2-4 -> built-in Pha
 })
 ```
 
-**Inner Loop roles** (role has 2+ serial same-prefix tasks): Set `inner_loop: true`. The team-worker agent handles the loop internally.
-
-**Single-task roles**: Set `inner_loop: false`.
+**Inner Loop**: Determined per-task from task description `InnerLoop:` field, not per-role:
+- Serial chain (2+ tasks, each blockedBy previous): `inner_loop: true` — single worker loops
+- Parallel tasks (no mutual blockedBy): `inner_loop: false` — separate workers per task
+- Single-task roles: `inner_loop: false`
 
 ---
 

package/.claude/skills/team-coordinate/roles/coordinator/commands/analyze-task.md

@@ -130,7 +130,7 @@ For each role, determine frontmatter and generation hints:
 | Field | Derivation |
 |-------|------------|
 | `prefix` | From capability prefix (e.g., RESEARCH, DRAFT, IMPL) |
-| `inner_loop` | `true` if role has 2+ serial same-prefix tasks |
+| `inner_loop` | `true` if role has 2+ same-prefix tasks AND they form a serial chain (each blockedBy the previous). `false` if tasks are parallel (no mutual blockedBy) or role has only 1 task |
 | `CLI tools` | Suggested, not mandatory — coordinator may adjust based on task needs |
 | `pattern_hint` | Reference pattern name from role-spec-template (research/document/code/analysis/validation) — guides coordinator's Phase 2-4 composition, NOT a rigid template selector |
 | `output_type` | `artifact` (new files in session/artifacts/) / `codebase` (modify existing project files) / `mixed` (both) — determines verification strategy in Behavioral Traits |

package/.claude/skills/team-coordinate/roles/coordinator/commands/dispatch.md

@@ -95,9 +95,10 @@ RoleSpec: <session-folder>/role-specs/<role-name>.md
 
 | Condition | InnerLoop |
 |-----------|-----------|
-| Role has 2+ serial same-prefix tasks | true |
+| Role has 2+ same-prefix tasks forming a serial chain (each blockedBy the previous) | true |
 | Role has 1 task | false |
-| Tasks are parallel (no dependency between them) | false |
+| Role has 2+ same-prefix tasks but they are parallel (no mutual blockedBy) | false |
+| Mixed: some serial, some parallel within same role | Set per-task: true for serial chain members, false for parallel members |
 
 ### Dependency Validation
 

package/.claude/skills/team-coordinate/roles/coordinator/commands/monitor.md

@@ -144,9 +144,10 @@ Ready tasks found?
   +- NONE + work in progress -> report waiting -> STOP
   +- NONE + nothing in progress -> PIPELINE_COMPLETE -> handleComplete
   +- HAS ready tasks -> for each:
-      +- Is task owner an Inner Loop role AND that role already has an active_worker?
+      +- Parse task description `InnerLoop:` field (NOT session.roles[].inner_loop)
+      +- InnerLoop: true AND same-role worker already in active_workers?
       |   +- YES -> SKIP spawn (existing worker will pick it up via inner loop)
-      |   +- NO -> normal spawn below
+      |   +- NO -> normal spawn below (InnerLoop: false OR no active same-role worker)
       +- TaskUpdate -> in_progress
       +- team_msg log -> task_unblocked (session_id=<session-id>)
       +- Spawn team-worker (see spawn tool call below)

package/.claude/skills/team-coordinate/roles/coordinator/role.md

@@ -207,15 +207,9 @@ Regardless of complexity score or role count, coordinator MUST:
    - `project_root` = result of `Bash({ command: "pwd" })`
    - `skill_root` = `<project_root>/.claude/skills/team-coordinate`
 
-2. **Check `needs_research` flag** from task-analysis.json:
-   - If `true`: **Spawn researcher worker first** to gather codebase context
-     - Wait for researcher callback
-     - Merge research findings into task context
-     - Update task-analysis.json with enriched context
+2. **Generate session ID**: `TC-<slug>-<date>` (slug from first 3 meaningful words of task)
 
-3. **Generate session ID**: `TC-<slug>-<date>` (slug from first 3 meaningful words of task)
-
-4. **Create session folder structure**:
+3. **Create session folder structure**:
    ```
    .workflow/.team/<session-id>/
    +-- role-specs/
@@ -226,11 +220,11 @@ Regardless of complexity score or role count, coordinator MUST:
    +-- .msg/
    ```
 
-5. **Call TeamCreate** with team name derived from session ID
+4. **Call TeamCreate** with team name derived from session ID
 
-6. **Read `specs/role-spec-template.md`** for Behavioral Traits + Reference Patterns
+5. **Read `specs/role-spec-template.md`** for Behavioral Traits + Reference Patterns
 
-7. **For each role in task-analysis.json#roles**:
+6. **For each role in task-analysis.json#roles**:
    - Fill YAML frontmatter: role, prefix, inner_loop, additional_members, message_types
    - **Compose Phase 2-4 content** (NOT copy from template):
      - Phase 2: Derive input sources and context loading steps from **task description + upstream dependencies**
@@ -239,14 +233,14 @@ Regardless of complexity score or role count, coordinator MUST:
      - Reference Patterns may guide phase structure, but task description determines specific content
    - Write generated role-spec to `<session>/role-specs/<role-name>.md`
 
-8. **Register roles** in team-session.json#roles (with `role_spec` path instead of `role_file`)
+7. **Register roles** in team-session.json#roles (with `role_spec` path instead of `role_file`)
 
-9. **Initialize shared infrastructure**:
+8. **Initialize shared infrastructure**:
    - `wisdom/learnings.md`, `wisdom/decisions.md`, `wisdom/issues.md` (empty with headers)
    - `explorations/cache-index.json` (`{ "entries": [] }`)
    - `discussions/` (empty directory)
 
-10. **Initialize pipeline metadata** via team_msg:
+9. **Initialize pipeline metadata** via team_msg:
 ```typescript
 // 使用 team_msg 将 pipeline 元数据写入 .msg/meta.json
 // 注意: 此处为动态角色，执行时需将 <placeholders> 替换为 task-analysis.json 中生成的实际角色列表
@@ -265,7 +259,14 @@ mcp__ccw-tools__team_msg({
 })
 ```
 
-11. **Write team-session.json** with: session_id, task_description, status="active", roles, pipeline (empty), active_workers=[], completion_action="interactive", created_at
+10. **Write team-session.json** with: session_id, task_description, status="active", roles, pipeline (empty), active_workers=[], completion_action="interactive", created_at
+
+11. **Check `needs_research` flag** from task-analysis.json:
+    - If `true`: Spawn researcher worker (role-spec now exists from step 6) to gather codebase context
+      - Wait for researcher callback
+      - Merge research findings into task context
+      - Update task-analysis.json with enriched context
+    - If `false`: Skip, proceed to Phase 3
 
 **Success**: Session created, role-spec files generated, shared infrastructure initialized.
 

package/.claude/skills/team-coordinate/specs/pipelines.md

@@ -38,18 +38,20 @@ Phase 3-N: monitor.md
 
 ## Dependency Graph Structure
 
-task-analysis.json encodes the pipeline:
+task-analysis.json encodes the pipeline as adjacency list (task ID -> blockedBy array):
 
 ```json
 {
   "dependency_graph": {
-    "RESEARCH-001": { "role": "researcher", "blockedBy": [], "priority": "P0" },
-    "IMPL-001":     { "role": "developer",  "blockedBy": ["RESEARCH-001"], "priority": "P1" },
-    "TEST-001":     { "role": "tester",     "blockedBy": ["IMPL-001"], "priority": "P2" }
+    "RESEARCH-001": [],
+    "IMPL-001": ["RESEARCH-001"],
+    "TEST-001": ["IMPL-001"]
   }
 }
 ```
 
+Role mapping comes from `task-analysis.json#capabilities[].tasks[]`, not from the dependency graph itself.
+
 ## Role-Worker Map
 
 Dynamic — loaded from session role-specs at runtime:
@@ -64,6 +66,7 @@ Role-spec files contain YAML frontmatter:
 role: <role-name>
 prefix: <PREFIX>
 inner_loop: <true|false>
+output_tag: "[<role-name>]"
 message_types:
   success: <type>
   error: error

package/.claude/skills/team-coordinate/specs/role-spec-template.md

@@ -11,6 +11,7 @@ Template used by coordinator to generate lightweight worker role-spec files at r
 role: <role_name>
 prefix: <PREFIX>
 inner_loop: <true|false>
+output_tag: "[<role_name>]"
 CLI tools: [<CLI tool-names>]
 message_types:
   success: <prefix>_complete

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

@@ -40,7 +40,7 @@ Skill(skill="team-lifecycle-v4", args="task description")
 | analyst | [roles/analyst/role.md](roles/analyst/role.md) | RESEARCH-* | false |
 | writer | [roles/writer/role.md](roles/writer/role.md) | DRAFT-* | true |
 | planner | [roles/planner/role.md](roles/planner/role.md) | PLAN-* | true |
-| executor | [roles/executor/role.md](roles/executor/role.md) | IMPL-* | true |
+| executor | [roles/executor/role.md](roles/executor/role.md) | IMPL-* | dynamic |
 | tester | [roles/tester/role.md](roles/tester/role.md) | TEST-* | false |
 | reviewer | [roles/reviewer/role.md](roles/reviewer/role.md) | REVIEW-*, QUALITY-*, IMPROVE-* | false |
 | supervisor | [roles/supervisor/role.md](roles/supervisor/role.md) | CHECKPOINT-* | false |