组件与UI设计技能 (component-design) 是做什么的？
一个结构化的UX/UI发现和规范工作流，用于设计Web和应用程序组件、区块和页面。生成可供视觉原型设计工具（如 stitch-design ）和代码实施工作流使用的生产级设计规范（design-spec.md）。
护栏与核心原则
[!IMPORTANT] 1. 零编码护栏（纯设计范围）：本技能严格关注UX、UI、布局架构、排版和视觉令牌。绝不输出React组件、Next.js指令、TypeScript prop接口或包安装命令（无shadcn/Radix CLI命令）。代码实施由下游开发工作流处理。
[!CAUTION] 2. 设计令牌前提门（令牌优先规则）：没有经过验证的规范性设计令牌在
docs/project.json中，任何组件都不能被设计。缺失的令牌必须在起草组件设计之前进行打磨和持久化。请参阅 token-verification-matrix.md。
[!TIP] 3. 令牌守恒规则（禁止在技能内直接生成图像）：绝不要直接调用
generate_image。为用户制定结构化的图像生成提示，由用户生成并放入项目目录。
[!NOTE] 4. 选择性模式查找（令牌守恒）：检查
references/component-design-patterns.md中的路由表，并只加载references/patterns/下匹配的组件文件（例如hero.md）。如果匹配，在自适应访谈中追问用户是否希望实现该模式。
工作流概览
flowchart TD
Start["调用 /component-design<br/>(页面 + 组件名称)"] --> Step1["步骤1：动态上下文与令牌门<br/>(扫描 docs/**, CONTEXT.md、令牌及目标模式)"]
Step1 --> CheckTokens{"docs/project.json中的<br/>设计令牌是否完整？"}
CheckTokens -- "令牌缺失" --> GrillTokens["打磨缺失令牌<br/>(3个上下文驱动的选项)"]
GrillTokens --> SaveTokens["持久化到 docs/project.json"]
SaveTokens --> Step2
CheckTokens -- "已验证" --> Step2["步骤2：多轮自适应打磨<br/>(第1-3轮 + 目标模式打磨)"]
Step2 --> Step3["步骤3：视觉资产提示制定<br/>(提供立即可用的图像提示)"]
Step3 --> Step4["步骤4：搭建并编写 design-spec.md<br/>(docs/design/components/[page]/[component]/)"]
Step4 --> Step5["步骤5：子代理审计与自动修复<br/>(invoke_subagent 检查护栏与令牌)"]
Step5 --> Finish["规范准备就绪，可向下游移交<br/>(视觉原型制作 / 实施)"]
执行运行手册
步骤1：动态上下文发现与设计令牌验证门
- 扫描项目上下文：动态检查
docs/和根目录CONTEXT.md中的所有文件，以提取目标用户画像、业务目标和现有设计书签。 - 扫描支持的语言环境：读取
docs/project.json中的project_context_and_metadata.supported_languages。 - 验证设计令牌：根据 token-verification-matrix.md 审查
docs/project.json中的"design_system"。 - 打磨缺失令牌：如果令牌缺失，制定3个针对项目的选项（其中一个标记为
(推荐)），询问用户，并将其持久化到"design_system"下。 - 目标设计模式查找：扫描
references/component-design-patterns.md中的路由表，并且如果存在与正在设计的组件匹配的模式，则只查看references/patterns/下特定的组件模式文件。
步骤2：渐进式多轮组件打磨
使用 ask_question（或交互式聊天）执行自适应3轮访谈，在每轮之间暂停以接收用户答案。关于完整的提问表述，请参阅 adaptive-grilling-rounds.md：
- 如果在
references/patterns/中找到了匹配的模式，将其问卷纳入第1轮或第2轮，明确询问用户是否希望实现该模式。 - 第1轮（意图与故事）：明确组件目的、用户待完成的任务以及情感基调。
- 第2轮（空间层次与网格）：根据第1轮的回复，定制多列布局、密度比例和焦点视线流。
- 第3轮（交互与强调）：根据第1轮和第2轮的结果，建立悬停/焦点状态动态、媒体资产以及双向（BiDi）/从右到左（RTL）细节。
步骤3：主动式视觉资产提示制定
如果组件需要定制图形、背景或图标，为用户制定结构化的生成提示，而不是调用 generate_image。提示块格式请参阅 adaptive-grilling-rounds.md。
步骤4：搭建组件文件夹与 design-spec.md
- 创建目录：
docs/design/components/[页面名称]/[组件名称]/ - 使用 design-spec.template.md 中的规范性9部分布局搭建
design-spec.md：- §1 执行摘要与故事
- §2 视觉层次与空间流
- §3 布局网格与响应式断点（移动端、平板、桌面端）
- §4 设计令牌与颜色映射（浅色与深色）
- §5 排版缩放（每个支持的语言环境）
- §6 交互状态矩阵（默认、悬停、激活、焦点、禁用、骨架屏）
- §7 双向（RTL）适配
- §8 可访问性与人机工程学（WCAG AA/AAA，触摸目标 $≥ 44\text{px}$）
- §9 推荐的视觉资产与提示
步骤5：独立子代理质量审计 (invoke_subagent)
为了保证无偏的质量，在向用户展示结果之前，调用一个独立的评审子代理：
- 生成审计子代理（
TypeName: "self"，Role: "Independent Design & UX Auditor"，Model: "inherit"）。 - 使用 subagent-audit-protocol.md 中的结构化审计提示。
- 如果
ISSUES_FOUND，在得出结论之前立即解决design-spec.md中所有标记的问题。
下游移交
一旦 design-spec.md 获得批准并验证：
- 视觉原型制作：触发
stitch-design以在Google Stitch中生成UI屏幕和布局变体。 - 代码实施：将
design-spec.md提供给组件实施技能（例如nextjs-component-dev/nextjs-create-component）。
执行验证清单
在完成执行之前，确认：
- 交付物中不存在代码或库安装命令（无React、Next.js、shadcn CLI）。
-
docs/project.json中的规范性设计令牌已验证且完整。 - 输出目录结构为
docs/design/components/[页面]/[组件]/。 - 打磨选项是动态合成的，没有硬编码的仓库假设。
- 组件打磨遵循了渐进式自适应轮次。
- 未直接调用
generate_image；资产提示已提供给用户。 -
design-spec.md包含所有9个必需的章节。 - 已通过
invoke_subagent调用独立子代理审计，并且所有问题已解决。