mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-03-06 16:31:12 +08:00
Refactor team collaboration skills and update documentation
- Renamed `team-lifecycle-v5` to `team-lifecycle` across various documentation files for consistency. - Updated references in code examples and usage sections to reflect the new skill name. - Added a new command file for the `monitor` functionality in the `team-iterdev` skill, detailing the coordinator's monitoring events and task management. - Introduced new components for dynamic pipeline visualization and session coordinates display in the frontend. - Implemented utility functions for pipeline stage detection and status derivation based on message history. - Enhanced the team role panel to map members to their respective pipeline roles with status indicators. - Updated Chinese documentation to reflect the changes in skill names and descriptions.
This commit is contained in:
catlog22
@@ -11,20 +11,23 @@ Iterative development team skill. Generator-Critic loops (developer<->reviewer,
|
||||
## Architecture
|
||||
|
||||
```
|
||||
+-------------------------------------------------+
|
||||
| Skill(skill="team-iterdev") |
|
||||
| args="task description" or args="--role=xxx" |
|
||||
+-------------------+-----------------------------+
|
||||
| Role Router
|
||||
+---- --role present? ----+
|
||||
| NO | YES
|
||||
v v
|
||||
Orchestration Mode Role Dispatch
|
||||
(auto -> coordinator) (route to role.md)
|
||||
|
|
||||
+----+----+----------+---------+---------+
|
||||
v v v v v
|
||||
coordinator architect developer tester reviewer
|
||||
+---------------------------------------------------+
|
||||
| Skill(skill="team-iterdev") |
|
||||
| args="<task-description>" |
|
||||
+-------------------+-------------------------------+
|
||||
|
|
||||
Orchestration Mode (auto -> coordinator)
|
||||
|
|
||||
Coordinator (inline)
|
||||
Phase 0-5 orchestration
|
||||
|
|
||||
+-------+-------+-------+-------+
|
||||
v v v v
|
||||
[tw] [tw] [tw] [tw]
|
||||
archi- devel- tester review-
|
||||
tect oper er
|
||||
|
||||
(tw) = team-worker agent
|
||||
```
|
||||
|
||||
## Role Router
|
||||
@@ -35,13 +38,13 @@ Parse `$ARGUMENTS` to extract `--role`. If absent -> Orchestration Mode (auto ro
|
||||
|
||||
### Role Registry
|
||||
|
||||
| Role | File | Task Prefix | Type | Compact |
|
||||
|------|------|-------------|------|---------|
|
||||
| coordinator | [roles/coordinator.md](roles/coordinator.md) | (none) | orchestrator | **MUST re-read after compression** |
|
||||
| architect | [roles/architect.md](roles/architect.md) | DESIGN-* | pipeline | MUST re-read after compression |
|
||||
| developer | [roles/developer.md](roles/developer.md) | DEV-* | pipeline | MUST re-read after compression |
|
||||
| tester | [roles/tester.md](roles/tester.md) | VERIFY-* | pipeline | MUST re-read after compression |
|
||||
| reviewer | [roles/reviewer.md](roles/reviewer.md) | REVIEW-* | pipeline | MUST re-read after compression |
|
||||
| Role | Spec | Task Prefix | Inner Loop |
|
||||
|------|------|-------------|------------|
|
||||
| coordinator | [roles/coordinator/role.md](roles/coordinator/role.md) | (none) | - |
|
||||
| architect | [role-specs/architect.md](role-specs/architect.md) | DESIGN-* | false |
|
||||
| developer | [role-specs/developer.md](role-specs/developer.md) | DEV-* | true |
|
||||
| tester | [role-specs/tester.md](role-specs/tester.md) | VERIFY-* | false |
|
||||
| reviewer | [role-specs/reviewer.md](role-specs/reviewer.md) | REVIEW-* | false |
|
||||
|
||||
> **COMPACT PROTECTION**: Role files are execution documents, not reference material. When context compression occurs and role instructions are reduced to summaries, you **MUST immediately `Read` the corresponding role.md to reload before continuing execution**. Never execute any Phase based on summaries alone.
|
||||
|
||||
@@ -404,39 +407,62 @@ Real-time tracking of all sprint task progress. Coordinator updates at each task
|
||||
|
||||
## Coordinator Spawn Template
|
||||
|
||||
When coordinator spawns workers, use background mode (Spawn-and-Stop):
|
||||
### v5 Worker Spawn (all roles)
|
||||
|
||||
When coordinator spawns workers, use `team-worker` agent with role-spec path:
|
||||
|
||||
```
|
||||
Task({
|
||||
subagent_type: "general-purpose",
|
||||
subagent_type: "team-worker",
|
||||
description: "Spawn <role> worker",
|
||||
team_name: <team-name>,
|
||||
team_name: "iterdev",
|
||||
name: "<role>",
|
||||
run_in_background: true,
|
||||
prompt: `You are team "<team-name>" <ROLE>.
|
||||
prompt: `## Role Assignment
|
||||
role: <role>
|
||||
role_spec: .claude/skills/team-iterdev/role-specs/<role>.md
|
||||
session: <session-folder>
|
||||
session_id: <session-id>
|
||||
team_name: iterdev
|
||||
requirement: <task-description>
|
||||
inner_loop: <true|false>
|
||||
|
||||
## Primary Instruction
|
||||
All your work must be executed by calling Skill to load role definition:
|
||||
Skill(skill="team-iterdev", args="--role=<role>")
|
||||
|
||||
Current requirement: <task-description>
|
||||
Session: <session-folder>
|
||||
|
||||
## Role Guidelines
|
||||
- Only process <PREFIX>-* tasks, do not execute other roles' work
|
||||
- All output must have [<role>] identifier prefix
|
||||
- Communicate only with coordinator
|
||||
- Do not use TaskCreate to create tasks for other roles
|
||||
- Before each SendMessage, call mcp__ccw-tools__team_msg to log
|
||||
|
||||
## Workflow
|
||||
1. Call Skill -> load role definition and execution logic
|
||||
2. Follow role.md 5-Phase flow
|
||||
3. team_msg + SendMessage result to coordinator
|
||||
4. TaskUpdate completed -> check next task`
|
||||
Read role_spec file to load Phase 2-4 domain instructions.
|
||||
Execute built-in Phase 1 (task discovery) -> role-spec Phase 2-4 -> built-in Phase 5 (report).`
|
||||
})
|
||||
```
|
||||
|
||||
**Inner Loop roles** (developer): Set `inner_loop: true`. The team-worker agent handles the loop internally.
|
||||
|
||||
**Single-task roles** (architect, tester, reviewer): Set `inner_loop: false`.
|
||||
|
||||
---
|
||||
|
||||
## Completion Action
|
||||
|
||||
When the pipeline completes (all tasks done, coordinator Phase 5):
|
||||
|
||||
```
|
||||
AskUserQuestion({
|
||||
questions: [{
|
||||
question: "IterDev pipeline complete. What would you like to do?",
|
||||
header: "Completion",
|
||||
multiSelect: false,
|
||||
options: [
|
||||
{ label: "Archive & Clean (Recommended)", description: "Archive session, clean up tasks and team resources" },
|
||||
{ label: "Keep Active", description: "Keep session active for follow-up work or inspection" },
|
||||
{ label: "Export Results", description: "Export deliverables to a specified location, then clean" }
|
||||
]
|
||||
}]
|
||||
})
|
||||
```
|
||||
|
||||
| Choice | Action |
|
||||
|--------|--------|
|
||||
| Archive & Clean | Update session status="completed" -> TeamDelete(iterdev) -> output final summary |
|
||||
| Keep Active | Update session status="paused" -> output resume instructions: `Skill(skill="team-iterdev", args="resume")` |
|
||||
| Export Results | AskUserQuestion for target path -> copy deliverables -> Archive & Clean |
|
||||
|
||||
---
|
||||
|
||||
## Unified Session Directory
|
||||
|
||||
@@ -1,260 +0,0 @@
|
||||
# Architect Role
|
||||
|
||||
Technical architect. Responsible for technical design, task decomposition, and architecture decision records.
|
||||
|
||||
## Identity
|
||||
|
||||
- **Name**: `architect` | **Tag**: `[architect]`
|
||||
- **Task Prefix**: `DESIGN-*`
|
||||
- **Responsibility**: Read-only analysis (Technical Design)
|
||||
|
||||
## Boundaries
|
||||
|
||||
### MUST
|
||||
|
||||
- Only process `DESIGN-*` prefixed tasks
|
||||
- All output must carry `[architect]` identifier
|
||||
- Phase 2: Read .msg/meta.json, Phase 5: Write architecture_decisions
|
||||
- Work strictly within technical design responsibility scope
|
||||
|
||||
### MUST NOT
|
||||
|
||||
- Execute work outside this role's responsibility scope
|
||||
- Write implementation code, execute tests, or perform code review
|
||||
- Communicate directly with other worker roles (must go through coordinator)
|
||||
- Create tasks for other roles (TaskCreate is coordinator-exclusive)
|
||||
- Modify files or resources outside this role's responsibility
|
||||
- Omit `[architect]` identifier in any output
|
||||
|
||||
---
|
||||
|
||||
## Toolbox
|
||||
|
||||
### Tool Capabilities
|
||||
|
||||
| Tool | Type | Purpose |
|
||||
|------|------|---------|
|
||||
| Task | Agent | Spawn cli-explore-agent for codebase exploration |
|
||||
| Read | File | Read session files, shared memory, design files |
|
||||
| Write | File | Write design documents and task breakdown |
|
||||
| Bash | Shell | Execute shell commands |
|
||||
|
||||
---
|
||||
|
||||
## Message Types
|
||||
|
||||
| Type | Direction | Trigger | Description |
|
||||
|------|-----------|---------|-------------|
|
||||
| `design_ready` | architect -> coordinator | Design completed | Design ready for implementation |
|
||||
| `design_revision` | architect -> coordinator | Design revised | Design updated based on feedback |
|
||||
| `error` | architect -> coordinator | Processing failure | Error report |
|
||||
|
||||
## Message Bus
|
||||
|
||||
Before every SendMessage, log via `mcp__ccw-tools__team_msg`:
|
||||
|
||||
|
||||
```
|
||||
mcp__ccw-tools__team_msg({
|
||||
operation: "log",
|
||||
session_id: <session-id>,
|
||||
from: "architect",
|
||||
type: <message-type>,
|
||||
data: { ref: <design-path> }
|
||||
})
|
||||
```
|
||||
|
||||
**CLI fallback** (when MCP unavailable):
|
||||
|
||||
```
|
||||
Bash("ccw team log --session-id <session-id> --from architect --type <message-type> --json")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Execution (5-Phase)
|
||||
|
||||
### Phase 1: Task Discovery
|
||||
|
||||
> See SKILL.md Shared Infrastructure -> Worker Phase 1: Task Discovery
|
||||
|
||||
Standard task discovery flow: TaskList -> filter by prefix `DESIGN-*` + owner match + pending + unblocked -> TaskGet -> TaskUpdate in_progress.
|
||||
|
||||
### Phase 2: Context Loading + Codebase Exploration
|
||||
|
||||
**Inputs**:
|
||||
|
||||
| Input | Source | Required |
|
||||
|-------|--------|----------|
|
||||
| Session path | Task description (Session: <path>) | Yes |
|
||||
| Shared memory | <session-folder>/.msg/meta.json | Yes |
|
||||
| Codebase | Project files | Yes |
|
||||
| Wisdom | <session-folder>/wisdom/ | No |
|
||||
|
||||
**Loading steps**:
|
||||
|
||||
1. Extract session path from task description
|
||||
2. Read .msg/meta.json for context
|
||||
|
||||
```
|
||||
Read(<session-folder>/.msg/meta.json)
|
||||
```
|
||||
|
||||
3. Multi-angle codebase exploration via cli-explore-agent:
|
||||
|
||||
```
|
||||
Task({
|
||||
subagent_type: "cli-explore-agent",
|
||||
run_in_background: false,
|
||||
description: "Explore architecture",
|
||||
prompt: `Explore codebase architecture for: <task-description>
|
||||
|
||||
Focus on:
|
||||
- Existing patterns
|
||||
- Module structure
|
||||
- Dependencies
|
||||
- Similar implementations
|
||||
|
||||
Report relevant files and integration points.`
|
||||
})
|
||||
```
|
||||
|
||||
### Phase 3: Technical Design + Task Decomposition
|
||||
|
||||
**Design strategy selection**:
|
||||
|
||||
| Condition | Strategy |
|
||||
|-----------|----------|
|
||||
| Single module change | Direct inline design |
|
||||
| Cross-module change | Multi-component design with integration points |
|
||||
| Large refactoring | Phased approach with milestones |
|
||||
|
||||
**Outputs**:
|
||||
|
||||
1. **Design Document** (`<session-folder>/design/design-<num>.md`):
|
||||
|
||||
```markdown
|
||||
# Technical Design — <num>
|
||||
|
||||
**Requirement**: <task-description>
|
||||
**Sprint**: <sprint-number>
|
||||
|
||||
## Architecture Decision
|
||||
|
||||
**Approach**: <selected-approach>
|
||||
**Rationale**: <rationale>
|
||||
**Alternatives Considered**: <alternatives>
|
||||
|
||||
## Component Design
|
||||
|
||||
### <Component-1>
|
||||
- **Responsibility**: <description>
|
||||
- **Dependencies**: <deps>
|
||||
- **Files**: <file-list>
|
||||
- **Complexity**: <low/medium/high>
|
||||
|
||||
## Task Breakdown
|
||||
|
||||
### Task 1: <title>
|
||||
- **Files**: <file-list>
|
||||
- **Estimated Complexity**: <level>
|
||||
- **Dependencies**: <deps or None>
|
||||
|
||||
## Integration Points
|
||||
|
||||
- **<Integration-1>**: <description>
|
||||
|
||||
## Risks
|
||||
|
||||
- **<Risk-1>**: <mitigation>
|
||||
```
|
||||
|
||||
2. **Task Breakdown JSON** (`<session-folder>/design/task-breakdown.json`):
|
||||
|
||||
```json
|
||||
{
|
||||
"design_id": "design-<num>",
|
||||
"tasks": [
|
||||
{
|
||||
"id": "task-1",
|
||||
"title": "<title>",
|
||||
"files": ["<file1>", "<file2>"],
|
||||
"complexity": "<level>",
|
||||
"dependencies": [],
|
||||
"acceptance_criteria": "<criteria>"
|
||||
}
|
||||
],
|
||||
"total_files": <count>,
|
||||
"execution_order": ["task-1", "task-2"]
|
||||
}
|
||||
```
|
||||
|
||||
### Phase 4: Design Validation
|
||||
|
||||
**Validation checks**:
|
||||
|
||||
| Check | Method | Pass Criteria |
|
||||
|-------|--------|---------------|
|
||||
| Components defined | Verify component list | At least 1 component |
|
||||
| Task breakdown exists | Verify task list | At least 1 task |
|
||||
| Dependencies mapped | Check all components have dependencies field | All have dependencies (can be empty) |
|
||||
| Integration points | Verify integration section | Key integrations documented |
|
||||
|
||||
### Phase 5: Report to Coordinator
|
||||
|
||||
> See SKILL.md Shared Infrastructure -> Worker Phase 5: Report
|
||||
|
||||
1. **Update shared memory**:
|
||||
|
||||
```
|
||||
sharedMemory.architecture_decisions.push({
|
||||
design_id: "design-<num>",
|
||||
approach: <approach>,
|
||||
rationale: <rationale>,
|
||||
components: <component-names>,
|
||||
task_count: <count>
|
||||
})
|
||||
Write(<session-folder>/.msg/meta.json, JSON.stringify(sharedMemory, null, 2))
|
||||
```
|
||||
|
||||
2. **Log and send message**:
|
||||
|
||||
```
|
||||
mcp__ccw-tools__team_msg({
|
||||
operation: "log", session_id: <session-id>, from: "architect",
|
||||
type: "design_ready",
|
||||
data: { ref: <design-path> }
|
||||
})
|
||||
|
||||
SendMessage({
|
||||
type: "message", recipient: "coordinator",
|
||||
content: `## [architect] Design Ready
|
||||
|
||||
**Components**: <count>
|
||||
**Tasks**: <task-count>
|
||||
**Design**: <design-path>
|
||||
**Breakdown**: <breakdown-path>`,
|
||||
})
|
||||
```
|
||||
|
||||
3. **Mark task complete**:
|
||||
|
||||
```
|
||||
TaskUpdate({ taskId: <task-id>, status: "completed" })
|
||||
```
|
||||
|
||||
4. **Loop to Phase 1** for next task
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Scenario | Resolution |
|
||||
|----------|------------|
|
||||
| No DESIGN-* tasks available | Idle, wait for coordinator assignment |
|
||||
| Codebase exploration fails | Design based on task description alone |
|
||||
| Too many components identified | Simplify, suggest phased approach |
|
||||
| Conflicting patterns found | Document in design, recommend resolution |
|
||||
| Context/Plan file not found | Notify coordinator, request location |
|
||||
| Critical issue beyond scope | SendMessage fix_required to coordinator |
|
||||
| Unexpected error | Log error via team_msg, report to coordinator |
|
||||
@@ -1,420 +0,0 @@
|
||||
# Coordinator Role
|
||||
|
||||
Orchestrate the IterDev workflow: Sprint planning, backlog management, task ledger maintenance, Generator-Critic loop control (developer<->reviewer, max 3 rounds), cross-sprint learning, conflict handling, concurrency control, rollback strategy, user feedback loop, and tech debt tracking.
|
||||
|
||||
## Identity
|
||||
|
||||
- **Name**: `coordinator` | **Tag**: `[coordinator]`
|
||||
- **Responsibility**: Orchestration + Stability Management + Quality Tracking
|
||||
|
||||
## Boundaries
|
||||
|
||||
### MUST
|
||||
|
||||
- All output must carry `[coordinator]` identifier
|
||||
- Maintain task-ledger.json for real-time progress
|
||||
- Manage developer<->reviewer GC loop (max 3 rounds)
|
||||
- Record learning to .msg/meta.json at Sprint end
|
||||
- Detect and coordinate task conflicts
|
||||
- Manage shared resource locks (resource_locks)
|
||||
- Record rollback points and support emergency rollback
|
||||
- Collect and track user feedback (user_feedback_items)
|
||||
- Identify and record tech debt (tech_debt_items)
|
||||
- Generate tech debt reports
|
||||
|
||||
### MUST NOT
|
||||
|
||||
- Execute implementation work directly (delegate to workers)
|
||||
- Write source code directly
|
||||
- Call implementation-type subagents directly
|
||||
- Modify task outputs (workers own their deliverables)
|
||||
- Skip dependency validation when creating task chains
|
||||
|
||||
> **Core principle**: Coordinator is the orchestrator, not the executor. All actual work must be delegated to worker roles via TaskCreate.
|
||||
|
||||
---
|
||||
|
||||
## Entry Router
|
||||
|
||||
When coordinator is invoked, first detect the invocation type:
|
||||
|
||||
| Detection | Condition | Handler |
|
||||
|-----------|-----------|---------|
|
||||
| Worker callback | Message contains `[role-name]` tag from a known worker role | -> handleCallback: auto-advance pipeline |
|
||||
| Status check | Arguments contain "check" or "status" | -> handleCheck: output execution graph, no advancement |
|
||||
| Manual resume | Arguments contain "resume" or "continue" | -> handleResume: check worker states, advance pipeline |
|
||||
| New session | None of the above | -> Phase 0 (Session Resume Check) |
|
||||
|
||||
For callback/check/resume: load monitor logic and execute the appropriate handler, then STOP.
|
||||
|
||||
---
|
||||
|
||||
## Phase 0: Session Resume Check
|
||||
|
||||
**Objective**: Detect and resume interrupted sessions before creating new ones.
|
||||
|
||||
**Workflow**:
|
||||
|
||||
1. Scan `.workflow/.team/IDS-*/.msg/meta.json` for sessions with status "active" or "paused"
|
||||
2. No sessions found -> proceed to Phase 1
|
||||
3. Single session found -> resume it (-> Session Reconciliation)
|
||||
4. Multiple sessions -> AskUserQuestion for user selection
|
||||
|
||||
**Session Reconciliation**:
|
||||
|
||||
1. Audit TaskList -> get real status of all tasks
|
||||
2. Reconcile: session state <-> TaskList status (bidirectional sync)
|
||||
3. Reset any in_progress tasks -> pending (they were interrupted)
|
||||
4. Determine remaining pipeline from reconciled state
|
||||
5. Rebuild team if disbanded (TeamCreate + spawn needed workers only)
|
||||
6. Create missing tasks with correct blockedBy dependencies
|
||||
7. Verify dependency chain integrity
|
||||
8. Update session file with reconciled state
|
||||
9. Kick first executable task's worker -> Phase 4
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Requirement Clarification
|
||||
|
||||
**Objective**: Parse user input and gather execution parameters.
|
||||
|
||||
**Workflow**:
|
||||
|
||||
1. **Parse arguments** for explicit settings: mode, scope, focus areas
|
||||
|
||||
2. **Assess complexity** for pipeline selection:
|
||||
|
||||
| Signal | Weight | Keywords |
|
||||
|--------|--------|----------|
|
||||
| Changed files > 10 | +3 | Large changeset |
|
||||
| Changed files 3-10 | +2 | Medium changeset |
|
||||
| Structural change | +3 | refactor, architect, restructure, system, module |
|
||||
| Cross-cutting | +2 | multiple, across, cross |
|
||||
| Simple fix | -2 | fix, bug, typo, patch |
|
||||
|
||||
| Score | Pipeline | Description |
|
||||
|-------|----------|-------------|
|
||||
| >= 5 | multi-sprint | Incremental iterative delivery for large features |
|
||||
| 2-4 | sprint | Standard: Design -> Dev -> Verify + Review |
|
||||
| 0-1 | patch | Simple: Dev -> Verify |
|
||||
|
||||
3. **Ask for missing parameters** via AskUserQuestion:
|
||||
|
||||
```
|
||||
AskUserQuestion({
|
||||
questions: [{
|
||||
question: "Select development mode:",
|
||||
header: "Mode",
|
||||
multiSelect: false,
|
||||
options: [
|
||||
{ label: "patch (recommended)", description: "Patch mode: implement -> verify (simple fixes)" },
|
||||
{ label: "sprint (recommended)", description: "Sprint mode: design -> implement -> verify + review" },
|
||||
{ label: "multi-sprint (recommended)", description: "Multi-sprint: incremental iterative delivery (large features)" }
|
||||
]
|
||||
}]
|
||||
})
|
||||
```
|
||||
|
||||
**Success**: All parameters captured, mode finalized.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Create Team + Initialize Session
|
||||
|
||||
**Objective**: Initialize team, session file, task ledger, shared memory, and wisdom directory.
|
||||
|
||||
**Workflow**:
|
||||
|
||||
1. Generate session ID: `IDS-{slug}-{YYYY-MM-DD}`
|
||||
2. Create session folder structure
|
||||
3. Call TeamCreate with team name
|
||||
4. Initialize wisdom directory (learnings.md, decisions.md, conventions.md, issues.md)
|
||||
5. Write session file with: session_id, mode, scope, status="active"
|
||||
6. Initialize task-ledger.json:
|
||||
|
||||
```
|
||||
{
|
||||
"sprint_id": "sprint-1",
|
||||
"sprint_goal": "<task-description>",
|
||||
"pipeline": "<selected-pipeline>",
|
||||
"tasks": [],
|
||||
"metrics": { "total": 0, "completed": 0, "in_progress": 0, "blocked": 0, "velocity": 0 }
|
||||
}
|
||||
```
|
||||
|
||||
7. Initialize .msg/meta.json:
|
||||
|
||||
```
|
||||
{
|
||||
"sprint_history": [],
|
||||
"architecture_decisions": [],
|
||||
"implementation_context": [],
|
||||
"review_feedback_trends": [],
|
||||
"gc_round": 0,
|
||||
"max_gc_rounds": 3,
|
||||
"resource_locks": {},
|
||||
"task_checkpoints": {},
|
||||
"user_feedback_items": [],
|
||||
"tech_debt_items": []
|
||||
}
|
||||
```
|
||||
|
||||
**Success**: Team created, session file written, wisdom initialized, task ledger and shared memory ready.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: Create Task Chain
|
||||
|
||||
**Objective**: Dispatch tasks based on mode with proper dependencies.
|
||||
|
||||
### Patch Pipeline
|
||||
|
||||
| Task ID | Owner | Blocked By | Description |
|
||||
|---------|-------|------------|-------------|
|
||||
| DEV-001 | developer | (none) | Implement fix |
|
||||
| VERIFY-001 | tester | DEV-001 | Verify fix |
|
||||
|
||||
### Sprint Pipeline
|
||||
|
||||
| Task ID | Owner | Blocked By | Description |
|
||||
|---------|-------|------------|-------------|
|
||||
| DESIGN-001 | architect | (none) | Technical design and task breakdown |
|
||||
| DEV-001 | developer | DESIGN-001 | Implement design |
|
||||
| VERIFY-001 | tester | DEV-001 | Test execution |
|
||||
| REVIEW-001 | reviewer | DEV-001 | Code review |
|
||||
|
||||
### Multi-Sprint Pipeline
|
||||
|
||||
Sprint 1: DESIGN-001 -> DEV-001 -> DEV-002(incremental) -> VERIFY-001 -> DEV-fix -> REVIEW-001
|
||||
|
||||
Subsequent sprints created dynamically after Sprint N completes.
|
||||
|
||||
**Task Creation**: Use TaskCreate + TaskUpdate(owner, addBlockedBy) for each task. Include `Session: <session-folder>` in every task description.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: Spawn-and-Stop
|
||||
|
||||
**Objective**: Spawn first batch of ready workers in background, then STOP.
|
||||
|
||||
**Design**: Spawn-and-Stop + Callback pattern.
|
||||
- Spawn workers with `Task(run_in_background: true)` -> immediately return
|
||||
- Worker completes -> SendMessage callback -> auto-advance
|
||||
- User can use "check" / "resume" to manually advance
|
||||
- Coordinator does one operation per invocation, then STOPS
|
||||
|
||||
**Workflow**:
|
||||
|
||||
1. Find tasks with: status=pending, blockedBy all resolved, owner assigned
|
||||
2. For each ready task -> spawn worker using Spawn Template
|
||||
3. Output status summary
|
||||
4. STOP
|
||||
|
||||
### Callback Handler
|
||||
|
||||
| Received Message | Action |
|
||||
|-----------------|--------|
|
||||
| architect: design_ready | Update ledger -> unblock DEV |
|
||||
| developer: dev_complete | Update ledger -> unblock VERIFY + REVIEW |
|
||||
| tester: verify_passed | Update ledger (test_pass_rate) |
|
||||
| tester: verify_failed | Create DEV-fix task |
|
||||
| tester: fix_required | Create DEV-fix task -> assign developer |
|
||||
| reviewer: review_passed | Update ledger (review_score) -> mark complete |
|
||||
| reviewer: review_revision | **GC loop** -> create DEV-fix -> REVIEW-next |
|
||||
| reviewer: review_critical | **GC loop** -> create DEV-fix -> REVIEW-next |
|
||||
|
||||
### GC Loop Control
|
||||
|
||||
When receiving `review_revision` or `review_critical`:
|
||||
|
||||
1. Read .msg/meta.json -> get gc_round
|
||||
2. If gc_round < max_gc_rounds (3):
|
||||
- Increment gc_round
|
||||
- Create DEV-fix task with review feedback
|
||||
- Create REVIEW-next task blocked by DEV-fix
|
||||
- Update ledger
|
||||
- Log gc_loop_trigger message
|
||||
3. Else (max rounds reached):
|
||||
- Accept with warning
|
||||
- Log sprint_complete message
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Report + Next Steps
|
||||
|
||||
**Objective**: Completion report and follow-up options.
|
||||
|
||||
**Workflow**:
|
||||
|
||||
1. Load session state -> count completed tasks, duration
|
||||
2. Record sprint learning to .msg/meta.json
|
||||
3. List deliverables with output paths
|
||||
4. Update session status -> "completed"
|
||||
5. Offer next steps via AskUserQuestion
|
||||
|
||||
---
|
||||
|
||||
## Protocol Implementations
|
||||
|
||||
### Resource Lock Protocol
|
||||
|
||||
Concurrency control for shared resources. Prevents multiple workers from modifying the same files simultaneously.
|
||||
|
||||
| Action | Trigger Condition | Behavior |
|
||||
|--------|-------------------|----------|
|
||||
| Acquire lock | Worker requests exclusive access | Check resource_locks via team_msg(type='state_update'). If unlocked, record lock with task ID, timestamp, holder. Log resource_locked. Return success. |
|
||||
| Deny lock | Resource already locked | Return failure with current holder's task ID. Log resource_contention. Worker must wait. |
|
||||
| Release lock | Worker completes task | Remove lock entry. Log resource_unlocked. |
|
||||
| Force release | Lock held beyond timeout (5 min) | Force-remove lock entry. Notify holder. Log warning. |
|
||||
| Deadlock detection | Multiple tasks waiting on each other | Abort youngest task, release its locks. Notify coordinator. |
|
||||
|
||||
### Conflict Detection Protocol
|
||||
|
||||
Detects and resolves file-level conflicts between concurrent development tasks.
|
||||
|
||||
| Action | Trigger Condition | Behavior |
|
||||
|--------|-------------------|----------|
|
||||
| Detect conflict | DEV task completes with changed files | Compare changed files against other in_progress/completed tasks. If overlap, update task's conflict_info to status "detected". Log conflict_detected. |
|
||||
| Resolve conflict | Conflict detected | Set resolution_strategy (manual/auto_merge/abort). Create fix-conflict task for developer. Log conflict_resolved. |
|
||||
| Skip | No file overlap | No action needed. |
|
||||
|
||||
### Rollback Point Protocol
|
||||
|
||||
Manages state snapshots for safe recovery.
|
||||
|
||||
| Action | Trigger Condition | Behavior |
|
||||
|--------|-------------------|----------|
|
||||
| Create rollback point | Task phase completes | Generate snapshot ID, record rollback_procedure (default: git revert HEAD) in task's rollback_info. |
|
||||
| Execute rollback | Task failure or user request | Log rollback_initiated. Execute stored procedure. Log rollback_completed or rollback_failed. |
|
||||
| Validate snapshot | Before rollback | Verify snapshot ID exists and procedure is valid. |
|
||||
|
||||
### Dependency Validation Protocol
|
||||
|
||||
Validates external dependencies before task execution.
|
||||
|
||||
| Action | Trigger Condition | Behavior |
|
||||
|--------|-------------------|----------|
|
||||
| Validate | Task startup with dependencies | Check installed version vs expected. Record status (ok/mismatch/missing) in external_dependencies. |
|
||||
| Report mismatch | Any dependency has issues | Log dependency_mismatch. Block task until resolved. |
|
||||
| Update notification | Important update available | Log dependency_update_needed. Add to backlog. |
|
||||
|
||||
### Checkpoint Management Protocol
|
||||
|
||||
Saves and restores task execution state for interruption recovery.
|
||||
|
||||
| Action | Trigger Condition | Behavior |
|
||||
|--------|-------------------|----------|
|
||||
| Save checkpoint | Task reaches milestone | Store checkpoint in task_checkpoints with timestamp. Retain last 5 per task. Log context_checkpoint_saved. |
|
||||
| Restore checkpoint | Task resumes after interruption | Load latest checkpoint. Log context_restored. |
|
||||
| Not found | Resume requested but no checkpoints | Return failure. Worker starts fresh. |
|
||||
|
||||
### User Feedback Protocol
|
||||
|
||||
Collects, categorizes, and tracks user feedback.
|
||||
|
||||
| Action | Trigger Condition | Behavior |
|
||||
|--------|-------------------|----------|
|
||||
| Receive feedback | User provides feedback | Create feedback item (FB-xxx) with severity, category. Store in user_feedback_items (max 50). Log user_feedback_received. |
|
||||
| Link to task | Feedback relates to task | Update source_task_id, set status "reviewed". |
|
||||
| Triage | High/critical severity | Prioritize in next sprint. Create task if actionable. |
|
||||
|
||||
### Tech Debt Management Protocol
|
||||
|
||||
Identifies, tracks, and prioritizes technical debt.
|
||||
|
||||
| Action | Trigger Condition | Behavior |
|
||||
|--------|-------------------|----------|
|
||||
| Identify debt | Worker reports tech debt | Create debt item (TD-xxx) with category, severity, effort. Store in tech_debt_items. Log tech_debt_identified. |
|
||||
| Generate report | Sprint retrospective | Aggregate by severity and category. Report totals. |
|
||||
| Prioritize | Sprint planning | Rank by severity. Recommend items for current sprint. |
|
||||
| Resolve | Developer completes debt task | Update status to "resolved". Record in sprint history. |
|
||||
|
||||
---
|
||||
|
||||
## Toolbox
|
||||
|
||||
### Tool Capabilities
|
||||
|
||||
| Tool | Type | Purpose |
|
||||
|------|------|---------|
|
||||
| TeamCreate | Team | Create team instance |
|
||||
| TeamDelete | Team | Disband team |
|
||||
| SendMessage | Communication | Send messages to workers |
|
||||
| TaskCreate | Task | Create tasks for workers |
|
||||
| TaskUpdate | Task | Update task status/owner/dependencies |
|
||||
| TaskList | Task | List all tasks |
|
||||
| TaskGet | Task | Get task details |
|
||||
| Task | Agent | Spawn worker agents |
|
||||
| AskUserQuestion | Interaction | Ask user for input |
|
||||
| Read | File | Read session files |
|
||||
| Write | File | Write session files |
|
||||
| Bash | Shell | Execute shell commands |
|
||||
|
||||
---
|
||||
|
||||
## Message Types
|
||||
|
||||
| Type | Direction | Trigger | Description |
|
||||
|------|-----------|---------|-------------|
|
||||
| sprint_started | coordinator -> all | Sprint begins | Sprint initialization |
|
||||
| gc_loop_trigger | coordinator -> developer | Review needs revision | GC loop iteration |
|
||||
| sprint_complete | coordinator -> all | Sprint ends | Sprint summary |
|
||||
| task_unblocked | coordinator -> worker | Task dependencies resolved | Task ready |
|
||||
| error | coordinator -> all | Error occurred | Error notification |
|
||||
| shutdown | coordinator -> all | Team disbands | Shutdown notice |
|
||||
| conflict_detected | coordinator -> all | File conflict found | Conflict alert |
|
||||
| conflict_resolved | coordinator -> all | Conflict resolved | Resolution notice |
|
||||
| resource_locked | coordinator -> all | Resource acquired | Lock notification |
|
||||
| resource_unlocked | coordinator -> all | Resource released | Unlock notification |
|
||||
| resource_contention | coordinator -> all | Lock denied | Contention alert |
|
||||
| rollback_initiated | coordinator -> all | Rollback started | Rollback notice |
|
||||
| rollback_completed | coordinator -> all | Rollback succeeded | Success notice |
|
||||
| rollback_failed | coordinator -> all | Rollback failed | Failure alert |
|
||||
| dependency_mismatch | coordinator -> all | Dependency issue | Dependency alert |
|
||||
| dependency_update_needed | coordinator -> all | Update available | Update notice |
|
||||
| context_checkpoint_saved | coordinator -> all | Checkpoint created | Checkpoint notice |
|
||||
| context_restored | coordinator -> all | Checkpoint restored | Restore notice |
|
||||
| user_feedback_received | coordinator -> all | Feedback recorded | Feedback notice |
|
||||
| tech_debt_identified | coordinator -> all | Tech debt found | Debt notice |
|
||||
|
||||
## Message Bus
|
||||
|
||||
Before every SendMessage, log via `mcp__ccw-tools__team_msg`:
|
||||
|
||||
|
||||
```
|
||||
mcp__ccw-tools__team_msg({
|
||||
operation: "log",
|
||||
session_id: <session-id>,
|
||||
from: "coordinator",
|
||||
type: <message-type>,
|
||||
data: { ref: <artifact-path> }
|
||||
})
|
||||
```
|
||||
|
||||
**CLI fallback** (when MCP unavailable):
|
||||
|
||||
```
|
||||
Bash("ccw team log --session-id <session-id> --from coordinator --type <message-type> --json")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Error | Resolution |
|
||||
|-------|------------|
|
||||
| GC loop exceeds 3 rounds | Accept current code, record to sprint_history |
|
||||
| Velocity below 50% | Alert user, suggest scope reduction |
|
||||
| Task ledger corrupted | Rebuild from TaskList state |
|
||||
| Design rejected 3+ times | Coordinator intervenes, simplifies design |
|
||||
| Tests continuously fail | Create DEV-fix for developer |
|
||||
| Conflict detected | Update conflict_info, create DEV-fix task |
|
||||
| Resource lock timeout | Force release after 5 min, notify holder |
|
||||
| Rollback requested | Validate snapshot_id, execute procedure |
|
||||
| Deadlock detected | Abort youngest task, release locks |
|
||||
| Dependency mismatch | Log mismatch, block task until resolved |
|
||||
| Checkpoint restore failure | Log error, worker restarts from Phase 1 |
|
||||
| User feedback critical | Create fix task immediately, elevate priority |
|
||||
| Tech debt exceeds threshold | Generate report, suggest dedicated sprint |
|
||||
| Feedback task link fails | Retain feedback, mark unlinked, manual follow-up |
|
||||
@@ -0,0 +1,172 @@
|
||||
# Command: Monitor
|
||||
|
||||
Handle all coordinator monitoring events: worker callbacks, status checks, pipeline advancement, Generator-Critic loop control (developer<->reviewer), and completion.
|
||||
|
||||
## Constants
|
||||
|
||||
| Key | Value |
|
||||
|-----|-------|
|
||||
| SPAWN_MODE | background |
|
||||
| ONE_STEP_PER_INVOCATION | true |
|
||||
| WORKER_AGENT | team-worker |
|
||||
| MAX_GC_ROUNDS | 3 |
|
||||
|
||||
## Phase 2: Context Loading
|
||||
|
||||
| Input | Source | Required |
|
||||
|-------|--------|----------|
|
||||
| Session state | <session>/session.json | Yes |
|
||||
| Task list | TaskList() | Yes |
|
||||
| Trigger event | From Entry Router detection | Yes |
|
||||
| Meta state | <session>/.msg/meta.json | Yes |
|
||||
| Task ledger | <session>/task-ledger.json | No |
|
||||
|
||||
1. Load session.json for current state, pipeline mode, gc_round, max_gc_rounds
|
||||
2. Run TaskList() to get current task statuses
|
||||
3. Identify trigger event type from Entry Router
|
||||
|
||||
## Phase 3: Event Handlers
|
||||
|
||||
### handleCallback
|
||||
|
||||
Triggered when a worker sends completion message.
|
||||
|
||||
1. Parse message to identify role and task ID:
|
||||
|
||||
| Message Pattern | Role Detection |
|
||||
|----------------|---------------|
|
||||
| `[architect]` or task ID `DESIGN-*` | architect |
|
||||
| `[developer]` or task ID `DEV-*` | developer |
|
||||
| `[tester]` or task ID `VERIFY-*` | tester |
|
||||
| `[reviewer]` or task ID `REVIEW-*` | reviewer |
|
||||
|
||||
2. Mark task as completed:
|
||||
|
||||
```
|
||||
TaskUpdate({ taskId: "<task-id>", status: "completed" })
|
||||
```
|
||||
|
||||
3. Record completion in session state and update task-ledger.json metrics
|
||||
|
||||
4. **Generator-Critic check** (when reviewer completes):
|
||||
- If completed task is REVIEW-* AND pipeline is sprint or multi-sprint:
|
||||
- Read review report for GC signal (critical_count, score)
|
||||
- Read session.json for gc_round
|
||||
|
||||
| GC Signal | gc_round < max | Action |
|
||||
|-----------|----------------|--------|
|
||||
| review.critical_count > 0 OR review.score < 7 | Yes | Increment gc_round, create DEV-fix task blocked by this REVIEW, log `gc_loop_trigger` |
|
||||
| review.critical_count > 0 OR review.score < 7 | No (>= max) | Force convergence, accept with warning, log to wisdom/issues.md |
|
||||
| review.critical_count == 0 AND review.score >= 7 | - | Review passed, proceed to handleComplete check |
|
||||
|
||||
- Log team_msg with type "gc_loop_trigger" or "task_unblocked"
|
||||
|
||||
5. Proceed to handleSpawnNext
|
||||
|
||||
### handleSpawnNext
|
||||
|
||||
Find and spawn the next ready tasks.
|
||||
|
||||
1. Scan task list for tasks where:
|
||||
- Status is "pending"
|
||||
- All blockedBy tasks have status "completed"
|
||||
|
||||
2. For each ready task, determine role from task prefix:
|
||||
|
||||
| Task Prefix | Role | Inner Loop |
|
||||
|-------------|------|------------|
|
||||
| DESIGN-* | architect | false |
|
||||
| DEV-* | developer | true |
|
||||
| VERIFY-* | tester | false |
|
||||
| REVIEW-* | reviewer | false |
|
||||
|
||||
3. Spawn team-worker:
|
||||
|
||||
```
|
||||
Task({
|
||||
subagent_type: "team-worker",
|
||||
description: "Spawn <role> worker for <task-id>",
|
||||
team_name: "iterdev",
|
||||
name: "<role>",
|
||||
run_in_background: true,
|
||||
prompt: `## Role Assignment
|
||||
role: <role>
|
||||
role_spec: .claude/skills/team-iterdev/role-specs/<role>.md
|
||||
session: <session-folder>
|
||||
session_id: <session-id>
|
||||
team_name: iterdev
|
||||
requirement: <task-description>
|
||||
inner_loop: <true|false>
|
||||
|
||||
Read role_spec file to load Phase 2-4 domain instructions.
|
||||
Execute built-in Phase 1 -> role-spec Phase 2-4 -> built-in Phase 5.`
|
||||
})
|
||||
```
|
||||
|
||||
4. **Parallel spawn rules**:
|
||||
|
||||
| Pipeline | Scenario | Spawn Behavior |
|
||||
|----------|----------|---------------|
|
||||
| Patch | DEV -> VERIFY | One worker at a time |
|
||||
| Sprint | VERIFY + REVIEW both unblocked | Spawn BOTH in parallel |
|
||||
| Sprint | Other stages | One worker at a time |
|
||||
| Multi-Sprint | VERIFY + DEV-fix both unblocked | Spawn BOTH in parallel |
|
||||
| Multi-Sprint | Other stages | One worker at a time |
|
||||
|
||||
5. STOP after spawning -- wait for next callback
|
||||
|
||||
### handleCheck
|
||||
|
||||
Output current pipeline status. Do NOT advance pipeline.
|
||||
|
||||
```
|
||||
Pipeline Status (<pipeline-mode>):
|
||||
[DONE] DESIGN-001 (architect) -> design/design-001.md
|
||||
[DONE] DEV-001 (developer) -> code/dev-log.md
|
||||
[RUN] VERIFY-001 (tester) -> verifying...
|
||||
[RUN] REVIEW-001 (reviewer) -> reviewing...
|
||||
[WAIT] DEV-fix (developer) -> blocked by REVIEW-001
|
||||
|
||||
GC Rounds: <gc_round>/<max_gc_rounds>
|
||||
Sprint: <sprint_id>
|
||||
Session: <session-id>
|
||||
```
|
||||
|
||||
### handleResume
|
||||
|
||||
Resume pipeline after user pause or interruption.
|
||||
|
||||
1. Audit task list for inconsistencies:
|
||||
- Tasks stuck in "in_progress" -> reset to "pending"
|
||||
- Tasks with completed blockers but still "pending" -> include in spawn list
|
||||
2. Proceed to handleSpawnNext
|
||||
|
||||
### handleComplete
|
||||
|
||||
Triggered when all pipeline tasks are completed.
|
||||
|
||||
**Completion check by mode**:
|
||||
|
||||
| Mode | Completion Condition |
|
||||
|------|---------------------|
|
||||
| patch | DEV-001 + VERIFY-001 completed |
|
||||
| sprint | DESIGN-001 + DEV-001 + VERIFY-001 + REVIEW-001 (+ any GC tasks) completed |
|
||||
| multi-sprint | All sprint tasks (+ any GC tasks) completed |
|
||||
|
||||
1. Verify all tasks completed via TaskList()
|
||||
2. If any tasks not completed, return to handleSpawnNext
|
||||
3. **Multi-sprint check**: If multi-sprint AND more sprints planned:
|
||||
- Record sprint metrics to .msg/meta.json sprint_history
|
||||
- Evaluate downgrade eligibility (velocity >= expected, review avg >= 8)
|
||||
- Pause for user confirmation before Sprint N+1
|
||||
4. If all completed, transition to coordinator Phase 5 (Report + Completion Action)
|
||||
|
||||
## Phase 4: State Persistence
|
||||
|
||||
After every handler execution:
|
||||
|
||||
1. Update session.json with current state (gc_round, last event, active tasks)
|
||||
2. Update task-ledger.json metrics (completed count, in_progress count, velocity)
|
||||
3. Update .msg/meta.json gc_round if changed
|
||||
4. Verify task list consistency
|
||||
5. STOP and wait for next event
|
||||
@@ -1,275 +0,0 @@
|
||||
# Developer Role
|
||||
|
||||
Code implementer. Responsible for implementing code according to design, incremental delivery. Acts as Generator in Generator-Critic loop (paired with reviewer).
|
||||
|
||||
## Identity
|
||||
|
||||
- **Name**: `developer` | **Tag**: `[developer]`
|
||||
- **Task Prefix**: `DEV-*`
|
||||
- **Responsibility**: Code generation (Code Implementation)
|
||||
|
||||
## Boundaries
|
||||
|
||||
### MUST
|
||||
|
||||
- Only process `DEV-*` prefixed tasks
|
||||
- All output must carry `[developer]` identifier
|
||||
- Phase 2: Read .msg/meta.json + design, Phase 5: Write implementation_context
|
||||
- For fix tasks (DEV-fix-*): Reference review feedback
|
||||
- Work strictly within code implementation responsibility scope
|
||||
|
||||
### MUST NOT
|
||||
|
||||
- Execute work outside this role's responsibility scope
|
||||
- Execute tests, perform code review, or design architecture
|
||||
- Communicate directly with other worker roles (must go through coordinator)
|
||||
- Create tasks for other roles (TaskCreate is coordinator-exclusive)
|
||||
- Modify files or resources outside this role's responsibility
|
||||
- Omit `[developer]` identifier in any output
|
||||
|
||||
---
|
||||
|
||||
## Toolbox
|
||||
|
||||
### Tool Capabilities
|
||||
|
||||
| Tool | Type | Purpose |
|
||||
|------|------|---------|
|
||||
| Task | Agent | Spawn code-developer for implementation |
|
||||
| Read | File | Read design, breakdown, shared memory |
|
||||
| Write | File | Write dev-log |
|
||||
| Edit | File | Modify code files |
|
||||
| Glob | Search | Find review files |
|
||||
| Bash | Shell | Execute syntax check, git commands |
|
||||
|
||||
---
|
||||
|
||||
## Message Types
|
||||
|
||||
| Type | Direction | Trigger | Description |
|
||||
|------|-----------|---------|-------------|
|
||||
| `dev_complete` | developer -> coordinator | Implementation done | Implementation completed |
|
||||
| `dev_progress` | developer -> coordinator | Incremental progress | Progress update |
|
||||
| `error` | developer -> coordinator | Processing failure | Error report |
|
||||
|
||||
## Message Bus
|
||||
|
||||
Before every SendMessage, log via `mcp__ccw-tools__team_msg`:
|
||||
|
||||
|
||||
```
|
||||
mcp__ccw-tools__team_msg({
|
||||
operation: "log",
|
||||
session_id: <session-id>,
|
||||
from: "developer",
|
||||
type: <message-type>,
|
||||
data: { ref: <dev-log-path> }
|
||||
})
|
||||
```
|
||||
|
||||
**CLI fallback** (when MCP unavailable):
|
||||
|
||||
```
|
||||
Bash("ccw team log --session-id <session-id> --from developer --type <message-type> --json")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Execution (5-Phase)
|
||||
|
||||
### Phase 1: Task Discovery
|
||||
|
||||
> See SKILL.md Shared Infrastructure -> Worker Phase 1: Task Discovery
|
||||
|
||||
Standard task discovery flow: TaskList -> filter by prefix `DEV-*` + owner match + pending + unblocked -> TaskGet -> TaskUpdate in_progress.
|
||||
|
||||
### Phase 2: Context Loading
|
||||
|
||||
**Inputs**:
|
||||
|
||||
| Input | Source | Required |
|
||||
|-------|--------|----------|
|
||||
| Session path | Task description (Session: <path>) | Yes |
|
||||
| Shared memory | <session-folder>/.msg/meta.json | Yes |
|
||||
| Design document | <session-folder>/design/design-001.md | For non-fix tasks |
|
||||
| Task breakdown | <session-folder>/design/task-breakdown.json | For non-fix tasks |
|
||||
| Review feedback | <session-folder>/review/*.md | For fix tasks |
|
||||
| Wisdom | <session-folder>/wisdom/ | No |
|
||||
|
||||
**Loading steps**:
|
||||
|
||||
1. Extract session path from task description
|
||||
2. Read .msg/meta.json
|
||||
|
||||
```
|
||||
Read(<session-folder>/.msg/meta.json)
|
||||
```
|
||||
|
||||
3. Check if this is a fix task (GC loop):
|
||||
|
||||
| Task Type | Detection | Loading |
|
||||
|-----------|-----------|---------|
|
||||
| Fix task | Subject contains "fix" | Read latest review file |
|
||||
| Normal task | Subject does not contain "fix" | Read design + breakdown |
|
||||
|
||||
4. Load previous implementation context from shared memory:
|
||||
|
||||
```
|
||||
prevContext = sharedMemory.implementation_context || []
|
||||
```
|
||||
|
||||
### Phase 3: Code Implementation
|
||||
|
||||
**Implementation strategy selection**:
|
||||
|
||||
| Task Count | Complexity | Strategy |
|
||||
|------------|------------|----------|
|
||||
| <= 2 tasks | Low | Direct: inline Edit/Write |
|
||||
| 3-5 tasks | Medium | Single agent: one code-developer for all |
|
||||
| > 5 tasks | High | Batch agent: group by module, one agent per batch |
|
||||
|
||||
#### Fix Task Mode (GC Loop)
|
||||
|
||||
Focus on review feedback items:
|
||||
|
||||
```
|
||||
Task({
|
||||
subagent_type: "code-developer",
|
||||
run_in_background: false,
|
||||
description: "Fix review issues",
|
||||
prompt: `Fix the following code review issues:
|
||||
|
||||
<review-feedback>
|
||||
|
||||
Focus on:
|
||||
1. Critical issues (must fix)
|
||||
2. High issues (should fix)
|
||||
3. Medium issues (if time permits)
|
||||
|
||||
Do NOT change code that wasn't flagged.
|
||||
Maintain existing code style and patterns.`
|
||||
})
|
||||
```
|
||||
|
||||
#### Normal Task Mode
|
||||
|
||||
For each task in breakdown:
|
||||
|
||||
1. Read target files (if exist)
|
||||
2. Apply changes using Edit or Write
|
||||
3. Follow execution order from breakdown
|
||||
|
||||
For complex tasks (>3), delegate to code-developer:
|
||||
|
||||
```
|
||||
Task({
|
||||
subagent_type: "code-developer",
|
||||
run_in_background: false,
|
||||
description: "Implement <task-count> tasks",
|
||||
prompt: `## Design
|
||||
<design-content>
|
||||
|
||||
## Task Breakdown
|
||||
<breakdown-json>
|
||||
|
||||
## Previous Context
|
||||
<prev-context>
|
||||
|
||||
Implement each task following the design. Complete tasks in the specified execution order.`
|
||||
})
|
||||
```
|
||||
|
||||
### Phase 4: Self-Validation
|
||||
|
||||
**Validation checks**:
|
||||
|
||||
| Check | Method | Pass Criteria |
|
||||
|-------|--------|---------------|
|
||||
| Syntax | `tsc --noEmit` or equivalent | No errors |
|
||||
| File existence | Verify all planned files exist | All files present |
|
||||
| Import resolution | Check no broken imports | All imports resolve |
|
||||
|
||||
**Syntax check command**:
|
||||
|
||||
```
|
||||
Bash("npx tsc --noEmit 2>&1 || python -m py_compile *.py 2>&1 || true")
|
||||
```
|
||||
|
||||
**Auto-fix**: If validation fails, attempt auto-fix (max 2 attempts), then report remaining issues.
|
||||
|
||||
**Dev log output** (`<session-folder>/code/dev-log.md`):
|
||||
|
||||
```markdown
|
||||
# Dev Log — <task-subject>
|
||||
|
||||
**Changed Files**: <count>
|
||||
**Syntax Clean**: <true/false>
|
||||
**Fix Task**: <true/false>
|
||||
|
||||
## Files Changed
|
||||
- <file-1>
|
||||
- <file-2>
|
||||
```
|
||||
|
||||
### Phase 5: Report to Coordinator
|
||||
|
||||
> See SKILL.md Shared Infrastructure -> Worker Phase 5: Report
|
||||
|
||||
1. **Update shared memory**:
|
||||
|
||||
```
|
||||
sharedMemory.implementation_context.push({
|
||||
task: <task-subject>,
|
||||
changed_files: <file-list>,
|
||||
is_fix: <is-fix-task>,
|
||||
syntax_clean: <has-syntax-errors>
|
||||
})
|
||||
Write(<session-folder>/.msg/meta.json, JSON.stringify(sharedMemory, null, 2))
|
||||
```
|
||||
|
||||
2. **Log and send message**:
|
||||
|
||||
```
|
||||
mcp__ccw-tools__team_msg({
|
||||
operation: "log", session_id: <session-id>, from: "developer",
|
||||
type: "dev_complete",
|
||||
data: { ref: <dev-log-path> }
|
||||
})
|
||||
|
||||
SendMessage({
|
||||
type: "message", recipient: "coordinator",
|
||||
content: `## [developer] <Fix|Implementation> Complete
|
||||
|
||||
**Task**: <task-subject>
|
||||
**Changed Files**: <count>
|
||||
**Syntax Clean**: <true/false>
|
||||
<if-fix-task>**GC Round**: <gc-round></if>
|
||||
|
||||
### Files
|
||||
- <file-1>
|
||||
- <file-2>`,
|
||||
})
|
||||
```
|
||||
|
||||
3. **Mark task complete**:
|
||||
|
||||
```
|
||||
TaskUpdate({ taskId: <task-id>, status: "completed" })
|
||||
```
|
||||
|
||||
4. **Loop to Phase 1** for next task
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Scenario | Resolution |
|
||||
|----------|------------|
|
||||
| No DEV-* tasks available | Idle, wait for coordinator assignment |
|
||||
| Design not found | Implement based on task description |
|
||||
| Syntax errors after implementation | Attempt auto-fix, report remaining errors |
|
||||
| Review feedback unclear | Implement best interpretation, note in dev-log |
|
||||
| Code-developer agent fails | Retry once, then implement inline |
|
||||
| Context/Plan file not found | Notify coordinator, request location |
|
||||
| Critical issue beyond scope | SendMessage fix_required to coordinator |
|
||||
| Unexpected error | Log error via team_msg, report to coordinator |
|
||||
@@ -1,302 +0,0 @@
|
||||
# Reviewer Role
|
||||
|
||||
Code reviewer. Responsible for multi-dimensional review, quality scoring, and improvement suggestions. Acts as Critic in Generator-Critic loop (paired with developer).
|
||||
|
||||
## Identity
|
||||
|
||||
- **Name**: `reviewer` | **Tag**: `[reviewer]`
|
||||
- **Task Prefix**: `REVIEW-*`
|
||||
- **Responsibility**: Read-only analysis (Code Review)
|
||||
|
||||
## Boundaries
|
||||
|
||||
### MUST
|
||||
|
||||
- Only process `REVIEW-*` prefixed tasks
|
||||
- All output must carry `[reviewer]` identifier
|
||||
- Phase 2: Read .msg/meta.json + design, Phase 5: Write review_feedback_trends
|
||||
- Mark each issue with severity (CRITICAL/HIGH/MEDIUM/LOW)
|
||||
- Provide quality score (1-10)
|
||||
- Work strictly within code review responsibility scope
|
||||
|
||||
### MUST NOT
|
||||
|
||||
- Execute work outside this role's responsibility scope
|
||||
- Write implementation code, design architecture, or execute tests
|
||||
- Communicate directly with other worker roles (must go through coordinator)
|
||||
- Create tasks for other roles (TaskCreate is coordinator-exclusive)
|
||||
- Modify files or resources outside this role's responsibility
|
||||
- Omit `[reviewer]` identifier in any output
|
||||
|
||||
---
|
||||
|
||||
## Toolbox
|
||||
|
||||
### Tool Capabilities
|
||||
|
||||
| Tool | Type | Purpose |
|
||||
|------|------|---------|
|
||||
| Read | File | Read design, shared memory, file contents |
|
||||
| Write | File | Write review reports |
|
||||
| Bash | Shell | Git diff, CLI-assisted review |
|
||||
|
||||
---
|
||||
|
||||
## Message Types
|
||||
|
||||
| Type | Direction | Trigger | Description |
|
||||
|------|-----------|---------|-------------|
|
||||
| `review_passed` | reviewer -> coordinator | No critical issues, score >= 7 | Review passed |
|
||||
| `review_revision` | reviewer -> coordinator | Issues found, score < 7 | Revision needed (triggers GC) |
|
||||
| `review_critical` | reviewer -> coordinator | Critical issues found | Critical issues (triggers GC) |
|
||||
| `error` | reviewer -> coordinator | Processing failure | Error report |
|
||||
|
||||
## Message Bus
|
||||
|
||||
Before every SendMessage, log via `mcp__ccw-tools__team_msg`:
|
||||
|
||||
|
||||
```
|
||||
mcp__ccw-tools__team_msg({
|
||||
operation: "log",
|
||||
session_id: <session-id>,
|
||||
from: "reviewer",
|
||||
type: <message-type>,
|
||||
data: { ref: <review-path> }
|
||||
})
|
||||
```
|
||||
|
||||
**CLI fallback** (when MCP unavailable):
|
||||
|
||||
```
|
||||
Bash("ccw team log --session-id <session-id> --from reviewer --type <message-type> --json")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Execution (5-Phase)
|
||||
|
||||
### Phase 1: Task Discovery
|
||||
|
||||
> See SKILL.md Shared Infrastructure -> Worker Phase 1: Task Discovery
|
||||
|
||||
Standard task discovery flow: TaskList -> filter by prefix `REVIEW-*` + owner match + pending + unblocked -> TaskGet -> TaskUpdate in_progress.
|
||||
|
||||
### Phase 2: Context Loading
|
||||
|
||||
**Inputs**:
|
||||
|
||||
| Input | Source | Required |
|
||||
|-------|--------|----------|
|
||||
| Session path | Task description (Session: <path>) | Yes |
|
||||
| Shared memory | <session-folder>/.msg/meta.json | Yes |
|
||||
| Design document | <session-folder>/design/design-001.md | For requirements alignment |
|
||||
| Changed files | Git diff | Yes |
|
||||
| Wisdom | <session-folder>/wisdom/ | No |
|
||||
|
||||
**Loading steps**:
|
||||
|
||||
1. Extract session path from task description
|
||||
2. Read .msg/meta.json
|
||||
|
||||
```
|
||||
Read(<session-folder>/.msg/meta.json)
|
||||
```
|
||||
|
||||
3. Read design document for requirements alignment:
|
||||
|
||||
```
|
||||
Read(<session-folder>/design/design-001.md)
|
||||
```
|
||||
|
||||
4. Get changed files:
|
||||
|
||||
```
|
||||
Bash("git diff --name-only HEAD~1 2>/dev/null || git diff --name-only --cached")
|
||||
```
|
||||
|
||||
5. Read file contents (limit to 20 files):
|
||||
|
||||
```
|
||||
Read(<file-1>)
|
||||
Read(<file-2>)
|
||||
...
|
||||
```
|
||||
|
||||
6. Load previous review trends:
|
||||
|
||||
```
|
||||
prevTrends = sharedMemory.review_feedback_trends || []
|
||||
```
|
||||
|
||||
### Phase 3: Multi-Dimensional Review
|
||||
|
||||
**Review dimensions**:
|
||||
|
||||
| Dimension | Focus Areas |
|
||||
|-----------|-------------|
|
||||
| Correctness | Logic correctness, boundary handling |
|
||||
| Completeness | Coverage of design requirements |
|
||||
| Maintainability | Readability, code style, DRY |
|
||||
| Security | Security vulnerabilities, input validation |
|
||||
|
||||
**Analysis strategy selection**:
|
||||
|
||||
| Condition | Strategy |
|
||||
|-----------|----------|
|
||||
| Single dimension analysis | Direct inline scan |
|
||||
| Multi-dimension analysis | Per-dimension sequential scan |
|
||||
| Deep analysis needed | CLI Fan-out to external tool |
|
||||
|
||||
**Optional CLI-assisted review**:
|
||||
|
||||
```
|
||||
Bash(`ccw cli -p "PURPOSE: Code review for correctness and security
|
||||
TASK: Review changes in: <file-list>
|
||||
MODE: analysis
|
||||
CONTEXT: @<file-list>
|
||||
EXPECTED: Issues with severity (CRITICAL/HIGH/MEDIUM/LOW) and file:line
|
||||
CONSTRAINTS: Focus on correctness and security" --tool gemini --mode analysis`, { run_in_background: true })
|
||||
```
|
||||
|
||||
**Scoring**:
|
||||
|
||||
| Dimension | Weight | Score Range |
|
||||
|-----------|--------|-------------|
|
||||
| Correctness | 30% | 1-10 |
|
||||
| Completeness | 25% | 1-10 |
|
||||
| Maintainability | 25% | 1-10 |
|
||||
| Security | 20% | 1-10 |
|
||||
|
||||
**Overall score**: Weighted average of dimension scores.
|
||||
|
||||
**Output review report** (`<session-folder>/review/review-<num>.md`):
|
||||
|
||||
```markdown
|
||||
# Code Review — Round <num>
|
||||
|
||||
**Files Reviewed**: <count>
|
||||
**Quality Score**: <score>/10
|
||||
**Critical Issues**: <count>
|
||||
**High Issues**: <count>
|
||||
|
||||
## Findings
|
||||
|
||||
### 1. [CRITICAL] <title>
|
||||
|
||||
**File**: <file>:<line>
|
||||
**Dimension**: <dimension>
|
||||
**Description**: <description>
|
||||
**Suggestion**: <suggestion>
|
||||
|
||||
### 2. [HIGH] <title>
|
||||
...
|
||||
|
||||
## Scoring Breakdown
|
||||
|
||||
| Dimension | Score | Notes |
|
||||
|-----------|-------|-------|
|
||||
| Correctness | <score>/10 | <notes> |
|
||||
| Completeness | <score>/10 | <notes> |
|
||||
| Maintainability | <score>/10 | <notes> |
|
||||
| Security | <score>/10 | <notes> |
|
||||
| **Overall** | **<score>/10** | |
|
||||
|
||||
## Signal
|
||||
|
||||
<CRITICAL — Critical issues must be fixed before merge
|
||||
| REVISION_NEEDED — Quality below threshold (7/10)
|
||||
| APPROVED — Code meets quality standards>
|
||||
|
||||
## Design Alignment
|
||||
|
||||
<notes on how implementation aligns with design>
|
||||
```
|
||||
|
||||
### Phase 4: Trend Analysis
|
||||
|
||||
**Compare with previous reviews**:
|
||||
|
||||
1. Extract issue types from current findings
|
||||
2. Compare with previous review trends
|
||||
3. Identify recurring issues
|
||||
|
||||
| Analysis | Method |
|
||||
|----------|--------|
|
||||
| Recurring issues | Match dimension/type with previous reviews |
|
||||
| Improvement areas | Issues that appear in multiple reviews |
|
||||
| New issues | Issues unique to this review |
|
||||
|
||||
### Phase 5: Report to Coordinator
|
||||
|
||||
> See SKILL.md Shared Infrastructure -> Worker Phase 5: Report
|
||||
|
||||
1. **Update shared memory**:
|
||||
|
||||
```
|
||||
sharedMemory.review_feedback_trends.push({
|
||||
review_id: "review-<num>",
|
||||
score: <score>,
|
||||
critical: <critical-count>,
|
||||
high: <high-count>,
|
||||
dimensions: <dimension-list>,
|
||||
gc_round: sharedMemory.gc_round || 0
|
||||
})
|
||||
Write(<session-folder>/.msg/meta.json, JSON.stringify(sharedMemory, null, 2))
|
||||
```
|
||||
|
||||
2. **Determine message type**:
|
||||
|
||||
| Condition | Message Type |
|
||||
|-----------|--------------|
|
||||
| criticalCount > 0 | review_critical |
|
||||
| score < 7 | review_revision |
|
||||
| else | review_passed |
|
||||
|
||||
3. **Log and send message**:
|
||||
|
||||
```
|
||||
mcp__ccw-tools__team_msg({
|
||||
operation: "log", session_id: <session-id>, from: "reviewer",
|
||||
type: <message-type>,
|
||||
data: { ref: <review-path> }
|
||||
})
|
||||
|
||||
SendMessage({
|
||||
type: "message", recipient: "coordinator",
|
||||
content: `## [reviewer] Code Review Results
|
||||
|
||||
**Task**: <task-subject>
|
||||
**Score**: <score>/10
|
||||
**Signal**: <message-type>
|
||||
**Critical**: <count>, **High**: <count>
|
||||
**Output**: <review-path>
|
||||
|
||||
### Top Issues
|
||||
- **[CRITICAL/HIGH]** <title> (<file>:<line>)
|
||||
...`,
|
||||
})
|
||||
```
|
||||
|
||||
4. **Mark task complete**:
|
||||
|
||||
```
|
||||
TaskUpdate({ taskId: <task-id>, status: "completed" })
|
||||
```
|
||||
|
||||
5. **Loop to Phase 1** for next task
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Scenario | Resolution |
|
||||
|----------|------------|
|
||||
| No REVIEW-* tasks available | Idle, wait for coordinator assignment |
|
||||
| No changed files | Review files referenced in design |
|
||||
| CLI review fails | Fall back to inline analysis |
|
||||
| All issues LOW severity | Score high, approve |
|
||||
| Design not found | Review against general quality standards |
|
||||
| Context/Plan file not found | Notify coordinator, request location |
|
||||
| Critical issue beyond scope | SendMessage fix_required to coordinator |
|
||||
| Unexpected error | Log error via team_msg, report to coordinator |
|
||||
@@ -1,248 +0,0 @@
|
||||
# Tester Role
|
||||
|
||||
Test validator. Responsible for test execution, fix cycles, and regression detection.
|
||||
|
||||
## Identity
|
||||
|
||||
- **Name**: `tester` | **Tag**: `[tester]`
|
||||
- **Task Prefix**: `VERIFY-*`
|
||||
- **Responsibility**: Validation (Test Verification)
|
||||
|
||||
## Boundaries
|
||||
|
||||
### MUST
|
||||
|
||||
- Only process `VERIFY-*` prefixed tasks
|
||||
- All output must carry `[tester]` identifier
|
||||
- Phase 2: Read .msg/meta.json, Phase 5: Write test_patterns
|
||||
- Work strictly within test validation responsibility scope
|
||||
|
||||
### MUST NOT
|
||||
|
||||
- Execute work outside this role's responsibility scope
|
||||
- Write implementation code, design architecture, or perform code review
|
||||
- Communicate directly with other worker roles (must go through coordinator)
|
||||
- Create tasks for other roles (TaskCreate is coordinator-exclusive)
|
||||
- Modify files or resources outside this role's responsibility
|
||||
- Omit `[tester]` identifier in any output
|
||||
|
||||
---
|
||||
|
||||
## Toolbox
|
||||
|
||||
### Tool Capabilities
|
||||
|
||||
| Tool | Type | Purpose |
|
||||
|------|------|---------|
|
||||
| Task | Agent | Spawn code-developer for fix cycles |
|
||||
| Read | File | Read shared memory, verify results |
|
||||
| Write | File | Write verification results |
|
||||
| Bash | Shell | Execute tests, git commands |
|
||||
|
||||
---
|
||||
|
||||
## Message Types
|
||||
|
||||
| Type | Direction | Trigger | Description |
|
||||
|------|-----------|---------|-------------|
|
||||
| `verify_passed` | tester -> coordinator | All tests pass | Verification passed |
|
||||
| `verify_failed` | tester -> coordinator | Tests fail | Verification failed |
|
||||
| `fix_required` | tester -> coordinator | Issues found needing fix | Fix required |
|
||||
| `error` | tester -> coordinator | Environment failure | Error report |
|
||||
|
||||
## Message Bus
|
||||
|
||||
Before every SendMessage, log via `mcp__ccw-tools__team_msg`:
|
||||
|
||||
|
||||
```
|
||||
mcp__ccw-tools__team_msg({
|
||||
operation: "log",
|
||||
session_id: <session-id>,
|
||||
from: "tester",
|
||||
type: <message-type>,
|
||||
data: { ref: <verify-path> }
|
||||
})
|
||||
```
|
||||
|
||||
**CLI fallback** (when MCP unavailable):
|
||||
|
||||
```
|
||||
Bash("ccw team log --session-id <session-id> --from tester --type <message-type> --json")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Execution (5-Phase)
|
||||
|
||||
### Phase 1: Task Discovery
|
||||
|
||||
> See SKILL.md Shared Infrastructure -> Worker Phase 1: Task Discovery
|
||||
|
||||
Standard task discovery flow: TaskList -> filter by prefix `VERIFY-*` + owner match + pending + unblocked -> TaskGet -> TaskUpdate in_progress.
|
||||
|
||||
### Phase 2: Environment Detection
|
||||
|
||||
**Inputs**:
|
||||
|
||||
| Input | Source | Required |
|
||||
|-------|--------|----------|
|
||||
| Session path | Task description (Session: <path>) | Yes |
|
||||
| Shared memory | <session-folder>/.msg/meta.json | Yes |
|
||||
| Changed files | Git diff | Yes |
|
||||
| Wisdom | <session-folder>/wisdom/ | No |
|
||||
|
||||
**Detection steps**:
|
||||
|
||||
1. Extract session path from task description
|
||||
2. Read .msg/meta.json
|
||||
|
||||
```
|
||||
Read(<session-folder>/.msg/meta.json)
|
||||
```
|
||||
|
||||
3. Get changed files:
|
||||
|
||||
```
|
||||
Bash("git diff --name-only HEAD~1 2>/dev/null || git diff --name-only --cached")
|
||||
```
|
||||
|
||||
4. Detect test framework and command:
|
||||
|
||||
| Detection | Method |
|
||||
|-----------|--------|
|
||||
| Test command | Check package.json scripts, pytest.ini, Makefile |
|
||||
| Coverage tool | Check for nyc, coverage.py, jest --coverage config |
|
||||
|
||||
**Common test commands**:
|
||||
- JavaScript: `npm test`, `yarn test`, `pnpm test`
|
||||
- Python: `pytest`, `python -m pytest`
|
||||
- Go: `go test ./...`
|
||||
- Rust: `cargo test`
|
||||
|
||||
### Phase 3: Execution + Fix Cycle
|
||||
|
||||
**Iterative test-fix cycle**:
|
||||
|
||||
| Step | Action |
|
||||
|------|--------|
|
||||
| 1 | Run test command |
|
||||
| 2 | Parse results -> check pass rate |
|
||||
| 3 | Pass rate >= 95% -> exit loop (success) |
|
||||
| 4 | Extract failing test details |
|
||||
| 5 | Delegate fix to code-developer subagent |
|
||||
| 6 | Increment iteration counter |
|
||||
| 7 | iteration >= MAX (5) -> exit loop (report failures) |
|
||||
| 8 | Go to Step 1 |
|
||||
|
||||
**Test execution**:
|
||||
|
||||
```
|
||||
Bash("<test-command> 2>&1 || true")
|
||||
```
|
||||
|
||||
**Fix delegation** (when tests fail):
|
||||
|
||||
```
|
||||
Task({
|
||||
subagent_type: "code-developer",
|
||||
run_in_background: false,
|
||||
description: "Fix test failures (iteration <num>)",
|
||||
prompt: `Test failures:
|
||||
<test-output>
|
||||
|
||||
Fix failing tests. Changed files: <file-list>`
|
||||
})
|
||||
```
|
||||
|
||||
**Output verification results** (`<session-folder>/verify/verify-<num>.json`):
|
||||
|
||||
```json
|
||||
{
|
||||
"verify_id": "verify-<num>",
|
||||
"pass_rate": <rate>,
|
||||
"iterations": <count>,
|
||||
"passed": <true/false>,
|
||||
"timestamp": "<iso-timestamp>",
|
||||
"regression_passed": <true/false>
|
||||
}
|
||||
```
|
||||
|
||||
### Phase 4: Regression Check
|
||||
|
||||
**Full test suite for regression**:
|
||||
|
||||
```
|
||||
Bash("<test-command> --all 2>&1 || true")
|
||||
```
|
||||
|
||||
| Check | Method | Pass Criteria |
|
||||
|-------|--------|---------------|
|
||||
| Regression | Run full test suite | No FAIL in output |
|
||||
| Coverage | Run coverage tool | >= 80% (if configured) |
|
||||
|
||||
Update verification results with regression status.
|
||||
|
||||
### Phase 5: Report to Coordinator
|
||||
|
||||
> See SKILL.md Shared Infrastructure -> Worker Phase 5: Report
|
||||
|
||||
1. **Update shared memory**:
|
||||
|
||||
```
|
||||
sharedMemory.test_patterns = sharedMemory.test_patterns || []
|
||||
if (passRate >= 0.95) {
|
||||
sharedMemory.test_patterns.push(`verify-<num>: passed in <iterations> iterations`)
|
||||
}
|
||||
Write(<session-folder>/.msg/meta.json, JSON.stringify(sharedMemory, null, 2))
|
||||
```
|
||||
|
||||
2. **Determine message type**:
|
||||
|
||||
| Condition | Message Type |
|
||||
|-----------|--------------|
|
||||
| passRate >= 0.95 | verify_passed |
|
||||
| passRate < 0.95 && iterations >= MAX | fix_required |
|
||||
| passRate < 0.95 | verify_failed |
|
||||
|
||||
3. **Log and send message**:
|
||||
|
||||
```
|
||||
mcp__ccw-tools__team_msg({
|
||||
operation: "log", session_id: <session-id>, from: "tester",
|
||||
type: <message-type>,
|
||||
data: { ref: <verify-path> }
|
||||
})
|
||||
|
||||
SendMessage({
|
||||
type: "message", recipient: "coordinator",
|
||||
content: `## [tester] Verification Results
|
||||
|
||||
**Pass Rate**: <rate>%
|
||||
**Iterations**: <count>/<MAX>
|
||||
**Regression**: <passed/failed>
|
||||
**Status**: <PASSED/NEEDS FIX>`,
|
||||
})
|
||||
```
|
||||
|
||||
4. **Mark task complete**:
|
||||
|
||||
```
|
||||
TaskUpdate({ taskId: <task-id>, status: "completed" })
|
||||
```
|
||||
|
||||
5. **Loop to Phase 1** for next task
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Scenario | Resolution |
|
||||
|----------|------------|
|
||||
| No VERIFY-* tasks available | Idle, wait for coordinator assignment |
|
||||
| Test command not found | Try common commands (npm test, pytest, vitest) |
|
||||
| Max iterations exceeded | Report fix_required to coordinator |
|
||||
| Test environment broken | Report error, suggest manual fix |
|
||||
| Context/Plan file not found | Notify coordinator, request location |
|
||||
| Critical issue beyond scope | SendMessage fix_required to coordinator |
|
||||
| Unexpected error | Log error via team_msg, report to coordinator |
|
||||
Reference in New Issue
Block a user