design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Design pages using the
design_page
and
edit_page
MCP tools.
design_page
creates AI-generated design variations that the user can preview and select.
edit_page
applies direct code edits to an existing Subframe page. Both produce designs the user can refine visually in the Subframe editor and then implement in code.
Don't write UI code directly. Subframe generates production-ready React/Tailwind code that matches the design system. Design first, then implement with
/subframe:develop
.
使用
design_page
edit_page
这两个MCP工具来设计页面。
design_page
会生成由AI创建的多种设计变体,供用户预览和选择。
edit_page
则用于对已有的Subframe页面直接进行代码编辑。这两种工具生成的设计都可以在Subframe编辑器中进行可视化优化,之后再落地为代码。
请勿直接编写UI代码。 Subframe会生成符合设计系统的生产级React/Tailwind代码。请先完成设计,再通过
/subframe:develop
实现代码落地。

When to Use This

使用场景

Use
/subframe:design
when the user:
  • Needs UI while coding
  • Wants to explore design options
  • Has codebase context that should inform the design
  • Wants a starting point to refine in a design tool
  • Is collaborating on designs with a team
  • Wants to modify an existing page
The key value:
/subframe:design
and
/subframe:develop
bridge coding and design. They work in both directions — create designs while coding and then ensure your code exactly reflects your design.
当用户有以下需求时,请使用
/subframe:design
  • 编码过程中需要配套UI
  • 希望探索多种设计方案
  • 拥有需要融入设计的代码库上下文
  • 需要一个可在设计工具中优化的起点
  • 正在与团队协作进行设计
  • 希望修改现有页面
核心价值:
/subframe:design
/subframe:develop
打通了编码与设计的流程。它们支持双向协作——编码时可同步设计,同时确保代码与设计完全一致。

MCP Authentication

MCP认证

If you cannot find the
design_page
tool (or any Subframe MCP tools), the MCP server likely needs to be authenticated. Ask the user to authenticate the Subframe MCP server. If the user is using Claude Code, instruct them to run
/mcp
to view and authenticate their MCP servers, and then say "done" when they're finished.
如果找不到
design_page
工具(或任何Subframe MCP工具),大概率是MCP服务器需要认证。请让用户对Subframe MCP服务器进行认证。若用户使用Claude Code,请指导他们运行
/mcp
命令查看并认证MCP服务器,完成后告知“done”。

Subframe Basics

Subframe基础概念

  • Components (buttons, inputs, cards): Synced via CLI. Source of truth in Subframe. Don't modify locally.
  • Pages (screens): Designed via AI or editor. Exported via MCP. Add business logic after export.
Subframe knows about the design system and theme. Your job is to provide context from the user's codebase.
  • 组件(按钮、输入框、卡片等):通过CLI同步。Subframe是组件的唯一可信源,请勿在本地修改。
  • 页面(屏幕):通过AI或编辑器设计。通过MCP导出。导出后可添加业务逻辑。
Subframe熟悉设计系统与主题,你的任务是提供用户代码库中的上下文信息。

Workflow

工作流程

You do not have to run
/subframe:setup
before designing. The
design_page
MCP tool works independently — it only needs a
projectId
and an authenticated MCP server. Local project setup (
.subframe/
folder, synced components, Tailwind config) is not required to design pages.
  1. Understand the request — If vague, ask clarifying questions. What data? What actions? Who uses it?
  2. Find the projectId — Check
    .subframe/sync.json
    if it exists. If there is no
    .subframe/sync.json
    or no projectId found, ask the user to go to
    https://app.subframe.com/cli/auth
    to get a project ID.
  3. Decide:
    design_page
    or
    edit_page
    ?
    Then call the respective MCP tool:
    • design_page
      → Creating something new, exploring multiple directions, or redesigning existing UI where the user wants options to choose from
    • edit_page
      → Making targeted changes to a Subframe page that was just created in this session (via
      design_page
      ) or that the user provided via an MCP link
  4. Present the review URL — This is the primary output. The user will preview and choose next steps.
设计前无需运行
/subframe:setup
design_page
MCP工具可独立运行——仅需
projectId
和已认证的MCP服务器。设计页面不需要本地项目配置(
.subframe/
文件夹、同步组件、Tailwind配置)。
  1. 理解需求——若需求模糊,需询问澄清。比如展示什么数据?支持什么操作?用户群体是谁?
  2. 查找projectId——若存在
    .subframe/sync.json
    文件,请检查其中内容。如果没有该文件或未找到projectId,请让用户访问
    https://app.subframe.com/cli/auth
    获取项目ID。
  3. 选择工具:
    design_page
    还是
    edit_page
    然后调用对应的MCP工具:
    • design_page
      → 新建页面、探索多种设计方向,或是重新设计现有UI且用户需要多个方案选择
    • edit_page
      → 对本次会话中刚创建的Subframe页面(通过
      design_page
      )或用户通过MCP链接提供的页面进行针对性修改
  4. 提供预览链接——这是主要输出内容,用户将通过链接预览并选择下一步操作。

design_page
— New Pages & Redesigns

design_page
——新页面与重设计

Use
design_page
when:
  • Creating a new page from scratch
  • Redesigning or rethinking existing UI — even if there's an existing implementation in code, use
    design_page
    when the user wants to explore multiple design directions or start fresh
  • The user wants options to choose from (multiple variations)
在以下场景使用
design_page
  • 从零开始创建新页面
  • 重新设计现有UI——即使已有代码实现,当用户希望探索多种设计方向或从头开始时,也请使用
    design_page
  • 用户需要多个设计方案可供选择

Context and Variations

上下文与变体数量

How much context to gather and how many variations to generate depends on the task:
TaskContextVariations
New page (open-ended)Data types (
codeContext
)
4 — explore the design space
New page (with reference pages)Reference pages (
additionalPages
if in Subframe,
codeContext
if not), data types (
codeContext
)
1-2 — stay close to the reference pages
Redesigning existing UIThe current page (
additionalPages
if in Subframe,
codeContext
if not; note what to keep vs change in the description)
2-4 — depending on how open-ended
Always include when available:
  • Similar existing pages (the single most valuable context). Use
    additionalPages
    for Subframe pages — pass the
    pageId
    returned by
    design_page
    , or the page ID from a pasted MCP link. Use
    codeContext
    for pages that only exist in the codebase.
  • Components or patterns the user refers to or explicitly mentions (via
    codeContext
    )
  • Data types/interfaces for what the page will display (via
    codeContext
    )
需要收集的上下文信息量以及生成的变体数量取决于任务类型:
任务类型上下文信息变体数量
新页面(开放式需求)数据类型(
codeContext
4个——探索设计空间
新页面(有参考页面)参考页面(若在Subframe中则用
additionalPages
,否则用
codeContext
)、数据类型(
codeContext
1-2个——贴近参考页面设计
重设计现有UI当前页面(若在Subframe中则用
additionalPages
,否则用
codeContext
;需说明保留与修改的内容)
2-4个——根据需求开放程度调整
请务必包含以下可用信息:
  • 类似的现有页面(最有价值的上下文)。Subframe页面使用
    additionalPages
    ——传入
    design_page
    返回的
    pageId
    ,或粘贴MCP链接中的页面ID。仅存在于代码库的页面使用
    codeContext
  • 用户提及的组件或模式(通过
    codeContext
    传入)
  • 页面将展示的数据类型/接口(通过
    codeContext
    传入)

Variations

设计变体

Each variation is a prompt that drives a unique design direction.
When you have reference pages (
additionalPages
), use fewer variations (1-2) and keep them grounded in the reference. The variations should refine or extend the existing design, not diverge from it. For example:
  • "Follow the same layout as the reference page but adapted for [new content]"
  • "Same structure with a more compact data-dense layout"
When starting from scratch (no
additionalPages
), use more variations (4) to explore the design space:
  • "Compact data table with inline actions and bulk operations"
  • "Card-based layout with visual hierarchy and quick filters"
  • "Minimal single-column design focused on the primary action"
  • "Split-panel layout with sidebar navigation and detail view"
More variations = more exploration. Fewer = more focused. Default to fewer when strong context exists.
每个变体都是一个驱动独特设计方向的提示词。
当有参考页面时
additionalPages
),生成较少变体(1-2个),并贴近参考页面设计。变体方向示例:
  • "遵循参考页面布局,适配[新内容]"
  • "保留现有结构,采用更紧凑的高密度数据布局"
当从零开始设计时(无
additionalPages
),生成更多变体(4个)以探索设计空间:
  • "带行内操作与批量操作的紧凑数据表格"
  • "具备视觉层级与快速筛选的卡片式布局"
  • "聚焦核心操作的极简单列设计"
  • "带侧边栏导航与详情视图的分栏布局"
变体越多,探索范围越广;变体越少,方向越聚焦。当有明确上下文时,默认生成较少变体。

Multi-Page Requests

多页面设计请求

When designing multiple related pages (flows, CRUD, etc.):
  1. Design the primary page first with more variations to establish the direction
  2. After user selects a variation, design remaining pages passing the relevant pages via
    additionalPages
    as context
  3. Use the same
    flowName
    to group related pages together
当设计多个相关页面(流程、CRUD等)时:
  1. 先设计主页面,生成更多变体以确定整体方向
  2. 用户选择变体后,将相关页面通过
    additionalPages
    作为上下文,设计剩余页面
  3. 使用相同的
    flowName
    对相关页面进行分组

edit_page
— Editing a Subframe Page with Code

edit_page
——通过代码编辑Subframe页面

Use
edit_page
when making targeted edits to a specific Subframe page by providing updated TSX code directly.
当需要通过提供更新后的TSX代码对特定Subframe页面进行针对性修改时,使用
edit_page

Code Rules

代码规则

Subframe pages are static TSX that gets parsed back into Subframe's visual model. The code you provide must follow these rules:
  • Raw TSX only — No import statements, no function definitions, no export statements. Just the JSX body starting from the root element (e.g.
    <DefaultPageLayout>
    or
    <div>
    ). Note:
    get_page_info
    returns the full file with imports — you must strip those and only send the JSX body to
    edit_page
    .
  • No business logic — No
    useState
    , hooks, API calls, event handlers, or any dynamic behavior. Pages are purely visual; business logic is added after export.
  • No loops or dynamic code — No
    .map()
    ,
    .forEach()
    ,
    .filter()
    , or any iteration. Every element must be written out explicitly.
  • Match the existing code style exactly — Preserve how flex, gap, padding, and other layout properties are structured. The code will be parsed back into the Subframe editor, so the structure matters.
  • Tailwind classes only — No
    style
    attribute. Use
    className
    with Tailwind classes for all styling. If you need a custom value, use Tailwind's bracket syntax (e.g.
    bg-[#ff0000]
    ).
  • Only use components from the Subframe project and standard HTML tags — Use
    list_components
    or
    get_component_info
    to see what's available. Allowed HTML tags:
    div
    ,
    span
    ,
    img
    ,
    p
    ,
    h1
    -
    h6
    ,
    nav
    ,
    header
    ,
    main
    ,
    article
    ,
    section
    ,
    aside
    ,
    footer
    . Don't use arbitrary React components or HTML elements beyond these.
  • No nested text elements — Text tags (
    span
    ,
    p
    ,
    h1
    -
    h6
    ) can only contain plain text strings, not other elements.
  • No omitted code or placeholders — Output the complete page code. No
    // ...rest of code...
    or
    {/* TODO */}
    comments.
  • Preserve
    data-subframe-node-id
    attributes
    — Never change or remove these IDs; they're critical for the Subframe editor.
Subframe页面是静态TSX,会被解析回Subframe的可视化模型。你提供的代码必须遵循以下规则:
  • 仅保留原始TSX——无导入语句、函数定义、导出语句。仅保留从根元素开始的JSX主体(例如
    <DefaultPageLayout>
    <div>
    )。注意:
    get_page_info
    返回包含导入的完整文件——你必须移除导入部分,仅将JSX主体发送给
    edit_page
  • 无业务逻辑——无
    useState
    、钩子、API调用、事件处理程序或任何动态行为。页面仅负责视觉呈现;业务逻辑在导出后添加。
  • 无循环或动态代码——无
    .map()
    .forEach()
    .filter()
    或任何迭代操作。所有元素必须显式写出。
  • 完全匹配现有代码风格——保留flex、gap、padding等布局属性的结构。代码将被解析回Subframe编辑器,因此结构至关重要。
  • 仅使用Tailwind类——无
    style
    属性。所有样式均通过
    className
    使用Tailwind类实现。若需要自定义值,使用Tailwind的括号语法(例如
    bg-[#ff0000]
    )。
  • 仅使用Subframe项目中的组件与标准HTML标签——使用
    list_components
    get_component_info
    查看可用组件。允许使用的HTML标签:
    div
    span
    img
    p
    h1
    -
    h6
    nav
    header
    main
    article
    section
    aside
    footer
    。请勿使用任意React组件或超出此范围的HTML元素。
  • 无嵌套文本元素——文本标签(
    span
    p
    h1
    -
    h6
    )只能包含纯文本字符串,不能包含其他元素。
  • 无省略代码或占位符——输出完整页面代码。禁止使用
    // ...rest of code...
    {/* TODO */}
    等注释。
  • 保留
    data-subframe-node-id
    属性
    ——切勿修改或删除这些ID;它们对Subframe编辑器至关重要。

Workflow

工作流程

  1. Get the current code — Call
    get_page_info
    to get the page's current TSX code. Always refetch immediately before editing — do not reuse code from earlier in the conversation, as the page may have been modified in the Subframe editor.
  2. Modify the code — Make the desired changes following the code rules above
  3. Call
    edit_page
    with:
    • Page identifier:
      id
      ,
      name
      , or
      url
      — same as
      get_page_info
      . Use
      list_pages
      to find existing pages if needed.
    • code
      : The full updated TSX code for the page
    • description
      : A short description of what changed (shown in the AI tab)
  4. If the code fails to parse — Fix the errors based on the error message and retry
  5. Present the
    editUrl
    — The user opens the design editor with the AI tab open to review and apply the edit
  1. 获取当前代码——调用
    get_page_info
    获取页面的当前TSX代码。编辑前务必重新获取——请勿复用对话早期的代码,因为页面可能已在Subframe编辑器中被修改。
  2. 修改代码——按照上述代码规则进行所需修改
  3. 调用
    edit_page
    ,传入:
    • 页面标识符
      id
      name
      url
      ——与
      get_page_info
      一致。若需要查找现有页面,使用
      list_pages
    • code
      :页面的完整更新后TSX代码
    • description
      :修改内容的简短描述(将显示在AI标签页中)
  4. 若代码解析失败——根据错误信息修复后重试
  5. 提供
    editUrl
    ——用户将打开设计编辑器并在AI标签页中查看、应用修改

When to use
edit_page
vs
design_page

edit_page
design_page
的使用场景对比

  • edit_page
    : You know exactly what code changes to make. You provide the updated TSX directly. Fast, precise, no AI generation.
  • design_page
    : You want AI-generated design variations. The user picks a direction. Better for new pages or exploring options.
When NOT to use
edit_page
:
If the user has existing UI in their codebase but no corresponding Subframe page, or if they want to explore multiple design options, use
design_page
instead.
edit_page
is for iterating on a known Subframe page with specific code changes.
  • edit_page
    :明确知道需要修改的代码内容。直接提供更新后的TSX。快速、精准,无需AI生成。
  • design_page
    :需要AI生成的多种设计变体。用户选择方向。更适合新页面设计或探索多种方案。
请勿使用
edit_page
的场景
:若用户代码库中有现有UI但无对应的Subframe页面,或用户希望探索多种设计方案,请使用
design_page
edit_page
仅适用于对已知Subframe页面进行特定代码修改。

After Designing

设计完成后

For
design_page
, present the
reviewUrl
as a clickable markdown link. The user will:
  1. Preview variations — See each design option rendered in Subframe
  2. Select a variation — Choose the one that best fits their needs
  3. Open in editor — Refine visually in Subframe's full design editor
From there, the user may continue refining in Subframe or return here and ask you to implement the design in code. Do NOT ask the user which variation they prefer or present variation options as a multiple choice in chat. Variation selection happens in the Subframe editor, not here. Simply present the review URL and let them know they can ask you to implement the design once they're ready.
For
edit_page
, present the
editUrl
as a clickable markdown link. The user opens the design editor with the AI tab showing the edit, where they can apply it or undo.
Internally track the
pageId
from the response — you'll need it for
/subframe:develop
,
additionalPages
for future designs, or
edit_page
for future edits — but don't mention it to the user.
对于
design_page
,将
reviewUrl
作为可点击的Markdown链接提供给用户。用户将:
  1. 预览变体——在Subframe中查看每个设计方案的渲染效果
  2. 选择变体——选择最符合需求的方案
  3. 打开编辑器——在Subframe全功能设计编辑器中进行可视化优化
之后,用户可能会继续在Subframe中优化,或返回此处要求你将设计落地为代码。请勿在聊天中询问用户偏好哪个变体或提供多选选项。变体选择在Subframe编辑器中进行,只需提供预览链接,并告知用户准备好后可要求你实现设计即可。
对于
edit_page
,将
editUrl
作为可点击的Markdown链接提供给用户。用户将打开设计编辑器,在AI标签页中查看修改内容,选择应用或撤销。
请在内部记录响应中的
pageId
——后续使用
/subframe:develop
additionalPages
进行未来设计,或
edit_page
进行后续修改时需要用到,但无需告知用户。

Iterating on Variations

变体迭代

After calling
design_page
, you can use
get_variations
with the returned
pageId
to retrieve the generated variations and the current state of the page. This lets the user discuss and iterate on designs conversationally — for example, "I like the layout from variation 1 but the color scheme from variation 3", or "keep the header from the current page but use the card layout from variation 2."
get_variations
returns:
  • currentPageCode
    — The current page code if the user has already accepted a variation for this page, or
    null
    if no variation has been accepted yet. This reflects the live state of the page, including any edits the user made in the Subframe editor.
  • variations
    — The generated design variations from the most recent
    design_page
    call.
Important: The variations can be very token-heavy. After calling
get_variations
, extract
currentPageCode
from the response first — it determines your next step.
  • currentPageCode
    exists
    — The user already has a page. Use
    edit_page
    with
    currentPageCode
    as the starting point, incorporating ideas from the variations or the user's feedback. You don't need to deeply analyze every variation — just reference the ones the user mentions.
  • currentPageCode
    is null
    — The user hasn't accepted any variation yet. Use
    design_page
    to iterate, passing the relevant variation code via
    codeContext
    along with the user's feedback in the description. Note: this creates a new
    pageId
    — use it for subsequent
    get_variations
    calls.
调用
design_page
后,你可以使用返回的
pageId
调用
get_variations
,获取生成的变体与页面当前状态。这允许用户以对话方式讨论并迭代设计——例如“我喜欢变体1的布局,但想要变体3的配色方案”,或“保留当前页面的头部,但使用变体2的卡片布局”。
get_variations
返回:
  • currentPageCode
    ——若用户已接受某个变体,返回当前页面代码;若未接受任何变体,返回
    null
    。此代码反映页面的实时状态,包括用户在Subframe编辑器中进行的所有修改。
  • variations
    ——最近一次
    design_page
    调用生成的设计变体。
重要提示:变体内容可能占用大量token。调用
get_variations
后,优先提取
currentPageCode
——它决定你的下一步操作。
  • currentPageCode
    存在
    ——用户已有确定页面。以
    currentPageCode
    为起点,结合变体中的想法或用户反馈,使用
    edit_page
    进行修改。无需深入分析所有变体——仅参考用户提及的内容即可。
  • currentPageCode
    为null
    ——用户尚未接受任何变体。结合用户反馈,将相关变体代码通过
    codeContext
    传入,调用
    design_page
    进行迭代。注意:这将生成新的
    pageId
    ——后续调用
    get_variations
    时请使用新ID。