catlog22/Claude-Code-Workflow
1
0
Fork 0
mirror of https://github.com/catlog22/Claude-Code-Workflow.git synced 2026-03-29 20:11:04 +08:00
Code Issues Packages Projects Releases Wiki Activity

refactor: deep Codex v4 API conversion for all 20 team skills

Browse Source 
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:
catlog22
2026-03-27 22:25:32 +08:00
parent 3d39ac6ac8
commit 88ea7fc6d7
60 changed files with 2318 additions and 215 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
.codex/skills/team-frontend-debug/SKILL.md
View File

@@ -1,7 +1,7 @@
---
name: team-frontend-debug
description: Frontend debugging team using Chrome DevTools MCP. Dual-mode — feature-list testing or bug-report debugging. Triggers on "team-frontend-debug", "frontend debug".
allowed-tools: spawn_agent(*), wait_agent(*), send_input(*), close_agent(*), report_agent_job_result(*), request_user_input(*), Read(*), Write(*), Edit(*), Bash(*), Glob(*), Grep(*), mcp__chrome-devtools__*(*)
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(*), mcp__chrome-devtools__*(*)
---
# Frontend Debug Team
@@ -64,7 +64,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 |
@@ -131,6 +132,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>
@@ -154,7 +157,20 @@ 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.
### Model Selection Guide
Debug workflows require tool-heavy interaction (Chrome DevTools MCP). Reasoning effort varies by role.
| Role | reasoning_effort | Rationale |
|------|-------------------|-----------|
| tester | medium | Systematic feature testing via DevTools, follows test plan |
| reproducer | medium | Reproduce bugs via DevTools interaction steps |
| analyzer | high | Root cause analysis requires deep reasoning about evidence |
| fixer | high | Code fixes must address root cause precisely |
| verifier | medium | Verification follows defined success criteria via DevTools |
## User Commands
@@ -166,6 +182,53 @@ After spawning, use `wait_agent({ ids: [...], timeout_ms: 900000 })` to collect
| `feedback <text>` | Inject feedback for revision |
| `retry <TASK-ID>` | Re-run a failed task |
## v4 Agent Coordination
### Message Semantics
| Intent | API | Example |
|--------|-----|---------|
| Queue supplementary info (don't interrupt) | `send_message` | Send DevTools evidence to running analyzer |
| Assign new work / trigger debug round | `assign_task` | Assign re-fix after verification failure |
| 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 team-session.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: "ANALYZE-001", items: [...] })` -- send evidence from reproducer to analyzer
- `assign_task({ target: "FIX-001", items: [...] })` -- assign fix based on analysis results
- `close_agent({ target: "VERIFY-001" })` -- cleanup after verification
### Iterative Debug Loop Pattern
When verifier reports a fix did not resolve the issue, coordinator uses `assign_task` to trigger re-analysis and re-fix:
```
// Verifier reports failure -> coordinator dispatches re-fix
assign_task({
target: "FIX-001", // reuse existing fixer if inner_loop, or spawn new
items: [
{ type: "text", text: `## Re-fix Assignment
verification_result: FAIL
failure_evidence: <verifier's screenshot/console evidence>
previous_fix_summary: <what was tried>
instruction: Analyze verification failure and apply corrected fix.` }
]
})
```
This pattern enables iterative debug rounds: FIX -> VERIFY -> re-FIX -> re-VERIFY (max 3 rounds).
## Completion Action
When pipeline completes, coordinator presents:

36
.codex/skills/team-frontend-debug/roles/coordinator/commands/monitor.md
View File

@@ -67,6 +67,16 @@ Output:
## handleResume
**Agent Health Check** (v4):
```
// Verify actual running agents match session state
const runningAgents = list_agents({})
// For each active_agent in tasks.json:
// - If agent NOT in runningAgents -> agent crashed
// - Reset that task to pending, remove from active_agents
// This prevents stale agent references from blocking the pipeline
```
1. No active workers -> handleSpawnNext
2. Has active -> check each status
- completed -> mark done
@@ -90,6 +100,7 @@ Find ready tasks, spawn workers, STOP.
```
spawn_agent({
agent_type: "team_worker",
task_name: taskId, // e.g., "TEST-001" — enables named targeting
items: [{
description: "Spawn <role> worker for <task-id>",
team_name: "frontend-debug",
@@ -110,10 +121,33 @@ Find ready tasks, spawn workers, STOP.
```
- Add to active_workers
5. Update session, output summary, STOP
6. Use `wait_agent({ ids: [<spawned-agent-ids>] })` to wait for callbacks. Workers use `report_agent_job_result()` to send results back.
6. Use `wait_agent({ targets: [<spawned-task-names>], timeout_ms: 900000 })` to wait for callbacks. If `result.timed_out`, mark tasks as `timed_out` and close agents. Use `close_agent({ target: taskId })` with task_name for cleanup. Workers use `report_agent_job_result()` to send results back.
**Cross-Agent Supplementary Context** (v4):
When spawning workers in a later pipeline phase, send upstream results as supplementary context to already-running workers:
```
// Example: Send analysis results to running fixer
send_message({
target: "<running-agent-task-name>",
items: [{ type: "text", text: `## Supplementary Context\n${upstreamFindings}` }]
})
// Note: send_message queues info without interrupting the agent's current work
```
Use `send_message` (not `assign_task`) for supplementary info that enriches but doesn't redirect the agent's current task.
## handleComplete
**Cleanup Verification** (v4):
```
// Verify all agents are properly closed
const remaining = list_agents({})
// If any team agents still running -> close_agent each
// Ensures clean session shutdown
```
Pipeline done. Generate debug report and completion action.
1. Generate debug summary:

14
.codex/skills/team-frontend-debug/roles/coordinator/role.md
View File

@@ -6,7 +6,7 @@ Orchestrate team-frontend-debug: analyze -> dispatch -> spawn -> monitor -> repo
**You are a dispatcher, not a doer.** Your ONLY outputs are:
- Session state files (`.workflow/.team/` directory)
- `spawn_agent` / `wait_agent` / `close_agent` / `send_input` calls
- `spawn_agent` / `wait_agent` / `close_agent` / `send_message` / `assign_task` calls
- Status reports to the user / `request_user_input` prompts
**FORBIDDEN** (even if the task seems trivial):
@@ -36,6 +36,8 @@ WRONG: mcp__chrome-devtools__* calls — worker work
- Handle iteration loops (analyzer requesting more evidence)
- Execute completion action when pipeline finishes
- **Always proceed through full Phase 1-5 workflow, never skip to direct execution**
- Use `send_message` for supplementary context (non-interrupting) and `assign_task` for triggering new work
- Use `list_agents` for session resume health checks and cleanup verification
### MUST NOT
- Read source code or explore codebase (delegate to workers)
@@ -141,6 +143,16 @@ Delegate to @commands/monitor.md#handleSpawnNext:
- interactive -> request_user_input (Archive/Keep/Export)
- auto_archive -> Archive & Clean
## v4 Coordination Patterns
### Message Semantics
- **send_message**: Queue supplementary info to a running agent. Does NOT interrupt current processing. Use for: sharing upstream results, context enrichment, FYI notifications.
- **assign_task**: Assign new work and trigger processing. Use for: waking idle agents, redirecting work, requesting new output.
### Agent Lifecycle Management
- **list_agents({})**: Returns all running agents. Use in handleResume to reconcile session state with actual running agents. Use in handleComplete to verify clean shutdown.
- **Named targeting**: Workers spawned with `task_name: "<task-id>"` can be addressed by name in send_message, assign_task, and close_agent calls.
## Error Handling
| Error | Resolution |