feat: Add coordinator commands and role specifications for UI design team

- Implemented the 'monitor' command for coordinator role to handle monitoring events, task completion, and pipeline management.
- Created role specifications for the coordinator, detailing responsibilities, command execution protocols, and session management.
- Added role specifications for the analyst, discussant, explorer, and synthesizer in the ultra-analyze skill, defining their context loading, analysis, and synthesis processes.
This commit is contained in:
catlog22
2026-03-03 23:35:41 +08:00
parent a7ed0365f7
commit 26bda9c634
188 changed files with 9332 additions and 3512 deletions

View File

@@ -0,0 +1,105 @@
---
prefix: EXPLORE
inner_loop: false
subagents: [cli-explore-agent]
message_types:
success: context_ready
error: error
---
# Issue Explorer
Analyze issue context, explore codebase for relevant files, map dependencies and impact scope. Produce a shared context report for planner, reviewer, and implementer.
## Phase 2: Issue Loading & Context Setup
| Input | Source | Required |
|-------|--------|----------|
| Issue ID | Task description (GH-\d+ or ISS-\d{8}-\d{6}) | Yes |
| Issue details | `ccw issue status <id> --json` | Yes |
| Session path | Extracted from task description | Yes |
| .msg/meta.json | <session>/wisdom/.msg/meta.json | No |
1. Extract issue ID from task description via regex: `(?:GH-\d+|ISS-\d{8}-\d{6})`
2. If no issue ID found -> report error, STOP
3. Load issue details:
```
Bash("ccw issue status <issueId> --json")
```
4. Parse JSON response for issue metadata (title, context, priority, labels, feedback)
5. Load wisdom files from `<session>/wisdom/` if available
## Phase 3: Codebase Exploration & Impact Analysis
**Complexity assessment determines exploration depth**:
| Signal | Weight | Keywords |
|--------|--------|----------|
| Structural change | +2 | refactor, architect, restructure, module, system |
| Cross-cutting | +2 | multiple, across, cross |
| Integration | +1 | integrate, api, database |
| High priority | +1 | priority >= 4 |
| Score | Complexity | Strategy |
|-------|------------|----------|
| >= 4 | High | Deep exploration via cli-explore-agent |
| 2-3 | Medium | Hybrid: ACE search + selective agent |
| 0-1 | Low | Direct ACE search only |
**Exploration execution**:
| Complexity | Execution |
|------------|-----------|
| Low | Direct ACE search: `mcp__ace-tool__search_context(project_root_path, query)` |
| Medium/High | Spawn cli-explore-agent: `Task({ subagent_type: "cli-explore-agent", run_in_background: false })` |
**cli-explore-agent prompt template**:
```
## Issue Context
ID: <issueId>
Title: <issue.title>
Description: <issue.context>
Priority: <issue.priority>
## MANDATORY FIRST STEPS
1. Run: ccw tool exec get_modules_by_depth '{}'
2. Execute ACE searches based on issue keywords
3. Run: ccw spec load --category exploration
## Exploration Focus
- Identify files directly related to this issue
- Map dependencies and integration points
- Assess impact scope (how many modules/files affected)
- Find existing patterns relevant to the fix
- Check for previous related changes (git log)
## Output
Write findings to: <session>/explorations/context-<issueId>.json
```
**Report schema**:
```json
{
"issue_id": "string",
"issue": { "id": "", "title": "", "priority": 0, "status": "", "labels": [], "feedback": "" },
"relevant_files": [{ "path": "", "relevance": "" }],
"dependencies": [],
"impact_scope": "low | medium | high",
"existing_patterns": [],
"related_changes": [],
"key_findings": [],
"complexity_assessment": "Low | Medium | High"
}
```
## Phase 4: Context Report & Wisdom Contribution
1. Write context report to `<session>/explorations/context-<issueId>.json`
2. If file not found from agent, build minimal report from ACE results
3. Update `<session>/wisdom/.msg/meta.json` under `explorer` namespace:
- Read existing -> merge `{ "explorer": { issue_id, complexity, impact_scope, file_count } }` -> write back
4. Contribute discoveries to `<session>/wisdom/learnings.md` if new patterns found

View File

@@ -0,0 +1,89 @@
---
prefix: BUILD
inner_loop: false
message_types:
success: impl_complete
failed: impl_failed
error: error
---
# Issue Implementer
Load solution plan, route to execution backend (Agent/Codex/Gemini), run tests, and commit. Execution method determined by coordinator during task creation. Supports parallel instances for batch mode.
## Modes
| Backend | Condition | Method |
|---------|-----------|--------|
| agent | task_count <= 3 or explicit | `Task({ subagent_type: "code-developer", run_in_background: false })` |
| codex | task_count > 3 or explicit | `ccw cli --tool codex --mode write --id issue-<issueId>` |
| gemini | explicit | `ccw cli --tool gemini --mode write --id issue-<issueId>` |
## Phase 2: Load Solution & Resolve Executor
| Input | Source | Required |
|-------|--------|----------|
| Issue ID | Task description (GH-\d+ or ISS-\d{8}-\d{6}) | Yes |
| Bound solution | `ccw issue solutions <id> --json` | Yes |
| Explorer context | `<session>/explorations/context-<issueId>.json` | No |
| Execution method | Task description (`execution_method: Agent|Codex|Gemini|Auto`) | Yes |
| Code review | Task description (`code_review: Skip|Gemini Review|Codex Review`) | No |
1. Extract issue ID from task description
2. If no issue ID -> report error, STOP
3. Load bound solution: `Bash("ccw issue solutions <issueId> --json")`
4. If no bound solution -> report error, STOP
5. Load explorer context (if available)
6. Resolve execution method (Auto: task_count <= 3 -> agent, else codex)
7. Update issue status: `Bash("ccw issue update <issueId> --status in-progress")`
## Phase 3: Implementation (Multi-Backend Routing)
**Execution prompt template** (all backends):
```
## Issue
ID: <issueId>
Title: <solution.bound.title>
## Solution Plan
<solution.bound JSON>
## Codebase Context (from explorer)
Relevant files: <explorerContext.relevant_files>
Existing patterns: <explorerContext.existing_patterns>
Dependencies: <explorerContext.dependencies>
## Implementation Requirements
1. Follow the solution plan tasks in order
2. Write clean, minimal code following existing patterns
3. Run tests after each significant change
4. Ensure all existing tests still pass
5. Do NOT over-engineer
## Quality Checklist
- All solution tasks implemented
- No TypeScript/linting errors
- Existing tests pass
- New tests added where appropriate
```
Route by executor:
- **agent**: `Task({ subagent_type: "code-developer", run_in_background: false, prompt: <prompt> })`
- **codex**: `Bash("ccw cli -p \"<prompt>\" --tool codex --mode write --id issue-<issueId>")`
- **gemini**: `Bash("ccw cli -p \"<prompt>\" --tool gemini --mode write --id issue-<issueId>")`
On CLI failure, resume: `ccw cli -p "Continue" --resume issue-<issueId> --tool <tool> --mode write`
## Phase 4: Verify & Commit
| Check | Method | Pass Criteria |
|-------|--------|---------------|
| Tests pass | Detect and run test command | No new failures |
| Code review | Optional, per task config | Review output logged |
- Tests pass -> optional code review -> `ccw issue update <issueId> --status resolved` -> report `impl_complete`
- Tests fail -> report `impl_failed` with truncated test output
Update `<session>/wisdom/.msg/meta.json` under `implementer` namespace:
- Read existing -> merge `{ "implementer": { issue_id, executor, test_status, review_status } }` -> write back

View File

@@ -0,0 +1,94 @@
---
prefix: MARSHAL
inner_loop: false
subagents: [issue-queue-agent]
message_types:
success: queue_ready
conflict: conflict_found
error: error
---
# Issue Integrator
Queue orchestration, conflict detection, and execution order optimization. Internally invokes issue-queue-agent for intelligent queue formation with DAG-based parallel groups.
## Phase 2: Collect Bound Solutions
| Input | Source | Required |
|-------|--------|----------|
| Issue IDs | Task description (GH-\d+ or ISS-\d{8}-\d{6}) | Yes |
| Bound solutions | `ccw issue solutions <id> --json` | Yes |
| .msg/meta.json | <session>/wisdom/.msg/meta.json | No |
1. Extract issue IDs from task description via regex
2. Verify all issues have bound solutions:
```
Bash("ccw issue solutions <issueId> --json")
```
3. Check for unbound issues:
| Condition | Action |
|-----------|--------|
| All issues bound | Proceed to Phase 3 |
| Any issue unbound | Report error to coordinator, STOP |
## Phase 3: Queue Formation via issue-queue-agent
**Agent invocation**:
```
Task({
subagent_type: "issue-queue-agent",
run_in_background: false,
description: "Form queue for <count> issues",
prompt: "
## Issues to Queue
Issue IDs: <issueIds>
## Bound Solutions
<solution list with issue_id, solution_id, task_count>
## Instructions
1. Load all bound solutions from .workflow/issues/solutions/
2. Analyze file conflicts between solutions using Gemini CLI
3. Determine optimal execution order (DAG-based)
4. Produce ordered execution queue
## Expected Output
Write queue to: .workflow/issues/queue/execution-queue.json
"
})
```
**Parse queue result**:
```
Read(".workflow/issues/queue/execution-queue.json")
```
**Queue schema**:
```json
{
"queue": [{ "issue_id": "", "solution_id": "", "order": 0, "depends_on": [], "estimated_files": [] }],
"conflicts": [{ "issues": [], "files": [], "resolution": "" }],
"parallel_groups": [{ "group": 0, "issues": [] }]
}
```
## Phase 4: Conflict Resolution & Reporting
**Queue validation**:
| Condition | Action |
|-----------|--------|
| Queue file exists, no unresolved conflicts | Report `queue_ready` |
| Queue file exists, has unresolved conflicts | Report `conflict_found` for user decision |
| Queue file not found | Report `error`, STOP |
**Queue metrics for report**: queue size, parallel group count, resolved conflict count, execution order list.
Update `<session>/wisdom/.msg/meta.json` under `integrator` namespace:
- Read existing -> merge `{ "integrator": { queue_size, parallel_groups, conflict_count } }` -> write back

View File

@@ -0,0 +1,85 @@
---
prefix: SOLVE
inner_loop: false
additional_prefixes: [SOLVE-fix]
subagents: [issue-plan-agent]
message_types:
success: solution_ready
multi: multi_solution
error: error
---
# Issue Planner
Design solutions and decompose into implementation tasks. Internally invokes issue-plan-agent for ACE exploration and solution generation. For revision tasks (SOLVE-fix), design alternative approaches addressing reviewer feedback.
## Phase 2: Context Loading
| Input | Source | Required |
|-------|--------|----------|
| Issue ID | Task description (GH-\d+ or ISS-\d{8}-\d{6}) | Yes |
| Explorer context | `<session>/explorations/context-<issueId>.json` | No |
| Review feedback | Task description (for SOLVE-fix tasks) | No |
| .msg/meta.json | <session>/wisdom/.msg/meta.json | No |
1. Extract issue ID from task description via regex: `(?:GH-\d+|ISS-\d{8}-\d{6})`
2. If no issue ID found -> report error, STOP
3. Load explorer context report (if available):
```
Read("<session>/explorations/context-<issueId>.json")
```
4. Check if this is a revision task (SOLVE-fix-N):
- If yes, extract reviewer feedback from task description
- Design alternative approach addressing reviewer concerns
5. Load wisdom files for accumulated codebase knowledge
## Phase 3: Solution Generation via issue-plan-agent
**Agent invocation**:
```
Task({
subagent_type: "issue-plan-agent",
run_in_background: false,
description: "Plan solution for <issueId>",
prompt: "
issue_ids: [\"<issueId>\"]
project_root: \"<projectRoot>\"
## Explorer Context (pre-gathered)
Relevant files: <explorerContext.relevant_files>
Key findings: <explorerContext.key_findings>
Complexity: <explorerContext.complexity_assessment>
## Revision Required (if SOLVE-fix)
Previous solution was rejected by reviewer. Feedback:
<reviewFeedback>
Design an ALTERNATIVE approach that addresses the reviewer's concerns.
"
})
```
**Expected agent result**:
| Field | Description |
|-------|-------------|
| `bound` | Array of auto-bound solutions: `[{issue_id, solution_id, task_count}]` |
| `pending_selection` | Array of multi-solution issues: `[{issue_id, solutions: [...]}]` |
## Phase 4: Solution Selection & Reporting
**Outcome routing**:
| Condition | Message Type | Action |
|-----------|-------------|--------|
| Single solution auto-bound | `solution_ready` | Report to coordinator |
| Multiple solutions pending | `multi_solution` | Report for user selection |
| No solution generated | `error` | Report failure to coordinator |
Write solution summary to `<session>/solutions/solution-<issueId>.json`.
Update `<session>/wisdom/.msg/meta.json` under `planner` namespace:
- Read existing -> merge `{ "planner": { issue_id, solution_id, task_count, is_revision } }` -> write back

View File

@@ -0,0 +1,89 @@
---
prefix: AUDIT
inner_loop: false
message_types:
success: approved
concerns: concerns
rejected: rejected
error: error
---
# Issue Reviewer
Review solution plans for technical feasibility, risk, and completeness. Quality gate role between plan and execute phases. Provides clear verdicts: approved, rejected, or concerns.
## Phase 2: Context & Solution Loading
| Input | Source | Required |
|-------|--------|----------|
| Issue IDs | Task description (GH-\d+ or ISS-\d{8}-\d{6}) | Yes |
| Explorer context | `<session>/explorations/context-<issueId>.json` | No |
| Bound solution | `ccw issue solutions <id> --json` | Yes |
| .msg/meta.json | <session>/wisdom/.msg/meta.json | No |
1. Extract issue IDs from task description via regex
2. Load explorer context reports for each issue
3. Load bound solutions for each issue:
```
Bash("ccw issue solutions <issueId> --json")
```
## Phase 3: Multi-Dimensional Review
Review each solution across three weighted dimensions:
**Technical Feasibility (40%)**:
| Criterion | Check |
|-----------|-------|
| File Coverage | Solution covers all affected files from explorer context |
| Dependency Awareness | Considers dependency cascade effects |
| API Compatibility | Maintains backward compatibility |
| Pattern Conformance | Follows existing code patterns (ACE semantic validation) |
**Risk Assessment (30%)**:
| Criterion | Check |
|-----------|-------|
| Scope Creep | Solution stays within issue boundary (task_count <= 10) |
| Breaking Changes | No destructive modifications |
| Side Effects | No unforeseen side effects |
| Rollback Path | Can rollback if issues occur |
**Completeness (30%)**:
| Criterion | Check |
|-----------|-------|
| All Tasks Defined | Task decomposition is complete (count > 0) |
| Test Coverage | Includes test plan |
| Edge Cases | Considers boundary conditions |
**Score calculation**:
```
total_score = round(
technical_feasibility.score * 0.4 +
risk_assessment.score * 0.3 +
completeness.score * 0.3
)
```
**Verdict rules**:
| Score | Verdict | Message Type |
|-------|---------|-------------|
| >= 80 | approved | `approved` |
| 60-79 | concerns | `concerns` |
| < 60 | rejected | `rejected` |
## Phase 4: Compile Audit Report
1. Write audit report to `<session>/audits/audit-report.json`:
- Per-issue: issueId, solutionId, total_score, verdict, per-dimension scores and findings
- Overall verdict (any rejected -> overall rejected)
2. Update `<session>/wisdom/.msg/meta.json` under `reviewer` namespace:
- Read existing -> merge `{ "reviewer": { overall_verdict, review_count, scores } }` -> write back
3. For rejected solutions, include specific rejection reasons and actionable feedback for SOLVE-fix task creation