Back to Details

pds

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Pencil Design System Generator

Pencil设计系统生成器

Generate a complete, Mews-inspired design system in a Pencil 
.pen
file. Research the business domain, create ~60 themed tokens, build visual foundation documentation, ~25 reusable components organized by category, and composition patterns — all from a single command like 
/pds coffee shop that sells coffee online
. Domain screens are generated only if the user explicitly requests them.
在Pencil的
.pen
文件中生成一套完整的、受Mews启发的设计系统。只需输入一条命令，比如
/pds 在线销售咖啡的咖啡店
，即可完成业务领域调研、创建约60个主题化设计令牌、构建视觉基础文档、整理约25个按分类组织的可复用组件，以及设计组合模式。仅当用户明确要求时，才会生成领域相关页面。

Getting Started

快速开始

When this skill is invoked via 
/pds
, begin with:
  1. Parse the user's input — extract domain, brand name, color preferences, font preferences from their message after 
    /pds
  2. Greet and confirm — show what was understood and what will be built:
Pencil Design System Generator

Domain: [extracted domain]
Brand:  [extracted name or "unnamed"]
Colors: [extracted preferences or "will research"]
Fonts:  [extracted preferences or "will research"]

I'll build this step by step:
 1. Research    -> design brief
 2. Tokens      -> ~64 themed variables (light + dark)
 3. Foundations  -> visual documentation
 4. Components  -> ~25 reusable parts
 5. Patterns    -> 4 composition showcases

Each step pauses for your review. Type:
  c  to continue
  r  to redo (tell me what to change)
  s  to skip ahead to final verification

Want screens too? Tell me now or add them later.

Starting with domain research...
  1. Proceed to Phase 1 immediately — the first review pause comes after the design brief is ready.
当通过
/pds
调用该技能时，按以下步骤开始：
  1. 解析用户输入 — 从
    /pds
    后的消息中提取业务领域、品牌名称、颜色偏好、字体偏好
  2. 问候并确认 — 展示已理解的信息及将要构建的内容：
Pencil Design System Generator

Domain: [extracted domain]
Brand:  [extracted name or "unnamed"]
Colors: [extracted preferences or "will research"]
Fonts:  [extracted preferences or "will research"]

I'll build this step by step:
 1. Research    -> design brief
 2. Tokens      -> ~64 themed variables (light + dark)
 3. Foundations  -> visual documentation
 4. Components  -> ~25 reusable parts
 5. Patterns    -> 4 composition showcases

Each step pauses for your review. Type:
  c  to continue
  r  to redo (tell me what to change)
  s  to skip ahead to final verification

Want screens too? Tell me now or add them later.

Starting with domain research...
  1. 立即进入第一阶段 — 设计 brief 完成后进入首次审核暂停环节。

Input

输入说明

The user provides a business domain (e.g., "bakery", "fitness app", "SaaS dashboard"). Optional extras: brand name, color preferences, font preferences, specific screens wanted, light/dark theme preference. If the user gives only a domain, infer everything else from research.
If the user specifies colors or fonts: Use their values as the primary/accent/background tokens in Phase 3 and derive the remaining palette around them (secondary, muted, foregrounds). Research still runs to fill in gaps, but user preferences take priority over both research and fallback tables.
用户需提供业务领域（例如："面包店"、"健身应用"、"SaaS仪表盘"）。可额外提供：品牌名称、颜色偏好、字体偏好、所需特定页面、亮色/暗色主题偏好。若用户仅提供领域，则通过调研推导其他所有内容。
若用户指定颜色或字体： 在第三阶段将其值用作主要/强调/背景令牌，并围绕这些值推导其余调色板（次要、柔和、前景色）。仍会通过调研填补空白，但用户优先级高于调研结果和备用表格。

Canvas Organization

画布布局

The canvas is laid out left-to-right in three core sections (always created), plus an optional screens section:
[Foundations 1440×2400] → 100px gap → [Components 1440×2400] → 100px gap → [Patterns 1440×1800] → (optional) [Screens →]
  • Foundations — Visual documentation: color palette swatches, typography specimens, spacing scale, elevation examples, border radius showcase.
  • Components — All ~25 reusable components, organized under category sub-frames (Buttons, Inputs, Typography, Badges, Alerts, Cards, Navigation, Tables, etc.).
  • Patterns — Composition showcases: form pattern, data display pattern, navigation pattern, card layout pattern. Each uses component refs to demonstrate real usage.
  • Screens (only if user requests) — 3–5 domain-relevant screens placed to the right of Patterns.
No components live at the document root except these section frames and the optional navigation index.
画布从左到右分为三个核心区域（必创建），外加一个可选页面区域：
[Foundations 1440×2400] → 100px gap → [Components 1440×2400] → 100px gap → [Patterns 1440×1800] → (optional) [Screens →]
  • 基础规范区 — 视觉文档：调色板样本、字体示例、间距尺度、层级阴影示例、圆角展示。
  • 组件区 — 约25个可复用组件，按分类子框架组织（按钮、输入框、排版、徽章、提示框、卡片、导航、表格等）。
  • 设计模式区 — 组合展示：表单模式、数据展示模式、导航模式、卡片布局模式。所有展示均使用组件引用以演示实际用法。
  • 页面区（仅用户请求时创建） — 3-5个领域相关页面，位于设计模式区右侧。
除这些区域框架和可选导航索引外，所有组件均不能直接放在文档根目录下。

Workflow

工作流程

Execute these phases in order. Each phase builds on the previous. Never skip mandatory phases. Reference files in 
references/
contain detailed specs — load them as each phase begins.
⛔ Review gates are placed after major phases. At each gate you MUST stop, show results, and wait for user input before continuing. The user controls the pace — they type 
c
to continue, 
r
to redo, or 
s
to skip ahead.
按顺序执行以下阶段，每个阶段基于前一阶段构建，不得跳过强制阶段。
references/
目录下的参考文件包含详细规范 — 每个阶段开始前需加载对应文件。
⛔ 审核节点 设置在主要阶段之后。每个节点必须暂停，展示结果，等待用户输入后再继续。用户可控制进度 — 输入
c
继续，
r
重新制作（说明修改内容），
s
跳至最终验证环节。

Phase 1 — Research the Domain

第一阶段 — 领域调研

Use 
WebSearch
to study the domain's design conventions. Identify five pillars: color palette, typography, imagery themes, screen inventory, and UI density/tone. Document findings as a design brief.
Typography is research-driven, not table-driven. Run specific font research queries (e.g., 
"bakery website fonts 2026"
, 
"best Google Fonts for bakery"
) and validate against 3–5 real websites in the domain. The font pairing table in 
domain-research-guide.md
is a fallback — always prefer research-validated choices. See 
references/domain-research-guide.md
.
⛔ REVIEW — Design Brief
Present the research findings as a design brief:
Design Brief — [Domain]

Primary:    [hex] ([description])
Secondary:  [hex] ([description])
Accent:     [hex] ([description])
Background: [hex] ([description])
Heading:    [font name]
Body:       [font name]
Mono:       [font name]
Tone:       [2-3 adjectives]

Based on: [list 2-3 reference sites studied]
[c] Continue to token creation [r] Redo — tell me what to change (e.g., "use teal instead of brown") [s] Skip to final verification
WAIT for user input. Do NOT proceed.
使用
WebSearch
研究该领域的设计惯例，确定五大支柱：调色板、排版、图像主题、页面清单、UI密度与风格。将调研结果整理为设计 brief。
排版需基于调研，而非表格。 运行特定的字体调研查询（例如：
"bakery website fonts 2026"
、
"best Google Fonts for bakery"
），并与该领域内3-5个真实网站进行验证。
domain-research-guide.md
中的字体配对表仅作为备选 — 始终优先选择经调研验证的字体。详见
references/domain-research-guide.md
。
⛔ 审核 — 设计Brief
将调研结果整理为设计 brief 展示：
Design Brief — [Domain]

Primary:    [hex] ([description])
Secondary:  [hex] ([description])
Accent:     [hex] ([description])
Background: [hex] ([description])
Heading:    [font name]
Body:       [font name]
Mono:       [font name]
Tone:       [2-3 adjectives]

Based on: [list 2-3 reference sites studied]
[c] 继续创建设计令牌 [r] 重新制作 — 说明修改内容（例如："用蓝绿色代替棕色"） [s] 跳至最终验证
等待用户输入，不得继续。

Phase 2 — Initialize the Pencil Document

第二阶段 — 初始化Pencil文档

  1. Call 
    get_editor_state({ include_schema: true })
    .
  2. If no active document, call 
    open_document("new")
    .
  3. Call 
    get_guidelines({ topic: "design-system" })
    .
  4. Call 
    get_style_guide_tags()
    then 
    get_style_guide({ tags: [...] })
    with 5–10 domain-matching tags.
  5. Call 
    get_variables({ filePath })
    to check for existing tokens.
Merge the style guide with Phase 1 research to form the final design direction.
  1. 调用
    get_editor_state({ include_schema: true })
    。
  2. 若无活跃文档，调用
    open_document("new")
    。
  3. 调用
    get_guidelines({ topic: "design-system" })
    。
  4. 调用
    get_style_guide_tags()
    ，然后使用5-10个匹配领域的标签调用
    get_style_guide({ tags: [...] })
    。
  5. 调用
    get_variables({ filePath })
    检查现有令牌。
将风格指南与第一阶段的调研结果合并，形成最终设计方向。

Phase 3 — Create Design Tokens

第三阶段 — 创建设计令牌

Call 
set_variables
to create the full token system (~60 tokens). Every color, font, radius, spacing value, shadow, font size, and line height is a variable.
Handling user-specified colors: If the user provided color preferences (e.g., "terracotta and cream"), map them to the appropriate tokens (
--primary
, 
--background
, 
--accent
) and derive the rest of the palette (secondary, muted, foregrounds, borders) to complement. The industry palette tables are starting points, not mandates.
Post-creation color changes: Since all components use 
$--
token references (not hardcoded hex), calling 
set_variables
again with new color values updates the entire design system instantly — every component, pattern, and screen inherits the change. No per-node updates needed.
Token categories:
CategoryCountExamples
Core colors19
--background
, 
--foreground
, 
--primary
, 
--secondary
, 
--muted
, 
--accent
, 
--destructive
, 
--border
, 
--input
, 
--ring
Semantic colors8
--color-success
, 
--color-warning
, 
--color-error
, 
--color-info
+ foregrounds
Typography3
--font-primary
, 
--font-secondary
, 
--font-mono
Border radius6
--radius-none
(0) through 
--radius-pill
(9999)
Spacing12
--space-1
(4) through 
--space-24
(96)
Shadows4
--shadow-sm
, 
--shadow-md
, 
--shadow-lg
, 
--shadow-xl
Font sizes9
--text-xs
(12) through 
--text-5xl
(48)
Line heights3
--leading-tight
(1.25), 
--leading-normal
(1.5), 
--leading-relaxed
(1.75)
Set up theme axis 
{ "mode": ["light", "dark"] }
. All token values are domain-tailored. See 
references/design-tokens-reference.md
for full JSON payloads.
Post-creation verification: After calling 
set_variables
, immediately call 
get_variables
and verify that every color token's values show 
"theme":{"mode":"light"}
and 
"theme":{"mode":"dark"}
(not 
"theme":{}
). If theme mappings are missing, the 
set_variables
call used the wrong format — see the CRITICAL warning in 
design-tokens-reference.md
.
⛔ REVIEW — Tokens
Call 
get_variables
and present results:
Tokens Created — [count] total

| Category        | Count | Status      |
|-----------------|-------|-------------|
| Core colors     | 19    | light+dark  |
| Semantic colors | 8     | light+dark  |
| Typography      | 3     |             |
| Border radius   | 6     |             |
| Spacing         | 12    |             |
| Shadows         | 4     |             |
| Font sizes      | 9     |             |
| Line heights    | 3     |             |

[any warnings: missing themes, wrong format, etc.]
[c] Continue to Foundations [r] Redo — tell me what to change [s] Skip to final verification
WAIT for user input. Do NOT proceed.
调用
set_variables
创建完整的令牌系统（约60个令牌）。所有颜色、字体、圆角、间距值、阴影、字号、行高均设为变量。
处理用户指定的颜色： 若用户提供颜色偏好（例如："赤陶色和奶油色"），将其映射到对应的令牌（
--primary
、
--background
、
--accent
），并推导其余调色板（次要、柔和、前景色、边框）以形成互补。行业调色板表仅作为起点，而非强制要求。
创建后颜色修改： 由于所有组件均使用
$--
令牌引用（而非硬编码十六进制值），再次调用
set_variables
并传入新颜色值即可即时更新整个设计系统 — 所有组件、模式和页面都会继承更改，无需逐个节点更新。
令牌分类：
分类数量示例
核心颜色19
--background
, 
--foreground
, 
--primary
, 
--secondary
, 
--muted
, 
--accent
, 
--destructive
, 
--border
, 
--input
, 
--ring
语义颜色8
--color-success
, 
--color-warning
, 
--color-error
, 
--color-info
+ 前景色
排版3
--font-primary
, 
--font-secondary
, 
--font-mono
圆角6
--radius-none
(0) 至 
--radius-pill
(9999)
间距12
--space-1
(4) 至 
--space-24
(96)
阴影4
--shadow-sm
, 
--shadow-md
, 
--shadow-lg
, 
--shadow-xl
字号9
--text-xs
(12) 至 
--text-5xl
(48)
行高3
--leading-tight
(1.25), 
--leading-normal
(1.5), 
--leading-relaxed
(1.75)
设置主题轴
{ "mode": ["light", "dark"] }
。所有令牌值均针对领域定制。完整JSON负载详见
references/design-tokens-reference.md
。
创建后验证： 调用
set_variables
后，立即调用
get_variables
，验证每个颜色令牌的值均显示
"theme":{"mode":"light"}
和
"theme":{"mode":"dark"}
（而非
"theme":{}
）。若缺少主题映射，则
set_variables
调用格式错误 — 详见
design-tokens-reference.md
中的CRITICAL警告。
⛔ 审核 — 设计令牌
调用
get_variables
并展示结果：
Tokens Created — [count] total

| Category        | Count | Status      |
|-----------------|-------|-------------|
| Core colors     | 19    | light+dark  |
| Semantic colors | 8     | light+dark  |
| Typography      | 3     |             |
| Border radius   | 6     |             |
| Spacing         | 12    |             |
| Shadows         | 4     |             |
| Font sizes      | 9     |             |
| Line heights    | 3     |             |

[any warnings: missing themes, wrong format, etc.]
[c] 继续构建基础规范 [r] 重新制作 — 说明修改内容 [s] 跳至最终验证
等待用户输入，不得继续。

Phase 4 — Build Foundations (Visual Documentation)

第四阶段 — 构建基础规范（视觉文档）

Create the Foundations section frame at the left of the canvas. Inside it, build 5 visual documentation frames:
  1. Color Palette — Grid of labeled swatches for all 27 color tokens.
  2. Typography Scale — 6 specimens (H1 → Caption) rendered at real sizes with metadata labels.
  3. Spacing Scale — 12 visual blocks showing each spacing value with labels.
  4. Elevation — 4 cards demonstrating shadow levels.
  5. Border Radius — 6 rectangles showcasing each radius token.
Critical: Use a neutral white backdrop (
fill: "#FFFFFF"
), NOT the design system's own 
$--background
token. The Foundations section is documentation chrome — using the themed background (e.g., cream for a bakery, blue-gray for SaaS) makes light swatches like 
--card
, 
--secondary
, and 
--muted
nearly invisible. A neutral white surface lets every color be evaluated accurately against a known reference. Swatches use 
$--
tokens for their fills; only the documentation frame itself is neutral.
These are documentation frames, NOT reusable components. They use 
$--
tokens for swatch fills everywhere. See 
references/foundations-specs.md
for exact 
batch_design
code (spread across 3 calls within 25-op limits).
After each batch, call 
get_screenshot
to verify rendering.
⛔ REVIEW — Foundations
Call 
get_screenshot
on the Foundations frame and present:
Foundations Complete

Sections built:
 - Color Palette (27 swatches)
 - Typography Scale (6 specimens)
 - Spacing Scale (12 blocks)
 - Elevation (4 shadow levels)
 - Border Radius (6 shapes)

[screenshot]
[any visual issues: blank swatches, overlap, clipping]
[c] Continue to Components [r] Redo — tell me what to fix [s] Skip to final verification
WAIT for user input. Do NOT proceed.
在画布左侧创建基础规范区框架，内部构建5个视觉文档框架：
  1. 调色板 — 所有27个颜色令牌的带标签样本网格。
  2. 排版尺度 — 6个示例（H1 → 说明文字），按实际尺寸渲染并附带元数据标签。
  3. 间距尺度 — 12个视觉块，展示每个间距值及对应标签。
  4. 层级阴影 — 4张卡片，演示不同阴影层级。
  5. 圆角展示 — 6个矩形，展示每个圆角令牌效果。
关键要求：使用中性白色背景（
fill: "#FFFFFF"
），而非设计系统自身的
$--background
令牌。 基础规范区是文档展示层 — 使用主题化背景（例如面包店的奶油色、SaaS的蓝灰色）会导致浅色样本如
--card
、
--secondary
、
--muted
几乎不可见。中性白色背景可让每种颜色在已知参考下准确呈现。样本填充使用
$--
令牌；仅文档框架本身为中性色。
这些是文档框架，而非可复用组件。所有样本填充均使用
$--
令牌。精确的
batch_design
代码（分3次调用，符合25操作限制）详见
references/foundations-specs.md
。
每次批量调用后，调用
get_screenshot
验证渲染效果。
⛔ 审核 — 基础规范
对基础规范区框架调用
get_screenshot
并展示：
Foundations Complete

Sections built:
 - Color Palette (27 swatches)
 - Typography Scale (6 specimens)
 - Spacing Scale (12 blocks)
 - Elevation (4 shadow levels)
 - Border Radius (6 shapes)

[screenshot]
[any visual issues: blank swatches, overlap, clipping]
[c] 继续构建组件 [r] 重新制作 — 说明需要修复的内容 [s] 跳至最终验证
等待用户输入，不得继续。

Phase 5 — Build Base Components (~15 Primitives)

第五阶段 — 构建基础组件（约15个基础元素）

Create the Components section frame to the right of Foundations with 
fill: "#FFFFFF"
(same neutral backdrop rationale as Foundations — light-fill variants like Ghost buttons and muted badges need a known white reference). Inside it, create category sub-frames with titles and display rows. Insert components under their category frame — NOT at document root.
BatchCategoryComponentsCount
1ButtonsPrimary, Secondary, Outline, Ghost, Destructive5
2InputsTextField, Textarea, Select, InputGroup4
3TypographyH1, H2, H3, Body, Caption, Label6
4BadgesDefault, Success, Warning, Error4
5AlertsInfo, Success, Warning, Error4
Every component has 
reusable: true
, uses only 
$--
tokens, and follows 
"Category/Variant"
naming. See 
references/component-specs.md
.
MANDATORY — Post-Batch Validation (after EVERY batch_design call):
  1. Check the batch response for "unknown properties were ignored" warnings — fix immediately.
  2. Call 
    get_screenshot
    on the affected section — visually confirm no overlapping elements, no invisible shadows, no broken layouts.
  3. If ANY horizontal arrangement shows items stacked/overlapping, the frame is missing 
    layout: "horizontal"
    . Fix it before proceeding to the next batch.
在基础规范区右侧创建组件区框架，设置
fill: "#FFFFFF"
（与基础规范区使用中性背景的原因相同 — 浅色填充变体如幽灵按钮、柔和徽章需要已知的白色参考）。在内部创建带标题的分类子框架和展示行，将组件插入对应分类框架下 — 不得放在文档根目录。
批次分类组件数量
1按钮主按钮、次要按钮、轮廓按钮、幽灵按钮、危险按钮5
2输入框文本输入框、文本域、选择器、输入组4
3排版H1、H2、H3、正文、说明文字、标签6
4徽章默认、成功、警告、错误4
5提示框信息、成功、警告、错误4
每个组件均设置
reusable: true
，仅使用
$--
令牌，并遵循
"分类/变体"
命名规则。详见
references/component-specs.md
。
强制要求 — 批次后验证（每次
batch_design
调用后）：
  1. 检查批次响应中的"unknown properties were ignored"警告 — 立即修复。
  2. 对受影响区域调用
    get_screenshot
    — 视觉确认无元素重叠、无不可见阴影、无布局断裂。
  3. 若任何水平排列出现元素堆叠/重叠，说明框架缺少
    layout: "horizontal"
    ，修复后再进入下一批次。

Phase 6 — Build Composite Components (~10 Composites)

第六阶段 — 构建复合组件（约10个复合元素）

Continue inside the Components section frame, adding category sub-frames for each composite group.
BatchCategoryComponentsCount
6CardHeader + Content + Actions slots1
7NavigationSidebar container, ActiveItem, DefaultItem, SectionTitle4
8TableWrapper, HeaderRow, DataRow3
9TabsContainer, ActiveTab, InactiveTab3
10BreadcrumbsItem, Separator, ActiveItem3
11PaginationContainer, PageItem, ActiveItem, PrevNext4
12ModalDialog with Header/Body/Footer1
13DropdownContainer, Item, Divider, SectionTitle4
14MiscAvatar, Divider, Switch, Checkbox, Radio5
After batches 8, 11, and 14: run 
get_screenshot
and 
snapshot_layout({ problemsOnly: true })
. Fix issues immediately. See 
references/component-specs.md
.
⛔ REVIEW — Components
Call 
batch_get({ patterns: [{ reusable: true }] })
, 
get_screenshot
, and 
snapshot_layout({ problemsOnly: true })
. Present:
Components Created — [count] reusable

| Category    | Components                              | Count |
|-------------|----------------------------------------|-------|
| Buttons     | Primary, Secondary, Outline, Ghost, Destructive | 5 |
| Inputs      | TextField, Textarea, Select, InputGroup | 4 |
| Typography  | H1, H2, H3, Body, Caption, Label      | 6 |
| Badges      | Default, Success, Warning, Error       | 4 |
| Alerts      | Info, Success, Warning, Error          | 4 |
| Card        | Header + Content + Actions             | 1 |
| Navigation  | Sidebar, Active, Default, SectionTitle | 4 |
| Table       | Wrapper, HeaderRow, DataRow            | 3 |
| ...         | [remaining composites]                 | ... |

[screenshot]
[layout issues from snapshot_layout, if any]
[c] Continue to Patterns [r] Redo — tell me what to fix [s] Skip to final verification
WAIT for user input. Do NOT proceed.
在组件区框架内继续添加复合组件的分类子框架。
批次分类组件数量
6卡片头部+内容+操作插槽1
7导航侧边栏容器、激活项、默认项、分区标题4
8表格容器、表头行、数据行3
9标签页容器、激活标签、未激活标签3
10面包屑项、分隔符、激活项3
11分页容器、页码项、激活项、上一页/下一页4
12模态框带头部/主体/底部的对话框1
13下拉菜单容器、菜单项、分隔符、分区标题4
14其他头像、分隔线、开关、复选框、单选框5
在批次8、11、14完成后：调用
get_screenshot
和
snapshot_layout({ problemsOnly: true })
，立即修复问题。详见
references/component-specs.md
。
⛔ 审核 — 组件
调用
batch_get({ patterns: [{ reusable: true }] })
、
get_screenshot
和
snapshot_layout({ problemsOnly: true })
，并展示：
Components Created — [count] reusable

| 分类    | 组件                              | 数量 |
|-------------|----------------------------------------|-------|
| 按钮     | 主按钮、次要按钮、轮廓按钮、幽灵按钮、危险按钮 | 5 |
| 输入框      | 文本输入框、文本域、选择器、输入组 | 4 |
| 排版  | H1、H2、H3、正文、说明文字、标签      | 6 |
| 徽章      | 默认、成功、警告、错误       | 4 |
| 提示框      | 信息、成功、警告、错误          | 4 |
| 卡片        | 头部+内容+操作             | 1 |
| 导航  | 侧边栏、激活项、默认项、分区标题 | 4 |
| 表格       | 容器、表头行、数据行            | 3 |
| ...         | [剩余复合组件]                 | ... |

[screenshot]
[layout issues from snapshot_layout, if any]
[c] 继续构建设计模式 [r] 重新制作 — 说明需要修复的内容 [s] 跳至最终验证
等待用户输入，不得继续。

Phase 7 — Build Patterns (Composition Showcases)

第七阶段 — 构建设计模式（组合展示）

Create the Patterns section frame to the right of Components. Build 4 composition showcases that demonstrate real usage of the components:
  1. Form Pattern — Vertical stack of InputGroup refs + Submit button.
  2. Data Display Pattern — Table ref with populated rows + Pagination ref.
  3. Navigation Pattern — Sidebar ref + Breadcrumbs ref + Tabs ref.
  4. Card Layout Pattern — Grid of populated Card refs with images and domain content.
Each pattern uses only 
ref
instances + 
$--
tokens. After each pattern, run the Post-Batch Validation (screenshot + check for overlapping/broken layouts). See 
references/screen-patterns.md
.
⛔ REVIEW — Patterns
Call 
get_screenshot
on the Patterns frame and present:
Patterns Complete — 4 composition showcases

 1. Form Pattern       — InputGroup refs + Submit button
 2. Data Display       — Table ref + Pagination ref
 3. Navigation Pattern — Sidebar + Breadcrumbs + Tabs refs
 4. Card Layout        — Grid of populated Card refs

[screenshot]
[any layout or ref issues]
[c] Continue to Screens (or skip to verification if no screens requested) [r] Redo — tell me what to fix [s] Skip to final verification
WAIT for user input. Do NOT proceed.
在组件区右侧创建设计模式区框架，构建4个组合展示，演示组件的实际用法：
  1. 表单模式 — 输入组引用的垂直堆叠 + 提交按钮。
  2. 数据展示模式 — 带填充行的表格引用 + 分页引用。
  3. 导航模式 — 侧边栏引用 + 面包屑引用 + 标签页引用。
  4. 卡片布局模式 — 带图片和领域内容的填充卡片引用网格。
每个模式仅使用
ref
实例 + 
$--
令牌。每个模式完成后，执行批次后验证（截图 + 检查重叠/断裂布局）。详见
references/screen-patterns.md
。
⛔ 审核 — 设计模式
对设计模式区框架调用
get_screenshot
并展示：
Patterns Complete — 4 composition showcases

 1. Form Pattern       — 输入组引用 + 提交按钮
 2. Data Display       — 表格引用 + 分页引用
 3. Navigation Pattern — 侧边栏 + 面包屑 + 标签页引用
 4. Card Layout        — 填充卡片引用网格

[screenshot]
[any layout or ref issues]
[c] 继续构建页面（若未请求页面则跳至验证环节） [r] 重新制作 — 说明需要修复的内容 [s] 跳至最终验证
等待用户输入，不得继续。

Phase 8 — Create Domain Screens (only if user requests)

第八阶段 — 创建领域页面（仅用户请求时）

Skip this phase unless the user explicitly asks for screens (e.g., "build screens for a bakery", "I need a landing page and menu screen", "create example screens"). The core deliverable is Foundations + Components + Patterns — screens are an optional add-on.
If the user requests screens, build 3–5 placed to the right of the Patterns section. Each screen uses only component 
ref
instances and 
$--
variable tokens.
Per-screen workflow:
  1. Call 
    find_empty_space_on_canvas({ direction: "right", width: 1440, height: 900, padding: 100 })
    .
  2. Insert screen frame at returned position.
  3. Build layout with component refs. Customize via 
    U(instanceId+"/descendantId", {...})
    .
  4. Add domain imagery via 
    G()
    .
  5. Call 
    get_screenshot
    to verify.
See 
references/screen-patterns.md
for domain-specific screen templates.
⛔ REVIEW — Domain Screens (only if Phase 8 was executed)
Call 
get_screenshot
on each screen and present:
Domain Screens — [count] created

 1. [Screen Name] — [brief description]
 2. [Screen Name] — [brief description]
 ...

[screenshots]
[any issues: missing refs, hardcoded values, layout problems]
[c] Continue to Business Logic Screens (or verification) [r] Redo — tell me what to fix [s] Skip to final verification
WAIT for user input. Do NOT proceed.
除非用户明确要求页面，否则跳过此阶段（例如："为面包店构建页面"、"我需要一个着陆页和菜单页面"、"创建示例页面"）。核心交付物为基础规范+组件+设计模式 — 页面为可选附加内容。
若用户请求页面，在设计模式区右侧构建3-5个页面，每个页面仅使用组件
ref
实例和
$--
变量令牌。
单页面工作流程：
  1. 调用
    find_empty_space_on_canvas({ direction: "right", width: 1440, height: 900, padding: 100 })
    。
  2. 在返回位置插入页面框架。
  3. 使用组件引用构建布局，通过
    U(instanceId+"/descendantId", {...})
    进行自定义。
  4. 通过
    G()
    添加领域相关图片。
  5. 调用
    get_screenshot
    验证。
领域特定页面模板详见
references/screen-patterns.md
。
⛔ 审核 — 领域页面（仅执行第八阶段时展示）
对每个页面调用
get_screenshot
并展示：
Domain Screens — [count] created

 1. [页面名称] — [简要描述]
 2. [页面名称] — [简要描述]
 ...

[screenshots]
[any issues: missing refs, hardcoded values, layout problems]
[c] 继续构建业务逻辑页面（或跳至验证环节） [r] 重新制作 — 说明需要修复的内容 [s] 跳至最终验证
等待用户输入，不得继续。

Phase 8b — Business Logic Screens (only if user provides requirements)

第八阶段b — 业务逻辑页面（仅用户提供需求时）

Skip this phase unless the user provides specific product requirements, user flows, or feature specs. This differs from Phase 8 (generic domain screens) — here the user supplies their actual business logic and the AI designs screens tailored to it.
The user might provide:
  • User flows: "checkout: cart → address → payment → confirmation"
  • Feature specs: "CRM with contact list, deal pipeline kanban, activity timeline"
  • A PRD or user story document
  • Wireframe descriptions: "onboarding wizard with 4 steps"
Workflow:
  1. Read existing components: 
    batch_get({ patterns: [{ reusable: true }], readDepth: 2 })
    .
  2. Read existing tokens: 
    get_variables({ filePath })
    .
  3. Plan screens based on user requirements — map each user flow or feature to a screen.
  4. For each screen: a. Call 
    find_empty_space_on_canvas({ direction: "right", width: 1440, height: 900, padding: 100 })
    . b. Insert screen frame at returned position. c. Build layout using existing component 
    ref
    instances. d. Customize content via 
    U(instanceId+"/descendantId", {...})
    with realistic business data. e. Add imagery via 
    G()
    where appropriate. f. Call 
    get_screenshot
    to verify.
⛔ REVIEW — Business Logic Screens
Call 
get_screenshot
on each screen and present:
Business Logic Screens — [count] created

 1. [Screen Name] — maps to: [which user requirement/flow]
 2. [Screen Name] — maps to: [which user requirement/flow]
 ...

[screenshots]
[any issues or gaps vs requirements]
[c] Continue to Layout Enforcement [r] Redo — tell me what to fix [s] Skip to final verification
WAIT for user input. Do NOT proceed.
除非用户提供特定产品需求、用户流程或功能规范，否则跳过此阶段。此阶段与第八阶段（通用领域页面）不同 — 用户需提供实际业务逻辑，AI将据此设计定制化页面。
用户可能提供：
  • 用户流程："结账流程：购物车 → 地址 → 支付 → 确认"
  • 功能规范："包含联系人列表、交易管道看板、活动时间线的CRM"
  • PRD或用户故事文档
  • 线框描述："包含4个步骤的引导向导"
工作流程：
  1. 读取现有组件：
    batch_get({ patterns: [{ reusable: true }], readDepth: 2 })
    。
  2. 读取现有令牌：
    get_variables({ filePath })
    。
  3. 根据用户需求规划页面 — 将每个用户流程或功能映射到对应页面。
  4. 对每个页面： a. 调用
    find_empty_space_on_canvas({ direction: "right", width: 1440, height: 900, padding: 100 })
    。 b. 在返回位置插入页面框架。 c. 使用现有组件
    ref
    实例构建布局。 d. 通过
    U(instanceId+"/descendantId", {...})
    添加真实业务数据以自定义内容。 e. 酌情通过
    G()
    添加图片。 f. 调用
    get_screenshot
    验证。
⛔ 审核 — 业务逻辑页面
对每个页面调用
get_screenshot
并展示：
Business Logic Screens — [count] created

 1. [页面名称] — 对应：[用户需求/流程]
 2. [页面名称] — 对应：[用户需求/流程]
 ...

[screenshots]
[any issues or gaps vs requirements]
[c] 继续执行布局强制检查 [r] 重新制作 — 说明需要修复的内容 [s] 跳至最终验证
等待用户输入，不得继续。

Phase 9 — Layout Enforcement Pass (MANDATORY)

第九阶段 — 布局强制检查（强制要求）

Why this exists: The AI consistently drops 
layout: "horizontal"
from frames during generation, even when specs include it. This pass programmatically catches and fixes every missing layout. This phase is NOT optional — skip it and the design will have broken layouts.
Step 1 — Collect all frames with flex properties.
batch_get({ filePath, patterns: [{ type: "frame" }], searchDepth: 10, readDepth: 0 })
Search within EACH top-level section (Foundations, Components, Patterns, and any screens).
Step 2 — Identify frames needing layout enforcement. From the results, find every frame that has ANY of: 
gap
, 
alignItems
, 
justifyContent
— regardless of whether 
layout
already appears (since 
batch_get
doesn't display 
layout: "horizontal"
in its output — it's considered the default).
Step 3 — Bulk-apply 
layout: "horizontal"
to ALL identified frames.
javascript
U("frameId1", { layout: "horizontal" })
U("frameId2", { layout: "horizontal" })
// ... for every frame with gap/alignItems/justifyContent
Exclude frames that should be vertical (identifiable by name: category sections, form containers, vertical stacks). Apply 
layout: "vertical"
to those instead.
Step 4 — Verify shadows use hex colors. Check any frame with 
effect
property. If 
color
uses 
rgba()
format, replace with 8-digit hex 
#RRGGBBAA
.
Step 5 — Screenshot every section to confirm no overlapping elements.
This is safe to run multiple times — setting 
layout: "horizontal"
on a frame that already has it is a no-op.
存在原因： AI在生成过程中经常会遗漏框架的
layout: "horizontal"
属性，即使规范中包含该属性。此步骤将以编程方式捕获并修复所有缺失的布局设置。此阶段为强制要求 — 跳过将导致设计出现布局断裂问题。
步骤1 — 收集所有包含flex属性的框架。
batch_get({ filePath, patterns: [{ type: "frame" }], searchDepth: 10, readDepth: 0 })
在每个顶级区域（基础规范、组件、设计模式及所有页面）内搜索。
步骤2 — 识别需要强制设置布局的框架。 从结果中找出所有包含以下任一属性的框架：
gap
、
alignItems
、
justifyContent
— 无论
layout
是否已存在（因为
batch_get
的输出中不会显示
layout: "horizontal"
— 它被视为默认值）。
步骤3 — 为所有识别出的框架批量应用
layout: "horizontal"
。
javascript
U("frameId1", { layout: "horizontal" })
U("frameId2", { layout: "horizontal" })
// ... 对所有包含gap/alignItems/justifyContent的框架执行此操作
排除应为垂直布局的框架（可通过名称识别：分类区域、表单容器、垂直堆叠），对这些框架应用
layout: "vertical"
。
步骤4 — 验证阴影使用十六进制颜色。 检查所有包含
effect
属性的框架。若
color
使用
rgba()
格式，替换为8位十六进制
#RRGGBBAA
。
步骤5 — 对每个区域截图，确认无元素重叠。
此步骤可安全重复执行 — 对已设置
layout: "horizontal"
的框架再次设置不会产生影响。

Phase 10 — Final Verification

第十阶段 — 最终验证

Run comprehensive QA. Fix every issue before presenting to the user.
  1. Visual — 
    get_screenshot
    on Foundations, Components, Patterns (and screens if created). Check alignment, spacing, typography, color, overflow.
  2. Layout — 
    snapshot_layout({ problemsOnly: true })
    to detect clipping/overflow. Fix all.
  3. Token audit — 
    search_all_unique_properties
    for 
    fillColor
    , 
    textColor
    , 
    fontFamily
    , 
    fontSize
    . Replace leaked hex values and raw font sizes with 
    $--
    tokens.
  4. Component audit — 
    batch_get({ patterns: [{ reusable: true }] })
    . Verify ~25 components.
  5. Organization audit — Verify no orphan components at document root. All should be under Components section.
  6. Fix and re-verify — Re-screenshot affected areas after fixes.
  7. Present — Summarize tokens, components, patterns (and screens if created). Show key screenshots.
See 
references/verification-checklist.md
.
执行全面QA，在向用户交付前修复所有问题。
  1. 视觉检查 — 对基础规范、组件、设计模式（及已创建的页面）调用
    get_screenshot
    ，检查对齐、间距、排版、颜色、溢出情况。
  2. 布局检查 — 调用
    snapshot_layout({ problemsOnly: true })
    检测裁剪/溢出，修复所有问题。
  3. 令牌审计 — 使用
    search_all_unique_properties
    查找
    fillColor
    、
    textColor
    、
    fontFamily
    、
    fontSize
    ，将泄露的十六进制值和原始字号替换为
    $--
    令牌。
  4. 组件审计 — 调用
    batch_get({ patterns: [{ reusable: true }] })
    ，验证约25个组件。
  5. 组织审计 — 验证无孤立组件在文档根目录，所有组件均位于组件区框架下。
  6. 修复并重验证 — 修复后对受影响区域重新截图验证。
  7. 展示 — 总结令牌、组件、设计模式（及已创建的页面），展示关键截图。
详见
references/verification-checklist.md
。

Phase 11 — Canvas Navigation Index

第十一阶段 — 画布导航索引

Create a small navigation index frame at the canvas origin (x: 0, y: 0) showing a map of all sections with their positions:
Design System Index
├── Foundations (x, y)
├── Components (x, y)
├── Patterns (x, y)
└── Screens (x, y) — only if screens were created
This helps users navigate the canvas. Only include the Screens entry if Phase 8 was executed.
在画布原点（x: 0, y: 0）创建一个小型导航索引框架，展示所有区域及其位置：
Design System Index
├── Foundations (x, y)
├── Components (x, y)
├── Patterns (x, y)
└── Screens (x, y) — 仅创建页面时显示
这将帮助用户导航画布。仅当执行第八阶段时才包含Screens条目。

Phase 12 — Code Export (optional, user-triggered)

第十二阶段 — 代码导出（可选，用户触发）

Skip this phase unless the user explicitly requests code export (e.g., "export to Tailwind", "convert to code", "generate React components", "export as CSS"). This phase converts the design system into production-ready Tailwind CSS + React components.
Step 1 — Collect preferences. Ask the user for:
  • Tailwind version: v3 or v4
  • Framework: Next.js or Vite+React
Step 2 — Extract tokens. Call 
get_variables({ filePath })
to read all ~64 tokens. Categorize by type (color, number, string, shadow). Separate themed (light/dark) from static tokens.
Step 3 — Read components. Call 
batch_get({ patterns: [{ reusable: true }], readDepth: 3, searchDepth: 3 })
to get every reusable component with its full node tree.
Step 4 — Load Pencil's code generation guidelines. Call 
get_guidelines("code")
and 
get_guidelines("tailwind")
. These are the primary authority for translating Pencil nodes to code — they cover component instance mapping, property-to-Tailwind-class translation, font wiring, and visual verification. Follow them for all translation work in Steps 8-9.
Step 5 — Generate 
globals.css
. Build the CSS file with all tokens as CSS custom properties:
  • v3: 
    :root
    with HSL values (space-separated, no 
    hsl()
    wrapper), 
    .dark
    overrides, 
    @layer base
    font utilities
  • v4: 
    @import "tailwindcss"
    , 
    @custom-variant dark
    , 
    :root
    with hex values, 
    .dark
    overrides, 
    @layer base
    font utilities
Step 6 — Generate 
tailwind.config.js
(v3 only). Map all tokens to Tailwind utility names: colors via 
hsl(var(--name))
, radii, shadows, font sizes, spacing, line heights.
Step 7 — Generate font loading code.
  • Next.js: 
    layout.tsx
    with 
    next/font/google
    loader setting 
    --font-primary
    , 
    --font-secondary
    , 
    --font-mono
    CSS variables
  • Vite+React: 
    <link>
    tags in 
    index.html
    loading all three fonts from Google Fonts
Step 8 — Generate component TSX files. One file per component category (button.tsx, input.tsx, card.tsx, badge.tsx, alert.tsx, etc.). Each component:
  • Uses only token-referencing Tailwind classes (no hardcoded hex)
  • Has TypeScript interfaces with variant props where applicable
  • Accepts and spreads an optional 
    className
    prop
  • Uses v3 mapped classes (
    bg-primary
    ) or v4 arbitrary values (
    bg-[var(--primary)]
    ) based on the chosen version
Step 9 — Generate screen/page TSX files. For each screen design in the .pen file:
  1. Deep-read the screen frame: 
    batch_get({ nodeIds: [screenId], readDepth: 10, resolveInstances: true })
  2. Take a reference screenshot: 
    get_screenshot({ nodeId: screenId })
  3. Follow Pencil's Component Implementation Workflow (from Step 4's 
    get_guidelines("code")
    ):
    • Steps 1A-1C: Extract components, map ALL instances with ALL overrides and descendants
    • Step 2: Create React components using 
      get_guidelines("tailwind")
      for property-to-class mapping
    • Step 3: Validate each component with 
      get_screenshot
      — pixel-perfect match required
    • Step 4: Integrate into frame, verify instance count and prop completeness
  4. Handle screen-level elements: semantic HTML for headings/labels/links, page wrapper, form behavior, icon name conversion, image fills
  5. Assemble into a complete page file with all imports
  6. Visually verify the rendered page against the Pencil screenshot — fix any discrepancies
See 
references/code-export-guide.md
(Section 7) for the complete screen export workflow and common pitfalls.
除非用户明确要求代码导出，否则跳过此阶段（例如："导出为Tailwind"、"转换为代码"、"生成React组件"、"导出为CSS"）。此阶段将设计系统转换为可用于生产的Tailwind CSS + React组件。
步骤1 — 收集偏好。 询问用户：
  • Tailwind版本： v3或v4
  • 框架： Next.js或Vite+React
步骤2 — 提取令牌。 调用
get_variables({ filePath })
读取所有约64个令牌，按类型（颜色、数字、字符串、阴影）分类，区分主题化（亮色/暗色）与静态令牌。
步骤3 — 读取组件。 调用
batch_get({ patterns: [{ reusable: true }], readDepth: 3, searchDepth: 3 })
获取每个可复用组件的完整节点树。
步骤4 — 加载Pencil的代码生成指南。 调用
get_guidelines("code")
和
get_guidelines("tailwind")
。这些是将Pencil节点转换为代码的主要依据，涵盖组件实例映射、属性到Tailwind类的转换、字体配置和视觉验证。步骤8-9的所有转换工作均需遵循这些指南。
步骤5 — 生成
globals.css
。 构建包含所有令牌的CSS文件，将令牌设为CSS自定义属性：
  • v3： 
    :root
    中使用HSL值（空格分隔，无
    hsl()
    包装），
    .dark
    覆盖样式，
    @layer base
    字体工具类
  • v4： 
    @import "tailwindcss"
    ，
    @custom-variant dark
    ，
    :root
    中使用十六进制值，
    .dark
    覆盖样式，
    @layer base
    字体工具类
步骤6 — 生成
tailwind.config.js
（仅v3）。 将所有令牌映射到Tailwind工具类名称：颜色通过
hsl(var(--name))
，圆角、阴影、字号、间距、行高。
步骤7 — 生成字体加载代码。
  • Next.js： 
    layout.tsx
    中使用
    next/font/google
    加载器设置
    --font-primary
    、
    --font-secondary
    、
    --font-mono
    CSS变量
  • Vite+React： 
    index.html
    中的
    <link>
    标签从Google Fonts加载所有三种字体
步骤8 — 生成组件TSX文件。 每个组件分类对应一个文件（button.tsx、input.tsx、card.tsx、badge.tsx、alert.tsx等）。每个组件：
  • 仅使用引用令牌的Tailwind类（无硬编码十六进制值）
  • 包含带变体属性的TypeScript接口（若适用）
  • 接受并传播可选的
    className
    属性
  • 根据所选版本使用v3映射类（
    bg-primary
    ）或v4任意值（
    bg-[var(--primary)]
    ）
步骤9 — 生成页面TSX文件。 对.pen文件中的每个页面设计：
  1. 深度读取页面框架：
    batch_get({ nodeIds: [screenId], readDepth: 10, resolveInstances: true })
  2. 截取参考截图：
    get_screenshot({ nodeId: screenId })
  3. 遵循Pencil的组件实现工作流（来自步骤4的
    get_guidelines("code")
    ）：
    • 步骤1A-1C：提取组件，映射所有包含覆盖和子节点的实例
    • 步骤2：使用
      get_guidelines("tailwind")
      将属性转换为Tailwind类，创建React组件
    • 步骤3：使用
      get_screenshot
      验证每个组件 — 要求像素级匹配
    • 步骤4：集成到框架中，验证实例数量和属性完整性
  4. 处理页面级元素：标题/标签/链接的语义化HTML、页面容器、表单行为、图标名称转换、图片填充
  5. 组装为完整的页面文件，包含所有导入
  6. 视觉验证渲染页面与Pencil截图是否一致 — 修复所有差异
完整的页面导出工作流和常见陷阱详见
references/code-export-guide.md
（第7节）。

Critical Rules

关键规则

Rule 1 — Always reuse components. Search with 
batch_get({ patterns: [{ reusable: true }] })
before creating. On screens, every element must be a 
ref
instance.
Rule 2 — Never hardcode values. All colors use 
$--
tokens. All fonts use 
$--font-*
. All radii use 
$--radius-*
. All font sizes use 
$--text-*
. Raw values only appear in 
set_variables
.
Rule 3 — Prevent overflow. Constrain text with 
width: "fill_container"
. Use layout frames. Validate with 
snapshot_layout({ problemsOnly: true })
.
Rule 4 — Verify visually. Call 
get_screenshot
after every major batch. Fix problems immediately.
Rule 5 — Reuse assets. Copy images with 
C()
instead of regenerating with 
G()
.
Rule 6 — Domain coherence. Every choice connects back to Phase 1 research.
Rule 7 — Canvas organization. All components go inside the Components section frame under categorized sub-frames. No components at document root. Foundations, Components, Patterns, and Screens flow left-to-right on the canvas.
规则1 — 始终复用组件。 创建前调用
batch_get({ patterns: [{ reusable: true }] })
搜索现有组件。页面上的所有元素必须是
ref
实例。
规则2 — 绝不硬编码值。 所有颜色使用
$--
令牌，所有字体使用
$--font-*
，所有圆角使用
$--radius-*
，所有字号使用
$--text-*
。原始值仅能出现在
set_variables
中。
规则3 — 防止溢出。 使用
width: "fill_container"
限制文本，使用布局框架，通过
snapshot_layout({ problemsOnly: true })
验证。
规则4 — 视觉验证。 每次主要批量调用后调用
get_screenshot
，立即修复问题。
规则5 — 复用资源。 使用
C()
复制图片，而非使用
G()
重新生成。
规则6 — 领域一致性。 每个选择均需关联到第一阶段的调研结果。
规则7 — 画布组织。 所有组件必须放在组件区框架下的分类子框架中，不得放在文档根目录。基础规范、组件、设计模式、页面在画布上从左到右排列。

Component Inventory

组件清单

#ComponentTypeVariants
1–5ButtonPrimitivePrimary, Secondary, Outline, Ghost, Destructive
6–9InputPrimitiveTextField, Textarea, Select, InputGroup
10–15TypographyPrimitiveH1, H2, H3, Body, Caption, Label
16–19BadgePrimitiveDefault, Success, Warning, Error
20–23AlertPrimitiveInfo, Success, Warning, Error
24CardCompositeHeader + Content + Actions slots
25–28Sidebar NavCompositeContainer, ActiveItem, DefaultItem, SectionTitle
29–31TableCompositeWrapper, HeaderRow, DataRow
32–34TabsCompositeContainer, ActiveTab, InactiveTab
35–37BreadcrumbsCompositeItem, Separator, ActiveItem
38–41PaginationCompositeContainer, PageItem, ActiveItem, PrevNext
42Modal/DialogCompositeOverlay + Content with slots
43–46DropdownCompositeContainer, MenuItem, Divider, SectionTitle
47–51MiscellaneousCompositeAvatar, Divider, Switch, Checkbox, Radio
#组件类型变体
1–5按钮基础元素主按钮、次要按钮、轮廓按钮、幽灵按钮、危险按钮
6–9输入框基础元素文本输入框、文本域、选择器、输入组
10–15排版基础元素H1、H2、H3、正文、说明文字、标签
16–19徽章基础元素默认、成功、警告、错误
20–23提示框基础元素信息、成功、警告、错误
24卡片复合元素头部+内容+操作插槽
25–28侧边栏导航复合元素容器、激活项、默认项、分区标题
29–31表格复合元素容器、表头行、数据行
32–34标签页复合元素容器、激活标签、未激活标签
35–37面包屑复合元素项、分隔符、激活项
38–41分页复合元素容器、页码项、激活项、上一页/下一页
42模态框/对话框复合元素遮罩+带插槽的内容
43–46下拉菜单复合元素容器、菜单项、分隔符、分区标题
47–51其他复合元素头像、分隔线、开关、复选框、单选框

References

参考文件

Load the relevant file before starting each phase:
  • references/pencil-mcp-guide.md
     — Complete Pencil MCP tool reference with examples and operation syntax.
  • references/domain-research-guide.md
     — Domain research strategies, color psychology, font pairings, screen inventories.
  • references/design-tokens-reference.md
     — Token architecture, 
    set_variables
    JSON payloads, ~60 token definitions, industry palettes.
  • references/foundations-specs.md
     — Visual foundation documentation: color palette, typography scale, spacing, elevation, radius 
    batch_design
    code.
  • references/component-specs.md
     — All ~25 component 
    batch_design
    operation code with section frame organization.
  • references/screen-patterns.md
     — Layout patterns, composition showcases, and domain-specific screen templates.
  • references/verification-checklist.md
     — Visual QA, layout checks, token audits, canvas organization verification.
  • references/code-export-guide.md
     — Tailwind CSS export: token extraction, v3/v4 templates, Pencil-to-Tailwind class cheatsheet, component translation, framework setup (Next.js / Vite+React).
每个阶段开始前加载对应参考文件：
  • references/pencil-mcp-guide.md
     — 完整的Pencil MCP工具参考，包含示例和操作语法。
  • references/domain-research-guide.md
     — 领域调研策略、色彩心理学、字体配对、页面清单。
  • references/design-tokens-reference.md
     — 令牌架构、
    set_variables
    JSON负载、约60个令牌定义、行业调色板。
  • references/foundations-specs.md
     — 视觉基础文档：调色板、排版尺度、间距、层级阴影、圆角的
    batch_design
    代码。
  • references/component-specs.md
     — 所有约25个组件的
    batch_design
    操作代码，包含区域框架组织方式。
  • references/screen-patterns.md
     — 布局模式、组合展示、领域特定页面模板。
  • references/verification-checklist.md
     — 视觉QA、布局检查、令牌审计、画布组织验证。
  • references/code-export-guide.md
     — Tailwind CSS导出：令牌提取、v3/v4模板、Pencil到Tailwind类速查表、组件转换、框架设置（Next.js / Vite+React）。