mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-03-05 16:13:08 +08:00
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
64
.claude/skills/team-iterdev/role-specs/architect.md
Normal file
64
.claude/skills/team-iterdev/role-specs/architect.md
Normal file
@@ -0,0 +1,64 @@
|
||||
---
|
||||
prefix: DESIGN
|
||||
inner_loop: false
|
||||
message_types:
|
||||
success: design_ready
|
||||
revision: design_revision
|
||||
error: error
|
||||
---
|
||||
|
||||
# Architect
|
||||
|
||||
Technical design, task decomposition, and architecture decision records for iterative development.
|
||||
|
||||
## Phase 2: Context Loading + Codebase Exploration
|
||||
|
||||
| Input | Source | Required |
|
||||
|-------|--------|----------|
|
||||
| Task description | From task subject/description | Yes |
|
||||
| Session path | Extracted from task description | Yes |
|
||||
| .msg/meta.json | <session>/.msg/meta.json | No |
|
||||
| Wisdom files | <session>/wisdom/ | No |
|
||||
|
||||
1. Extract session path and requirement from task description
|
||||
2. Read .msg/meta.json for shared context (architecture_decisions, implementation_context)
|
||||
3. Read wisdom files if available (learnings.md, decisions.md, conventions.md)
|
||||
4. Explore codebase for existing patterns, module structure, dependencies:
|
||||
- Use mcp__ace-tool__search_context for semantic discovery
|
||||
- Identify similar implementations 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>/design/design-<num>.md`):
|
||||
- Architecture decision: approach, rationale, alternatives
|
||||
- Component design: responsibility, dependencies, files, complexity
|
||||
- Task breakdown: files, estimated complexity, dependencies, acceptance criteria
|
||||
- Integration points and risks with mitigations
|
||||
|
||||
2. **Task Breakdown JSON** (`<session>/design/task-breakdown.json`):
|
||||
- Array of tasks with id, title, files, complexity, dependencies, acceptance_criteria
|
||||
- Execution order for developer to follow
|
||||
|
||||
## Phase 4: Design Validation
|
||||
|
||||
| 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 | All components have dependencies field | All present (can be empty) |
|
||||
| Integration points | Verify integration section | Key integrations documented |
|
||||
|
||||
1. Run validation checks above
|
||||
2. Write architecture_decisions entry to .msg/meta.json:
|
||||
- design_id, approach, rationale, components, task_count
|
||||
3. Write discoveries to wisdom/decisions.md and wisdom/conventions.md
|
||||
73
.claude/skills/team-iterdev/role-specs/developer.md
Normal file
73
.claude/skills/team-iterdev/role-specs/developer.md
Normal file
@@ -0,0 +1,73 @@
|
||||
---
|
||||
prefix: DEV
|
||||
inner_loop: true
|
||||
message_types:
|
||||
success: dev_complete
|
||||
progress: dev_progress
|
||||
error: error
|
||||
---
|
||||
|
||||
# Developer
|
||||
|
||||
Code implementer. Implements code according to design, incremental delivery. Acts as Generator in Generator-Critic loop (paired with reviewer).
|
||||
|
||||
## Phase 2: Context Loading
|
||||
|
||||
| Input | Source | Required |
|
||||
|-------|--------|----------|
|
||||
| Task description | From task subject/description | Yes |
|
||||
| Session path | Extracted from task description | Yes |
|
||||
| .msg/meta.json | <session>/.msg/meta.json | Yes |
|
||||
| Design document | <session>/design/design-001.md | For non-fix tasks |
|
||||
| Task breakdown | <session>/design/task-breakdown.json | For non-fix tasks |
|
||||
| Review feedback | <session>/review/*.md | For fix tasks |
|
||||
| Wisdom files | <session>/wisdom/ | No |
|
||||
|
||||
1. Extract session path from task description
|
||||
2. Read .msg/meta.json for shared context
|
||||
3. Detect task type:
|
||||
|
||||
| Task Type | Detection | Loading |
|
||||
|-----------|-----------|---------|
|
||||
| Fix task | Subject contains "fix" | Read latest review file for feedback |
|
||||
| Normal task | No "fix" in subject | Read design document + task breakdown |
|
||||
|
||||
4. Load previous implementation_context from .msg/meta.json
|
||||
5. Read wisdom files for conventions and known issues
|
||||
|
||||
## 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 only
|
||||
- Fix critical issues first, then high, then medium
|
||||
- Do NOT change code that was not flagged
|
||||
- Maintain existing code style and patterns
|
||||
|
||||
**Normal Task Mode**:
|
||||
- Read target files, apply changes using Edit or Write
|
||||
- Follow execution order from task breakdown
|
||||
- Validate syntax after each major change
|
||||
|
||||
## Phase 4: Self-Validation
|
||||
|
||||
| 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 |
|
||||
|
||||
1. Run syntax check: `tsc --noEmit` / `python -m py_compile` / equivalent
|
||||
2. Auto-fix if validation fails (max 2 attempts)
|
||||
3. Write dev log to `<session>/code/dev-log.md`:
|
||||
- Changed files count, syntax status, fix task flag, file list
|
||||
4. Update implementation_context in .msg/meta.json:
|
||||
- task, changed_files, is_fix, syntax_clean
|
||||
5. Write discoveries to wisdom/learnings.md
|
||||
65
.claude/skills/team-iterdev/role-specs/reviewer.md
Normal file
65
.claude/skills/team-iterdev/role-specs/reviewer.md
Normal file
@@ -0,0 +1,65 @@
|
||||
---
|
||||
prefix: REVIEW
|
||||
inner_loop: false
|
||||
message_types:
|
||||
success: review_passed
|
||||
revision: review_revision
|
||||
critical: review_critical
|
||||
error: error
|
||||
---
|
||||
|
||||
# Reviewer
|
||||
|
||||
Code reviewer. Multi-dimensional review, quality scoring, improvement suggestions. Acts as Critic in Generator-Critic loop (paired with developer).
|
||||
|
||||
## Phase 2: Context Loading
|
||||
|
||||
| Input | Source | Required |
|
||||
|-------|--------|----------|
|
||||
| Task description | From task subject/description | Yes |
|
||||
| Session path | Extracted from task description | Yes |
|
||||
| .msg/meta.json | <session>/.msg/meta.json | Yes |
|
||||
| Design document | <session>/design/design-001.md | For requirements alignment |
|
||||
| Changed files | Git diff | Yes |
|
||||
|
||||
1. Extract session path from task description
|
||||
2. Read .msg/meta.json for shared context and previous review_feedback_trends
|
||||
3. Read design document for requirements alignment
|
||||
4. Get changed files via git diff, read file contents (limit 20 files)
|
||||
|
||||
## Phase 3: Multi-Dimensional Review
|
||||
|
||||
**Review dimensions**:
|
||||
|
||||
| Dimension | Weight | Focus Areas |
|
||||
|-----------|--------|-------------|
|
||||
| Correctness | 30% | Logic correctness, boundary handling |
|
||||
| Completeness | 25% | Coverage of design requirements |
|
||||
| Maintainability | 25% | Readability, code style, DRY |
|
||||
| Security | 20% | Vulnerabilities, input validation |
|
||||
|
||||
Per-dimension: scan modified files, record findings with severity (CRITICAL/HIGH/MEDIUM/LOW), include file:line references and suggestions.
|
||||
|
||||
**Scoring**: Weighted average of dimension scores (1-10 each).
|
||||
|
||||
**Output review report** (`<session>/review/review-<num>.md`):
|
||||
- Files reviewed count, quality score, issue counts by severity
|
||||
- Per-finding: severity, file:line, dimension, description, suggestion
|
||||
- Scoring breakdown by dimension
|
||||
- Signal: CRITICAL / REVISION_NEEDED / APPROVED
|
||||
- Design alignment notes
|
||||
|
||||
## Phase 4: Trend Analysis + Verdict
|
||||
|
||||
1. Compare with previous review_feedback_trends from .msg/meta.json
|
||||
2. Identify recurring issues, improvement areas, new issues
|
||||
|
||||
| Verdict Condition | Message Type |
|
||||
|-------------------|--------------|
|
||||
| criticalCount > 0 | review_critical |
|
||||
| score < 7 | review_revision |
|
||||
| else | review_passed |
|
||||
|
||||
3. Update review_feedback_trends in .msg/meta.json:
|
||||
- review_id, score, critical count, high count, dimensions, gc_round
|
||||
4. Write discoveries to wisdom/learnings.md
|
||||
74
.claude/skills/team-iterdev/role-specs/tester.md
Normal file
74
.claude/skills/team-iterdev/role-specs/tester.md
Normal file
@@ -0,0 +1,74 @@
|
||||
---
|
||||
prefix: VERIFY
|
||||
inner_loop: false
|
||||
message_types:
|
||||
success: verify_passed
|
||||
failure: verify_failed
|
||||
fix: fix_required
|
||||
error: error
|
||||
---
|
||||
|
||||
# Tester
|
||||
|
||||
Test validator. Test execution, fix cycles, and regression detection.
|
||||
|
||||
## Phase 2: Environment Detection
|
||||
|
||||
| Input | Source | Required |
|
||||
|-------|--------|----------|
|
||||
| Task description | From task subject/description | Yes |
|
||||
| Session path | Extracted from task description | Yes |
|
||||
| .msg/meta.json | <session>/.msg/meta.json | Yes |
|
||||
| Changed files | Git diff | Yes |
|
||||
|
||||
1. Extract session path from task description
|
||||
2. Read .msg/meta.json for shared context
|
||||
3. Get changed files via git diff
|
||||
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 commands: npm test, pytest, go test ./..., cargo test
|
||||
|
||||
## Phase 3: Execution + Fix Cycle
|
||||
|
||||
**Iterative test-fix cycle** (max 5 iterations):
|
||||
|
||||
| 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 |
|
||||
|
||||
**Fix delegation**: Spawn code-developer subagent with test output and changed file list. Run synchronously (run_in_background: false).
|
||||
|
||||
## Phase 4: Regression Check + Report
|
||||
|
||||
1. Run full test suite for regression: `<test-command> --all`
|
||||
|
||||
| Check | Method | Pass Criteria |
|
||||
|-------|--------|---------------|
|
||||
| Regression | Run full test suite | No FAIL in output |
|
||||
| Coverage | Run coverage tool | >= 80% (if configured) |
|
||||
|
||||
2. Write verification results to `<session>/verify/verify-<num>.json`:
|
||||
- verify_id, pass_rate, iterations, passed, timestamp, regression_passed
|
||||
|
||||
3. Determine message type:
|
||||
|
||||
| Condition | Message Type |
|
||||
|-----------|--------------|
|
||||
| passRate >= 0.95 | verify_passed |
|
||||
| passRate < 0.95 && iterations >= MAX | fix_required |
|
||||
| passRate < 0.95 | verify_failed |
|
||||
|
||||
4. Update .msg/meta.json with test_patterns entry
|
||||
5. Write discoveries to wisdom/issues.md
|
||||
Reference in New Issue
Block a user