mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-03-21 19:08:17 +08:00
feat: Enhance search functionality with quality tiers and scoped indexing
- Updated `search_code` function to include a `quality` parameter for search quality tiers: "fast", "balanced", "thorough", and "auto". - Introduced `search_scope` function to limit search results to a specific directory scope. - Added `index_scope` function for indexing a specific directory without re-indexing the entire project. - Refactored `SearchPipeline` to support quality-based routing in the `search` method. - Implemented `Shard` and `ShardManager` classes to manage multiple index shards with LRU eviction and efficient file routing. - Added debounce functionality in `IncrementalIndexer` to batch file events and reduce redundant processing. - Enhanced `FileWatcher` to integrate with `IncrementalIndexer` for improved event handling.
This commit is contained in:
catlog22
@@ -40,7 +40,7 @@ Parse the following fields from your prompt:
|
||||
| `role_spec` | Yes | Path to supervisor role.md |
|
||||
| `session` | Yes | Session folder path |
|
||||
| `session_id` | Yes | Session ID for message bus operations |
|
||||
| `team_name` | Yes | Team name for SendMessage |
|
||||
| `team_name` | Yes | Team name (used by Agent spawn for message routing; NOT used directly in SendMessage calls) |
|
||||
| `requirement` | Yes | Original task/requirement description |
|
||||
| `recovery` | No | `true` if respawned after crash — triggers recovery protocol |
|
||||
|
||||
@@ -94,14 +94,13 @@ team_msg(operation="get_state", session_id=<session_id>) // all roles
|
||||
```
|
||||
- Record which roles have completed, their key_findings, decisions
|
||||
- Read `<session>/wisdom/*.md` — absorb accumulated team knowledge
|
||||
- Read `<session>/team-session.json` — understand pipeline mode, stages
|
||||
- Read `<session>/session.json` — understand pipeline mode, stages
|
||||
|
||||
### Step 3: Report Ready
|
||||
```javascript
|
||||
SendMessage({
|
||||
type: "message",
|
||||
recipient: "coordinator",
|
||||
content: "[supervisor] Resident supervisor ready. Baseline loaded for session <session_id>. Awaiting checkpoint assignments.",
|
||||
to: "coordinator",
|
||||
message: "[supervisor] Resident supervisor ready. Baseline loaded for session <session_id>. Awaiting checkpoint assignments.",
|
||||
summary: "[supervisor] Ready, awaiting checkpoints"
|
||||
})
|
||||
```
|
||||
@@ -194,9 +193,8 @@ context_accumulator.append({
|
||||
### Step 9: Report to Coordinator
|
||||
```javascript
|
||||
SendMessage({
|
||||
type: "message",
|
||||
recipient: "coordinator",
|
||||
content: "[supervisor] CHECKPOINT-NNN complete.\nVerdict: <verdict> (score: <score>)\nFindings: <top-3>\nRisks: <count> logged\nQuality trend: <trend>\nArtifact: <path>",
|
||||
to: "coordinator",
|
||||
message: "[supervisor] CHECKPOINT-NNN complete.\nVerdict: <verdict> (score: <score>)\nFindings: <top-3>\nRisks: <count> logged\nQuality trend: <trend>\nArtifact: <path>",
|
||||
summary: "[supervisor] CHECKPOINT-NNN: <verdict>"
|
||||
})
|
||||
```
|
||||
@@ -220,17 +218,23 @@ If spawned with `recovery: true` in prompt:
|
||||
|
||||
## Shutdown Protocol
|
||||
|
||||
When receiving a `shutdown_request` message:
|
||||
When a new conversation turn delivers a message containing `type: "shutdown_request"`:
|
||||
|
||||
1. Extract `requestId` from the received message JSON (system injects this field at delivery time)
|
||||
2. Respond via SendMessage:
|
||||
|
||||
```javascript
|
||||
SendMessage({
|
||||
type: "shutdown_response",
|
||||
request_id: "<from message>",
|
||||
approve: true
|
||||
to: "coordinator",
|
||||
message: {
|
||||
type: "shutdown_response",
|
||||
request_id: "<extracted request_id>",
|
||||
approve: true
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
Agent terminates.
|
||||
Agent terminates after sending response.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
name: team-worker
|
||||
description: |
|
||||
Unified worker agent for team-lifecycle. Contains all shared team behavior
|
||||
(Phase 1 Task Discovery, Phase 5 Report + Fast-Advance, Message Bus, Consensus
|
||||
Handling, Inner Loop lifecycle). Loads role-specific Phase 2-4 logic from a
|
||||
(Phase 1 Task Discovery, Phase 5 Report + Pipeline Notification, Message Bus,
|
||||
Consensus Handling, Inner Loop lifecycle). Loads role-specific Phase 2-4 logic from a
|
||||
role_spec markdown file passed in the prompt.
|
||||
|
||||
Examples:
|
||||
@@ -21,7 +21,7 @@ color: green
|
||||
|
||||
You are a **team-lifecycle worker agent**. You execute a specific role within a team pipeline. Your behavior is split into:
|
||||
|
||||
- **Built-in phases** (Phase 1, Phase 5): Task discovery, reporting, fast-advance, inner loop — defined below.
|
||||
- **Built-in phases** (Phase 1, Phase 5): Task discovery, reporting, pipeline notification, inner loop — defined below.
|
||||
- **Role-specific phases** (Phase 2-4): Loaded from a role_spec markdown file.
|
||||
|
||||
---
|
||||
@@ -36,7 +36,7 @@ Parse the following fields from your prompt:
|
||||
| `role_spec` | Yes | Path to role-spec .md file containing Phase 2-4 instructions |
|
||||
| `session` | Yes | Session folder path (e.g., `.workflow/.team/TLS-xxx-2026-02-27`) |
|
||||
| `session_id` | Yes | Session ID (folder name, e.g., `TLS-xxx-2026-02-27`). Used directly as `session_id` param for all message bus operations |
|
||||
| `team_name` | Yes | Team name for SendMessage |
|
||||
| `team_name` | Yes | Team name (used by Agent spawn for message routing; NOT used directly in SendMessage calls) |
|
||||
| `requirement` | Yes | Original task/requirement description |
|
||||
| `inner_loop` | Yes | `true` or `false` — whether to loop through same-prefix tasks |
|
||||
|
||||
@@ -82,7 +82,7 @@ Entry:
|
||||
| team_msg state_update | YES | YES |
|
||||
| Accumulate summary | YES | - |
|
||||
| SendMessage to coordinator | NO | YES (all tasks) |
|
||||
| Fast-Advance check | - | YES |
|
||||
| Pipeline status check | - | YES |
|
||||
|
||||
**Interrupt conditions** (break inner loop immediately):
|
||||
- consensus_blocked HIGH → SendMessage → STOP
|
||||
@@ -99,6 +99,7 @@ Execute on every loop iteration:
|
||||
- Subject starts with this role's `prefix` + `-` (e.g., `DRAFT-`, `IMPL-`)
|
||||
- Status is `pending`
|
||||
- `blockedBy` list is empty (all dependencies resolved)
|
||||
- **Owner matches** `agent_name` from prompt (e.g., task owner "explorer-1" matches agent_name "explorer-1"). This prevents parallel workers from claiming each other's tasks.
|
||||
- If role has `additional_prefixes` (e.g., reviewer handles REVIEW-* + QUALITY-* + IMPROVE-*), check all prefixes
|
||||
3. **No matching tasks?**
|
||||
- If first iteration → report idle, SendMessage "No tasks found for [role]", STOP
|
||||
@@ -153,7 +154,7 @@ mcp__ccw-tools__team_msg({
|
||||
summary: "Request exploration agent for X",
|
||||
data: { reason: "...", scope: "..." }
|
||||
})
|
||||
SendMessage({ recipient: "coordinator", content: "..." })
|
||||
SendMessage({ to: "coordinator", message: "...", summary: "Request agent delegation" })
|
||||
```
|
||||
|
||||
### Consensus Handling
|
||||
@@ -180,7 +181,7 @@ Discussion: <session-folder>/discussions/<round-id>-discussion.md
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Report + Fast-Advance (Built-in)
|
||||
## Phase 5: Report + Pipeline Notification (Built-in)
|
||||
|
||||
After Phase 4 completes, determine Phase 5 variant (see Execution Flow for decision table).
|
||||
|
||||
@@ -228,62 +229,29 @@ After Phase 4 completes, determine Phase 5 variant (see Execution Flow for decis
|
||||
|
||||
1. **TaskUpdate**: Mark current task `completed`
|
||||
2. **Message Bus**: Log state_update (same call as Phase 5-L step 2)
|
||||
3. **Compile final report** and **SendMessage** to coordinator:
|
||||
3. **Compile final report + pipeline status**, then send **one single SendMessage** to coordinator:
|
||||
|
||||
First, call `TaskList()` to check pipeline status. Then compose and send:
|
||||
|
||||
```javascript
|
||||
SendMessage({
|
||||
type: "message",
|
||||
recipient: "coordinator",
|
||||
content: "[<role>] <final-report>",
|
||||
to: "coordinator",
|
||||
message: "[<role>] Final report:\n<report-body>\n\nPipeline status: <status-line>",
|
||||
summary: "[<role>] Final report delivered"
|
||||
})
|
||||
```
|
||||
Report contents: tasks completed (count + list), artifacts produced (paths), files modified (with evidence), discuss results (verdicts + ratings), key decisions (from context_accumulator), verification summary, warnings/issues.
|
||||
4. **Fast-Advance Check**: Call `TaskList()`, find pending tasks whose blockedBy are ALL completed, apply rules:
|
||||
|
||||
| Condition | Action |
|
||||
|-----------|--------|
|
||||
| Same-prefix successor (inner loop role) | Do NOT spawn — main agent handles via inner loop |
|
||||
| 1 ready task, simple linear successor, different prefix | Spawn directly via `Agent(run_in_background: true)` + log `fast_advance` |
|
||||
| Multiple ready tasks (parallel window) | SendMessage to coordinator (needs orchestration) |
|
||||
| No ready tasks + others running | SendMessage to coordinator (status update) |
|
||||
| No ready tasks + nothing running | SendMessage to coordinator (pipeline may be complete) |
|
||||
| Checkpoint task (e.g., spec->impl transition) | SendMessage to coordinator (needs user confirmation) |
|
||||
**Report body** includes: tasks completed (count + list), artifacts produced (paths), files modified (with evidence), discuss results (verdicts + ratings), key decisions (from context_accumulator), verification summary, warnings/issues.
|
||||
|
||||
### Fast-Advance Spawn
|
||||
**Status line** (append to same message based on TaskList scan):
|
||||
|
||||
When fast-advancing to a different-prefix successor:
|
||||
| Condition | Status line |
|
||||
|-----------|-------------|
|
||||
| 1+ ready tasks (unblocked) | `"Tasks unblocked: <task-list>. Ready for next stage."` |
|
||||
| No ready tasks + others running | `"All my tasks done. Other tasks still running."` |
|
||||
| No ready tasks + nothing running | `"All my tasks done. Pipeline may be complete."` |
|
||||
|
||||
```
|
||||
Agent({
|
||||
subagent_type: "team-worker",
|
||||
description: "Spawn <successor-role> worker",
|
||||
team_name: <team_name>,
|
||||
name: "<successor-role>",
|
||||
run_in_background: true,
|
||||
prompt: `## Role Assignment
|
||||
role: <successor-role>
|
||||
role_spec: <derive from SKILL path>/role-specs/<successor-role>.md
|
||||
session: <session>
|
||||
session_id: <session_id>
|
||||
team_name: <team_name>
|
||||
requirement: <requirement>
|
||||
inner_loop: <true|false based on successor role>`
|
||||
})
|
||||
```
|
||||
|
||||
After spawning, MUST log to message bus (passive log, NOT a SendMessage):
|
||||
|
||||
```
|
||||
mcp__ccw-tools__team_msg(
|
||||
operation="log",
|
||||
session_id=<session_id>,
|
||||
from=<role>,
|
||||
type="fast_advance",
|
||||
summary="[<role>] fast-advanced <completed-task-id> → spawned <successor-role> for <successor-task-id>"
|
||||
)
|
||||
```
|
||||
|
||||
Coordinator reads this on next callback to reconcile `active_workers`.
|
||||
**IMPORTANT**: Send exactly ONE SendMessage per Phase 5-F. Multiple SendMessage calls in one turn have undefined delivery behavior. Do NOT spawn agents — coordinator handles all spawning.
|
||||
|
||||
---
|
||||
|
||||
@@ -306,7 +274,7 @@ The worker MUST load available cross-role context before executing role-spec Pha
|
||||
|
||||
After Phase 4 verification, the worker MUST publish its contributions:
|
||||
|
||||
1. **Artifact**: Write deliverable to `<session>/artifacts/<prefix>-<task-id>-<name>.md`
|
||||
1. **Artifact**: Write deliverable to the path specified by role_spec Phase 4. If role_spec does not specify a path, use default: `<session>/artifacts/<prefix>-<task-id>-<name>.md`
|
||||
2. **State data**: Prepare payload for Phase 5 `state_update` message (see Phase 5-L step 2 for schema)
|
||||
3. **Wisdom**: Append new patterns to `learnings.md`, decisions to `decisions.md`, issues to `issues.md`
|
||||
4. **Context accumulator** (inner_loop only): Append summary (see Phase 5-L step 3 for schema). Maintain full accumulator for context continuity across iterations.
|
||||
@@ -324,9 +292,18 @@ Load in Phase 2 to inform execution. Contribute in Phase 4/5 with discoveries.
|
||||
|
||||
---
|
||||
|
||||
## Message Bus Protocol
|
||||
## Communication Protocols
|
||||
|
||||
Always use `mcp__ccw-tools__team_msg` for team communication.
|
||||
### Addressing Convention
|
||||
|
||||
- **SendMessage**: For triggering coordinator turns (auto-delivered). Always use `to: "coordinator"` — the main conversation context (team lead) is always addressable as `"coordinator"` regardless of team name.
|
||||
- **mcp__ccw-tools__team_msg**: For persistent state logging and cross-role queries (manual). Uses `session_id`, not team_name.
|
||||
|
||||
SendMessage triggers coordinator action; team_msg persists state for other roles to query. Always do **both** in Phase 5: team_msg first (state), then SendMessage (notification).
|
||||
|
||||
### Message Bus Protocol
|
||||
|
||||
Always use `mcp__ccw-tools__team_msg` for state persistence and cross-role queries.
|
||||
|
||||
### log (with state_update) — Primary for Phase 5
|
||||
|
||||
@@ -380,11 +357,33 @@ ccw team log --session-id <session_id> --from <role> --type <type> --json
|
||||
| Process own prefix tasks | Process other role's prefix tasks |
|
||||
| SendMessage to coordinator | Directly communicate with other workers |
|
||||
| Use CLI tools for analysis/exploration | Create tasks for other roles |
|
||||
| Fast-advance simple successors | Spawn parallel worker batches |
|
||||
| Notify coordinator of unblocked tasks | Spawn agents (workers cannot call Agent) |
|
||||
| Write to own artifacts + wisdom | Modify resources outside own scope |
|
||||
|
||||
---
|
||||
|
||||
## Shutdown Handling
|
||||
|
||||
When a new conversation turn delivers a message containing `type: "shutdown_request"`:
|
||||
|
||||
1. Extract `requestId` from the received message JSON (system injects this field at delivery time)
|
||||
2. Respond via SendMessage:
|
||||
|
||||
```javascript
|
||||
SendMessage({
|
||||
to: "coordinator",
|
||||
message: {
|
||||
type: "shutdown_response",
|
||||
request_id: "<extracted request_id>",
|
||||
approve: true
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
Agent terminates after sending response. Note: messages are only delivered between turns, so you are always idle when receiving this — no in-progress work to worry about. For ephemeral workers (inner_loop=false) that already reached STOP, SendMessage from coordinator is silently ignored — this handler is a safety net for inner_loop=true workers or workers in idle states.
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Scenario | Resolution |
|
||||
|
||||
@@ -103,7 +103,7 @@ TEXT-LEVEL ONLY. No source code reading.
|
||||
Delegate to @commands/dispatch.md:
|
||||
1. Read dependency graph and parallel mode from session.json
|
||||
2. Topological sort tasks
|
||||
3. Create tasks via TaskCreate with blockedBy
|
||||
3. Create tasks via TaskCreate, then set dependencies via TaskUpdate({ addBlockedBy })
|
||||
4. Update session.json with task count
|
||||
|
||||
## Phase 4: Spawn-and-Stop
|
||||
|
||||
@@ -99,7 +99,7 @@ TEXT-LEVEL ONLY. No source code reading.
|
||||
|
||||
Delegate to @commands/dispatch.md:
|
||||
1. Read pipeline mode and angles from session.json
|
||||
2. Create tasks for selected pipeline with correct blockedBy
|
||||
2. Create tasks for selected pipeline, then set dependencies via TaskUpdate({ addBlockedBy })
|
||||
3. Update session.json with task count
|
||||
|
||||
## Phase 4: Spawn-and-Stop
|
||||
|
||||
@@ -241,7 +241,7 @@ Coordinator supports `resume` / `continue` for interrupted sessions:
|
||||
3. Audit TaskList -> reconcile session state <-> task status
|
||||
4. Reset in_progress -> pending (interrupted tasks)
|
||||
5. Rebuild team and spawn needed workers only
|
||||
6. Create missing tasks with correct blockedBy
|
||||
6. Create missing tasks, set dependencies via TaskUpdate({ addBlockedBy })
|
||||
7. Kick first executable task -> Phase 4 coordination loop
|
||||
|
||||
---
|
||||
|
||||
@@ -144,7 +144,7 @@ For callback/check/resume/adapt/complete: load `@commands/monitor.md` and execut
|
||||
4. Detect fast-advance orphans (in_progress without recent activity) -> reset to pending
|
||||
5. Determine remaining pipeline from reconciled state
|
||||
6. Rebuild team if disbanded (TeamCreate + spawn needed workers only)
|
||||
7. Create missing tasks with correct blockedBy dependencies
|
||||
7. Create missing tasks, set dependencies via TaskUpdate({ addBlockedBy })
|
||||
8. Verify dependency chain integrity
|
||||
9. Update session file with reconciled state
|
||||
10. Kick first executable task's worker -> Phase 4
|
||||
@@ -278,7 +278,7 @@ mcp__ccw-tools__team_msg({
|
||||
Delegate to `@commands/dispatch.md` which creates the full task chain:
|
||||
1. Reads dependency_graph from task-analysis.json
|
||||
2. Topological sorts tasks
|
||||
3. Creates tasks via TaskCreate with correct blockedBy
|
||||
3. Creates tasks via TaskCreate, then sets dependencies via TaskUpdate({ addBlockedBy })
|
||||
4. Assigns owner based on role mapping from task-analysis.json
|
||||
5. Includes `Session: <session-folder>` in every task description
|
||||
6. Sets InnerLoop flag for multi-task roles
|
||||
|
||||
@@ -77,7 +77,7 @@ If `.workflow/.team/${teamConfig.sessionPrefix}-*/team-session.json` exists:
|
||||
## Phase 3: Dispatch
|
||||
|
||||
- Execute `commands/dispatch.md`
|
||||
- Creates TaskCreate calls with blockedBy dependencies
|
||||
- Creates TaskCreate calls, then sets dependencies via TaskUpdate({ addBlockedBy })
|
||||
|
||||
## Phase 4: Spawn & Monitor
|
||||
|
||||
@@ -144,7 +144,7 @@ Write `task-analysis.json` to session directory:
|
||||
|
||||
Template — includes:
|
||||
- Topological sort from dependency graph
|
||||
- TaskCreate with blockedBy
|
||||
- TaskCreate + TaskUpdate({ addBlockedBy }) for dependencies
|
||||
- Task description template (PURPOSE/TASK/CONTEXT/EXPECTED/CONSTRAINTS)
|
||||
|
||||
### coordinator/commands/monitor.md
|
||||
|
||||
@@ -44,10 +44,10 @@ Analyzer needs more evidence. Create supplemental reproduction task.
|
||||
1. Parse Analyzer's evidence request (dimensions, specific actions)
|
||||
2. Create REPRODUCE-002 task:
|
||||
- TaskCreate with description from Analyzer's request
|
||||
- blockedBy: [] (can start immediately)
|
||||
- TaskUpdate to set owner (no blockedBy — can start immediately)
|
||||
3. Create ANALYZE-002 task:
|
||||
- blockedBy: [REPRODUCE-002]
|
||||
- Update FIX-001 blockedBy to include ANALYZE-002
|
||||
- TaskCreate + TaskUpdate with addBlockedBy: [REPRODUCE-002]
|
||||
- TaskUpdate FIX-001 with addBlockedBy to include ANALYZE-002
|
||||
4. Update team-session.json with new tasks
|
||||
5. -> handleSpawnNext
|
||||
|
||||
|
||||
@@ -98,7 +98,7 @@ Delegate to @commands/dispatch.md:
|
||||
1. Read dependency graph from task-analysis.json
|
||||
2. Read specs/pipelines.md for debug-pipeline task registry
|
||||
3. Topological sort tasks
|
||||
4. Create tasks via TaskCreate with blockedBy
|
||||
4. Create tasks via TaskCreate, then set blockedBy via TaskUpdate
|
||||
5. Update team-session.json
|
||||
|
||||
## Phase 4: Spawn-and-Stop
|
||||
|
||||
@@ -115,7 +115,7 @@ mcp__ccw-tools__team_msg({
|
||||
|
||||
Delegate to @commands/dispatch.md:
|
||||
1. Read specs/pipelines.md for selected pipeline task registry
|
||||
2. Create tasks via TaskCreate with blockedBy
|
||||
2. Create tasks via TaskCreate, then set blockedBy via TaskUpdate
|
||||
3. Update session.json
|
||||
|
||||
## Phase 4: Spawn-and-Stop
|
||||
|
||||
@@ -227,7 +227,7 @@ Verify task chain integrity:
|
||||
| Check | Method | Expected |
|
||||
|-------|--------|----------|
|
||||
| Task count correct | TaskList count | patch: 2, sprint: 4, multi: 5+ |
|
||||
| Dependencies correct | Trace blockedBy graph | Acyclic, correct ordering |
|
||||
| Dependencies correct | Trace addBlockedBy graph | Acyclic, correct ordering |
|
||||
| No circular dependencies | Trace full graph | Acyclic |
|
||||
| Structured descriptions | Each has PURPOSE/TASK/CONTEXT/EXPECTED | All present |
|
||||
|
||||
|
||||
@@ -111,13 +111,13 @@ mcp__ccw-tools__team_msg({
|
||||
|
||||
Delegate to @commands/dispatch.md:
|
||||
1. Read specs/pipelines.md for selected pipeline task registry
|
||||
2. Create tasks via TaskCreate with blockedBy
|
||||
2. Create tasks via TaskCreate, then TaskUpdate with addBlockedBy
|
||||
3. Update task-ledger.json
|
||||
|
||||
## Phase 4: Spawn-and-Stop
|
||||
|
||||
Delegate to @commands/monitor.md#handleSpawnNext:
|
||||
1. Find ready tasks (pending + blockedBy resolved)
|
||||
1. Find ready tasks (pending + all addBlockedBy dependencies resolved)
|
||||
2. Spawn team-worker agents (see SKILL.md Spawn Template)
|
||||
3. Output status summary
|
||||
4. STOP
|
||||
|
||||
@@ -105,7 +105,7 @@ Pipeline done. Generate report and completion action.
|
||||
|
||||
1. Shutdown resident supervisor (if active):
|
||||
```
|
||||
SendMessage({ type: "shutdown_request", recipient: "supervisor", content: "Pipeline complete" })
|
||||
SendMessage({ to: "supervisor", message: { type: "shutdown_request", reason: "Pipeline complete" } })
|
||||
```
|
||||
2. Generate summary (deliverables, stats, discussions)
|
||||
3. Read session.completion_action:
|
||||
|
||||
@@ -27,7 +27,6 @@ Every task description uses structured format for clarity:
|
||||
```
|
||||
TaskCreate({
|
||||
subject: "<TASK-ID>",
|
||||
owner: "<role>",
|
||||
description: "PURPOSE: <what this task achieves> | Success: <measurable completion criteria>
|
||||
TASK:
|
||||
- <step 1: specific action>
|
||||
@@ -44,9 +43,9 @@ CONSTRAINTS: <scope limits, focus areas>
|
||||
---
|
||||
InnerLoop: <true|false>
|
||||
BranchId: <B01|A|none>",
|
||||
blockedBy: [<dependency-list>],
|
||||
status: "pending"
|
||||
})
|
||||
TaskUpdate({ taskId: "<TASK-ID>", addBlockedBy: [<dependency-list>], owner: "<role>" })
|
||||
```
|
||||
|
||||
### Mode Router
|
||||
@@ -106,9 +105,9 @@ EXPECTED: <session>/artifacts/optimization-plan.md | Priority-ordered with impro
|
||||
CONSTRAINTS: Focus on highest-impact optimizations | Risk assessment required | Non-overlapping file targets per OPT-ID
|
||||
---
|
||||
InnerLoop: false",
|
||||
blockedBy: ["PROFILE-001"],
|
||||
status: "pending"
|
||||
})
|
||||
TaskUpdate({ taskId: "STRATEGY-001", addBlockedBy: ["PROFILE-001"] })
|
||||
```
|
||||
|
||||
**IMPL-001** (optimizer, Stage 3):
|
||||
@@ -130,9 +129,9 @@ EXPECTED: Modified source files + validation passing | Optimizations applied wit
|
||||
CONSTRAINTS: Preserve existing behavior | Minimal changes per optimization | Follow code conventions
|
||||
---
|
||||
InnerLoop: true",
|
||||
blockedBy: ["STRATEGY-001"],
|
||||
status: "pending"
|
||||
})
|
||||
TaskUpdate({ taskId: "IMPL-001", addBlockedBy: ["STRATEGY-001"] })
|
||||
```
|
||||
|
||||
**BENCH-001** (benchmarker, Stage 4 - parallel):
|
||||
@@ -154,9 +153,9 @@ EXPECTED: <session>/artifacts/benchmark-results.json | Per-metric comparison wit
|
||||
CONSTRAINTS: Must compare against baseline | Flag any regressions
|
||||
---
|
||||
InnerLoop: false",
|
||||
blockedBy: ["IMPL-001"],
|
||||
status: "pending"
|
||||
})
|
||||
TaskUpdate({ taskId: "BENCH-001", addBlockedBy: ["IMPL-001"] })
|
||||
```
|
||||
|
||||
**REVIEW-001** (reviewer, Stage 4 - parallel):
|
||||
@@ -178,9 +177,9 @@ EXPECTED: <session>/artifacts/review-report.md | Per-dimension findings with sev
|
||||
CONSTRAINTS: Focus on optimization changes only | Provide specific file:line references
|
||||
---
|
||||
InnerLoop: false",
|
||||
blockedBy: ["IMPL-001"],
|
||||
status: "pending"
|
||||
})
|
||||
TaskUpdate({ taskId: "REVIEW-001", addBlockedBy: ["IMPL-001"] })
|
||||
```
|
||||
|
||||
---
|
||||
@@ -207,11 +206,16 @@ For each target index `i` (0-based), with prefix char `P = pipeline_prefix_chars
|
||||
// Create session subdirectory for this pipeline
|
||||
Bash("mkdir -p <session>/artifacts/pipelines/<P>")
|
||||
|
||||
TaskCreate({ subject: "PROFILE-<P>01", ... }) // blockedBy: []
|
||||
TaskCreate({ subject: "STRATEGY-<P>01", ... }) // blockedBy: ["PROFILE-<P>01"]
|
||||
TaskCreate({ subject: "IMPL-<P>01", ... }) // blockedBy: ["STRATEGY-<P>01"]
|
||||
TaskCreate({ subject: "BENCH-<P>01", ... }) // blockedBy: ["IMPL-<P>01"]
|
||||
TaskCreate({ subject: "REVIEW-<P>01", ... }) // blockedBy: ["IMPL-<P>01"]
|
||||
TaskCreate({ subject: "PROFILE-<P>01", ... })
|
||||
TaskCreate({ subject: "STRATEGY-<P>01", ... })
|
||||
TaskCreate({ subject: "IMPL-<P>01", ... })
|
||||
TaskCreate({ subject: "BENCH-<P>01", ... })
|
||||
TaskCreate({ subject: "REVIEW-<P>01", ... })
|
||||
// Then set dependencies via TaskUpdate:
|
||||
TaskUpdate({ taskId: "STRATEGY-<P>01", addBlockedBy: ["PROFILE-<P>01"] })
|
||||
TaskUpdate({ taskId: "IMPL-<P>01", addBlockedBy: ["STRATEGY-<P>01"] })
|
||||
TaskUpdate({ taskId: "BENCH-<P>01", addBlockedBy: ["IMPL-<P>01"] })
|
||||
TaskUpdate({ taskId: "REVIEW-<P>01", addBlockedBy: ["IMPL-<P>01"] })
|
||||
```
|
||||
|
||||
Task descriptions follow same template as single mode, with additions:
|
||||
@@ -295,9 +299,9 @@ CONSTRAINTS: Only implement this branch's optimization | Do not touch files outs
|
||||
---
|
||||
InnerLoop: false
|
||||
BranchId: B{NN}",
|
||||
blockedBy: ["STRATEGY-001"],
|
||||
status: "pending"
|
||||
})
|
||||
TaskUpdate({ taskId: "IMPL-B{NN}", addBlockedBy: ["STRATEGY-001"] })
|
||||
|
||||
TaskCreate({
|
||||
subject: "BENCH-B{NN}",
|
||||
@@ -316,9 +320,9 @@ CONSTRAINTS: Only benchmark this branch's metrics
|
||||
---
|
||||
InnerLoop: false
|
||||
BranchId: B{NN}",
|
||||
blockedBy: ["IMPL-B{NN}"],
|
||||
status: "pending"
|
||||
})
|
||||
TaskUpdate({ taskId: "BENCH-B{NN}", addBlockedBy: ["IMPL-B{NN}"] })
|
||||
|
||||
TaskCreate({
|
||||
subject: "REVIEW-B{NN}",
|
||||
@@ -337,9 +341,9 @@ CONSTRAINTS: Only review this branch's changes
|
||||
---
|
||||
InnerLoop: false
|
||||
BranchId: B{NN}",
|
||||
blockedBy: ["IMPL-B{NN}"],
|
||||
status: "pending"
|
||||
})
|
||||
TaskUpdate({ taskId: "REVIEW-B{NN}", addBlockedBy: ["IMPL-B{NN}"] })
|
||||
```
|
||||
|
||||
7. Update session.json:
|
||||
@@ -355,7 +359,7 @@ Verify task chain integrity:
|
||||
| Check | Method | Expected |
|
||||
|-------|--------|----------|
|
||||
| Task count correct | TaskList count | single: 5, auto/fan-out: 2 (pre-CP-2.5), independent: 5*M |
|
||||
| Dependencies correct | Trace dependency graph | Acyclic, correct blockedBy |
|
||||
| Dependencies correct | Trace dependency graph | Acyclic, correct addBlockedBy |
|
||||
| No circular dependencies | Trace dependency graph | Acyclic |
|
||||
| Task IDs use correct prefixes | Pattern check | Match naming rules per mode |
|
||||
| Structured descriptions complete | Each has PURPOSE/TASK/CONTEXT/EXPECTED/CONSTRAINTS | All present |
|
||||
|
||||
@@ -172,7 +172,6 @@ CONSTRAINTS: Targeted fixes only | Do not touch other branches
|
||||
---
|
||||
InnerLoop: false
|
||||
BranchId: B{NN}",
|
||||
blockedBy: [],
|
||||
status: "pending"
|
||||
})
|
||||
```
|
||||
@@ -186,7 +185,6 @@ Create new BENCH and REVIEW with retry suffix:
|
||||
TaskCreate({
|
||||
subject: "FIX-{P}01-{cycle}",
|
||||
...same pattern with pipeline prefix...
|
||||
blockedBy: [],
|
||||
status: "pending"
|
||||
})
|
||||
```
|
||||
@@ -310,7 +308,7 @@ Triggered by user "revise <TASK-ID> [feedback]" command.
|
||||
1. Parse target task ID and optional feedback
|
||||
2. Detect branch/pipeline from task ID pattern
|
||||
3. Create revision task with same role but updated requirements, scoped to branch
|
||||
4. Set blockedBy to empty (immediate execution)
|
||||
4. Skip addBlockedBy (no dependencies, immediate execution)
|
||||
5. Cascade: create new downstream tasks within same branch only
|
||||
6. Proceed to handleSpawnNext
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ Execution method: <agent|codex|gemini>
|
||||
## Instructions
|
||||
1. Parse input to get issue list
|
||||
2. For each issue: call issue-plan-agent → write solution artifact
|
||||
3. After each solution: create EXEC-* task (owner: executor) with solution_file path
|
||||
3. After each solution: create EXEC-* task with solution_file path, then TaskUpdate to set owner: executor
|
||||
4. After all issues: send all_planned signal
|
||||
|
||||
InnerLoop: true`,
|
||||
|
||||
@@ -46,7 +46,7 @@ For callback/check/resume: load `@commands/monitor.md` and execute the appropria
|
||||
|
||||
1. Parse new input (Issue IDs / `--text` / `--plan`)
|
||||
2. Get current max PLAN-* sequence from `TaskList`
|
||||
3. `TaskCreate` new PLAN-00N task (owner: planner)
|
||||
3. `TaskCreate` new PLAN-00N task, then `TaskUpdate` to set owner: planner
|
||||
4. If planner already sent `all_planned` (check team_msg) -> `SendMessage` to planner to re-enter loop
|
||||
5. STOP
|
||||
|
||||
|
||||
@@ -1,16 +1,16 @@
|
||||
# Dispatch Tasks
|
||||
|
||||
Create task chains from dependency graph with proper blockedBy relationships.
|
||||
Create task chains from dependency graph with proper addBlockedBy relationships.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Read task-analysis.json -> extract pipeline_mode and dependency_graph
|
||||
2. Read specs/pipelines.md -> get task registry for selected pipeline
|
||||
3. Topological sort tasks (respect blockedBy)
|
||||
3. Topological sort tasks (respect addBlockedBy)
|
||||
4. Validate all owners exist in role registry (SKILL.md)
|
||||
5. For each task (in order):
|
||||
- TaskCreate with structured description (see template below)
|
||||
- TaskUpdate with blockedBy + owner assignment
|
||||
- TaskUpdate with addBlockedBy + owner assignment
|
||||
6. Update session.json with pipeline.tasks_total
|
||||
7. Validate chain (no orphans, no cycles, all refs valid)
|
||||
|
||||
@@ -38,51 +38,51 @@ RoleSpec: ~ or <project>/.claude/skills/team-quality-assurance/roles/<role>/rol
|
||||
### Discovery Mode
|
||||
```
|
||||
SCOUT-001 (scout): Multi-perspective issue scanning
|
||||
blockedBy: []
|
||||
addBlockedBy: []
|
||||
QASTRAT-001 (strategist): Test strategy formulation
|
||||
blockedBy: [SCOUT-001]
|
||||
addBlockedBy: [SCOUT-001]
|
||||
QAGEN-001 (generator): L1 unit test generation
|
||||
blockedBy: [QASTRAT-001], meta: layer=L1
|
||||
addBlockedBy: [QASTRAT-001], meta: layer=L1
|
||||
QARUN-001 (executor): L1 test execution + fix cycles
|
||||
blockedBy: [QAGEN-001], inner_loop: true, meta: layer=L1
|
||||
addBlockedBy: [QAGEN-001], inner_loop: true, meta: layer=L1
|
||||
QAANA-001 (analyst): Quality analysis report
|
||||
blockedBy: [QARUN-001]
|
||||
addBlockedBy: [QARUN-001]
|
||||
```
|
||||
|
||||
### Testing Mode
|
||||
```
|
||||
QASTRAT-001 (strategist): Test strategy formulation
|
||||
blockedBy: []
|
||||
addBlockedBy: []
|
||||
QAGEN-L1-001 (generator): L1 unit test generation
|
||||
blockedBy: [QASTRAT-001], meta: layer=L1
|
||||
addBlockedBy: [QASTRAT-001], meta: layer=L1
|
||||
QARUN-L1-001 (executor): L1 test execution + fix cycles
|
||||
blockedBy: [QAGEN-L1-001], inner_loop: true, meta: layer=L1
|
||||
addBlockedBy: [QAGEN-L1-001], inner_loop: true, meta: layer=L1
|
||||
QAGEN-L2-001 (generator): L2 integration test generation
|
||||
blockedBy: [QARUN-L1-001], meta: layer=L2
|
||||
addBlockedBy: [QARUN-L1-001], meta: layer=L2
|
||||
QARUN-L2-001 (executor): L2 test execution + fix cycles
|
||||
blockedBy: [QAGEN-L2-001], inner_loop: true, meta: layer=L2
|
||||
addBlockedBy: [QAGEN-L2-001], inner_loop: true, meta: layer=L2
|
||||
QAANA-001 (analyst): Quality analysis report
|
||||
blockedBy: [QARUN-L2-001]
|
||||
addBlockedBy: [QARUN-L2-001]
|
||||
```
|
||||
|
||||
### Full Mode
|
||||
```
|
||||
SCOUT-001 (scout): Multi-perspective issue scanning
|
||||
blockedBy: []
|
||||
addBlockedBy: []
|
||||
QASTRAT-001 (strategist): Test strategy formulation
|
||||
blockedBy: [SCOUT-001]
|
||||
addBlockedBy: [SCOUT-001]
|
||||
QAGEN-L1-001 (generator-1): L1 unit test generation
|
||||
blockedBy: [QASTRAT-001], meta: layer=L1
|
||||
addBlockedBy: [QASTRAT-001], meta: layer=L1
|
||||
QAGEN-L2-001 (generator-2): L2 integration test generation
|
||||
blockedBy: [QASTRAT-001], meta: layer=L2
|
||||
addBlockedBy: [QASTRAT-001], meta: layer=L2
|
||||
QARUN-L1-001 (executor-1): L1 test execution + fix cycles
|
||||
blockedBy: [QAGEN-L1-001], inner_loop: true, meta: layer=L1
|
||||
addBlockedBy: [QAGEN-L1-001], inner_loop: true, meta: layer=L1
|
||||
QARUN-L2-001 (executor-2): L2 test execution + fix cycles
|
||||
blockedBy: [QAGEN-L2-001], inner_loop: true, meta: layer=L2
|
||||
addBlockedBy: [QAGEN-L2-001], inner_loop: true, meta: layer=L2
|
||||
QAANA-001 (analyst): Quality analysis report
|
||||
blockedBy: [QARUN-L1-001, QARUN-L2-001]
|
||||
addBlockedBy: [QARUN-L1-001, QARUN-L2-001]
|
||||
SCOUT-002 (scout): Regression scan after fixes
|
||||
blockedBy: [QAANA-001]
|
||||
addBlockedBy: [QAANA-001]
|
||||
```
|
||||
|
||||
## InnerLoop Flag Rules
|
||||
|
||||
@@ -72,9 +72,9 @@ EXPECTED: <session>/results/run-<layer>-gc-<round>.json
|
||||
CONSTRAINTS: Read-only execution
|
||||
---
|
||||
InnerLoop: false
|
||||
RoleSpec: ~ or <project>/.claude/skills/team-quality-assurance/roles/executor/role.md",
|
||||
blockedBy: ["QAGEN-fix-<round>"]
|
||||
RoleSpec: ~ or <project>/.claude/skills/team-quality-assurance/roles/executor/role.md"
|
||||
})
|
||||
TaskUpdate({ taskId: "QARUN-gc-<round>", addBlockedBy: ["QAGEN-fix-<round>"] })
|
||||
```
|
||||
|
||||
6. -> handleSpawnNext
|
||||
|
||||
@@ -111,13 +111,13 @@ Delegate to @commands/dispatch.md:
|
||||
1. Read dependency graph from task-analysis.json
|
||||
2. Read specs/pipelines.md for selected pipeline's task registry
|
||||
3. Topological sort tasks
|
||||
4. Create tasks via TaskCreate with blockedBy
|
||||
4. Create tasks via TaskCreate, then TaskUpdate with addBlockedBy
|
||||
5. Update session.json
|
||||
|
||||
## Phase 4: Spawn-and-Stop
|
||||
|
||||
Delegate to @commands/monitor.md#handleSpawnNext:
|
||||
1. Find ready tasks (pending + blockedBy resolved)
|
||||
1. Find ready tasks (pending + all addBlockedBy dependencies resolved)
|
||||
2. Spawn team-worker agents (see SKILL.md Spawn Template)
|
||||
3. Output status summary
|
||||
4. STOP
|
||||
|
||||
@@ -150,7 +150,7 @@ mcp__ccw-tools__team_msg({
|
||||
operation: "log", session_id: sessionId,
|
||||
from: "coordinator", to: "all",
|
||||
type: "phase_started",
|
||||
ref: `${sessionFolder}/roadmap.md`
|
||||
data: { ref: `${sessionFolder}/roadmap.md` }
|
||||
})
|
||||
```
|
||||
|
||||
|
||||
@@ -58,7 +58,7 @@ mcp__ccw-tools__team_msg({
|
||||
operation: "log", session_id: sessionId,
|
||||
from: "coordinator", to: "all",
|
||||
type: "phase_paused",
|
||||
ref: `${sessionFolder}/state.md`
|
||||
data: { ref: `${sessionFolder}/state.md` }
|
||||
})
|
||||
```
|
||||
|
||||
|
||||
@@ -70,7 +70,7 @@ mcp__ccw-tools__team_msg({
|
||||
operation: "log", session_id: sessionId,
|
||||
from: "coordinator", to: "all",
|
||||
type: "phase_started",
|
||||
ref: `${sessionFolder}/state.md`
|
||||
data: { ref: `${sessionFolder}/state.md` }
|
||||
})
|
||||
```
|
||||
|
||||
|
||||
@@ -139,7 +139,7 @@ mcp__ccw-tools__team_msg({
|
||||
from: "coordinator",
|
||||
to: <target-role>,
|
||||
type: <message-type>,
|
||||
ref: <artifact-path>
|
||||
data: { ref: <artifact-path> }
|
||||
})
|
||||
```
|
||||
|
||||
|
||||
@@ -70,7 +70,8 @@ Worker completed. Process and advance.
|
||||
Fix-Verify Task Creation:
|
||||
```
|
||||
TaskCreate({ subject: "TDFIX-fix-<round>", description: "PURPOSE: Fix regressions | Session: <session>" })
|
||||
TaskCreate({ subject: "TDVAL-recheck-<round>", description: "...", blockedBy: ["TDFIX-fix-<round>"] })
|
||||
TaskCreate({ subject: "TDVAL-recheck-<round>", description: "..." })
|
||||
TaskUpdate({ taskId: "TDVAL-recheck-<round>", addBlockedBy: ["TDFIX-fix-<round>"] })
|
||||
```
|
||||
|
||||
7. -> handleSpawnNext
|
||||
|
||||
@@ -1,89 +0,0 @@
|
||||
---
|
||||
prefix: ANALYZE
|
||||
inner_loop: false
|
||||
additional_prefixes: [ANALYZE-fix]
|
||||
message_types:
|
||||
success: analysis_ready
|
||||
error: error
|
||||
---
|
||||
|
||||
# Deep Analyst
|
||||
|
||||
Perform deep multi-perspective analysis on exploration results via CLI tools. Generate structured insights, discussion points, and recommendations with confidence levels.
|
||||
|
||||
## Phase 2: Context Loading
|
||||
|
||||
| Input | Source | Required |
|
||||
|-------|--------|----------|
|
||||
| Task description | From task subject/description | Yes |
|
||||
| Session path | Extracted from task description | Yes |
|
||||
| Exploration results | `<session>/explorations/*.json` | Yes |
|
||||
|
||||
1. Extract session path, topic, perspective, dimensions from task description
|
||||
2. Detect direction-fix mode: `type:\s*direction-fix` with `adjusted_focus:\s*(.+)`
|
||||
3. Load corresponding exploration results:
|
||||
|
||||
| Condition | Source |
|
||||
|-----------|--------|
|
||||
| Direction fix | Read ALL exploration files, merge context |
|
||||
| Normal ANALYZE-N | Read exploration matching number N |
|
||||
| Fallback | Read first available exploration file |
|
||||
|
||||
4. Select CLI tool by perspective:
|
||||
|
||||
| Perspective | CLI Tool | Rule Template |
|
||||
|-------------|----------|---------------|
|
||||
| technical | gemini | analysis-analyze-code-patterns |
|
||||
| architectural | claude | analysis-review-architecture |
|
||||
| business | codex | analysis-analyze-code-patterns |
|
||||
| domain_expert | gemini | analysis-analyze-code-patterns |
|
||||
| direction-fix (any) | gemini | analysis-diagnose-bug-root-cause |
|
||||
|
||||
## Phase 3: Deep Analysis via CLI
|
||||
|
||||
Build analysis prompt with exploration context:
|
||||
|
||||
```
|
||||
PURPOSE: <Normal: "Deep analysis of '<topic>' from <perspective> perspective">
|
||||
<Fix: "Supplementary analysis with adjusted focus on '<adjusted_focus>'">
|
||||
Success: Actionable insights with confidence levels and evidence references
|
||||
|
||||
PRIOR EXPLORATION CONTEXT:
|
||||
- Key files: <top 5-8 files from exploration>
|
||||
- Patterns found: <top 3-5 patterns>
|
||||
- Key findings: <top 3-5 findings>
|
||||
|
||||
TASK:
|
||||
- <perspective-specific analysis tasks>
|
||||
- Generate structured findings with confidence levels (high/medium/low)
|
||||
- Identify discussion points requiring user input
|
||||
- List open questions needing further exploration
|
||||
|
||||
MODE: analysis
|
||||
CONTEXT: @**/* | Topic: <topic>
|
||||
EXPECTED: Structured analysis with: key_insights, key_findings, discussion_points, open_questions, recommendations
|
||||
CONSTRAINTS: Focus on <perspective> perspective | <dimensions>
|
||||
```
|
||||
|
||||
Execute: `ccw cli -p "<prompt>" --tool <cli-tool> --mode analysis --rule <rule>`
|
||||
|
||||
## Phase 4: Result Aggregation
|
||||
|
||||
Write analysis output to `<session>/analyses/analysis-<num>.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"perspective": "<perspective>",
|
||||
"dimensions": ["<dim1>", "<dim2>"],
|
||||
"is_direction_fix": false,
|
||||
"key_insights": [{"insight": "...", "confidence": "high", "evidence": "file:line"}],
|
||||
"key_findings": [{"finding": "...", "file_ref": "...", "impact": "..."}],
|
||||
"discussion_points": ["..."],
|
||||
"open_questions": ["..."],
|
||||
"recommendations": [{"action": "...", "rationale": "...", "priority": "high"}],
|
||||
"_metadata": {"cli_tool": "...", "cli_rule": "...", "perspective": "...", "timestamp": "..."}
|
||||
}
|
||||
```
|
||||
|
||||
Update `<session>/wisdom/.msg/meta.json` under `analyst` namespace:
|
||||
- Read existing -> merge `{ "analyst": { perspective, insight_count, finding_count, is_direction_fix } }` -> write back
|
||||
@@ -1,106 +0,0 @@
|
||||
---
|
||||
prefix: DISCUSS
|
||||
inner_loop: false
|
||||
message_types:
|
||||
success: discussion_processed
|
||||
error: error
|
||||
---
|
||||
|
||||
# Discussant
|
||||
|
||||
Process analysis results and user feedback. Execute direction adjustments, deep-dive explorations, or targeted Q&A based on discussion type. Update discussion timeline.
|
||||
|
||||
## Phase 2: Context Loading
|
||||
|
||||
| Input | Source | Required |
|
||||
|-------|--------|----------|
|
||||
| Task description | From task subject/description | Yes |
|
||||
| Session path | Extracted from task description | Yes |
|
||||
| Analysis results | `<session>/analyses/*.json` | Yes |
|
||||
| Exploration results | `<session>/explorations/*.json` | No |
|
||||
|
||||
1. Extract session path, topic, round, discussion type, user feedback:
|
||||
|
||||
| Field | Pattern | Default |
|
||||
|-------|---------|---------|
|
||||
| sessionFolder | `session:\s*(.+)` | required |
|
||||
| topic | `topic:\s*(.+)` | required |
|
||||
| round | `round:\s*(\d+)` | 1 |
|
||||
| discussType | `type:\s*(.+)` | "initial" |
|
||||
| userFeedback | `user_feedback:\s*(.+)` | empty |
|
||||
|
||||
2. Read all analysis and exploration results
|
||||
3. Aggregate current findings, insights, open questions
|
||||
|
||||
## Phase 3: Discussion Processing
|
||||
|
||||
Select strategy by discussion type:
|
||||
|
||||
| Type | Mode | Description |
|
||||
|------|------|-------------|
|
||||
| initial | inline | Aggregate all analyses: convergent themes, conflicts, top discussion points |
|
||||
| deepen | cli | Use CLI tool to investigate open questions deeper |
|
||||
| direction-adjusted | cli | Re-analyze via `ccw cli` from adjusted perspective |
|
||||
| specific-questions | cli | Targeted exploration answering user questions |
|
||||
|
||||
**initial**: Cross-perspective summary -- identify convergent themes, conflicting views, top 5 discussion points and open questions from all analyses.
|
||||
|
||||
**deepen**: Use CLI tool for deep investigation:
|
||||
```javascript
|
||||
Bash({
|
||||
command: `ccw cli -p "PURPOSE: Investigate open questions and uncertain insights; success = evidence-based findings
|
||||
TASK: • Focus on open questions: <questions> • Find supporting evidence • Validate uncertain insights • Document findings
|
||||
MODE: analysis
|
||||
CONTEXT: @**/* | Memory: Session <session-folder>, previous analyses
|
||||
EXPECTED: JSON output with investigation results | Write to <session>/discussions/deepen-<num>.json
|
||||
CONSTRAINTS: Evidence-based analysis only
|
||||
" --tool gemini --mode analysis --rule analysis-trace-code-execution`,
|
||||
run_in_background: false
|
||||
})
|
||||
```
|
||||
|
||||
**direction-adjusted**: CLI re-analysis from adjusted focus:
|
||||
```javascript
|
||||
Bash({
|
||||
command: `ccw cli -p "Re-analyze '<topic>' with adjusted focus on '<userFeedback>'" --tool gemini --mode analysis`,
|
||||
run_in_background: false
|
||||
})
|
||||
```
|
||||
|
||||
**specific-questions**: Use CLI tool for targeted Q&A:
|
||||
```javascript
|
||||
Bash({
|
||||
command: `ccw cli -p "PURPOSE: Answer specific user questions about <topic>; success = clear, evidence-based answers
|
||||
TASK: • Answer: <userFeedback> • Provide code references • Explain context
|
||||
MODE: analysis
|
||||
CONTEXT: @**/* | Memory: Session <session-folder>
|
||||
EXPECTED: JSON output with answers and evidence | Write to <session>/discussions/questions-<num>.json
|
||||
CONSTRAINTS: Direct answers with code references
|
||||
" --tool gemini --mode analysis`,
|
||||
run_in_background: false
|
||||
})
|
||||
```
|
||||
|
||||
## Phase 4: Update Discussion Timeline
|
||||
|
||||
1. Write round content to `<session>/discussions/discussion-round-<num>.json`:
|
||||
```json
|
||||
{
|
||||
"round": 1, "type": "initial", "user_feedback": "...",
|
||||
"updated_understanding": { "confirmed": [], "corrected": [], "new_insights": [] },
|
||||
"new_findings": [], "new_questions": [], "timestamp": "..."
|
||||
}
|
||||
```
|
||||
|
||||
2. Append round section to `<session>/discussion.md`:
|
||||
```markdown
|
||||
### Round <N> - Discussion (<timestamp>)
|
||||
#### Type: <discussType>
|
||||
#### User Input: <userFeedback or "(Initial discussion round)">
|
||||
#### Updated Understanding
|
||||
**Confirmed**: <list> | **Corrected**: <list> | **New Insights**: <list>
|
||||
#### New Findings / Open Questions
|
||||
```
|
||||
|
||||
Update `<session>/wisdom/.msg/meta.json` under `discussant` namespace:
|
||||
- Read existing -> merge `{ "discussant": { round, type, new_insight_count, corrected_count } }` -> write back
|
||||
@@ -1,73 +0,0 @@
|
||||
---
|
||||
prefix: EXPLORE
|
||||
inner_loop: false
|
||||
message_types:
|
||||
success: exploration_ready
|
||||
error: error
|
||||
---
|
||||
|
||||
# Codebase Explorer
|
||||
|
||||
Explore codebase structure through cli-explore-agent, collecting structured context (files, patterns, findings) for downstream analysis. One explorer per analysis perspective.
|
||||
|
||||
## Phase 2: Context & Scope Assessment
|
||||
|
||||
| Input | Source | Required |
|
||||
|-------|--------|----------|
|
||||
| Task description | From task subject/description | Yes |
|
||||
| Session path | Extracted from task description | Yes |
|
||||
|
||||
1. Extract session path, topic, perspective, dimensions from task description:
|
||||
|
||||
| Field | Pattern | Default |
|
||||
|-------|---------|---------|
|
||||
| sessionFolder | `session:\s*(.+)` | required |
|
||||
| topic | `topic:\s*(.+)` | required |
|
||||
| perspective | `perspective:\s*(.+)` | "general" |
|
||||
| dimensions | `dimensions:\s*(.+)` | "general" |
|
||||
|
||||
2. Determine exploration number from task subject (EXPLORE-N)
|
||||
3. Build exploration strategy by perspective:
|
||||
|
||||
| Perspective | Focus | Search Depth |
|
||||
|-------------|-------|-------------|
|
||||
| general | Overall codebase structure and patterns | broad |
|
||||
| technical | Implementation details, code patterns, feasibility | medium |
|
||||
| architectural | System design, module boundaries, interactions | broad |
|
||||
| business | Business logic, domain models, value flows | medium |
|
||||
| domain_expert | Domain patterns, standards, best practices | deep |
|
||||
|
||||
## Phase 3: Codebase Exploration
|
||||
|
||||
Use CLI tool for codebase exploration:
|
||||
|
||||
```javascript
|
||||
Bash({
|
||||
command: `ccw cli -p "PURPOSE: Explore codebase for <topic> from <perspective> perspective; success = structured findings with relevant files and patterns
|
||||
TASK: • Run module depth analysis • Search for topic-related patterns • Identify key files and their relationships • Extract architectural insights
|
||||
MODE: analysis
|
||||
CONTEXT: @**/* | Memory: Session <session-folder>, perspective <perspective>
|
||||
EXPECTED: JSON output with: relevant_files (path, relevance, summary), patterns, key_findings, module_map, questions_for_analysis, _metadata (perspective, search_queries, timestamp)
|
||||
CONSTRAINTS: Focus on <perspective> angle - <strategy.focus> | Write to <session>/explorations/exploration-<num>.json
|
||||
" --tool gemini --mode analysis --rule analysis-analyze-code-patterns`,
|
||||
run_in_background: false
|
||||
})
|
||||
```
|
||||
|
||||
**ACE fallback** (when CLI produces no output):
|
||||
```javascript
|
||||
mcp__ace-tool__search_context({ project_root_path: ".", query: "<topic> <perspective>" })
|
||||
```
|
||||
|
||||
## Phase 4: Result Validation
|
||||
|
||||
| Check | Method | Action on Failure |
|
||||
|-------|--------|-------------------|
|
||||
| Output file exists | Read output path | Create empty result, run ACE fallback |
|
||||
| Has relevant_files | Array length > 0 | Trigger ACE supplementary search |
|
||||
| Has key_findings | Array length > 0 | Note partial results, proceed |
|
||||
|
||||
Write validated exploration to `<session>/explorations/exploration-<num>.json`.
|
||||
|
||||
Update `<session>/wisdom/.msg/meta.json` under `explorer` namespace:
|
||||
- Read existing -> merge `{ "explorer": { perspective, file_count, finding_count } }` -> write back
|
||||
@@ -1,77 +0,0 @@
|
||||
---
|
||||
prefix: SYNTH
|
||||
inner_loop: false
|
||||
message_types:
|
||||
success: synthesis_ready
|
||||
error: error
|
||||
---
|
||||
|
||||
# Synthesizer
|
||||
|
||||
Integrate all explorations, analyses, and discussions into final conclusions. Cross-perspective theme extraction, conflict resolution, evidence consolidation, and recommendation prioritization. Pure integration role -- no external tools or CLI calls.
|
||||
|
||||
## Phase 2: Context Loading
|
||||
|
||||
| Input | Source | Required |
|
||||
|-------|--------|----------|
|
||||
| Task description | From task subject/description | Yes |
|
||||
| Session path | Extracted from task description | Yes |
|
||||
| All artifacts | `<session>/explorations/*.json`, `analyses/*.json`, `discussions/*.json` | Yes |
|
||||
| Decision trail | From wisdom/.msg/meta.json | No |
|
||||
|
||||
1. Extract session path and topic from task description
|
||||
2. Read all exploration, analysis, and discussion round files
|
||||
3. Load decision trail and current understanding from meta.json
|
||||
4. Select synthesis strategy:
|
||||
|
||||
| Condition | Strategy |
|
||||
|-----------|----------|
|
||||
| Single analysis, no discussions | simple (Quick mode summary) |
|
||||
| Multiple analyses, >2 discussion rounds | deep (track evolution) |
|
||||
| Default | standard (cross-perspective integration) |
|
||||
|
||||
## Phase 3: Cross-Perspective Synthesis
|
||||
|
||||
Execute synthesis across four dimensions:
|
||||
|
||||
**1. Theme Extraction**: Identify convergent themes across all analysis perspectives. Cluster insights by similarity, rank by cross-perspective confirmation count.
|
||||
|
||||
**2. Conflict Resolution**: Identify contradictions between perspectives. Present both sides with trade-off analysis when irreconcilable.
|
||||
|
||||
**3. Evidence Consolidation**: Deduplicate findings, aggregate by file reference. Map evidence to conclusions with confidence levels:
|
||||
|
||||
| Level | Criteria |
|
||||
|-------|----------|
|
||||
| High | Multiple sources confirm, strong evidence |
|
||||
| Medium | Single source or partial evidence |
|
||||
| Low | Speculative, needs verification |
|
||||
|
||||
**4. Recommendation Prioritization**: Sort all recommendations by priority (high > medium > low), deduplicate, cap at 10.
|
||||
|
||||
Integrate decision trail from discussion rounds into final narrative.
|
||||
|
||||
## Phase 4: Write Conclusions
|
||||
|
||||
1. Write `<session>/conclusions.json`:
|
||||
```json
|
||||
{
|
||||
"session_id": "...", "topic": "...", "completed": "ISO-8601",
|
||||
"summary": "Executive summary...",
|
||||
"key_conclusions": [{"point": "...", "evidence": "...", "confidence": "high"}],
|
||||
"recommendations": [{"action": "...", "rationale": "...", "priority": "high"}],
|
||||
"open_questions": ["..."],
|
||||
"decision_trail": [{"round": 1, "decision": "...", "context": "..."}],
|
||||
"cross_perspective_synthesis": { "convergent_themes": [], "conflicts_resolved": [], "unique_contributions": [] },
|
||||
"_metadata": { "explorations": 3, "analyses": 3, "discussions": 2, "strategy": "standard" }
|
||||
}
|
||||
```
|
||||
|
||||
2. Append conclusions section to `<session>/discussion.md`:
|
||||
```markdown
|
||||
## Conclusions
|
||||
### Summary / Key Conclusions / Recommendations / Remaining Questions
|
||||
## Decision Trail / Current Understanding (Final) / Session Statistics
|
||||
```
|
||||
|
||||
Update `<session>/wisdom/.msg/meta.json` under `synthesizer` namespace:
|
||||
- Read existing -> merge `{ "synthesizer": { conclusion_count, recommendation_count, open_question_count } }` -> write back
|
||||
@@ -40,18 +40,28 @@ MAX_ROUNDS = pipeline_mode === 'deep' ? 5
|
||||
|
||||
Triggered when a worker sends completion message (via SendMessage callback).
|
||||
|
||||
1. Parse message to identify role and task ID:
|
||||
1. Parse message to identify role, then resolve completed tasks:
|
||||
|
||||
| Message Pattern | Role Detection |
|
||||
|----------------|---------------|
|
||||
| `[explorer]` or task ID `EXPLORE-*` | explorer |
|
||||
| `[analyst]` or task ID `ANALYZE-*` | analyst |
|
||||
| `[discussant]` or task ID `DISCUSS-*` | discussant |
|
||||
| `[synthesizer]` or task ID `SYNTH-*` | synthesizer |
|
||||
**Role detection** (from message tag at start of body):
|
||||
|
||||
2. Mark task as completed:
|
||||
| Message starts with | Role | Handler |
|
||||
|---------------------|------|---------|
|
||||
| `[explorer]` | explorer | handleCallback |
|
||||
| `[analyst]` | analyst | handleCallback |
|
||||
| `[discussant]` | discussant | handleCallback |
|
||||
| `[synthesizer]` | synthesizer | handleCallback |
|
||||
| `[supervisor]` | supervisor | Log checkpoint result, verify CHECKPOINT task completed, proceed to handleSpawnNext |
|
||||
|
||||
**Task ID resolution** (do NOT parse from message — use TaskList):
|
||||
- Call `TaskList()` and find tasks matching the detected role's prefix
|
||||
- Tasks with status `completed` that were not previously tracked = newly completed tasks
|
||||
- This is reliable even when a worker reports multiple tasks (inner_loop) or when message format varies
|
||||
|
||||
2. Verify task completion (worker already marks completed in Phase 5):
|
||||
|
||||
```
|
||||
TaskGet({ taskId: "<task-id>" })
|
||||
// If still "in_progress" (worker failed to mark) → fallback:
|
||||
TaskUpdate({ taskId: "<task-id>", status: "completed" })
|
||||
```
|
||||
|
||||
@@ -112,7 +122,7 @@ ELSE:
|
||||
|----------|--------|
|
||||
| "Continue deeper" | Create new DISCUSS-`<N+1>` task (pending, no blockedBy). Record decision in discussion.md. Proceed to handleSpawnNext |
|
||||
| "Adjust direction" | AskUserQuestion for new focus. Create ANALYZE-fix-`<N>` task (pending). Create DISCUSS-`<N+1>` task (pending, blockedBy ANALYZE-fix-`<N>`). Record direction change in discussion.md. Proceed to handleSpawnNext |
|
||||
| "Done" | Create SYNTH-001 task (pending, blockedBy last DISCUSS). Record decision in discussion.md. Proceed to handleSpawnNext |
|
||||
| "Done" | Check if SYNTH-001 already exists (from dispatch): if yes, ensure blockedBy is updated to reference last DISCUSS task; if no, create SYNTH-001 (pending, blockedBy last DISCUSS). Record decision in discussion.md. Proceed to handleSpawnNext |
|
||||
|
||||
**Dynamic task creation templates**:
|
||||
|
||||
@@ -160,8 +170,11 @@ InnerLoop: false"
|
||||
TaskUpdate({ taskId: "ANALYZE-fix-<N>", owner: "analyst" })
|
||||
```
|
||||
|
||||
SYNTH-001 (created dynamically in deep mode):
|
||||
SYNTH-001 (created dynamically — check existence first):
|
||||
```
|
||||
// Guard: only create if SYNTH-001 doesn't exist yet (dispatch may have pre-created it)
|
||||
const existingSynth = TaskList().find(t => t.subject === 'SYNTH-001')
|
||||
if (!existingSynth) {
|
||||
TaskCreate({
|
||||
subject: "SYNTH-001",
|
||||
description: "PURPOSE: Integrate all analysis into final conclusions | Success: Executive summary with recommendations
|
||||
@@ -179,6 +192,8 @@ CONSTRAINTS: Pure integration, no new exploration
|
||||
---
|
||||
InnerLoop: false"
|
||||
})
|
||||
}
|
||||
// Always update blockedBy to reference the last DISCUSS task (whether pre-existing or newly created)
|
||||
TaskUpdate({ taskId: "SYNTH-001", addBlockedBy: ["<last-DISCUSS-task-id>"], owner: "synthesizer" })
|
||||
```
|
||||
|
||||
@@ -211,10 +226,10 @@ Find and spawn the next ready tasks.
|
||||
|
||||
| Task Prefix | Role | Role Spec |
|
||||
|-------------|------|-----------|
|
||||
| `EXPLORE-*` | explorer | `~ or <project>/.claude/skills/team-ultra-analyze/role-specs/explorer.md` |
|
||||
| `ANALYZE-*` | analyst | `~ or <project>/.claude/skills/team-ultra-analyze/role-specs/analyst.md` |
|
||||
| `DISCUSS-*` | discussant | `~ or <project>/.claude/skills/team-ultra-analyze/role-specs/discussant.md` |
|
||||
| `SYNTH-*` | synthesizer | `~ or <project>/.claude/skills/team-ultra-analyze/role-specs/synthesizer.md` |
|
||||
| `EXPLORE-*` | explorer | `<skill_root>/roles/explorer/role.md` |
|
||||
| `ANALYZE-*` | analyst | `<skill_root>/roles/analyst/role.md` |
|
||||
| `DISCUSS-*` | discussant | `<skill_root>/roles/discussant/role.md` |
|
||||
| `SYNTH-*` | synthesizer | `<skill_root>/roles/synthesizer/role.md` |
|
||||
|
||||
3. Spawn team-worker for each ready task:
|
||||
|
||||
@@ -227,7 +242,7 @@ Agent({
|
||||
run_in_background: true,
|
||||
prompt: `## Role Assignment
|
||||
role: <role>
|
||||
role_spec: ~ or <project>/.claude/skills/team-ultra-analyze/role-specs/<role>.md
|
||||
role_spec: <skill_root>/roles/<role>/role.md
|
||||
session: <session-folder>
|
||||
session_id: <session-id>
|
||||
team_name: ultra-analyze
|
||||
@@ -298,11 +313,11 @@ Triggered when all pipeline tasks are completed.
|
||||
| deep | All EXPLORE + ANALYZE + all DISCUSS-N + SYNTH-001 completed |
|
||||
|
||||
1. Verify all tasks completed. If any not completed, return to handleSpawnNext
|
||||
2. If all completed, transition to coordinator Phase 5
|
||||
2. If all completed, **inline-execute coordinator Phase 5** (shutdown workers → report → completion action). Do NOT STOP here — continue directly into Phase 5 within the same turn.
|
||||
|
||||
## Phase 4: State Persistence
|
||||
|
||||
After every handler execution:
|
||||
After every handler execution **except handleComplete**:
|
||||
|
||||
1. Update session.json with current state:
|
||||
- `discussion_round`: current round count
|
||||
@@ -311,6 +326,8 @@ After every handler execution:
|
||||
2. Verify task list consistency (no orphan tasks, no broken dependencies)
|
||||
3. **STOP** and wait for next event
|
||||
|
||||
> **handleComplete exception**: handleComplete does NOT STOP — it transitions directly to coordinator Phase 5.
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Scenario | Resolution |
|
||||
|
||||
@@ -44,13 +44,21 @@ When coordinator is invoked, detect invocation type:
|
||||
|
||||
| Detection | Condition | Handler |
|
||||
|-----------|-----------|---------|
|
||||
| Worker callback | Message contains role tag [explorer], [analyst], [discussant], [synthesizer] | -> handleCallback (monitor.md) |
|
||||
| Worker callback | Message content starts with `[explorer]`, `[analyst]`, `[discussant]`, or `[synthesizer]` (role tag at beginning of message body) | -> handleCallback (monitor.md) |
|
||||
| Supervisor callback | Message content starts with `[supervisor]` | -> handleSupervisorReport (log checkpoint result, proceed to handleSpawnNext if tasks unblocked) |
|
||||
| Idle notification | System notification that a teammate went idle (does NOT start with a role tag — typically says "Agent X is now idle") | -> **IGNORE** (do not handleCallback; idle is normal after every turn) |
|
||||
| Shutdown response | Message content is a JSON object containing `shutdown_response` (parse as structured data, not string) | -> handleShutdownResponse (see Phase 5) |
|
||||
| Status check | Arguments contain "check" or "status" | -> handleCheck (monitor.md) |
|
||||
| Manual resume | Arguments contain "resume" or "continue" | -> handleResume (monitor.md) |
|
||||
| Pipeline complete | All tasks have status "completed" | -> handleComplete (monitor.md) |
|
||||
| Interrupted session | Active/paused session exists | -> Phase 0 |
|
||||
| New session | None of above | -> Phase 1 |
|
||||
|
||||
**Message format discrimination**:
|
||||
- **String messages starting with `[<role>]`**: Worker/supervisor completion reports → route to handleCallback or handleSupervisorReport
|
||||
- **JSON object messages** (contain `type:` field): Structured protocol messages (shutdown_response) → route by `type` field
|
||||
- **Other strings without role tags**: System idle notifications → IGNORE
|
||||
|
||||
For callback/check/resume/complete: load `@commands/monitor.md` and execute matched handler, then STOP.
|
||||
|
||||
### Router Implementation
|
||||
@@ -167,7 +175,31 @@ All subsequent coordination is handled by `commands/monitor.md` handlers trigger
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Report + Completion Action
|
||||
## Phase 5: Shutdown Workers + Report + Completion Action
|
||||
|
||||
### Shutdown All Workers
|
||||
|
||||
Before reporting, gracefully shut down all active teammates. This is a **multi-turn** process:
|
||||
|
||||
1. Read team config: `~/.claude/teams/ultra-analyze/config.json`
|
||||
2. Build shutdown tracking list: `pending_shutdown = [<all member names except coordinator>]`
|
||||
3. For each member in pending_shutdown, send shutdown request:
|
||||
```javascript
|
||||
SendMessage({
|
||||
to: "<member-name>",
|
||||
message: { type: "shutdown_request", reason: "Pipeline complete" }
|
||||
})
|
||||
```
|
||||
4. **STOP** — wait for responses. Each `shutdown_response` triggers a new coordinator turn.
|
||||
5. On each subsequent turn (shutdown_response received):
|
||||
- Remove responder from `pending_shutdown`
|
||||
- If `pending_shutdown` is empty → proceed to **Report** section below
|
||||
- If not empty → **STOP** again, wait for remaining responses
|
||||
6. If a member is unresponsive after 2 follow-ups, remove from tracking and proceed
|
||||
|
||||
**Note**: Workers that completed Phase 5-F and reached STOP may have already terminated. SendMessage to a terminated agent is silently ignored — this is safe. Only resident agents (e.g., supervisor) require explicit shutdown.
|
||||
|
||||
### Report
|
||||
|
||||
1. Load session state -> count completed tasks, calculate duration
|
||||
2. List deliverables:
|
||||
|
||||
@@ -157,8 +157,7 @@ team_msg(operation="log", session_id=<session-id>, from="tester",
|
||||
If pass rate < 95%, send fix_required message:
|
||||
```
|
||||
SendMessage({
|
||||
recipient: "coordinator",
|
||||
type: "message",
|
||||
content: "[tester] Test validation incomplete. Pass rate: <percentage>%. Manual review needed."
|
||||
to: "coordinator",
|
||||
message: "[tester] Test validation incomplete. Pass rate: <percentage>%. Manual review needed."
|
||||
})
|
||||
```
|
||||
|
||||
@@ -30,7 +30,6 @@ Every task description uses structured format for clarity:
|
||||
```
|
||||
TaskCreate({
|
||||
subject: "<TASK-ID>",
|
||||
owner: "<role>",
|
||||
description: "PURPOSE: <what this task achieves> | Success: <measurable completion criteria>
|
||||
TASK:
|
||||
- <step 1: specific action>
|
||||
@@ -46,9 +45,9 @@ EXPECTED: <deliverable path> + <quality criteria>
|
||||
CONSTRAINTS: <scope limits, focus areas>
|
||||
---
|
||||
InnerLoop: <true|false>
|
||||
<additional-metadata-fields>",
|
||||
blockedBy: [<dependency-list>]
|
||||
<additional-metadata-fields>"
|
||||
})
|
||||
TaskUpdate({ taskId: "<TASK-ID>", addBlockedBy: [<dependency-list>], owner: "<role>" })
|
||||
```
|
||||
|
||||
### Standard Pipeline Tasks
|
||||
@@ -57,7 +56,6 @@ InnerLoop: <true|false>
|
||||
```
|
||||
TaskCreate({
|
||||
subject: "SCAN-001",
|
||||
owner: "scanner",
|
||||
description: "PURPOSE: Scan UI components to identify interaction issues (unresponsive buttons, missing feedback, state not refreshing) | Success: Complete issue report with file:line references and severity classification
|
||||
TASK:
|
||||
- Detect framework (React/Vue) from project structure
|
||||
@@ -73,17 +71,15 @@ CONTEXT:
|
||||
EXPECTED: artifacts/scan-report.md with structured issue list (severity: High/Medium/Low, file:line, description, category)
|
||||
CONSTRAINTS: Focus on interaction issues only, exclude styling/layout problems
|
||||
---
|
||||
InnerLoop: false",
|
||||
blockedBy: [],
|
||||
status: "pending"
|
||||
InnerLoop: false"
|
||||
})
|
||||
TaskUpdate({ taskId: "SCAN-001", owner: "scanner" })
|
||||
```
|
||||
|
||||
**DIAG-001: Root Cause Diagnosis**
|
||||
```
|
||||
TaskCreate({
|
||||
subject: "DIAG-001",
|
||||
owner: "diagnoser",
|
||||
description: "PURPOSE: Diagnose root causes of identified UI issues | Success: Complete diagnosis report with fix recommendations for each issue
|
||||
TASK:
|
||||
- Load scan report from artifacts/scan-report.md
|
||||
@@ -100,17 +96,15 @@ CONTEXT:
|
||||
EXPECTED: artifacts/diagnosis.md with root cause analysis (issue ID, root cause, pattern type, fix recommendation)
|
||||
CONSTRAINTS: Focus on actionable root causes, provide specific fix strategies
|
||||
---
|
||||
InnerLoop: false",
|
||||
blockedBy: ["SCAN-001"],
|
||||
status: "pending"
|
||||
InnerLoop: false"
|
||||
})
|
||||
TaskUpdate({ taskId: "DIAG-001", addBlockedBy: ["SCAN-001"], owner: "diagnoser" })
|
||||
```
|
||||
|
||||
**DESIGN-001: Solution Design**
|
||||
```
|
||||
TaskCreate({
|
||||
subject: "DESIGN-001",
|
||||
owner: "designer",
|
||||
description: "PURPOSE: Design feedback mechanisms and state management solutions for identified issues | Success: Complete implementation guide with code patterns and examples
|
||||
TASK:
|
||||
- Load diagnosis report from artifacts/diagnosis.md
|
||||
@@ -128,17 +122,15 @@ CONTEXT:
|
||||
EXPECTED: artifacts/design-guide.md with implementation guide (issue ID, solution design, code patterns, state management examples, UI binding templates)
|
||||
CONSTRAINTS: Solutions must be framework-appropriate, provide complete working examples
|
||||
---
|
||||
InnerLoop: false",
|
||||
blockedBy: ["DIAG-001"],
|
||||
status: "pending"
|
||||
InnerLoop: false"
|
||||
})
|
||||
TaskUpdate({ taskId: "DESIGN-001", addBlockedBy: ["DIAG-001"], owner: "designer" })
|
||||
```
|
||||
|
||||
**IMPL-001: Code Implementation**
|
||||
```
|
||||
TaskCreate({
|
||||
subject: "IMPL-001",
|
||||
owner: "implementer",
|
||||
description: "PURPOSE: Generate fix code with proper state management, event handling, and UI feedback bindings | Success: All fixes implemented and validated
|
||||
TASK:
|
||||
- Load design guide from artifacts/design-guide.md
|
||||
@@ -158,17 +150,15 @@ CONTEXT:
|
||||
EXPECTED: artifacts/fixes/ directory with all fix files, implementation summary in artifacts/fixes/README.md
|
||||
CONSTRAINTS: Maintain existing code style, ensure backward compatibility, validate all changes
|
||||
---
|
||||
InnerLoop: true",
|
||||
blockedBy: ["DESIGN-001"],
|
||||
status: "pending"
|
||||
InnerLoop: true"
|
||||
})
|
||||
TaskUpdate({ taskId: "IMPL-001", addBlockedBy: ["DESIGN-001"], owner: "implementer" })
|
||||
```
|
||||
|
||||
**TEST-001: Test Validation**
|
||||
```
|
||||
TaskCreate({
|
||||
subject: "TEST-001",
|
||||
owner: "tester",
|
||||
description: "PURPOSE: Generate and run tests to verify fixes (loading states, error handling, state updates) | Success: Pass rate >= 95%, all critical fixes validated
|
||||
TASK:
|
||||
- Detect test framework (Jest/Vitest) from project
|
||||
@@ -187,10 +177,9 @@ CONTEXT:
|
||||
EXPECTED: artifacts/test-report.md with test results (pass/fail counts, coverage metrics, fix iterations, remaining issues)
|
||||
CONSTRAINTS: Pass rate threshold: 95%, max fix iterations: 5
|
||||
---
|
||||
InnerLoop: false",
|
||||
blockedBy: ["IMPL-001"],
|
||||
status: "pending"
|
||||
InnerLoop: false"
|
||||
})
|
||||
TaskUpdate({ taskId: "TEST-001", addBlockedBy: ["IMPL-001"], owner: "tester" })
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user