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,52 @@
# Analyze Task
Parse plan-and-execute input -> detect input type -> determine execution method -> assess scope.
**CONSTRAINT**: Text-level analysis only. NO source code reading, NO codebase exploration.
## Signal Detection
| Input Pattern | Type | Action |
|--------------|------|--------|
| `ISS-\d{8}-\d{6}` pattern | Issue IDs | Use directly |
| `--text '...'` flag | Text requirement | Create issues via CLI |
| `--plan <path>` flag | Plan file | Read file, parse phases |
## Execution Method Selection
| Condition | Execution Method |
|-----------|-----------------|
| `--exec=codex` specified | Codex |
| `--exec=gemini` specified | Gemini |
| `-y` or `--yes` flag present | Auto (default Gemini) |
| No flags (interactive) | request_user_input -> user choice |
| Auto + task_count <= 3 | Gemini |
| Auto + task_count > 3 | Codex |
## Scope Assessment
| Factor | Complexity |
|--------|------------|
| Issue count 1-3 | Low |
| Issue count 4-10 | Medium |
| Issue count > 10 | High |
| Cross-cutting concern | +1 level |
## Output
Write <session>/task-analysis.json:
```json
{
"task_description": "<original>",
"input_type": "<issues|text|plan>",
"raw_input": "<original input>",
"execution_method": "<codex|gemini>",
"issue_count_estimate": 0,
"complexity": { "score": 0, "level": "Low|Medium|High" },
"pipeline_type": "plan-execute",
"roles": [
{ "name": "planner", "prefix": "PLAN", "inner_loop": true },
{ "name": "executor", "prefix": "EXEC", "inner_loop": true }
]
}
```

View File

@@ -0,0 +1,80 @@
# Command: dispatch
## Purpose
Create the initial task chain for team-planex pipeline. Creates PLAN-001 for planner. EXEC-* tasks are NOT pre-created -- planner creates them at runtime per issue.
## Phase 2: Context Loading
| Input | Source | Required |
|-------|--------|----------|
| Input type | Phase 1 requirements | Yes |
| Raw input | Phase 1 requirements | Yes |
| Session folder | Phase 2 session init | Yes |
| Execution method | Phase 1 requirements | Yes |
## Phase 3: Task Chain Creation
### Task Creation
Create a single PLAN-001 task entry in tasks.json:
```json
[
{
"id": "PLAN-001",
"title": "PLAN-001: Requirement decomposition and solution design",
"description": "Decompose requirements into issues and generate solutions.\n\nInput type: <issues|text|plan>\nInput: <raw-input>\nSession: <session-folder>\nExecution method: <agent|codex|gemini>\n\n## Instructions\n1. Parse input to get issue list\n2. For each issue: call issue-plan-agent -> write solution artifact\n3. After each solution: create EXEC-* task entry in tasks.json with solution_file path, role: executor\n4. After all issues: send all_planned signal\n\nInnerLoop: true",
"status": "pending",
"role": "planner",
"prefix": "PLAN",
"deps": [],
"findings": "",
"error": ""
}
]
```
### EXEC-* Task Template (for planner reference)
Planner creates EXEC-* task entries in tasks.json at runtime using this template:
```json
{
"id": "EXEC-00N",
"title": "EXEC-00N: Implement <issue-title>",
"description": "Implement solution for issue <issueId>.\n\nIssue ID: <issueId>\nSolution file: <session-folder>/artifacts/solutions/<issueId>.json\nSession: <session-folder>\nExecution method: <agent|codex|gemini>\n\nInnerLoop: true",
"status": "pending",
"role": "executor",
"prefix": "EXEC",
"deps": [],
"findings": "",
"error": ""
}
```
### Add Command Task Template
When coordinator handles `add` command, create additional PLAN tasks in tasks.json:
```json
{
"id": "PLAN-00N",
"title": "PLAN-00N: Additional requirement decomposition",
"description": "Additional requirements to decompose.\n\nInput type: <issues|text|plan>\nInput: <new-input>\nSession: <session-folder>\nExecution method: <execution-method>\n\nInnerLoop: true",
"status": "pending",
"role": "planner",
"prefix": "PLAN",
"deps": [],
"findings": "",
"error": ""
}
```
## Phase 4: Validation
| Check | Criteria |
|-------|----------|
| PLAN-001 created | tasks.json contains PLAN-001 entry |
| Description complete | Contains Input, Session, Execution method |
| No orphans | All tasks have valid role |

View File

@@ -0,0 +1,164 @@
# Command: monitor
## Purpose
Event-driven pipeline coordination with Spawn-and-Stop pattern. Three wake-up sources: worker results, user `check`, user `resume`.
## Constants
| Constant | Value | Description |
|----------|-------|-------------|
| SPAWN_MODE | spawn_agent | All workers spawned via `spawn_agent` |
| ONE_STEP_PER_INVOCATION | true | Coordinator does one operation then STOPS |
| WORKER_AGENT | team_worker | All workers are team_worker agents |
## Phase 2: Context Loading
| Input | Source | Required |
|-------|--------|----------|
| Session file | `<session-folder>/.msg/meta.json` | Yes |
| Task list | Read tasks.json | Yes |
| Active workers | session.active_workers[] | Yes |
## Phase 3: Handler Routing
### Wake-up Source Detection
| Priority | Condition | Handler |
|----------|-----------|---------|
| 1 | Message contains `[planner]` or `[executor]` tag | handleCallback |
| 2 | Contains "check" or "status" | handleCheck |
| 3 | Contains "resume", "continue", or "next" | handleResume |
| 4 | None of the above (initial spawn) | handleSpawnNext |
---
### Handler: handleCallback
```
Receive result from wait_agent for [<role>]
+- Match role: planner or executor
+- Progress update (not final)?
| +- YES -> Update session -> STOP
+- Task status = completed?
| +- YES -> remove from active_workers -> update session
| | +- Close agent: close_agent({ id: <agentId> })
| | +- role = planner?
| | | +- Check for new EXEC-* tasks in tasks.json (planner creates them)
| | | +- -> handleSpawnNext (spawn executor for new EXEC-* tasks)
| | +- role = executor?
| | +- Mark issue done
| | +- -> handleSpawnNext (check for more EXEC-* tasks)
| +- NO -> progress message -> STOP
+- No matching worker found
+- Scan all active workers for completed tasks
+- Found completed -> process -> handleSpawnNext
+- None completed -> STOP
```
---
### Handler: handleCheck
Read-only status report. No advancement.
```
[coordinator] PlanEx Pipeline Status
[coordinator] Progress: <completed>/<total> (<percent>%)
[coordinator] Task Graph:
PLAN-001: <status-icon> <summary>
EXEC-001: <status-icon> <issue-title>
EXEC-002: <status-icon> <issue-title>
...
done=completed >>>=running o=pending
[coordinator] Active Workers:
> <subject> (<role>) - running <elapsed>
[coordinator] Ready to spawn: <subjects>
[coordinator] Commands: 'resume' to advance | 'check' to refresh
```
Then STOP.
---
### Handler: handleResume
```
Load active_workers
+- No active workers -> handleSpawnNext
+- Has active workers -> check each:
+- completed -> mark done, log
+- in_progress -> still running
+- other -> worker failure -> reset to pending
After:
+- Some completed -> handleSpawnNext
+- All running -> report status -> STOP
+- All failed -> handleSpawnNext (retry)
```
---
### Handler: handleSpawnNext
```
Collect task states from tasks.json
+- Filter tasks: PLAN-* and EXEC-* prefixes
+- readySubjects: pending + not blocked (no deps or all deps completed)
+- NONE ready + work in progress -> report waiting -> STOP
+- NONE ready + nothing running -> PIPELINE_COMPLETE -> Phase 5
+- HAS ready tasks -> for each:
+- Inner Loop role AND already has active_worker for that role?
| +- YES -> SKIP spawn (existing worker picks up via inner loop)
| +- NO -> spawn below
+- Determine role from task prefix:
| +- PLAN-* -> planner
| +- EXEC-* -> executor
+- 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-planex/roles/<role>/role.md
session: <session-folder>
session_id: <session-id>
team_name: <team-name>
requirement: <task-description>
inner_loop: true
execution_method: <method>` }]
})
// Collect results:
const result = wait_agent({ ids: [agentId], timeout_ms: 900000 })
// Process result, update tasks.json
close_agent({ id: agentId })
+- Add to session.active_workers
Update session -> output summary -> STOP
```
---
## Phase 4: Validation
| Check | Criteria |
|-------|----------|
| Session state consistent | active_workers matches in_progress tasks |
| No orphaned tasks | Every in_progress has active_worker |
| Pipeline completeness | All expected EXEC-* tasks accounted for |
## Worker Failure Handling
1. Reset task -> pending in tasks.json
2. Log via team_msg (type: error)
3. Report to user
## Error Handling
| Scenario | Resolution |
|----------|------------|
| Session file not found | Error, suggest re-initialization |
| Unknown role callback | Log, scan for other completions |
| All workers running on resume | Report status, suggest check later |
| Pipeline stall (no ready + no running + has pending) | Check deps chains, report |

View File

@@ -0,0 +1,140 @@
# Coordinator Role
Orchestrate team-planex: analyze -> dispatch -> spawn -> monitor -> report.
## Identity
- Name: coordinator | Tag: [coordinator]
- Responsibility: Parse input -> Create team -> Dispatch PLAN-001 -> Spawn planner -> Monitor results -> Spawn executors -> Report
## Boundaries
### MUST
- Parse user input (Issue IDs / --text / --plan) and determine execution method
- Create session and initialize tasks.json
- Dispatch tasks via `commands/dispatch.md`
- Monitor progress via `commands/monitor.md` with Spawn-and-Stop pattern
- Maintain session state (.msg/meta.json)
### MUST NOT
- Execute planning or implementation work directly (delegate to workers)
- Modify solution artifacts or code (workers own their deliverables)
- Call implementation CLI tools (code-developer, etc.) directly
- Skip dependency validation when creating task chains
## Command Execution Protocol
When coordinator needs to execute a command:
1. Read `commands/<command>.md`
2. Follow the workflow defined in the command
3. Commands are inline execution guides, NOT separate agents
4. Execute synchronously, complete before proceeding
## Entry Router
| Detection | Condition | Handler |
|-----------|-----------|---------|
| Worker result | Result from wait_agent contains [planner] or [executor] tag | -> handleCallback (monitor.md) |
| Status check | Args contain "check" or "status" | -> handleCheck (monitor.md) |
| Manual resume | Args contain "resume" or "continue" | -> handleResume (monitor.md) |
| Add tasks | Args contain "add" | -> handleAdd |
| Interrupted session | Active/paused session exists in `.workflow/.team/PEX-*` | -> Phase 0 |
| New session | None of above | -> Phase 1 |
For callback/check/resume: load `@commands/monitor.md` and execute the appropriate handler, then STOP.
### handleAdd
1. Parse new input (Issue IDs / `--text` / `--plan`)
2. Get current max PLAN-* sequence from tasks.json
3. Add new PLAN-00N task entry to tasks.json with role: "planner"
4. If planner already sent `all_planned` (check team_msg) -> signal planner to re-enter loop
5. STOP
## Phase 0: Session Resume Check
1. Scan `.workflow/.team/PEX-*/.msg/meta.json` for sessions with status "active" or "paused"
2. No sessions -> Phase 1
3. Single session -> resume (Session Reconciliation)
4. Multiple sessions -> request_user_input for selection
**Session Reconciliation**:
1. Read tasks.json -> reconcile session state vs task status
2. Reset in_progress tasks -> pending (they were interrupted)
3. Rebuild team if needed (create session + spawn needed workers)
4. Kick first executable task -> Phase 4
## Phase 1: Input Parsing + Execution Method
TEXT-LEVEL ONLY. No source code reading.
1. Delegate to @commands/analyze.md -> produces task-analysis.json
2. Parse arguments: Extract input type (Issue IDs / --text / --plan) and optional flags (--exec, -y)
3. Determine execution method (see specs/pipelines.md Selection Decision Table):
- Explicit `--exec` flag -> use specified method
- `-y` / `--yes` flag -> Auto mode
- No flags -> request_user_input for method choice
4. Store requirements: input_type, raw_input, execution_method
5. CRITICAL: Always proceed to Phase 2, never skip team workflow
## 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-planex`
2. Generate session ID: `PEX-<slug>-<date>`
3. Create session folder: `.workflow/.team/<session-id>/`
4. Create subdirectories: `artifacts/solutions/`, `wisdom/`
5. Create session folder + initialize `tasks.json` (empty array)
6. Initialize wisdom files (learnings.md, decisions.md, conventions.md, issues.md)
7. Initialize meta.json with pipeline metadata:
```typescript
mcp__ccw-tools__team_msg({
operation: "log", session_id: "<id>", from: "coordinator",
type: "state_update", summary: "Session initialized",
data: {
pipeline_mode: "plan-execute",
pipeline_stages: ["planner", "executor"],
roles: ["coordinator", "planner", "executor"],
team_name: "planex",
input_type: "<issues|text|plan>",
execution_method: "<codex|gemini>"
}
})
```
## Phase 3: Create Task Chain
Delegate to `@commands/dispatch.md`:
1. Read `roles/coordinator/commands/dispatch.md`
2. Execute its workflow to create PLAN-001 task in tasks.json
3. PLAN-001 contains input info + execution method in description
## Phase 4: Spawn-and-Stop
1. Load `@commands/monitor.md`
2. Execute `handleSpawnNext` to find ready tasks and spawn planner worker
3. Output status summary
4. STOP (idle, wait for worker result)
**ONE_STEP_PER_INVOCATION**: true -- coordinator does one operation per wake-up, then STOPS.
## Phase 5: Report + Completion Action
1. Load session state -> count completed tasks, duration
2. List deliverables with output paths
3. Update session status -> "completed"
4. Execute Completion Action per session.completion_action:
- interactive -> request_user_input (Archive/Keep/Export)
- auto_archive -> Archive & Clean (status=completed, clean up session)
- auto_keep -> Keep Active (status=paused)
- auto_yes -> Archive & Clean without prompting
## Error Handling
| Error | Resolution |
|-------|------------|
| Session file not found | Error, suggest re-initialization |
| Unknown worker callback | Log, scan for other completions |
| Pipeline stall | Check missing tasks, report to user |
| Worker crash | Reset task to pending, re-spawn on next beat |
| All workers running on resume | Report status, suggest check later |

View File

@@ -0,0 +1,91 @@
---
role: executor
prefix: EXEC
inner_loop: true
message_types:
success: impl_complete
error: impl_failed
---
# Executor
Single-issue implementation agent. Loads solution from artifact file, routes to execution backend (Codex/Gemini), verifies with tests, commits, and reports completion.
## Phase 2: Task & Solution Loading
| Input | Source | Required |
|-------|--------|----------|
| Issue ID | Task description `Issue ID:` field | Yes |
| Solution file | Task description `Solution file:` field | Yes |
| Session folder | Task description `Session:` field | Yes |
| Execution method | Task description `Execution method:` field | Yes |
| Wisdom | `<session>/wisdom/` | No |
1. Extract issue ID, solution file path, session folder, execution method
2. Load solution JSON from file (file-first)
3. If file not found -> fallback: `ccw issue solution <issueId> --json`
4. Load wisdom files for conventions and patterns
5. Verify solution has required fields: title, tasks
## Phase 3: Implementation
### Backend Selection
| Method | Backend | CLI Tool |
|--------|---------|----------|
| `codex` | `ccw cli --tool codex --mode write` | CLI |
| `gemini` | `ccw cli --tool gemini --mode write` | CLI |
### CLI Backend (Codex/Gemini)
```bash
ccw cli -p "PURPOSE: Implement solution for issue <issueId>; success = all tasks completed, tests pass
TASK: <solution.tasks as bullet points>
MODE: write
CONTEXT: @**/* | Memory: Session wisdom from <session>/wisdom/
EXPECTED: Working implementation with: code changes, test updates, no syntax errors
CONSTRAINTS: Follow existing patterns | Maintain backward compatibility
Issue: <issueId>
Title: <solution.title>
Solution: <solution JSON>" --tool <codex|gemini> --mode write --rule development-implement-feature
```
Wait for CLI completion before proceeding to verification.
## Phase 4: Verification + Commit
### Test Verification
| Check | Method | Pass Criteria |
|-------|--------|---------------|
| Tests | Detect and run project test command | All pass |
| Syntax | IDE diagnostics or `tsc --noEmit` | No errors |
If tests fail: retry implementation once, then report `impl_failed`.
### Commit
```bash
git add -A
git commit -m "feat(<issueId>): <solution.title>"
```
### Update Issue Status
```bash
ccw issue update <issueId> --status completed
```
### Report
Write results to discoveries file for coordinator to read.
## Boundaries
| Allowed | Prohibited |
|---------|-----------|
| Load solution from file | Create or modify issues |
| Implement via CLI tools (Codex/Gemini) | Modify solution artifacts |
| Run tests | Spawn additional agents (use CLI tools instead) |
| git commit | Direct user interaction |
| Update issue status | Create tasks for other roles |

View File

@@ -0,0 +1,112 @@
---
role: planner
prefix: PLAN
inner_loop: true
message_types:
success: issue_ready
error: error
---
# Planner
Requirement decomposition -> issue creation -> solution design -> EXEC-* task creation. Processes issues one at a time, creating executor tasks as solutions are completed.
## Phase 2: Context Loading
| Input | Source | Required |
|-------|--------|----------|
| Input type + raw input | Task description | Yes |
| Session folder | Task description `Session:` field | Yes |
| Execution method | Task description `Execution method:` field | Yes |
| Wisdom | `<session>/wisdom/` | No |
1. Extract session path, input type, raw input, execution method from task description
2. Load wisdom files if available
3. Parse input to determine issue list:
| Detection | Condition | Action |
|-----------|-----------|--------|
| Issue IDs | `ISS-\d{8}-\d{6}` pattern | Use directly |
| `--text '...'` | Flag in input | Create issue(s) via `ccw issue create` |
| `--plan <path>` | Flag in input | Read file, parse phases, batch create issues |
## Phase 3: Issue Processing Loop
For each issue, execute in sequence:
### 3a. Generate Solution
Use CLI tool for issue planning:
```bash
ccw cli -p "PURPOSE: Generate implementation solution for issue <issueId>; success = actionable task breakdown with file paths
TASK: * Load issue details * Analyze requirements * Design solution approach * Break down into implementation tasks * Identify files to modify/create
MODE: analysis
CONTEXT: @**/* | Memory: Session context from <session>/wisdom/
EXPECTED: JSON solution with: title, description, tasks array (each with description, files_touched), estimated_complexity
CONSTRAINTS: Follow project patterns | Reference existing implementations
" --tool gemini --mode analysis --rule planning-breakdown-task-steps
```
Parse CLI output to extract solution JSON. If CLI fails, fallback to `ccw issue solution <issueId> --json`.
### 3b. Write Solution Artifact
Write solution JSON to: `<session>/artifacts/solutions/<issueId>.json`
```json
{
"session_id": "<session-id>",
"issue_id": "<issueId>",
"solution": "<solution-from-agent>",
"planned_at": "<ISO timestamp>"
}
```
### 3c. Check Conflicts
Extract `files_touched` from solution. Compare against prior solutions in session.
Overlapping files -> log warning to `wisdom/issues.md`, continue.
### 3d. Create EXEC-* Task
Add new task entry to tasks.json:
```json
{
"id": "EXEC-00N",
"title": "EXEC-00N: Implement <issue-title>",
"description": "Implement solution for issue <issueId>.\n\nIssue ID: <issueId>\nSolution file: <session>/artifacts/solutions/<issueId>.json\nSession: <session>\nExecution method: <method>\n\nInnerLoop: true",
"status": "pending",
"role": "executor",
"prefix": "EXEC",
"deps": [],
"findings": "",
"error": ""
}
```
### 3e. Signal issue_ready
Write result via team_msg:
- type: `issue_ready`
### 3f. Continue Loop
Process next issue. Do NOT wait for executor.
## Phase 4: Completion Signal
After all issues processed:
1. Send `all_planned` message via team_msg
2. Summary: total issues planned, EXEC-* tasks created
## Boundaries
| Allowed | Prohibited |
|---------|-----------|
| Parse input, create issues | Write/modify business code |
| Generate solutions (CLI) | Run tests |
| Write solution artifacts | git commit |
| Create EXEC-* tasks in tasks.json | Call code-developer |
| Conflict checking | Direct user interaction |