Add quality standards and team command design patterns documentation

- Introduced a new quality standards document outlining assessment criteria for team command .md files, including completeness, pattern compliance, integration, and consistency dimensions. - Established quality gates and issue classification for errors, warnings, and informational notes. - Created a comprehensive team command design patterns document detailing infrastructure and collaboration patterns, including message bus integration, YAML front matter requirements, task lifecycle, five-phase execution structure, and error handling. - Included a pattern selection guide for collaboration scenarios to enhance team interaction models.
2026-02-15 02:42:45 +08:00 · 2026-02-13 23:39:06 +08:00
parent 5ad7a954d4
commit cdb240d2c2
61 changed files with 5181 additions and 14525 deletions
--- a/.claude/skills/team-skill-designer/SKILL.md
+++ b/.claude/skills/team-skill-designer/SKILL.md
@@ -120,13 +120,13 @@ Phase 1 collects ALL roles at once (not one at a time):
 - Coordinator is always generated
 - Worker roles collected as a batch

-### Pattern 5: Spec Reference (No Duplication)
+### Pattern 5: Self-Contained Specs

-Design pattern specs are referenced from team-command-designer:
+Design pattern specs are included locally in `specs/`:
 ```
-specs → ../team-command-designer/specs/team-design-patterns.md
-specs → ../team-command-designer/specs/collaboration-patterns.md
-specs → ../team-command-designer/specs/quality-standards.md
+specs/team-design-patterns.md    # Infrastructure patterns (8) + collaboration index
+specs/collaboration-patterns.md  # 10 collaboration patterns with convergence control
+specs/quality-standards.md       # Quality criteria
 ```

 ---
@@ -139,9 +139,9 @@ specs → ../team-command-designer/specs/quality-standards.md

 | Document | Purpose | When |
 |----------|---------|------|
-| [../team-command-designer/specs/team-design-patterns.md](../team-command-designer/specs/team-design-patterns.md) | Infrastructure patterns (8) + collaboration index | **Must read** |
-| [../team-command-designer/specs/collaboration-patterns.md](../team-command-designer/specs/collaboration-patterns.md) | 10 collaboration patterns with convergence control | **Must read** |
-| [../team-command-designer/specs/quality-standards.md](../team-command-designer/specs/quality-standards.md) | Quality criteria | Must read before generation |
+| [specs/team-design-patterns.md](specs/team-design-patterns.md) | Infrastructure patterns (8) + collaboration index | **Must read** |
+| [specs/collaboration-patterns.md](specs/collaboration-patterns.md) | 10 collaboration patterns with convergence control | **Must read** |
+| [specs/quality-standards.md](specs/quality-standards.md) | Quality criteria | Must read before generation |

 ### Template Files (Must read before generation)

@@ -166,8 +166,8 @@ specs → ../team-command-designer/specs/quality-standards.md

 ```
 Phase 0: Specification Study (MANDATORY)
-   -> Read: ../team-command-designer/specs/team-design-patterns.md
-   -> Read: ../team-command-designer/specs/collaboration-patterns.md
+   -> Read: specs/team-design-patterns.md
+   -> Read: specs/collaboration-patterns.md
   -> Read: templates/skill-router-template.md + templates/role-template.md
   -> Read: 1-2 existing team commands for reference
   -> Output: Internalized requirements (in-memory)
--- a/.claude/skills/team-skill-designer/phases/01-requirements-collection.md
+++ b/.claude/skills/team-skill-designer/phases/01-requirements-collection.md
@@ -13,7 +13,7 @@ Collect team definition and ALL role definitions in one pass.
 ## Input

 - User request (`$ARGUMENTS` or interactive input)
- Specification: `../team-command-designer/specs/team-design-patterns.md` (read in Phase 0)
+- Specification: `specs/team-design-patterns.md` (read in Phase 0)

 ## Execution Steps

--- a/.claude/skills/team-skill-designer/phases/02-pattern-analysis.md
+++ b/.claude/skills/team-skill-designer/phases/02-pattern-analysis.md
@@ -12,7 +12,7 @@ Analyze applicable patterns for each role in the team.
 ## Input

 - Dependency: `team-config.json` (Phase 1)
- Specification: `../team-command-designer/specs/team-design-patterns.md` (read in Phase 0)
+- Specification: `specs/team-design-patterns.md` (read in Phase 0)

 ## Execution Steps

--- a/.claude/skills/team-skill-designer/phases/05-validation.md
+++ b/.claude/skills/team-skill-designer/phases/05-validation.md
@@ -12,7 +12,7 @@ Verify quality and deliver the final skill package.
 ## Input

 - Dependency: `{workDir}/preview/` (Phase 3), `integration-report.json` (Phase 4)
- Specification: `../team-command-designer/specs/quality-standards.md`
+- Specification: `specs/quality-standards.md`

 ## Execution Steps

--- a/.claude/skills/team-skill-designer/specs/collaboration-patterns.md
+++ b/.claude/skills/team-skill-designer/specs/collaboration-patterns.md
--- a/.claude/skills/team-skill-designer/specs/quality-standards.md
+++ b/.claude/skills/team-skill-designer/specs/quality-standards.md
@@ -0,0 +1,126 @@
+# Quality Standards for Team Commands
+
+Quality assessment criteria for generated team command .md files.
+
+## When to Use
+
+| Phase | Usage | Section |
+|-------|-------|---------|
+| Phase 5 | Score generated command | All dimensions |
+| Phase 3 | Guide generation quality | Checklist |
+
+---
+
+## Quality Dimensions
+
+### 1. Completeness (25%)
+
+| Score | Criteria |
+|-------|----------|
+| 100% | All 15 required sections present with substantive content |
+| 80% | 12+ sections present, minor gaps in non-critical areas |
+| 60% | Core sections present (front matter, message bus, 5 phases, error handling) |
+| 40% | Missing critical sections |
+| 0% | Skeleton only |
+
+**Required Sections Checklist:**
+- [ ] YAML front matter with `group: team`
+- [ ] Overview with core capabilities
+- [ ] Role Definition (name, responsibility, communication)
+- [ ] Message Bus section with team_msg examples
+- [ ] Message Types table
+- [ ] Execution Process overview diagram
+- [ ] Phase 1: Task Discovery implementation
+- [ ] Phase 2: Context Loading implementation
+- [ ] Phase 3: Core Work implementation
+- [ ] Phase 4: Validation/Summary implementation
+- [ ] Phase 5: Report + Loop implementation
+- [ ] Error Handling table
+- [ ] Code examples in all phases
+
+### 2. Pattern Compliance (25%)
+
+| Score | Criteria |
+|-------|----------|
+| 100% | All 8 infrastructure patterns + selected collaboration patterns fully implemented |
+| 80% | 6 core infra patterns + at least 1 collaboration pattern with convergence |
+| 60% | Minimum 6 infra patterns, collaboration patterns present but incomplete |
+| 40% | Missing critical patterns (message bus or task lifecycle) |
+| 0% | No pattern compliance |
+
+**Infrastructure Pattern Checklist:**
+- [ ] Pattern 1: Message bus - team_msg before every SendMessage
+- [ ] Pattern 1b: CLI fallback - `ccw team` CLI fallback section with parameter mapping
+- [ ] Pattern 2: YAML front matter - all fields present, group: team
+- [ ] Pattern 3: Task lifecycle - TaskList/Get/Update flow
+- [ ] Pattern 4: Five-phase structure - all 5 phases present
+- [ ] Pattern 5: Complexity-adaptive (if applicable)
+- [ ] Pattern 6: Coordinator spawn compatible
+- [ ] Pattern 7: Error handling table
+- [ ] Pattern 8: Session files (if applicable)
+
+**Collaboration Pattern Checklist:**
+- [ ] At least one CP selected (CP-1 minimum)
+- [ ] Each selected CP has convergence criteria defined
+- [ ] Each selected CP has feedback loop mechanism
+- [ ] Each selected CP has timeout/fallback behavior
+- [ ] CP-specific message types registered in message bus section
+- [ ] Escalation path defined (CP-5) for error scenarios
+
+### 3. Integration (25%)
+
+| Score | Criteria |
+|-------|----------|
+| 100% | All integration checks pass, spawn snippet ready |
+| 80% | Minor integration notes, no blocking issues |
+| 60% | Some checks need attention but functional |
+| 40% | Task prefix conflict or missing critical tools |
+| 0% | Incompatible with team system |
+
+### 4. Consistency (25%)
+
+| Score | Criteria |
+|-------|----------|
+| 100% | Role name, task prefix, message types consistent throughout |
+| 80% | Minor inconsistencies in non-critical areas |
+| 60% | Some mixed terminology but intent clear |
+| 40% | Confusing or contradictory content |
+| 0% | Internally inconsistent |
+
+---
+
+## Quality Gates
+
+| Gate | Threshold | Action |
+|------|-----------|--------|
+| PASS | >= 80% | Deliver to `.claude/commands/team/{team-name}/` |
+| REVIEW | 60-79% | Fix recommendations, re-validate |
+| FAIL | < 60% | Major rework needed, re-run from Phase 3 |
+
+---
+
+## Issue Classification
+
+### Errors (Must Fix)
+
+- Missing YAML front matter
+- Missing `group: team`
+- No message bus section
+- No task lifecycle (TaskList/Get/Update)
+- No SendMessage to coordinator
+- Task prefix conflicts with existing
+
+### Warnings (Should Fix)
+
+- Missing error handling table
+- Incomplete Phase implementation (skeleton only)
+- Missing team_msg before some SendMessage calls
+- Missing CLI fallback section (`### CLI 回退` with `ccw team` examples)
+- No complexity-adaptive routing when role is complex
+
+### Info (Nice to Have)
+
+- Code examples could be more detailed
+- Additional message type examples
+- Session file structure documentation
+- CLI integration examples
--- a/.claude/skills/team-skill-designer/specs/team-design-patterns.md
+++ b/.claude/skills/team-skill-designer/specs/team-design-patterns.md
@@ -0,0 +1,472 @@
+# Team Command Design Patterns
+
+> Extracted from 5 production team commands: coordinate, plan, execute, test, review
+> Extended with 10 collaboration patterns for diverse team interaction models
+
+---
+
+## Pattern Architecture
+
+```
+Team Design Patterns
+├── Section A: Infrastructure Patterns (8)    ← HOW to build a team command
+│   ├── Pattern 1: Message Bus Integration
+│   ├── Pattern 2: YAML Front Matter
+│   ├── Pattern 3: Task Lifecycle
+│   ├── Pattern 4: Five-Phase Execution
+│   ├── Pattern 5: Complexity-Adaptive Routing
+│   ├── Pattern 6: Coordinator Spawn Integration
+│   ├── Pattern 7: Error Handling Table
+│   └── Pattern 8: Session File Structure
+│
+└── Section B: Collaboration Patterns (10)    ← HOW agents interact
+    ├── CP-1: Linear Pipeline (线性流水线)
+    ├── CP-2: Review-Fix Cycle (审查修复循环)
+    ├── CP-3: Parallel Fan-out/Fan-in (并行扇出扇入)
+    ├── CP-4: Consensus Gate (共识门控)
+    ├── CP-5: Escalation Chain (逐级升级)
+    ├── CP-6: Incremental Delivery (增量交付)
+    ├── CP-7: Swarming (群策攻关)
+    ├── CP-8: Consulting/Advisory (咨询顾问)
+    ├── CP-9: Dual-Track (双轨并行)
+    └── CP-10: Post-Mortem (复盘回顾)
+```
+
+**Section B** collaboration patterns are documented in: [collaboration-patterns.md](collaboration-patterns.md)
+
+---
+
+## When to Use
+
+| Phase | Usage | Section |
+|-------|-------|---------|
+| Phase 0 | Understand all patterns before design | All sections |
+| Phase 2 | Select applicable infrastructure + collaboration patterns | Pattern catalog |
+| Phase 3 | Apply patterns during generation | Implementation details |
+| Phase 4 | Verify compliance | Checklists |
+
+---
+
+# Section A: Infrastructure Patterns
+
+## Pattern 1: Message Bus Integration
+
+Every teammate must use `mcp__ccw-tools__team_msg` for persistent logging before every `SendMessage`.
+
+### Structure
+
+```javascript
+// BEFORE every SendMessage, call:
+mcp__ccw-tools__team_msg({
+  operation: "log",
+  team: teamName,
+  from: "<role-name>",       // planner | executor | tester | <new-role>
+  to: "coordinator",
+  type: "<message-type>",
+  summary: "<human-readable summary>",
+  ref: "<optional file path>",
+  data: { /* optional structured payload */ }
+})
+```
+
+### Standard Message Types
+
+| Type | Direction | Trigger | Payload |
+|------|-----------|---------|---------|
+| `plan_ready` | planner -> coordinator | Plan generation complete | `{ taskCount, complexity }` |
+| `plan_approved` | coordinator -> planner | Plan reviewed | `{ approved: true }` |
+| `plan_revision` | planner -> coordinator | Plan modified per feedback | `{ changes }` |
+| `task_unblocked` | coordinator -> any | Dependency resolved | `{ taskId }` |
+| `impl_complete` | executor -> coordinator | Implementation done | `{ changedFiles, syntaxClean }` |
+| `impl_progress` | any -> coordinator | Progress update | `{ batch, total }` |
+| `test_result` | tester -> coordinator | Test cycle end | `{ passRate, iterations }` |
+| `review_result` | tester -> coordinator | Review done | `{ verdict, findings }` |
+| `fix_required` | any -> coordinator | Critical issues | `{ details[] }` |
+| `error` | any -> coordinator | Blocking error | `{ message }` |
+| `shutdown` | coordinator -> all | Team dissolved | `{}` |
+
+### Collaboration Pattern Message Types
+
+| Type | Used By | Direction | Trigger |
+|------|---------|-----------|---------|
+| `vote` | CP-4 Consensus | any -> coordinator | Agent casts vote on proposal |
+| `escalate` | CP-5 Escalation | any -> coordinator | Agent escalates unresolved issue |
+| `increment_ready` | CP-6 Incremental | executor -> coordinator | Increment delivered for validation |
+| `swarm_join` | CP-7 Swarming | any -> coordinator | Agent joins swarm on blocker |
+| `consult_request` | CP-8 Consulting | any -> specialist | Agent requests expert advice |
+| `consult_response` | CP-8 Consulting | specialist -> requester | Expert provides advice |
+| `sync_checkpoint` | CP-9 Dual-Track | any -> coordinator | Track reaches sync point |
+| `retro_finding` | CP-10 Post-Mortem | any -> coordinator | Retrospective insight |
+
+### Adding New Message Types
+
+When designing a new role, define role-specific message types following the convention:
+- `{action}_ready` - Work product ready for review
+- `{action}_complete` - Work phase finished
+- `{action}_progress` - Intermediate progress update
+
+### CLI Fallback
+
+When `mcp__ccw-tools__team_msg` MCP is unavailable, use `ccw team` CLI as equivalent fallback:
+
+```javascript
+// Fallback: Replace MCP call with Bash CLI (parameters map 1:1)
+Bash(`ccw team log --team "${teamName}" --from "<role>" --to "coordinator" --type "<type>" --summary "<summary>" [--ref <path>] [--data '<json>'] --json`)
+```
+
+**Parameter mapping**: `team_msg(params)` → `ccw team <operation> --team <team> [--from/--to/--type/--summary/--ref/--data/--id/--last] [--json]`
+
+**Coordinator** uses all 4 operations: `log`, `list`, `status`, `read`
+**Teammates** primarily use: `log`
+
+### Message Bus Section Template
+
+```markdown
+## 消息总线
+
+每次 SendMessage **前**，必须调用 `mcp__ccw-tools__team_msg` 记录消息：
+
+\`\`\`javascript
+mcp__ccw-tools__team_msg({ operation: "log", team: teamName, from: "<role>", to: "coordinator", type: "<type>", summary: "<summary>" })
+\`\`\`
+
+### 支持的 Message Types
+
+| Type | 方向 | 触发时机 | 说明 |
+|------|------|----------|------|
+| `<type>` | <role> → coordinator | <when> | <what> |
+
+### CLI 回退
+
+当 `mcp__ccw-tools__team_msg` MCP 不可用时，使用 `ccw team` CLI 作为等效回退：
+
+\`\`\`javascript
+// 回退: 将 MCP 调用替换为 Bash CLI（参数一一对应）
+Bash(\`ccw team log --team "${teamName}" --from "<role>" --to "coordinator" --type "<type>" --summary "<summary>" --json\`)
+\`\`\`
+
+**参数映射**: `team_msg(params)` → `ccw team log --team <team> --from <role> --to coordinator --type <type> --summary "<text>" [--ref <path>] [--data '<json>'] [--json]`
+```
+
+---
+
+## Pattern 2: YAML Front Matter
+
+Every team command file must start with standardized YAML front matter.
+
+### Structure
+
+```yaml
+---
+name: <command-name>
+description: Team <role> - <capabilities in Chinese>
+argument-hint: ""
+allowed-tools: SendMessage(*), TaskUpdate(*), TaskList(*), TaskGet(*), TodoWrite(*), Read(*), Write(*), Edit(*), Bash(*), Glob(*), Grep(*), Task(*)
+group: team
+---
+```
+
+### Field Rules
+
+| Field | Rule | Example |
+|-------|------|---------|
+| `name` | Lowercase, matches filename | `plan`, `execute`, `test` |
+| `description` | `Team <role> -` prefix + Chinese capability list | `Team planner - 多角度代码探索、结构化实现规划` |
+| `argument-hint` | Empty string for teammates, has hint for coordinator | `""` |
+| `allowed-tools` | Start with `SendMessage(*), TaskUpdate(*), TaskList(*), TaskGet(*)` | See each role |
+| `group` | Always `team` | `team` |
+
+### Minimum Tool Set (All Teammates)
+
+```
+SendMessage(*), TaskUpdate(*), TaskList(*), TaskGet(*), TodoWrite(*), Read(*), Bash(*), Glob(*), Grep(*)
+```
+
+### Role-Specific Additional Tools
+
+| Role Type | Additional Tools |
+|-----------|-----------------|
+| Read-only (reviewer, analyzer) | None extra |
+| Write-capable (executor, fixer) | `Write(*), Edit(*)` |
+| Agent-delegating (planner, executor) | `Task(*)` |
+
+---
+
+## Pattern 3: Task Lifecycle
+
+All teammates follow the same task discovery and lifecycle pattern.
+
+### Standard Flow
+
+```javascript
+// Step 1: Find my tasks
+const tasks = TaskList()
+const myTasks = tasks.filter(t =>
+  t.subject.startsWith('<PREFIX>-') &&  // PLAN-*, IMPL-*, TEST-*, REVIEW-*
+  t.owner === '<role-name>' &&
+  t.status === 'pending' &&
+  t.blockedBy.length === 0              // Not blocked
+)
+
+// Step 2: No tasks -> idle
+if (myTasks.length === 0) return
+
+// Step 3: Claim task (lowest ID first)
+const task = TaskGet({ taskId: myTasks[0].id })
+TaskUpdate({ taskId: task.id, status: 'in_progress' })
+
+// Step 4: Execute work
+// ... role-specific logic ...
+
+// Step 5: Complete and loop
+TaskUpdate({ taskId: task.id, status: 'completed' })
+
+// Step 6: Check for next task
+const nextTasks = TaskList().filter(t =>
+  t.subject.startsWith('<PREFIX>-') &&
+  t.owner === '<role-name>' &&
+  t.status === 'pending' &&
+  t.blockedBy.length === 0
+)
+if (nextTasks.length > 0) {
+  // Continue with next task -> back to Step 3
+}
+```
+
+### Task Prefix Convention
+
+| Prefix | Role | Example |
+|--------|------|---------|
+| `PLAN-` | planner | `PLAN-001: Explore and plan implementation` |
+| `IMPL-` | executor | `IMPL-001: Implement approved plan` |
+| `TEST-` | tester | `TEST-001: Test-fix cycle` |
+| `REVIEW-` | tester | `REVIEW-001: Code review and requirement verification` |
+| `<NEW>-` | new role | Must be unique, uppercase, hyphen-suffixed |
+
+### Task Chain (defined in coordinate.md)
+
+```
+PLAN-001 → IMPL-001 → TEST-001 + REVIEW-001
+         ↑ blockedBy    ↑ blockedBy
+```
+
+---
+
+## Pattern 4: Five-Phase Execution Structure
+
+Every team command follows a consistent 5-phase internal structure.
+
+### Standard Phases
+
+| Phase | Purpose | Common Actions |
+|-------|---------|----------------|
+| Phase 1: Task Discovery | Find and claim assigned tasks | TaskList, TaskGet, TaskUpdate |
+| Phase 2: Context Loading | Load necessary context for work | Read plan/config, detect framework |
+| Phase 3: Core Work | Execute primary responsibility | Role-specific logic |
+| Phase 4: Validation/Summary | Verify work quality | Syntax check, criteria verification |
+| Phase 5: Report + Loop | Report to coordinator, check next | SendMessage, TaskUpdate, TaskList |
+
+### Phase Structure Template
+
+```markdown
+### Phase N: <Phase Name>
+
+\`\`\`javascript
+// Implementation code
+\`\`\`
+```
+
+---
+
+## Pattern 5: Complexity-Adaptive Routing
+
+All roles that process varying-difficulty tasks should implement adaptive routing.
+
+### Decision Logic
+
+```javascript
+function assessComplexity(description) {
+  let score = 0
+  if (/refactor|architect|restructure|module|system/.test(description)) score += 2
+  if (/multiple|across|cross/.test(description)) score += 2
+  if (/integrate|api|database/.test(description)) score += 1
+  if (/security|performance/.test(description)) score += 1
+  return score >= 4 ? 'High' : score >= 2 ? 'Medium' : 'Low'
+}
+```
+
+### Routing Table
+
+| Complexity | Direct Claude | CLI Agent | Sub-agent |
+|------------|---------------|-----------|-----------|
+| Low | Direct execution | - | - |
+| Medium | - | `cli-explore-agent` / `cli-lite-planning-agent` | - |
+| High | - | CLI agent | `code-developer` / `universal-executor` |
+
+### Sub-agent Delegation Pattern
+
+```javascript
+Task({
+  subagent_type: "<agent-type>",
+  run_in_background: false,
+  description: "<brief description>",
+  prompt: `
+## Task Objective
+${taskDescription}
+
+## Output Location
+${sessionFolder}/${outputFile}
+
+## MANDATORY FIRST STEPS
+1. Read: .workflow/project-tech.json (if exists)
+2. Read: .workflow/project-guidelines.json (if exists)
+
+## Expected Output
+${expectedFormat}
+`
+})
+```
+
+---
+
+## Pattern 6: Coordinator Spawn Integration
+
+New teammates must be spawnable from coordinate.md using standard pattern.
+
+### Skill Path Format (Folder-Based)
+
+Team commands use folder-based organization with colon-separated skill paths:
+
+```
+File location:  .claude/commands/team/{team-name}/{role-name}.md
+Skill path:     team:{team-name}:{role-name}
+
+Example:
+  .claude/commands/team/spec/analyst.md  →  team:spec:analyst
+  .claude/commands/team/security/scanner.md  →  team:security:scanner
+```
+
+### Spawn Template
+
+```javascript
+Task({
+  subagent_type: "general-purpose",
+  team_name: teamName,
+  name: "<role-name>",
+  prompt: `You are team "${teamName}" <ROLE>.
+
+When you receive <PREFIX>-* tasks, call Skill(skill="team:${teamName}:<role-name>") to execute.
+
+Current requirement: ${taskDescription}
+Constraints: ${constraints}
+
+## Message Bus (Required)
+Before each SendMessage, call mcp__ccw-tools__team_msg:
+mcp__ccw-tools__team_msg({ operation: "log", team: "${teamName}", from: "<role>", to: "coordinator", type: "<type>", summary: "<summary>" })
+
+Workflow:
+1. TaskList -> find <PREFIX>-* tasks assigned to you
+2. Skill(skill="team:${teamName}:<role-name>") to execute
+3. team_msg log + SendMessage results to coordinator
+4. TaskUpdate completed -> check next task`
+})
+```
+
+---
+
+## Pattern 7: Error Handling Table
+
+Every command ends with a standardized error handling table.
+
+### Template
+
+```markdown
+## Error Handling
+
+| Scenario | Resolution |
+|----------|------------|
+| No tasks available | Idle, wait for coordinator assignment |
+| Plan/Context file not found | Notify coordinator, request location |
+| Sub-agent failure | Retry once, then fallback to direct execution |
+| Max iterations exceeded | Report to coordinator, suggest intervention |
+| Critical issue beyond scope | SendMessage fix_required to coordinator |
+```
+
+---
+
+## Pattern 8: Session File Structure
+
+Roles that produce artifacts follow standard session directory patterns.
+
+### Convention
+
+```
+.workflow/.team-<purpose>/{identifier}-{YYYY-MM-DD}/
+├── <work-product-files>
+├── manifest.json (if multiple outputs)
+└── .task/ (if generating task files)
+    ├── TASK-001.json
+    └── TASK-002.json
+```
+
+---
+
+# Section B: Collaboration Patterns
+
+> Complete specification: [collaboration-patterns.md](collaboration-patterns.md)
+
+## Collaboration Pattern Quick Reference
+
+Every collaboration pattern has these standard elements:
+
+| Element | Description |
+|---------|-------------|
+| **Entry Condition** | When to activate this pattern |
+| **Workflow** | Step-by-step execution flow |
+| **Convergence Criteria** | How the pattern terminates successfully |
+| **Feedback Loop** | How information flows back to enable correction |
+| **Timeout/Fallback** | What happens when the pattern doesn't converge |
+| **Max Iterations** | Hard limit on cycles (where applicable) |
+
+### Pattern Selection Guide
+
+| Scenario | Recommended Pattern | Why |
+|----------|-------------------|-----|
+| Standard feature development | CP-1: Linear Pipeline | Well-defined sequential stages |
+| Code review with fixes needed | CP-2: Review-Fix Cycle | Iterative improvement until quality met |
+| Multi-angle analysis needed | CP-3: Fan-out/Fan-in | Parallel exploration, aggregated results |
+| Critical decision (architecture, security) | CP-4: Consensus Gate | Multiple perspectives before committing |
+| Agent stuck / self-repair failed | CP-5: Escalation Chain | Progressive expertise levels |
+| Large feature (many files) | CP-6: Incremental Delivery | Validated increments reduce risk |
+| Blocking issue stalls pipeline | CP-7: Swarming | All resources on one problem |
+| Domain-specific expertise needed | CP-8: Consulting | Expert advice without role change |
+| Design + Implementation parallel | CP-9: Dual-Track | Faster delivery with sync checkpoints |
+| Post-completion learning | CP-10: Post-Mortem | Capture insights for future improvement |
+
+---
+
+## Pattern Summary Checklist
+
+When designing a new team command, verify:
+
+### Infrastructure Patterns
+- [ ] YAML front matter with `group: team`
+- [ ] Message bus section with `team_msg` logging
+- [ ] CLI fallback section with `ccw team` CLI examples and parameter mapping
+- [ ] Role-specific message types defined
+- [ ] Task lifecycle: TaskList -> TaskGet -> TaskUpdate flow
+- [ ] Unique task prefix (no collision with existing PLAN/IMPL/TEST/REVIEW, scan `team/**/*.md`)
+- [ ] 5-phase execution structure
+- [ ] Complexity-adaptive routing (if applicable)
+- [ ] Coordinator spawn template integration
+- [ ] Error handling table
+- [ ] SendMessage communication to coordinator only
+- [ ] Session file structure (if producing artifacts)
+
+### Collaboration Patterns
+- [ ] At least one collaboration pattern selected
+- [ ] Convergence criteria defined (max iterations / quality gate / timeout)
+- [ ] Feedback loop implemented (how results flow back)
+- [ ] Timeout/fallback behavior specified
+- [ ] Pattern-specific message types registered
+- [ ] Coordinator aware of pattern (can route messages accordingly)