feat: migrate all codex team skills from spawn_agents_on_csv to spawn_agent + wait_agent architecture

- Delete 21 old team skill directories using CSV-wave pipeline pattern (~100+ files)
- Delete old team-lifecycle (v3) and team-planex-v2
- Create generic team-worker.toml and team-supervisor.toml (replacing tlv4-specific TOMLs)
- Convert 19 team skills from Claude Code format (Agent/SendMessage/TaskCreate)
  to Codex format (spawn_agent/wait_agent/tasks.json/request_user_input)
- Update team-lifecycle-v4 to use generic agent types (team_worker/team_supervisor)
- Convert all coordinator role files: dispatch.md, monitor.md, role.md
- Convert all worker role files: remove run_in_background, fix Bash syntax
- Convert all specs/pipelines.md references
- Final state: 20 team skills, 217 .md files, zero Claude Code API residuals

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
catlog22
2026-03-24 16:54:48 +08:00
parent 54283e5dbb
commit 1e560ab8e8
334 changed files with 28996 additions and 35516 deletions

View File

@@ -0,0 +1,64 @@
# 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
| Keywords | Capability | Prefix |
|----------|------------|--------|
| explore, analyze, context, impact, understand | explorer | EXPLORE |
| plan, solve, design, solution, approach | planner | SOLVE |
| review, audit, validate, feasibility | reviewer | AUDIT |
| marshal, integrate, queue, conflict, order | integrator | MARSHAL |
| build, implement, execute, code, develop | implementer | BUILD |
## 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
| Factor | Points |
|--------|--------|
| Issue count > 2 | +3 |
| Issue count > 4 | +2 more |
| Any high-priority issue (priority >= 4) | +2 |
| Multiple issue types / cross-cutting | +2 |
| Simple / single issue | -2 |
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
| Complexity | Pipeline | Tasks |
|------------|----------|-------|
| Low | quick | EXPLORE -> SOLVE -> MARSHAL -> BUILD |
| Medium | full | EXPLORE -> SOLVE -> AUDIT -> MARSHAL -> BUILD |
| High | batch | EXPLORE-001..N (parallel) -> SOLVE-001..N -> AUDIT -> MARSHAL -> BUILD-001..M (parallel) |
## Output
Write <session>/task-analysis.json:
```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
}
```

View File

@@ -0,0 +1,273 @@
# Dispatch
Create the issue resolution task chain with correct dependencies and structured task descriptions based on selected pipeline mode.
## Context Loading
| Input | Source | Required |
|-------|--------|----------|
| Requirement | From coordinator Phase 1 | Yes |
| Session folder | From coordinator Phase 2 | Yes |
| Pipeline mode | From session.json mode | Yes |
| Issue IDs | From session.json issue_ids | Yes |
| Execution method | From session.json execution_method | Yes |
| Code review | From session.json code_review | No |
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 is built as a JSON entry in the tasks array:
```json
{
"id": "<TASK-ID>",
"title": "<TASK-ID>",
"description": "PURPOSE: <what this task achieves> | Success: <completion criteria>\nTASK:\n - <step 1>\n - <step 2>\n - <step 3>\nCONTEXT:\n - Session: <session-folder>\n - Issue IDs: <issue-id-list>\n - Upstream artifacts: <artifact-list>\nEXPECTED: <deliverable path> + <quality criteria>\nCONSTRAINTS: <scope limits>\n---\nInnerLoop: false\nexecution_method: <method>\ncode_review: <setting>",
"status": "pending",
"role": "<role>",
"prefix": "<PREFIX>",
"deps": ["<dependency-list>"],
"findings": "",
"error": ""
}
```
## Pipeline Router
| Mode | Action |
|------|--------|
| quick | Create 4 tasks (EXPLORE -> SOLVE -> MARSHAL -> BUILD) |
| full | Create 5 tasks (EXPLORE -> SOLVE -> AUDIT -> MARSHAL -> BUILD) |
| batch | Create N+N+1+1+M tasks (EXPLORE-001..N -> SOLVE-001..N -> AUDIT-001 -> MARSHAL-001 -> BUILD-001..M) |
---
### Quick Pipeline
Build tasks array and write to tasks.json:
**EXPLORE-001** (explorer):
```json
{
"id": "EXPLORE-001",
"title": "EXPLORE-001",
"description": "PURPOSE: Analyze issue context and map codebase impact | Success: Context report with relevant files and dependencies\nTASK:\n - Load issue details via ccw issue status\n - Explore codebase for relevant files and patterns\n - Assess complexity and impact scope\nCONTEXT:\n - Session: <session-folder>\n - Issue IDs: <issue-id-list>\nEXPECTED: <session>/explorations/context-<issueId>.json with relevant files, dependencies, and impact assessment\nCONSTRAINTS: Exploration and analysis only, no solution design\n---\nInnerLoop: false",
"status": "pending",
"role": "explorer",
"prefix": "EXPLORE",
"deps": [],
"findings": "",
"error": ""
}
```
**SOLVE-001** (planner):
```json
{
"id": "SOLVE-001",
"title": "SOLVE-001",
"description": "PURPOSE: Design solution and decompose into implementation tasks | Success: Bound solution with task decomposition\nTASK:\n - Load explorer context report\n - Generate solution plan via CLI\n - Bind solution to issue\nCONTEXT:\n - Session: <session-folder>\n - Issue IDs: <issue-id-list>\n - Upstream artifacts: explorations/context-<issueId>.json\nEXPECTED: <session>/solutions/solution-<issueId>.json with solution plan and task list\nCONSTRAINTS: Solution design only, no code implementation\n---\nInnerLoop: false",
"status": "pending",
"role": "planner",
"prefix": "SOLVE",
"deps": ["EXPLORE-001"],
"findings": "",
"error": ""
}
```
**MARSHAL-001** (integrator):
```json
{
"id": "MARSHAL-001",
"title": "MARSHAL-001",
"description": "PURPOSE: Form execution queue with conflict detection and ordering | Success: Execution queue file with resolved conflicts\nTASK:\n - Verify all issues have bound solutions\n - Detect file conflicts between solutions\n - Produce ordered execution queue with DAG-based parallel groups\nCONTEXT:\n - Session: <session-folder>\n - Issue IDs: <issue-id-list>\n - Upstream artifacts: solutions/solution-<issueId>.json\nEXPECTED: .workflow/issues/queue/execution-queue.json with queue, conflicts, parallel groups\nCONSTRAINTS: Queue formation only, no implementation\n---\nInnerLoop: false",
"status": "pending",
"role": "integrator",
"prefix": "MARSHAL",
"deps": ["SOLVE-001"],
"findings": "",
"error": ""
}
```
**BUILD-001** (implementer):
```json
{
"id": "BUILD-001",
"title": "BUILD-001",
"description": "PURPOSE: Implement solution plan and verify with tests | Success: Code changes committed, tests pass\nTASK:\n - Load bound solution and explorer context\n - Route to execution backend (Auto/Codex/Gemini)\n - Run tests and verify implementation\n - Commit changes\nCONTEXT:\n - Session: <session-folder>\n - Issue IDs: <issue-id-list>\n - Upstream artifacts: explorations/context-<issueId>.json, solutions/solution-<issueId>.json, queue/execution-queue.json\nEXPECTED: <session>/builds/ with implementation results, tests passing\nCONSTRAINTS: Follow solution plan, no scope creep\n---\nInnerLoop: false\nexecution_method: <execution_method>\ncode_review: <code_review>",
"status": "pending",
"role": "implementer",
"prefix": "BUILD",
"deps": ["MARSHAL-001"],
"findings": "",
"error": ""
}
```
---
### Full Pipeline
Creates 5 tasks. EXPLORE-001 and SOLVE-001 same as Quick, then AUDIT gate before MARSHAL and BUILD.
**AUDIT-001** (reviewer):
```json
{
"id": "AUDIT-001",
"title": "AUDIT-001",
"description": "PURPOSE: Review solution for technical feasibility, risk, and completeness | Success: Clear verdict (approved/concerns/rejected) with scores\nTASK:\n - Load explorer context and bound solution\n - Score across 3 dimensions: technical feasibility (40%), risk (30%), completeness (30%)\n - Produce verdict: approved (>=80), concerns (60-79), rejected (<60)\nCONTEXT:\n - Session: <session-folder>\n - Issue IDs: <issue-id-list>\n - Upstream artifacts: explorations/context-<issueId>.json, solutions/solution-<issueId>.json\nEXPECTED: <session>/audits/audit-report.json with per-issue scores and overall verdict\nCONSTRAINTS: Review only, do not modify solutions\n---\nInnerLoop: false",
"status": "pending",
"role": "reviewer",
"prefix": "AUDIT",
"deps": ["SOLVE-001"],
"findings": "",
"error": ""
}
```
**MARSHAL-001**: Same as Quick, but `deps: ["AUDIT-001"]`.
**BUILD-001**: Same as Quick, `deps: ["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 role:
| Issue Count | Role Assignment |
|-------------|-----------------|
| N = 1 | role: "explorer" |
| N > 1 | role: "explorer-1", "explorer-2", ..., "explorer-N" (max 5) |
```json
{
"id": "EXPLORE-<NNN>",
"title": "EXPLORE-<NNN>",
"description": "PURPOSE: Analyze issue <issueId> context and map codebase impact | Success: Context report for <issueId>\nTASK:\n - Load issue details for <issueId>\n - Explore codebase for relevant files\n - Assess complexity and impact scope\nCONTEXT:\n - Session: <session-folder>\n - Issue IDs: <issueId>\nEXPECTED: <session>/explorations/context-<issueId>.json\nCONSTRAINTS: Single issue scope, exploration only\n---\nInnerLoop: false",
"status": "pending",
"role": "explorer-<N>",
"prefix": "EXPLORE",
"deps": [],
"findings": "",
"error": ""
}
```
**SOLVE-001..N** (planner, sequential after all EXPLORE):
```json
{
"id": "SOLVE-<NNN>",
"title": "SOLVE-<NNN>",
"description": "PURPOSE: Design solution for <issueId> | Success: Bound solution with tasks\nTASK:\n - Load explorer context for <issueId>\n - Generate solution plan\n - Bind solution\nCONTEXT:\n - Session: <session-folder>\n - Issue IDs: <issueId>\n - Upstream artifacts: explorations/context-<issueId>.json\nEXPECTED: <session>/solutions/solution-<issueId>.json\nCONSTRAINTS: Solution design only\n---\nInnerLoop: false",
"status": "pending",
"role": "planner",
"prefix": "SOLVE",
"deps": ["EXPLORE-001", "...", "EXPLORE-<N>"],
"findings": "",
"error": ""
}
```
**AUDIT-001** (reviewer, batch review):
```json
{
"id": "AUDIT-001",
"title": "AUDIT-001",
"description": "PURPOSE: Batch review all solutions | Success: Verdict for each solution\nTASK:\n - Load all explorer contexts and bound solutions\n - Score each solution across 3 dimensions\n - Produce per-issue verdicts and overall verdict\nCONTEXT:\n - Session: <session-folder>\n - Issue IDs: <all-issue-ids>\n - Upstream artifacts: explorations/*.json, solutions/*.json\nEXPECTED: <session>/audits/audit-report.json with batch results\nCONSTRAINTS: Review only\n---\nInnerLoop: false",
"status": "pending",
"role": "reviewer",
"prefix": "AUDIT",
"deps": ["SOLVE-001", "...", "SOLVE-<N>"],
"findings": "",
"error": ""
}
```
**MARSHAL-001** (integrator): `deps: ["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 roles:
| Build Count | Role Assignment |
|-------------|-----------------|
| M <= 2 | role: "implementer" |
| M > 2 | role: "implementer-1", ..., "implementer-M" (max 3) |
```json
{
"id": "BUILD-<NNN>",
"title": "BUILD-<NNN>",
"description": "PURPOSE: Implement solution for <issueId> | Success: Code committed, tests pass\nTASK:\n - Load bound solution and explorer context\n - Execute implementation via <execution_method>\n - Run tests, commit\nCONTEXT:\n - Session: <session-folder>\n - Issue IDs: <issueId>\n - Upstream artifacts: explorations/context-<issueId>.json, solutions/solution-<issueId>.json, queue/execution-queue.json\nEXPECTED: <session>/builds/ with results\nCONSTRAINTS: Follow solution plan\n---\nInnerLoop: false\nexecution_method: <execution_method>\ncode_review: <code_review>",
"status": "pending",
"role": "implementer-<M>",
"prefix": "BUILD",
"deps": ["MARSHAL-001"],
"findings": "",
"error": ""
}
```
---
### 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) -- added to tasks.json dynamically:
```json
{
"id": "SOLVE-fix-001",
"title": "SOLVE-fix-001",
"description": "PURPOSE: Revise solution addressing reviewer feedback (fix cycle <round>) | Success: Revised solution addressing rejection reasons\nTASK:\n - Read reviewer feedback from audit report\n - Design alternative approach addressing concerns\n - Re-bind revised solution\nCONTEXT:\n - Session: <session-folder>\n - Issue IDs: <rejected-issue-ids>\n - Upstream artifacts: audits/audit-report.json\n - Reviewer feedback: <rejection-reasons>\nEXPECTED: <session>/solutions/solution-<issueId>.json (revised)\nCONSTRAINTS: Address reviewer concerns specifically\n---\nInnerLoop: false",
"status": "pending",
"role": "planner",
"prefix": "SOLVE",
"deps": ["AUDIT-001"],
"findings": "",
"error": ""
}
```
**AUDIT-002** (reviewer, re-review) -- added to tasks.json dynamically:
```json
{
"id": "AUDIT-002",
"title": "AUDIT-002",
"description": "PURPOSE: Re-review revised solution (fix cycle <round>) | Success: Verdict on revised solution\nTASK:\n - Load revised solution\n - Re-evaluate previously rejected dimensions\n - Produce updated verdict\nCONTEXT:\n - Session: <session-folder>\n - Issue IDs: <rejected-issue-ids>\n - Upstream artifacts: solutions/solution-<issueId>.json (revised), audits/audit-report.json\nEXPECTED: <session>/audits/audit-report.json (updated)\nCONSTRAINTS: Focus on previously rejected dimensions\n---\nInnerLoop: false",
"status": "pending",
"role": "reviewer",
"prefix": "AUDIT",
"deps": ["SOLVE-fix-001"],
"findings": "",
"error": ""
}
```
## Validation
1. Verify all tasks created by reading tasks.json
2. Check dependency chain integrity:
- No circular dependencies
- All deps references exist
- First task(s) have empty deps (EXPLORE tasks)
3. Log task count and pipeline mode
4. Verify mode-specific constraints:
| Mode | Constraint |
|------|-----------|
| quick | Exactly 4 tasks, no AUDIT |
| full | Exactly 5 tasks, includes AUDIT |
| batch | N EXPLORE + N SOLVE + 1 AUDIT + 1 MARSHAL + deferred BUILD |

View File

@@ -0,0 +1,194 @@
# Monitor Pipeline
Event-driven pipeline coordination. Beat model: coordinator wake -> process -> spawn -> STOP.
## Constants
- SPAWN_MODE: spawn_agent
- ONE_STEP_PER_INVOCATION: true
- FAST_ADVANCE_AWARE: true
- WORKER_AGENT: team_worker
- MAX_FIX_CYCLES: 2
## Handler Router
| Source | Handler |
|--------|---------|
| Message contains [explorer], [planner], [reviewer], [integrator], [implementer] | handleCallback |
| "consensus_blocked" | handleConsensus |
| "capability_gap" | handleAdapt |
| "check" or "status" | handleCheck |
| "resume" or "continue" | handleResume |
| All tasks completed | handleComplete |
| Default | handleSpawnNext |
## handleCallback
Worker completed. Process and advance.
1. Parse message to identify role and task ID:
| Message Pattern | Role Detection |
|----------------|---------------|
| `[explorer]` or task ID `EXPLORE-*` | explorer |
| `[planner]` or task ID `SOLVE-*` | planner |
| `[reviewer]` or task ID `AUDIT-*` | reviewer |
| `[integrator]` or task ID `MARSHAL-*` | integrator |
| `[implementer]` or task ID `BUILD-*` | implementer |
2. Mark task as completed: Read tasks.json, update matching entry status to "completed", write back
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
| Verdict | fix_cycles < max | Action |
|---------|-----------------|--------|
| rejected | Yes | Increment fix_cycles, create SOLVE-fix + AUDIT re-review tasks (add to tasks.json per dispatch.md Review-Fix Cycle), proceed to handleSpawnNext |
| rejected | No (>= max) | Force proceed -- log warning, unblock MARSHAL |
| concerns | - | Log concerns, proceed to MARSHAL (non-blocking) |
| approved | - | Proceed to MARSHAL via handleSpawnNext |
- 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 (add to tasks.json per dispatch.md Batch Pipeline BUILD section)
- Proceed to handleSpawnNext
6. Close completed agent: `close_agent({ id: <agentId> })`
7. Proceed to handleSpawnNext
## handleCheck
Read-only status report, then STOP.
```
[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. Update tasks.json entry status -> "in_progress"
b. team_msg log -> task_unblocked
c. Spawn team_worker:
```
const agentId = spawn_agent({
agent_type: "team_worker",
items: [{ type: "text", text: `## Role Assignment
role: <role>
role_spec: ~ or <project>/.codex/skills/team-issue/roles/<role>/role.md
session: <session-folder>
session_id: <session-id>
team_name: issue
requirement: <task-description>
inner_loop: false
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. Collect results: `wait_agent({ ids: [agentId], timeout_ms: 900000 })`
e. Read discoveries from output files
f. Update tasks.json with results
g. Close agent: `close_agent({ id: agentId })`
5. Parallel spawn rules:
| Pipeline | Scenario | Spawn Behavior |
|----------|----------|---------------|
| Quick | All stages | One worker at a time |
| Full | All stages | One worker at a time |
| Batch | EXPLORE-001..N unblocked | Spawn ALL N explorer workers in parallel (max 5) |
| Batch | BUILD-001..M unblocked | Spawn ALL M implementer workers in parallel (max 3) |
| Batch | Other stages | One worker at a time |
**Parallel spawn** (Batch mode with multiple ready tasks for same role):
```
const agentIds = []
for (const task of readyTasks) {
agentIds.push(spawn_agent({
agent_type: "team_worker",
items: [{ type: "text", text: `## Role Assignment
role: <role>
role_spec: ~ or <project>/.codex/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
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).` }]
}))
}
const results = wait_agent({ ids: agentIds, timeout_ms: 900000 })
// Process results, close agents
for (const id of agentIds) { close_agent({ id }) }
```
6. Update session, output summary, STOP
## handleComplete
Pipeline done. Generate report and completion action.
Completion check by mode:
| Mode | Completion Condition |
|------|---------------------|
| quick | All 4 tasks completed |
| full | All 5 tasks (+ any fix cycle tasks) completed |
| batch | All N EXPLORE + N SOLVE + 1 AUDIT + 1 MARSHAL + M BUILD (+ any fix cycle tasks) completed |
1. Verify all tasks completed via reading tasks.json
2. If any tasks not completed, return to handleSpawnNext
3. If all completed -> transition to coordinator Phase 5
## handleConsensus
Handle consensus_blocked signals.
| Severity | Action |
|----------|--------|
| HIGH | Pause pipeline, notify user with findings summary |
| MEDIUM | Log finding, attempt to continue |
| LOW | Log finding, continue pipeline |
## 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 (add to tasks.json), 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

View File

@@ -0,0 +1,175 @@
---
role: coordinator
---
# 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
- Follow Command Execution Protocol for dispatch and monitor commands
- Respect pipeline stage dependencies (deps)
- Stop after spawning workers -- wait for results via wait_agent
- 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
| Detection | Condition | Handler |
|-----------|-----------|---------|
| Worker result | Result from wait_agent contains [explorer], [planner], [reviewer], [integrator], [implementer] | -> handleCallback (monitor.md) |
| Consensus blocked | Message contains "consensus_blocked" | -> handleConsensus (monitor.md) |
| Status check | Args contain "check" or "status" | -> handleCheck (monitor.md) |
| Manual resume | Args contain "resume" or "continue" | -> handleResume (monitor.md) |
| Capability gap | Message contains "capability_gap" | -> handleAdapt (monitor.md) |
| Pipeline complete | All tasks completed | -> handleComplete (monitor.md) |
| Interrupted session | Active session in .workflow/.team/TISL-* | -> Phase 0 |
| New session | None of above | -> Phase 1 |
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 (read tasks.json, reset in_progress->pending, rebuild team, spawn first ready task)
4. Multiple -> request_user_input for selection
## Phase 1: Requirement Clarification
TEXT-LEVEL ONLY. No source code reading.
1. Parse issue IDs and mode from $ARGUMENTS:
| Pattern | Extraction |
|---------|------------|
| `GH-\d+` | GitHub issue ID |
| `ISS-\d{8}-\d{6}` | Local issue ID |
| `--mode=<mode>` | Explicit mode override |
| `--all-pending` | Load all pending issues via `Bash("ccw issue list --status registered,pending --json")` |
2. If no issue IDs found -> request_user_input for clarification
3. **Mode auto-detection** (when `--mode` not specified):
| Condition | Mode |
|-----------|------|
| Issue count <= 2 AND no high-priority (priority < 4) | `quick` |
| Issue count <= 2 AND has high-priority (priority >= 4) | `full` |
| 3-4 issues | `full` |
| Issue count >= 5 | `batch` |
4. **Execution method selection** for BUILD phase (default: Auto):
| Option | Trigger |
|--------|---------|
| codex | task_count > 3 or explicit `--exec=codex` |
| gemini | task_count <= 3 or explicit `--exec=gemini` |
| qwen | explicit `--exec=qwen` |
| Auto | Auto-select based on task_count |
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("pwd")`
- `skill_root` = `<project_root>/.codex/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. Create session folder + initialize `tasks.json` (empty array)
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. Build tasks array and write to tasks.json with correct deps
3. Update session.json with task count
## Phase 4: Spawn-and-Stop
Delegate to @commands/monitor.md#handleSpawnNext:
1. Find ready tasks (pending + deps 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:
| Deliverable | Path |
|-------------|------|
| Context Reports | <session>/explorations/context-*.json |
| Solution Plans | <session>/solutions/solution-*.json |
| Audit Reports | <session>/audits/audit-report.json |
| Execution Queue | .workflow/issues/queue/execution-queue.json |
| Build Results | <session>/builds/ |
3. Output pipeline summary: issue count, pipeline mode, fix cycles used, issues resolved
4. Execute completion action (interactive):
```
request_user_input({
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" }
]
}]
})
```
| Choice | Steps |
|--------|-------|
| Archive & Clean | Verify all completed -> update session status="completed" -> clean up session -> output final summary |
| Keep Active | Update session status="paused" -> output: "Resume with: Skill(skill='team-issue', args='resume')" |
| New Batch | Return to Phase 1 |
## Error Handling
| Error | Resolution |
|-------|------------|
| No issue IDs provided | request_user_input for clarification |
| Session corruption | Attempt recovery, fallback to manual |
| Worker crash | Reset task to pending, respawn |
| Review rejection exceeds 2 rounds | Force convergence to MARSHAL |
| Deferred BUILD count unknown | Read execution-queue.json after MARSHAL completes |

View File

@@ -0,0 +1,94 @@
---
role: explorer
prefix: EXPLORE
inner_loop: false
message_types: [context_ready, error]
---
# 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
| Input | Source | Required |
|-------|--------|----------|
| Issue ID | Task description (GH-\d+ or ISS-\d{8}-\d{6}) | Yes |
| Issue details | `ccw issue status <id> --json` | Yes |
| Session path | Extracted from task description | Yes |
| wisdom meta | <session>/wisdom/.msg/meta.json | No |
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**:
| Signal | Weight | Keywords |
|--------|--------|----------|
| Structural change | +2 | refactor, architect, restructure, module, system |
| Cross-cutting | +2 | multiple, across, cross |
| Integration | +1 | integrate, api, database |
| High priority | +1 | priority >= 4 |
| Score | Complexity | Strategy |
|-------|------------|----------|
| >= 4 | High | Deep exploration via CLI tool |
| 2-3 | Medium | Hybrid: ACE search + selective CLI |
| 0-1 | Low | Direct ACE search only |
**Exploration execution**:
| Complexity | Execution |
|------------|-----------|
| Low | Direct ACE search: `mcp__ace-tool__search_context(project_root_path, query)` |
| Medium/High | CLI exploration: `Bash("ccw cli -p \"<exploration_prompt>\" --tool gemini --mode analysis")` |
**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**:
```json
{
"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"
}
```
## 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

View File

@@ -0,0 +1,87 @@
---
role: implementer
prefix: BUILD
inner_loop: false
message_types: [impl_complete, impl_failed, error]
---
# 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
| Backend | Condition | Method |
|---------|-----------|--------|
| codex | task_count > 3 or explicit | `ccw cli --tool codex --mode write --id issue-<issueId>` |
| gemini | task_count <= 3 or explicit | `ccw cli --tool gemini --mode write --id issue-<issueId>` |
| qwen | explicit | `ccw cli --tool qwen --mode write --id issue-<issueId>` |
## Phase 2: Load Solution & Resolve Executor
| Input | Source | Required |
|-------|--------|----------|
| Issue ID | Task description (GH-\d+ or ISS-\d{8}-\d{6}) | Yes |
| Bound solution | `ccw issue solutions <id> --json` | Yes |
| Explorer context | `<session>/explorations/context-<issueId>.json` | No |
| Execution method | Task description (`execution_method: Codex|Gemini|Qwen|Auto`) | Yes |
| Code review | Task description (`code_review: Skip|Gemini Review|Codex Review`) | No |
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>")`
- **gemini**: `Bash("ccw cli -p \"<prompt>\" --tool gemini --mode write --id issue-<issueId>")`
- **qwen**: `Bash("ccw cli -p \"<prompt>\" --tool qwen --mode write --id issue-<issueId>")`
On CLI failure, resume: `ccw cli -p "Continue" --resume issue-<issueId> --tool <tool> --mode write`
## Phase 4: Verify & Commit
| Check | Method | Pass Criteria |
|-------|--------|---------------|
| Tests pass | Detect and run test command | No new failures |
| Code review | Optional, per task config | Review output logged |
- 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

View File

@@ -0,0 +1,84 @@
---
role: integrator
prefix: MARSHAL
inner_loop: false
message_types: [queue_ready, conflict_found, error]
---
# 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
| Input | Source | Required |
|-------|--------|----------|
| Issue IDs | Task description (GH-\d+ or ISS-\d{8}-\d{6}) | Yes |
| Bound solutions | `ccw issue solutions <id> --json` | Yes |
| wisdom meta | <session>/wisdom/.msg/meta.json | No |
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:
| Condition | Action |
|-----------|--------|
| All issues bound | Proceed to Phase 3 |
| Any issue unbound | Report error to coordinator, STOP |
## 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")
```
**Parse queue result**:
```
Read(".workflow/issues/queue/execution-queue.json")
```
**Queue schema**:
```json
{
"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**:
| Condition | Action |
|-----------|--------|
| Queue file exists, no unresolved conflicts | Report `queue_ready` |
| Queue file exists, has unresolved conflicts | Report `conflict_found` for user decision |
| Queue file not found | Report `error`, STOP |
**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

View File

@@ -0,0 +1,81 @@
---
role: planner
prefix: SOLVE
inner_loop: false
additional_prefixes: [SOLVE-fix]
message_types: [solution_ready, multi_solution, error]
---
# 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
| Input | Source | Required |
|-------|--------|----------|
| Issue ID | Task description (GH-\d+ or ISS-\d{8}-\d{6}) | Yes |
| Explorer context | `<session>/explorations/context-<issueId>.json` | No |
| Review feedback | Task description (for SOLVE-fix tasks) | No |
| wisdom meta | <session>/wisdom/.msg/meta.json | No |
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")
```
**Expected CLI output**: Solution file path and binding confirmation
**Parse result**:
```
Read("<session>/solutions/solution-<issueId>.json")
```
## Phase 4: Solution Selection & Reporting
**Outcome routing**:
| Condition | Message Type | Action |
|-----------|-------------|--------|
| Single solution auto-bound | `solution_ready` | Report to coordinator |
| Multiple solutions pending | `multi_solution` | Report for user selection |
| No solution generated | `error` | Report failure to coordinator |
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

View File

@@ -0,0 +1,86 @@
---
role: reviewer
prefix: AUDIT
inner_loop: false
message_types: [approved, concerns, rejected, error]
---
# 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
| Input | Source | Required |
|-------|--------|----------|
| Issue IDs | Task description (GH-\d+ or ISS-\d{8}-\d{6}) | Yes |
| Explorer context | `<session>/explorations/context-<issueId>.json` | No |
| Bound solution | `ccw issue solutions <id> --json` | Yes |
| wisdom meta | <session>/wisdom/.msg/meta.json | No |
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%)**:
| Criterion | Check |
|-----------|-------|
| File Coverage | Solution covers all affected files from explorer context |
| Dependency Awareness | Considers dependency cascade effects |
| API Compatibility | Maintains backward compatibility |
| Pattern Conformance | Follows existing code patterns (ACE semantic validation) |
**Risk Assessment (30%)**:
| Criterion | Check |
|-----------|-------|
| Scope Creep | Solution stays within issue boundary (task_count <= 10) |
| Breaking Changes | No destructive modifications |
| Side Effects | No unforeseen side effects |
| Rollback Path | Can rollback if issues occur |
**Completeness (30%)**:
| Criterion | Check |
|-----------|-------|
| All Tasks Defined | Task decomposition is complete (count > 0) |
| Test Coverage | Includes test plan |
| Edge Cases | Considers boundary conditions |
**Score calculation**:
```
total_score = round(
technical_feasibility.score * 0.4 +
risk_assessment.score * 0.3 +
completeness.score * 0.3
)
```
**Verdict rules**:
| Score | Verdict | Message Type |
|-------|---------|-------------|
| >= 80 | approved | `approved` |
| 60-79 | concerns | `concerns` |
| < 60 | rejected | `rejected` |
## 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