mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-03-29 20:11:04 +08:00
refactor: deep Codex v4 API conversion for all 20 team skills
Upgrade all team-* skills from mechanical v3→v4 API renames to deep v4 tool integration with skill-adaptive patterns: - list_agents: health checks in handleResume, cleanup verification in handleComplete, added to allowed-tools and coordinator toolbox - Named targeting: task_name uses task-id (e.g. EXPLORE-001) instead of generic <role>-worker, enabling send_message/assign_task by name - Message semantics: send_message for supplementary cross-agent context vs assign_task for triggering work, with skill-specific examples - Model selection: per-role reasoning_effort guidance matching each skill's actual roles (not generic boilerplate) - timeout_ms: added to all wait_agent calls, timed_out handling in all 18 monitor.md files - Skill-adaptive v4 sections: ultra-analyze N-parallel coordination, lifecycle-v4 supervisor assign_task/send_message distinction, brainstorm ideator parallel patterns, iterdev generator-critic loops, frontend-debug iterative debug assign_task, perf-opt benchmark context sharing, executor lightweight trimmed v4, etc. 60 files changed across 20 team skills (SKILL.md, monitor.md, role.md) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: team-roadmap-dev
|
||||
description: Unified team skill for roadmap-driven development workflow. Coordinator discusses roadmap with user, then dispatches phased execution pipeline (plan -> execute -> verify). All roles invoke this skill with --role arg. Triggers on "team roadmap-dev".
|
||||
allowed-tools: spawn_agent(*), wait_agent(*), send_input(*), close_agent(*), report_agent_job_result(*), request_user_input(*), Read(*), Write(*), Edit(*), Bash(*), Glob(*), Grep(*)
|
||||
allowed-tools: spawn_agent(*), wait_agent(*), send_message(*), assign_task(*), close_agent(*), list_agents(*), report_agent_job_result(*), request_user_input(*), Read(*), Write(*), Edit(*), Bash(*), Glob(*), Grep(*)
|
||||
---
|
||||
|
||||
# Team Roadmap Dev
|
||||
@@ -59,7 +59,8 @@ Before calling ANY tool, apply this check:
|
||||
|
||||
| Tool Call | Verdict | Reason |
|
||||
|-----------|---------|--------|
|
||||
| `spawn_agent`, `wait_agent`, `close_agent`, `send_input` | ALLOWED | Orchestration |
|
||||
| `spawn_agent`, `wait_agent`, `close_agent`, `send_message`, `assign_task` | ALLOWED | Orchestration |
|
||||
| `list_agents` | ALLOWED | Agent health check |
|
||||
| `request_user_input` | ALLOWED | User interaction |
|
||||
| `mcp__ccw-tools__team_msg` | ALLOWED | Message bus |
|
||||
| `Read/Write` on `.workflow/.team/` files | ALLOWED | Session state |
|
||||
@@ -90,6 +91,8 @@ Coordinator spawns workers using this template:
|
||||
```
|
||||
spawn_agent({
|
||||
agent_type: "team_worker",
|
||||
task_name: "<task-id>",
|
||||
fork_context: false,
|
||||
items: [
|
||||
{ type: "text", text: `## Role Assignment
|
||||
role: <role>
|
||||
@@ -113,10 +116,23 @@ pipeline_phase: <pipeline-phase>` },
|
||||
})
|
||||
```
|
||||
|
||||
After spawning, use `wait_agent({ ids: [...], timeout_ms: 900000 })` to collect results, then `close_agent({ id })` each worker.
|
||||
After spawning, use `wait_agent({ targets: [...], timeout_ms: 900000 })` to collect results, then `close_agent({ target })` each worker.
|
||||
|
||||
**All worker roles** (planner, executor, verifier): Set `inner_loop: true`.
|
||||
|
||||
|
||||
### Model Selection Guide
|
||||
|
||||
Roadmap development is context-heavy with multi-phase execution. All roles use inner_loop and need high reasoning for complex planning/execution.
|
||||
|
||||
| Role | reasoning_effort | Rationale |
|
||||
|------|-------------------|-----------|
|
||||
| planner | high | Phase planning requires understanding full roadmap context |
|
||||
| executor | high | Implementation must align with phase plan precisely |
|
||||
| verifier | high | Gap detection requires thorough verification against plan |
|
||||
|
||||
All roles are inner_loop=true, enabling coordinator to send additional context via `assign_task` as phases progress.
|
||||
|
||||
## User Commands
|
||||
|
||||
| Command | Action |
|
||||
@@ -150,6 +166,42 @@ After spawning, use `wait_agent({ ids: [...], timeout_ms: 900000 })` to collect
|
||||
+-- meta.json # Session metadata + shared state
|
||||
```
|
||||
|
||||
## v4 Agent Coordination
|
||||
|
||||
### Message Semantics
|
||||
|
||||
| Intent | API | Example |
|
||||
|--------|-----|---------|
|
||||
| Queue supplementary info (don't interrupt) | `send_message` | Send phase context to running executor |
|
||||
| Assign phase work / gap closure | `assign_task` | Assign gap closure iteration to executor after verify |
|
||||
| Check running agents | `list_agents` | Verify agent health during resume |
|
||||
|
||||
### Agent Health Check
|
||||
|
||||
Use `list_agents({})` in handleResume and handleComplete:
|
||||
|
||||
```
|
||||
// Reconcile session state with actual running agents
|
||||
const running = list_agents({})
|
||||
// Compare with state.md and config.json active tasks
|
||||
// Reset orphaned tasks (in_progress but agent gone) to pending
|
||||
```
|
||||
|
||||
### Named Agent Targeting
|
||||
|
||||
Workers are spawned with `task_name: "<task-id>"` enabling direct addressing:
|
||||
- `send_message({ target: "EXEC-N01", items: [...] })` -- send supplementary context to executor
|
||||
- `assign_task({ target: "PLAN-N01", items: [...] })` -- assign next phase planning
|
||||
- `close_agent({ target: "VERIFY-N01" })` -- cleanup after verification
|
||||
|
||||
### Multi-Phase Context Accumulation
|
||||
|
||||
Each phase builds on previous phase results. Coordinator accumulates context across phases:
|
||||
- Phase N planner receives: roadmap.md + state.md + all previous phase summaries
|
||||
- Phase N executor receives: phase plan + previous phase implementation context
|
||||
- Phase N verifier receives: phase plan + executor results + success criteria from roadmap
|
||||
- On gap closure: verifier findings are sent back to executor via `assign_task` (max 3 iterations)
|
||||
|
||||
## Completion Action
|
||||
|
||||
When the pipeline completes:
|
||||
|
||||
Reference in New Issue
Block a user