name: 团队界面设计 description: UI设计团队的统一团队技能。所有角色通过–role参数调用此技能以执行特定角色任务。CP-9双轨设计+实现。 allowed-tools: TeamCreate(), TeamDelete(), SendMessage(), TaskCreate(), TaskUpdate(), TaskList(), TaskGet(), Task(), AskUserQuestion(), TodoWrite(), Read(), Write(), Edit(), Bash(), Glob(), Grep(), WebFetch(), WebSearch()

团队UI设计

用于UI设计的统一团队技能，涵盖设计系统分析、令牌定义、组件规格、可访问性审计和代码实现。所有团队成员通过--role=xxx调用此技能以路由到角色特定执行。

架构概览

┌─────────────────────────────────────────────────┐
│  技能(skill="团队界面设计", args="--role=xxx")  │
└───────────────────┬─────────────────────────────┘
                    │ 角色路由器
    ┌───────┬───────┼───────┬───────┐
    ↓       ↓       ↓       ↓       ↓
┌──────────┐┌──────────┐┌──────────┐┌──────────┐┌──────────┐
│协调员││研究员││设计师││审查员││实现者│
│ roles/   ││ roles/   ││ roles/   ││ roles/   ││ roles/    │
└──────────┘└──────────┘└──────────┘└──────────┘└───────────┘

角色路由器

输入解析

解析$ARGUMENTS以提取--role:

const args = "$ARGUMENTS"
const roleMatch = args.match(/--role[=\s]+(\w+)/)

if (!roleMatch) {
  throw new Error("缺少--role参数。可用角色: coordinator, researcher, designer, reviewer, implementer")
}

const role = roleMatch[1]
const teamName = args.match(/--team[=\s]+([\w-]+)/)?.[1] || "uidesign"

角色分发

const VALID_ROLES = {
  "coordinator":  { file: "roles/coordinator.md",  prefix: null },
  "researcher":   { file: "roles/researcher.md",   prefix: "RESEARCH" },
  "designer":     { file: "roles/designer.md",     prefix: "DESIGN" },
  "reviewer":     { file: "roles/reviewer.md",     prefix: "AUDIT" },
  "implementer":  { file: "roles/implementer.md",  prefix: "BUILD" }
}

if (!VALID_ROLES[role]) {
  throw new Error(`未知角色: ${role}。可用: ${Object.keys(VALID_ROLES).join(', ')}`)
}

// 读取并执行角色特定逻辑
Read(VALID_ROLES[role].file)
// → 执行该文件中定义的5阶段流程

可用角色

角色	任务前缀	责任	角色文件
`coordinator`	N/A	范围评估、双轨协调、同步点管理	roles/coordinator.md
`researcher`	RESEARCH-*	设计系统分析、组件清单、可访问性审计	roles/researcher.md
`designer`	DESIGN-*	设计令牌定义、组件规格、布局设计	roles/designer.md
`reviewer`	AUDIT-*	设计一致性、可访问性合规性、视觉审计	roles/reviewer.md
`implementer`	BUILD-*	组件代码实现、CSS生成、设计令牌消费	roles/implementer.md

共享基础设施

角色隔离规则

核心原则: 每个角色仅能执行自己职责范围内的工作。

输出标记（强制）

所有角色的输出必须带[role_name]标识前缀：

SendMessage({
  content: `## [${role}] ...`,
  summary: `[${role}] ...`
})

mcp__ccw-tools__team_msg({
  summary: `[${role}] ...`
})

协调员隔离

允许	禁止
需求澄清 (AskUserQuestion)	❌ 直接编写/修改代码
创建任务链 (TaskCreate)	❌ 调用实现类子代理
分发任务给工作者	❌ 直接执行分析/测试/审查
监控进度 (消息总线)	❌ 绕过工作者自行完成任务
汇报结果给用户	❌ 修改源代码或产物文件

工作者隔离

允许	禁止
处理自己前缀的任务	❌ 处理其他角色前缀的任务
SendMessage给协调员	❌ 直接与其他工作者通信
使用工具箱中声明的工具	❌ 为其他角色创建任务 (TaskCreate)

消息总线（所有角色）

每次SendMessage之前，必须调用mcp__ccw-tools__team_msg记录：

mcp__ccw-tools__team_msg({
  operation: "log",
  team: teamName,
  from: role,
  to: "coordinator",
  type: "<type>",
  summary: `[${role}] <summary>`,
  ref: "<file_path>"
})

按角色的消息类型:

角色	类型
coordinator	`task_unblocked`, `sync_checkpoint`, `fix_required`, `error`, `shutdown`
researcher	`research_ready`, `research_progress`, `error`
designer	`design_ready`, `design_revision`, `design_progress`, `error`
reviewer	`audit_result`, `audit_passed`, `fix_required`, `error`
implementer	`build_complete`, `build_progress`, `error`

CLI备用方案

当mcp__ccw-tools__team_msg MCP不可用时：

Bash(`ccw team log --team "${teamName}" --from "${role}" --to "coordinator" --type "<type>" --summary "<summary>" --json`)

任务生命周期（所有工作者角色）

// 标准任务生命周期，每个工作者角色遵循
// 阶段1: 发现
const tasks = TaskList()
const myTasks = tasks.filter(t =>
  t.subject.startsWith(`${VALID_ROLES[role].prefix}-`) &&
  t.owner === role &&
  t.status === 'pending' &&
  t.blockedBy.length === 0
)
if (myTasks.length === 0) return // 空闲
const task = TaskGet({ taskId: myTasks[0].id })
TaskUpdate({ taskId: task.id, status: 'in_progress' })

// 阶段2-4: 角色特定（见roles/{role}.md）

// 阶段5: 报告+循环 — 所有输出必须带[role]标识
mcp__ccw-tools__team_msg({ operation: "log", team: teamName, from: role, to: "coordinator", type: "...", summary: `[${role}] ...` })
SendMessage({ type: "message", recipient: "coordinator", content: `## [${role}] ...`, summary: `[${role}] ...` })
TaskUpdate({ taskId: task.id, status: 'completed' })
// 检查下一个任务 → 回到阶段1

三管道架构

CP-9双轨概念

轨道A (设计):     RESEARCH → DESIGN(令牌) → DESIGN(组件) → ...
                                      │                    │
                            同步点1          同步点2
                                      │                    │
轨道B (构建):              BUILD(令牌) ──→ BUILD(组件) → ...

设计和实现在同步点后并行进行。每个同步点验证设计工件是否足够稳定以供实现消费。

管道模式

component (单组件):
  RESEARCH-001 → DESIGN-001 → AUDIT-001 → BUILD-001

system (设计系统 - 双轨):
  轨道A: RESEARCH-001 → DESIGN-001(令牌) → DESIGN-002(组件)
  同步点1: AUDIT-001 (令牌审查)
  轨道B: BUILD-001(令牌, blockedBy AUDIT-001) ∥ DESIGN-002(组件)
  同步点2: AUDIT-002 (组件审查)
  轨道B: BUILD-002(组件, blockedBy AUDIT-002)

full-system (完整设计系统):
  RESEARCH-001 → DESIGN-001(令牌) → AUDIT-001
  → [DESIGN-002(组件) + BUILD-001(令牌)](并行, blockedBy AUDIT-001)
  → AUDIT-002 → BUILD-002(组件) → AUDIT-003(最终)

生成器-批评家循环

designer ↔ reviewer循环，确保设计一致性和可访问性：

┌──────────┐     设计工件     ┌──────────┐
│ 设计师   │ ──────────────────────→  │ 审查员   │
│(生成器)  │                         │ (批评家)  │
│          │  ←────────────────────── │           │
└──────────┘   审计反馈         └──────────┘
                (最多2轮)

收敛条件: audit.score >= 8 && audit.critical_count === 0

共享内存

{
  "design_intelligence": {},
  "design_token_registry": {
    "colors": {}, "typography": {}, "spacing": {}, "shadows": {}, "borders": {}
  },
  "style_decisions": [],
  "component_inventory": [],
  "accessibility_patterns": [],
  "audit_history": [],
  "industry_context": { "industry": "", "config": {}, "detected_stack": "" }
}

每个角色在阶段2读取，阶段5写入自己负责的字段。

设计智能 (ui-ux-pro-max)

研究员通过Skill(skill="ui-ux-pro-max", args="...")获取设计智能，写入design-intelligence.json，下游角色消费：

研究员 (流4)
  │ Skill("ui-ux-pro-max", args="<industry> <keywords> --design-system")
  │ Skill("ui-ux-pro-max", args="accessibility animation responsive --domain ux")
  │ Skill("ui-ux-pro-max", args="<keywords> --stack <detected-stack>")
  ↓
design-intelligence.json
  ├─→ 设计师: 推荐颜色/排版/样式 → 令牌值、反模式 → 组件规格
  ├─→ 审查员: 反模式 → 行业合规审计维度 (20%权重)
  └─→ 实现者: 堆栈指南 → 代码生成、反模式 → 验证

数据流:

design_system.colors/typography/style → 设计师用于令牌默认值（推荐优先模式）
recommendations.anti_patterns[] → 审查员审查合规性，设计师/实现者避免违反
stack_guidelines → 实现者代码生成约束
ux_guidelines[] → 设计师组件规格中的实现提示

降级策略: 当ui-ux-pro-max不可用时，使用LLM通用知识生成默认值，_source标记为"llm-general-knowledge"。

会话目录

.workflow/.team/UDS-{slug}-{YYYY-MM-DD}/
├── team-session.json           # 会话状态
├── shared-memory.json          # 跨角色累积知识
├── research/                   # 研究员输出
│   ├── design-system-analysis.json
│   ├── component-inventory.json
│   ├── accessibility-audit.json
│   ├── design-intelligence.json       # ui-ux-pro-max设计智能
│   └── design-intelligence-raw.md     # ui-ux-pro-max原始输出
├── design/                     # 设计师输出
│   ├── design-tokens.json
│   ├── component-specs/
│   │   └── {component-name}.md
│   └── layout-specs/
│       └── {layout-name}.md
├── audit/                      # 审查员输出
│   └── audit-{NNN}.md
└── build/                      # 实现者输出
    ├── token-files/
    └── component-files/

协调员生成模板

当协调员创建队友时：

TeamCreate({ team_name: teamName })

// 研究员
Task({
  subagent_type: "general-purpose",
  team_name: teamName,
  name: "researcher",
  prompt: `你是team "${teamName}"的研究员。
当你收到RESEARCH-*任务时，调用Skill(skill="团队界面设计", args="--role=researcher")执行。
当前需求: ${taskDescription}
约束: ${constraints}
会话: ${sessionFolder}

## 角色准则（强制）
- 你只能处理RESEARCH-*前缀的任务
- 所有输出必须带[researcher]标识前缀
- 仅与协调员通信

## 消息总线（必须）
每次SendMessage前，先调用mcp__ccw-tools__team_msg记录。

工作流程:
1. TaskList → 找到RESEARCH-*任务
2. Skill(skill="团队界面设计", args="--role=researcher")执行
3. team_msg log + SendMessage结果给协调员
4. TaskUpdate completed → 检查下一个任务`
})

// 设计师
Task({
  subagent_type: "general-purpose",
  team_name: teamName,
  name: "designer",
  prompt: `你是team "${teamName}"的设计师。
当你收到DESIGN-*任务时，调用Skill(skill="团队界面设计", args="--role=designer")执行。
当前需求: ${taskDescription}
会话: ${sessionFolder}

## 角色准则（强制）
- 你只能处理DESIGN-*前缀的任务
- 所有输出必须带[designer]标识前缀
- 仅与协调员通信

## 消息总线（必须）
每次SendMessage前，先调用mcp__ccw-tools__team_msg记录。

工作流程:
1. TaskList → 找到DESIGN-*任务
2. Skill(skill="团队界面设计", args="--role=designer")执行
3. team_msg log + SendMessage结果给协调员
4. TaskUpdate completed → 检查下一个任务`
})

// 审查员 (AUDIT)
Task({
  subagent_type: "general-purpose",
  team_name: teamName,
  name: "reviewer",
  prompt: `你是team "${teamName}"的审查员。
当你收到AUDIT-*任务时，调用Skill(skill="团队界面设计", args="--role=reviewer")执行。
当前需求: ${taskDescription}
会话: ${sessionFolder}

## 角色准则（强制）
- 你只能处理AUDIT-*前缀的任务
- 所有输出必须带[reviewer]标识前缀
- 仅与协调员通信

## 消息总线（必须）
每次SendMessage前，先调用mcp__ccw-tools__team_msg记录。

工作流程:
1. TaskList → 找到AUDIT-*任务
2. Skill(skill="团队界面设计", args="--role=reviewer")执行
3. team_msg log + SendMessage结果给协调员
4. TaskUpdate completed → 检查下一个任务`
})

// 实现者 (BUILD)
Task({
  subagent_type: "general-purpose",
  team_name: teamName,
  name: "implementer",
  prompt: `你是team "${teamName}"的实现者。
当你收到BUILD-*任务时，调用Skill(skill="团队界面设计", args="--role=implementer")执行。
当前需求: ${taskDescription}
会话: ${sessionFolder}

## 角色准则（强制）
- 你只能处理BUILD-*前缀的任务
- 所有输出必须带[implementer]标识前缀
- 仅与协调员通信

## 消息总线（必须）
每次SendMessage前，先调用mcp__ccw-tools__team_msg记录。

工作流程:
1. TaskList → 找到BUILD-*任务
2. Skill(skill="团队界面设计", args="--role=implementer")执行
3. team_msg log + SendMessage结果给协调员
4. TaskUpdate completed → 检查下一个任务`
})

错误处理

场景	解决方案
未知–role值	错误并列出可用角色列表
缺少–role参数	错误并提示用法
角色文件未找到	错误并显示预期路径
AUDIT分数<6超过2轮GC	协调员上报用户
双轨同步失败	回退到单轨顺序执行
设计令牌冲突	审查员仲裁，协调员介入
BUILD找不到设计文件	等待同步点或上报
ui-ux-pro-max不可用	降级为LLM通用知识，`_source: "llm-general-knowledge"`
行业反模式检查失败	审查员标记行业合规维度为N/A