Team Issue

Team Issue Resolution

Orchestrate issue resolution pipeline: explore context -> plan solution -> review (optional) -> marshal queue -> implement. Supports Quick, Full, and Batch pipelines with review-fix cycle.

Architecture

Skill(skill="team-issue", args="<issue-ids> [--mode=<mode>]")
                    |
         SKILL.md (this file) = Router
                    |
     +--------------+--------------+
     |                             |
  no --role flag              --role <name>
     |                             |
  Coordinator                  Worker
  roles/coordinator/role.md    roles/<name>/role.md
     |
     +-- clarify -> dispatch -> spawn workers -> STOP
                                    |
             +-------+-------+-------+-------+
             v       v       v       v       v
          [explor] [plann] [review] [integ] [imple]

Role Registry

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: TISL
• Session path: .workflow/.team/TISL-<slug>-<date>/
• Team name: issue
• 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: "issue",
  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: issue
requirement: <task-description>
inner_loop: false

## Progress Milestones
session_id: <session-id>
Report progress via team_msg at natural phase boundaries (context loaded -> core work done -> verification).
Report blockers immediately via team_msg type="blocker".
Report completion via team_msg type="task_complete" after final SendMessage.

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).`
})

Parallel spawn (Batch mode, N explorer or M implementer instances):

Agent({
  subagent_type: "team-worker",
  name: "<role>-<N>",
  team_name: "issue",
  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: issue
requirement: <task-description>
agent_name: <role>-<N>
inner_loop: false

## Progress Milestones
session_id: <session-id>
Report progress via team_msg at natural phase boundaries (context loaded -> core work done -> verification).
Report blockers immediately via team_msg type="blocker".
Report completion via team_msg type="task_complete" after final SendMessage.

Read role_spec file (@<skill_root>/roles/<role>/role.md) to load Phase 2-4 domain instructions.
Execute built-in Phase 1 (task discovery, owner=<role>-<N>) -> role Phase 2-4 -> built-in Phase 5 (report).`
})

User Commands

Session Directory

.workflow/.team/TISL-<slug>-<date>/
├── session.json                    # Session metadata + pipeline + fix_cycles
├── task-analysis.json              # Coordinator analyze output
├── .msg/
│   ├── messages.jsonl              # Message bus log
│   └── meta.json                   # Session state + cross-role state
├── wisdom/                         # Cross-task knowledge
│   ├── learnings.md
│   ├── decisions.md
│   ├── conventions.md
│   └── issues.md
├── explorations/                   # Explorer output
│   └── context-<issueId>.json
├── solutions/                      # Planner output
│   └── solution-<issueId>.json
├── audits/                         # Reviewer output
│   └── audit-report.json
├── queue/                          # Integrator output (also .workflow/issues/queue/)
└── builds/                         # Implementer output

Specs Reference

• specs/pipelines.md — Pipeline definitions and task registry

Error Handling

Analyze Task

Parse user issue description -> detect required capabilities -> assess complexity -> select pipeline mode.

CONSTRAINT: Text-level analysis only. NO source code reading, NO codebase exploration.

Signal Detection

Dependency Graph

Natural ordering tiers:

• Tier 0: explorer (context analysis — no dependencies)
• Tier 1: planner (requires explorer output)
• Tier 2: reviewer (requires planner output, full/batch modes only)
• Tier 3: integrator (requires reviewer or planner output)
• Tier 4: implementer (requires integrator output)

Complexity Scoring

Results:

• 0-2: Low -> quick (4 tasks: EXPLORE → SOLVE → MARSHAL → BUILD)
• 3-4: Medium -> full (5 tasks: EXPLORE → SOLVE → AUDIT → MARSHAL → BUILD)
• 5+: High -> batch (N+N+1+1+M tasks, parallel exploration and implementation)

Pipeline Selection

Output

Write <session>/task-analysis.json:

{
  "task_description": "<original>",
  "pipeline_type": "<quick|full|batch>",
  "issue_ids": ["<id1>", "<id2>"],
  "capabilities": [{ "name": "<cap>", "prefix": "<PREFIX>", "keywords": ["..."] }],
  "dependency_graph": { "<TASK-ID>": { "role": "<role>", "blockedBy": ["..."], "priority": "P0|P1|P2" } },
  "roles": [{ "name": "<role>", "prefix": "<PREFIX>", "inner_loop": false }],
  "complexity": { "score": 0, "level": "Low|Medium|High" },
  "parallel_explorers": 1,
  "parallel_builders": 1
}

Dispatch

Create the issue resolution task chain with correct dependencies and structured task descriptions based on selected pipeline mode.

Context Loading

1. Load requirement, pipeline mode, issue IDs, and execution method from session.json 2. Determine task chain from pipeline mode

Task Description Template

Every task description uses structured format:

TaskCreate({
  subject: "<TASK-ID>",
  description: "PURPOSE: <what this task achieves> | Success: <completion criteria>
TASK:
  - <step 1>
  - <step 2>
  - <step 3>
CONTEXT:
  - Session: <session-folder>
  - Issue IDs: <issue-id-list>
  - Upstream artifacts: <artifact-list>
EXPECTED: <deliverable path> + <quality criteria>
CONSTRAINTS: <scope limits>
---
InnerLoop: false
execution_method: <method>
code_review: <setting>"
})
TaskUpdate({ taskId: "<TASK-ID>", addBlockedBy: [<dependency-list>], owner: "<role>" })

Pipeline Router

---

Quick Pipeline

EXPLORE-001 (explorer):

TaskCreate({
  subject: "EXPLORE-001",
  description: "PURPOSE: Analyze issue context and map codebase impact | Success: Context report with relevant files and dependencies
TASK:
  - Load issue details via ccw issue status
  - Explore codebase for relevant files and patterns
  - Assess complexity and impact scope
CONTEXT:
  - Session: <session-folder>
  - Issue IDs: <issue-id-list>
EXPECTED: <session>/explorations/context-<issueId>.json with relevant files, dependencies, and impact assessment
CONSTRAINTS: Exploration and analysis only, no solution design
---
InnerLoop: false"
})
TaskUpdate({ taskId: "EXPLORE-001", owner: "explorer" })

SOLVE-001 (planner):

TaskCreate({
  subject: "SOLVE-001",
  description: "PURPOSE: Design solution and decompose into implementation tasks | Success: Bound solution with task decomposition
TASK:
  - Load explorer context report
  - Generate solution plan via CLI
  - Bind solution to issue
CONTEXT:
  - Session: <session-folder>
  - Issue IDs: <issue-id-list>
  - Upstream artifacts: explorations/context-<issueId>.json
EXPECTED: <session>/solutions/solution-<issueId>.json with solution plan and task list
CONSTRAINTS: Solution design only, no code implementation
---
InnerLoop: false"
})
TaskUpdate({ taskId: "SOLVE-001", addBlockedBy: ["EXPLORE-001"], owner: "planner" })

MARSHAL-001 (integrator):

TaskCreate({
  subject: "MARSHAL-001",
  description: "PURPOSE: Form execution queue with conflict detection and ordering | Success: Execution queue file with resolved conflicts
TASK:
  - Verify all issues have bound solutions
  - Detect file conflicts between solutions
  - Produce ordered execution queue with DAG-based parallel groups
CONTEXT:
  - Session: <session-folder>
  - Issue IDs: <issue-id-list>
  - Upstream artifacts: solutions/solution-<issueId>.json
EXPECTED: .workflow/issues/queue/execution-queue.json with queue, conflicts, parallel groups
CONSTRAINTS: Queue formation only, no implementation
---
InnerLoop: false"
})
TaskUpdate({ taskId: "MARSHAL-001", addBlockedBy: ["SOLVE-001"], owner: "integrator" })

BUILD-001 (implementer):

TaskCreate({
  subject: "BUILD-001",
  description: "PURPOSE: Implement solution plan and verify with tests | Success: Code changes committed, tests pass
TASK:
  - Load bound solution and explorer context
  - Route to execution backend (Auto/Codex/Gemini)
  - Run tests and verify implementation
  - Commit changes
CONTEXT:
  - Session: <session-folder>
  - Issue IDs: <issue-id-list>
  - Upstream artifacts: explorations/context-<issueId>.json, solutions/solution-<issueId>.json, queue/execution-queue.json
EXPECTED: <session>/builds/ with implementation results, tests passing
CONSTRAINTS: Follow solution plan, no scope creep
---
InnerLoop: false
execution_method: <execution_method>
code_review: <code_review>"
})
TaskUpdate({ taskId: "BUILD-001", addBlockedBy: ["MARSHAL-001"], owner: "implementer" })

---

Full Pipeline

Creates 5 tasks. EXPLORE-001 and SOLVE-001 same as Quick, then AUDIT gate before MARSHAL and BUILD.

AUDIT-001 (reviewer):

TaskCreate({
  subject: "AUDIT-001",
  description: "PURPOSE: Review solution for technical feasibility, risk, and completeness | Success: Clear verdict (approved/concerns/rejected) with scores
TASK:
  - Load explorer context and bound solution
  - Score across 3 dimensions: technical feasibility (40%), risk (30%), completeness (30%)
  - Produce verdict: approved (>=80), concerns (60-79), rejected (<60)
CONTEXT:
  - Session: <session-folder>
  - Issue IDs: <issue-id-list>
  - Upstream artifacts: explorations/context-<issueId>.json, solutions/solution-<issueId>.json
EXPECTED: <session>/audits/audit-report.json with per-issue scores and overall verdict
CONSTRAINTS: Review only, do not modify solutions
---
InnerLoop: false"
})
TaskUpdate({ taskId: "AUDIT-001", addBlockedBy: ["SOLVE-001"], owner: "reviewer" })

MARSHAL-001: Same as Quick, but addBlockedBy: ["AUDIT-001"].

BUILD-001: Same as Quick, addBlockedBy: ["MARSHAL-001"].

---

Batch Pipeline

Creates tasks in parallel batches. Issue count = N, BUILD tasks = M (from queue parallel groups).

EXPLORE-001..N (explorer, parallel):

For each issue in issue_ids (up to 5), create an EXPLORE task with distinct owner:

TaskCreate({
  subject: "EXPLORE-<NNN>",
  description: "PURPOSE: Analyze issue <issueId> context and map codebase impact | Success: Context report for <issueId>
TASK:
  - Load issue details for <issueId>
  - Explore codebase for relevant files
  - Assess complexity and impact scope
CONTEXT:
  - Session: <session-folder>
  - Issue IDs: <issueId>
EXPECTED: <session>/explorations/context-<issueId>.json
CONSTRAINTS: Single issue scope, exploration only
---
InnerLoop: false"
})
TaskUpdate({ taskId: "EXPLORE-<NNN>", owner: "explorer-<N>" })

SOLVE-001..N (planner, sequential after all EXPLORE):

TaskCreate({
  subject: "SOLVE-<NNN>",
  description: "PURPOSE: Design solution for <issueId> | Success: Bound solution with tasks
TASK:
  - Load explorer context for <issueId>
  - Generate solution plan
  - Bind solution
CONTEXT:
  - Session: <session-folder>
  - Issue IDs: <issueId>
  - Upstream artifacts: explorations/context-<issueId>.json
EXPECTED: <session>/solutions/solution-<issueId>.json
CONSTRAINTS: Solution design only
---
InnerLoop: false"
})
TaskUpdate({ taskId: "SOLVE-<NNN>", addBlockedBy: ["EXPLORE-001", ..., "EXPLORE-<N>"], owner: "planner" })

AUDIT-001 (reviewer, batch review):

TaskCreate({
  subject: "AUDIT-001",
  description: "PURPOSE: Batch review all solutions | Success: Verdict for each solution
TASK:
  - Load all explorer contexts and bound solutions
  - Score each solution across 3 dimensions
  - Produce per-issue verdicts and overall verdict
CONTEXT:
  - Session: <session-folder>
  - Issue IDs: <all-issue-ids>
  - Upstream artifacts: explorations/*.json, solutions/*.json
EXPECTED: <session>/audits/audit-report.json with batch results
CONSTRAINTS: Review only
---
InnerLoop: false"
})
TaskUpdate({ taskId: "AUDIT-001", addBlockedBy: ["SOLVE-001", ..., "SOLVE-<N>"], owner: "reviewer" })

MARSHAL-001 (integrator): addBlockedBy: ["AUDIT-001"].

BUILD-001..M (implementer, DAG parallel):

Note: In Batch mode, BUILD task count M is not known at dispatch time (depends on MARSHAL queue output). Defer BUILD task creation to handleCallback when MARSHAL completes. Coordinator creates BUILD tasks dynamically after reading execution-queue.json.

When M is known (deferred creation after MARSHAL), assign distinct owners:

TaskCreate({
  subject: "BUILD-<NNN>",
  description: "PURPOSE: Implement solution for <issueId> | Success: Code committed, tests pass
TASK:
  - Load bound solution and explorer context
  - Execute implementation via <execution_method>
  - Run tests, commit
CONTEXT:
  - Session: <session-folder>
  - Issue IDs: <issueId>
  - Upstream artifacts: explorations/context-<issueId>.json, solutions/solution-<issueId>.json, queue/execution-queue.json
EXPECTED: <session>/builds/ with results
CONSTRAINTS: Follow solution plan
---
InnerLoop: false
execution_method: <execution_method>
code_review: <code_review>"
})
TaskUpdate({ taskId: "BUILD-<NNN>", addBlockedBy: ["MARSHAL-001"], owner: "implementer-<M>" })

---

Review-Fix Cycle (Full/Batch modes)

When AUDIT rejects a solution, coordinator creates fix tasks dynamically in handleCallback — NOT at dispatch time.

SOLVE-fix-001 (planner, revision):

TaskCreate({
  subject: "SOLVE-fix-001",
  description: "PURPOSE: Revise solution addressing reviewer feedback (fix cycle <round>) | Success: Revised solution addressing rejection reasons
TASK:
  - Read reviewer feedback from audit report
  - Design alternative approach addressing concerns
  - Re-bind revised solution
CONTEXT:
  - Session: <session-folder>
  - Issue IDs: <rejected-issue-ids>
  - Upstream artifacts: audits/audit-report.json
  - Reviewer feedback: <rejection-reasons>
EXPECTED: <session>/solutions/solution-<issueId>.json (revised)
CONSTRAINTS: Address reviewer concerns specifically
---
InnerLoop: false"
})
TaskUpdate({ taskId: "SOLVE-fix-001", addBlockedBy: ["AUDIT-001"], owner: "planner" })

AUDIT-002 (reviewer, re-review):

TaskCreate({
  subject: "AUDIT-002",
  description: "PURPOSE: Re-review revised solution (fix cycle <round>) | Success: Verdict on revised solution
TASK:
  - Load revised solution
  - Re-evaluate previously rejected dimensions
  - Produce updated verdict
CONTEXT:
  - Session: <session-folder>
  - Issue IDs: <rejected-issue-ids>
  - Upstream artifacts: solutions/solution-<issueId>.json (revised), audits/audit-report.json
EXPECTED: <session>/audits/audit-report.json (updated)
CONSTRAINTS: Focus on previously rejected dimensions
---
InnerLoop: false"
})
TaskUpdate({ taskId: "AUDIT-002", addBlockedBy: ["SOLVE-fix-001"], owner: "reviewer" })

Validation

1. Verify all tasks created with TaskList() 2. Check dependency chain integrity:

• No circular dependencies
• All blockedBy references exist
• First task(s) have empty blockedBy (EXPLORE tasks)

3. Log task count and pipeline mode 4. Verify mode-specific constraints:

Monitor Pipeline

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_FIX_CYCLES: 2

Handler Router

handleCallback

Worker completed. Process and advance.

1. Parse message to identify role and task ID:

2. Mark task as completed: TaskUpdate({ taskId: "<task-id>", status: "completed" }) 3. Record completion in session state

4. Review gate check (when reviewer completes):

• If completed task is AUDIT-* AND pipeline is full or batch:
• Read audit report from <session>/audits/audit-report.json
• Read .msg/meta.json for fix_cycles

• Log team_msg with type "review_result" or "fix_required"
• If force proceeding past rejection, mark skipped fix tasks as completed (skip)

5. Deferred BUILD task creation (when integrator completes):

• If completed task is MARSHAL-* AND pipeline is batch:
• Read execution queue from .workflow/issues/queue/execution-queue.json
• Parse parallel_groups to determine BUILD task count M
• Create BUILD-001..M tasks dynamically (see dispatch.md Batch Pipeline BUILD section)
• Proceed to handleSpawnNext

6. Proceed to handleSpawnNext

handleCheck

Read-only status report, then STOP.

Worker Progress (from message bus):

Before generating status output, read worker milestones:

const progressMsgs = mcp__ccw-tools__team_msg({
  operation: "list", session_id: sessionId, type: "progress", last: 50
})
const blockerMsgs = mcp__ccw-tools__team_msg({
  operation: "list", session_id: sessionId, type: "blocker", last: 10
})

// Aggregate latest milestone per task
const taskProgress = {}
for (const msg of (progressMsgs.result?.messages || [])) {
  const tid = msg.data?.task_id
  if (tid && (!taskProgress[tid] || msg.ts > taskProgress[tid].ts)) {
    taskProgress[tid] = { phase: msg.data.phase, pct: msg.data.progress_pct, ts: msg.ts }
  }
}

Include in status output:

• Per-worker latest milestone (phase + progress_pct) next to task status
• Active blockers section (if any blockerMsgs found)

[coordinator] Pipeline Status (<pipeline-mode>)
[coordinator] Progress: <done>/<total> (<pct>%)
[coordinator] Active: <workers with elapsed time>
[coordinator] Ready: <pending tasks with resolved deps>
[coordinator] Fix Cycles: <fix_cycles>/<max_fix_cycles>
[coordinator] Commands: 'resume' to advance | 'check' to refresh

handleResume

1. Audit task list: Tasks stuck in "in_progress" -> reset to "pending" 2. Proceed to handleSpawnNext

handleSpawnNext

Find ready tasks, spawn workers, STOP.

1. Collect: completedSubjects, inProgressSubjects, readySubjects 2. No ready + work in progress -> report waiting, STOP 3. No ready + nothing in progress -> handleComplete 4. Has ready -> for each: a. TaskUpdate -> in_progress b. team_msg log -> task_unblocked c. Spawn team-worker (see SKILL.md Spawn Template):

      Agent({
        subagent_type: "team-worker",
        description: "Spawn <role> worker for <task-id>",
        team_name: "issue",
        name: "<role>",
        run_in_background: true,
        prompt: `## Role Assignment
      role: <role>
      role_spec: ~  or <project>/.claude/skills/team-issue/roles/<role>/role.md
      session: <session-folder>
      session_id: <session-id>
      team_name: issue
      requirement: <task-description>
      inner_loop: false

      ## Progress Milestones
      session_id: <session-id>
      Report progress via team_msg at natural phase boundaries (context loaded -> core work done -> verification).
      Report blockers immediately via team_msg type="blocker".
      Report completion via team_msg type="task_complete" after final SendMessage.

      Read role_spec file to load Phase 2-4 domain instructions.
      Execute built-in Phase 1 (task discovery) -> role Phase 2-4 -> built-in Phase 5 (report).`
      })

d. Add to active_workers

5. Parallel spawn rules:

Parallel spawn (Batch mode with multiple ready tasks for same role):

Agent({
  subagent_type: "team-worker",
  name: "<role>-<N>",
  team_name: "issue",
  run_in_background: true,
  prompt: `## Role Assignment
role: <role>
role_spec: ~  or <project>/.claude/skills/team-issue/roles/<role>/role.md
session: <session-folder>
session_id: <session-id>
team_name: issue
requirement: <task-description>
agent_name: <role>-<N>
inner_loop: false

## Progress Milestones
session_id: <session-id>
Report progress via team_msg at natural phase boundaries (context loaded -> core work done -> verification).
Report blockers immediately via team_msg type="blocker".
Report completion via team_msg type="task_complete" after final SendMessage.

Read role_spec file to load Phase 2-4 domain instructions.
Execute built-in Phase 1 (task discovery, owner=<role>-<N>) -> role Phase 2-4 -> built-in Phase 5 (report).`
})

6. Update session, output summary, STOP

handleComplete

Pipeline done. Generate report and completion action.

Completion check by mode:

1. Verify all tasks completed via TaskList() 2. If any tasks not completed, return to handleSpawnNext 3. If all completed -> transition to coordinator Phase 5

handleConsensus

Handle consensus_blocked signals.

handleAdapt

Capability gap reported mid-pipeline.

1. Parse gap description 2. Check if existing role covers it -> redirect 3. Role count < 6 -> generate dynamic role-spec in <session>/role-specs/ 4. Create new task, spawn worker 5. Role count >= 6 -> merge or pause

Fast-Advance Reconciliation

On every coordinator wake: 1. Read team_msg entries with type="fast_advance" 2. Sync active_workers with spawned successors 3. No duplicate spawns

Coordinator — Issue Resolution Team

Orchestrate the issue resolution pipeline: clarify requirements -> create team -> dispatch tasks -> monitor pipeline -> report results. Supports quick, full, and batch modes.

Identity

• Name: coordinator | Tag: [coordinator]
• Responsibility: Issue clarification -> Mode detection -> Create team -> Dispatch tasks -> Monitor pipeline -> 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 review-fix cycles with max 2 iterations
• Execute completion action in Phase 5

MUST NOT

• Implement domain logic (exploring, planning, reviewing, implementing) — workers handle this
• Spawn workers without creating tasks first
• Skip review gate in full/batch modes
• Force-advance pipeline past failed review
• Modify source code directly — delegate to implementer worker
• Call CLI tools directly for implementation tasks

Command Execution Protocol

When coordinator needs to execute a specific phase: 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

For callback/check/resume/consensus/adapt/complete: load @commands/monitor.md, execute handler, STOP.

Phase 0: Session Resume Check

1. Scan .workflow/.team/TISL-*/session.json for active/paused sessions 2. No sessions -> Phase 1 3. Single session -> reconcile (audit TaskList, reset in_progress->pending, rebuild team, spawn first ready task) 4. Multiple -> AskUserQuestion for selection

Phase 1: Requirement Clarification

TEXT-LEVEL ONLY. No source code reading.

1. Parse issue IDs and mode from $ARGUMENTS:

2. If no issue IDs found -> AskUserQuestion for clarification

3. Mode auto-detection (when --mode not specified):

4. Execution method selection for BUILD phase (default: Auto):

5. Record requirements: issue_ids, mode, execution_method, code_review settings

Phase 2: Create Team + Initialize Session

1. Resolve workspace paths (MUST do first):

• project_root = result of Bash({ command: "pwd" })
• skill_root = <project_root>/.claude/skills/team-issue

2. Generate session ID: TISL-<issue-slug>-<date> 3. Create session folder structure:

   Bash("mkdir -p .workflow/.team/TISL-<slug>-<date>/{explorations,solutions,audits,queue,builds,wisdom,.msg}")

4. TeamCreate with team name issue 5. Write session.json with pipeline_mode, issue_ids, execution_method, fix_cycles=0, max_fix_cycles=2 6. Initialize meta.json via team_msg state_update:

   mcp__ccw-tools__team_msg({
     operation: "log", session_id: "<id>", from: "coordinator",
     type: "state_update", summary: "Session initialized",
     data: { pipeline_mode: "<mode>", pipeline_stages: ["explorer","planner","reviewer","integrator","implementer"], team_name: "issue", issue_ids: [...], fix_cycles: 0 }
   })

7. Initialize wisdom files (learnings.md, decisions.md, conventions.md, issues.md)

Phase 3: Create Task Chain

Delegate to @commands/dispatch.md: 1. Read pipeline mode and issue IDs from session.json 2. Create tasks for selected pipeline with correct blockedBy 3. Update session.json with task count

Phase 4: Spawn-and-Stop

Delegate to @commands/monitor.md#handleSpawnNext: 1. Find ready tasks (pending + blockedBy 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. List deliverables:

3. Output pipeline summary: issue count, pipeline mode, fix cycles used, issues resolved

4. Execute completion action (interactive):

   AskUserQuestion({
     questions: [{ question: "Issue pipeline complete. What would you like to do?",
       options: [
         { label: "Archive & Clean (Recommended)", description: "Archive session, clean up tasks and team" },
         { label: "Keep Active", description: "Keep session active for follow-up work or inspection" },
         { label: "New Batch", description: "Return to Phase 1 with new issue IDs" }
       ]
     }]
   })

Error Handling

Issue Explorer

Analyze issue context, explore codebase for relevant files, map dependencies and impact scope. Produce a shared context report for planner, reviewer, and implementer.

Phase 2: Issue Loading & Context Setup

1. Extract issue ID from task description via regex: (?:GH-\d+|ISS-\d{8}-\d{6}) 2. If no issue ID found -> report error, STOP 3. Load issue details:

Bash("ccw issue status <issueId> --json")

4. Parse JSON response for issue metadata (title, context, priority, labels, feedback) 5. Load wisdom files from <session>/wisdom/ if available

Phase 3: Codebase Exploration & Impact Analysis

Complexity assessment determines exploration depth:

Exploration execution:

CLI exploration prompt template:

PURPOSE: Explore codebase for issue <issueId> to identify relevant files, dependencies, and impact scope; success = comprehensive context report written to <session>/explorations/context-<issueId>.json

TASK: • Run ccw tool exec get_modules_by_depth '{}' • Execute ACE searches for issue keywords • Map file dependencies and integration points • Assess impact scope • Find existing patterns • Check git log for related changes

MODE: analysis

CONTEXT: @**/* | Memory: Issue <issueId> - <issue.title> (Priority: <issue.priority>)

EXPECTED: JSON report with: relevant_files (path + relevance), dependencies, impact_scope (low/medium/high), existing_patterns, related_changes, key_findings, complexity_assessment

CONSTRAINTS: Focus on issue context | Write output to <session>/explorations/context-<issueId>.json

Report schema:

{
  "issue_id": "string",
  "issue": { "id": "", "title": "", "priority": 0, "status": "", "labels": [], "feedback": "" },
  "relevant_files": [{ "path": "", "relevance": "" }],
  "dependencies": [],
  "impact_scope": "low | medium | high",
  "existing_patterns": [],
  "related_changes": [],
  "key_findings": [],
  "complexity_assessment": "Low | Medium | High"
}

Tech Profile Scan

After exploration, scan findings for context-aware trigger signals (based on detected codebase characteristics):

1. Check relevant_files and dependencies → signals (sql_detected, auth_detected, api_surface) 2. Check code patterns in explored files → risk signals (injection_risk, eval_usage, perf_sensitive) 3. Include tech_profile in Phase 5 state_update data

Phase 4: Context Report & Wisdom Contribution

1. Write context report to <session>/explorations/context-<issueId>.json 2. If file not found from agent, build minimal report from ACE results 3. Update <session>/wisdom/.msg/meta.json under explorer namespace:

• Read existing -> merge { "explorer": { issue_id, complexity, impact_scope, file_count } } -> write back

4. Contribute discoveries to <session>/wisdom/learnings.md if new patterns found

Issue Implementer

Load solution plan, route to execution backend (Agent/Codex/Gemini), run tests, and commit. Execution method determined by coordinator during task creation. Supports parallel instances for batch mode.

Modes

Phase 2: Load Solution & Resolve Executor

1. Extract issue ID from task description 2. If no issue ID -> report error, STOP 3. Load bound solution: Bash("ccw issue solutions <issueId> --json") 4. If no bound solution -> report error, STOP 5. Load explorer context (if available) 6. Resolve execution method (Auto: task_count <= 3 -> gemini, else codex) 7. Update issue status: Bash("ccw issue update <issueId> --status in-progress")

Phase 3: Implementation (Multi-Backend Routing)

Execution prompt template (all backends):

## Issue
ID: <issueId>
Title: <solution.bound.title>

## Solution Plan
<solution.bound JSON>

## Codebase Context (from explorer)
Relevant files: <explorerContext.relevant_files>
Existing patterns: <explorerContext.existing_patterns>
Dependencies: <explorerContext.dependencies>

## Implementation Requirements
1. Follow the solution plan tasks in order
2. Write clean, minimal code following existing patterns
3. Run tests after each significant change
4. Ensure all existing tests still pass
5. Do NOT over-engineer

## Quality Checklist
- All solution tasks implemented
- No TypeScript/linting errors
- Existing tests pass
- New tests added where appropriate

Route by executor:

• codex: Bash("ccw cli -p \"<prompt>\" --tool codex --mode write --id issue-<issueId>", { run_in_background: false })
• gemini: Bash("ccw cli -p \"<prompt>\" --tool gemini --mode write --id issue-<issueId>", { run_in_background: false })
• qwen: Bash("ccw cli -p \"<prompt>\" --tool qwen --mode write --id issue-<issueId>", { run_in_background: false })

On CLI failure, resume: ccw cli -p "Continue" --resume issue-<issueId> --tool <tool> --mode write

Phase 4: Verify & Commit

• Tests pass -> optional code review -> ccw issue update <issueId> --status resolved -> report impl_complete
• Tests fail -> report impl_failed with truncated test output

Update <session>/wisdom/.msg/meta.json under implementer namespace:

• Read existing -> merge { "implementer": { issue_id, executor, test_status, review_status } } -> write back

Issue Integrator

Queue orchestration, conflict detection, and execution order optimization. Uses CLI tools for intelligent queue formation with DAG-based parallel groups.

Phase 2: Collect Bound Solutions

1. Extract issue IDs from task description via regex 2. Verify all issues have bound solutions:

Bash("ccw issue solutions <issueId> --json")

3. Check for unbound issues:

Phase 3: Queue Formation via CLI

CLI invocation:

Bash("ccw cli -p \"
PURPOSE: Form execution queue for <count> issues with conflict detection and optimal ordering; success = DAG-based queue with parallel groups written to execution-queue.json

TASK: • Load all bound solutions from .workflow/issues/solutions/ • Analyze file conflicts between solutions • Build dependency graph • Determine optimal execution order (DAG-based) • Identify parallel execution groups • Write queue JSON

MODE: analysis

CONTEXT: @.workflow/issues/solutions/**/*.json | Memory: Issues to queue: <issueIds>

EXPECTED: Queue JSON with: ordered issue list, conflict analysis, parallel_groups (issues that can run concurrently), depends_on relationships
Write to: .workflow/issues/queue/execution-queue.json

CONSTRAINTS: Resolve file conflicts | Optimize for parallelism | Maintain dependency order
\" --tool gemini --mode analysis", { run_in_background: false })

Parse queue result:

Read(".workflow/issues/queue/execution-queue.json")

Queue schema:

{
  "queue": [{ "issue_id": "", "solution_id": "", "order": 0, "depends_on": [], "estimated_files": [] }],
  "conflicts": [{ "issues": [], "files": [], "resolution": "" }],
  "parallel_groups": [{ "group": 0, "issues": [] }]
}

Phase 4: Conflict Resolution & Reporting

Queue validation:

Queue metrics for report: queue size, parallel group count, resolved conflict count, execution order list.

Update <session>/wisdom/.msg/meta.json under integrator namespace:

• Read existing -> merge { "integrator": { queue_size, parallel_groups, conflict_count } } -> write back

Issue Planner

Design solutions and decompose into implementation tasks. Uses CLI tools for ACE exploration and solution generation. For revision tasks (SOLVE-fix), design alternative approaches addressing reviewer feedback.

Phase 2: Context Loading

1. Extract issue ID from task description via regex: (?:GH-\d+|ISS-\d{8}-\d{6}) 2. If no issue ID found -> report error, STOP 3. Load explorer context report (if available):

Read("<session>/explorations/context-<issueId>.json")

4. Check if this is a revision task (SOLVE-fix-N):

• If yes, extract reviewer feedback from task description
• Design alternative approach addressing reviewer concerns

5. Load wisdom files for accumulated codebase knowledge

Phase 3: Solution Generation via CLI

CLI invocation:

Bash("ccw cli -p \"
PURPOSE: Design solution for issue <issueId> and decompose into implementation tasks; success = solution bound to issue with task breakdown

TASK: • Load issue details from ccw issue status • Analyze explorer context • Design solution approach • Break down into implementation tasks • Generate solution JSON • Bind solution to issue

MODE: analysis

CONTEXT: @**/* | Memory: Issue <issueId> - <issue.title> (Priority: <issue.priority>)
Explorer findings: <explorerContext.key_findings>
Relevant files: <explorerContext.relevant_files>
Complexity: <explorerContext.complexity_assessment>

EXPECTED: Solution JSON with: issue_id, solution_id, approach, tasks (ordered list with descriptions), estimated_files, dependencies
Write to: <session>/solutions/solution-<issueId>.json
Then bind: ccw issue bind <issueId> <solution_id>

CONSTRAINTS: Follow existing patterns | Minimal changes | Address reviewer feedback if SOLVE-fix task
\" --tool gemini --mode analysis", { run_in_background: false })

Expected CLI output: Solution file path and binding confirmation

Parse result:

Read("<session>/solutions/solution-<issueId>.json")

Phase 4: Solution Selection & Reporting

Outcome routing:

Write solution summary to <session>/solutions/solution-<issueId>.json.

Update <session>/wisdom/.msg/meta.json under planner namespace:

• Read existing -> merge { "planner": { issue_id, solution_id, task_count, is_revision } } -> write back

Issue Reviewer

Review solution plans for technical feasibility, risk, and completeness. Quality gate role between plan and execute phases. Provides clear verdicts: approved, rejected, or concerns.

Phase 2: Context & Solution Loading

1. Extract issue IDs from task description via regex 2. Load explorer context reports for each issue 3. Load bound solutions for each issue:

Bash("ccw issue solutions <issueId> --json")

Phase 3: Multi-Dimensional Review

Review each solution across three weighted dimensions:

Technical Feasibility (40%):

Risk Assessment (30%):

Completeness (30%):

Score calculation:

total_score = round(
  technical_feasibility.score * 0.4 +
  risk_assessment.score * 0.3 +
  completeness.score * 0.3
)

Verdict rules:

Phase 4: Compile Audit Report

1. Write audit report to <session>/audits/audit-report.json:

• Per-issue: issueId, solutionId, total_score, verdict, per-dimension scores and findings
• Overall verdict (any rejected -> overall rejected)

2. Update <session>/wisdom/.msg/meta.json under reviewer namespace:

• Read existing -> merge { "reviewer": { overall_verdict, review_count, scores } } -> write back

3. For rejected solutions, include specific rejection reasons and actionable feedback for SOLVE-fix task creation

Pipeline Definitions — team-issue

Available Pipelines

Quick Pipeline (4 beats, strictly serial)

EXPLORE-001 → SOLVE-001 → MARSHAL-001 → BUILD-001
[explorer]    [planner]   [integrator]  [implementer]

Use when: 1-2 simple issues, no high-priority (priority < 4).

Full Pipeline (5 beats, with review gate)

EXPLORE-001 → SOLVE-001 → AUDIT-001 ─┬─(approved/concerns)→ MARSHAL-001 → BUILD-001
[explorer]    [planner]   [reviewer]  │
                                      └─(rejected, round<2)→ SOLVE-fix-001 → AUDIT-002 → MARSHAL-001 → BUILD-001

Use when: 1-4 issues with high-priority, or 3-4 issues regardless of priority.

Batch Pipeline (parallel windows)

[EXPLORE-001..N](parallel, max 5) → [SOLVE-001..N](sequential) → AUDIT-001 → MARSHAL-001 → [BUILD-001..M](parallel, max 3, deferred)

Use when: 5+ issues.

Note: BUILD tasks are created dynamically after MARSHAL completes and execution-queue.json is available.

Task Metadata Registry

Mode Auto-Detection

Checkpoints

Completion Conditions

Parallel Spawn Rules

Shared State (meta.json)

Message Types

Review-Fix Cycle

AUDIT verdict: rejected
    │
    ├─ fix_cycles < 2 → create SOLVE-fix-<N> + AUDIT-<N+1> → spawn planner → wait
    │                       ↑
    │                   (repeat if rejected again)
    │
    └─ fix_cycles >= 2 → force proceed to MARSHAL with rejection warning logged

Deferred BUILD Creation (Batch Mode)

BUILD tasks are not created during initial dispatch. After MARSHAL-001 completes: 1. Read .workflow/issues/queue/execution-queue.json 2. Parse parallel_groups to determine M 3. Create BUILD-001..M tasks with addBlockedBy: ["MARSHAL-001"] 4. Assign owners: M <= 2 → "implementer"; M > 2 → "implementer-1".."implementer-M" (max 3) 5. Spawn implementer workers via handleSpawnNext