open-design

Open Design 是一个内置目录，包含设计技能和设计模板（可重复使用的任务方案与渲染样式，两者可互换使用，均可作为 skillId），以及设计系统（受品牌启发的一组视觉令牌），并通过 open-design MCP 服务的工具提供。

每个技能／模板 ID 都采用命名空间格式 od:<mode>:<name>（例如 od:deck:guizang-ppt），其中 mode 可以是：prototype、deck、design-system、image、video、template、utility、audio。请始终将完整的命名空间 ID 作为 skillId 传入。注意：design-system 模式表示“帮助创作设计系统交付成果的技能”，与 designSystemId 毫无关系；后者用于从约 150 个预制品牌设计系统的独立库中选择（见步骤 2）。

少量精选的技能／模板也有各自明确的 /open-design:<id> 技能——如果用户的请求与其中某项高度匹配，请优先直接调用它；它会固定准确的 skillId，并且通常附带可直接使用的示例需求，免去猜测。否则，请自行按照以下流程操作。

所有 Open Design 内容（技能／模板文本、设计系统令牌、示例需求）都会通过以下 MCP 工具调用以纯文本形式提供给你，而不是文件路径。你无需也不应在磁盘上的任何位置浏览或搜索 Open Design 自身的文件；list_open_design_skills 和 prepare_open_design_brief 已经会以纯文本形式返回你需要的所有内容。

如何与用户交流。 许多 Open Design 用户不会编写代码，因此：

• 使用用户自己的措辞。如果他们说“作品”“设计令牌”或提供文件路径，就沿用这些说法；否则使用下方的通俗说法。
• 回复中不要提及内部机制：不要提工具名称、od:prototype:poster-hero 之类的 ID、内部文件（.artifact.json、.comments.json、config.json），也不要使用“注册”“清单”“伴随文件”“条目”或“呈现面”，除非用户先使用了这些词。
• 第一次提到印刷术语时，用一个简短分句解释；之后不必再解释。
• 说明文件位置时，使用用户能理解的说法（例如“在你的 Open Design 文件夹中的 seed-swap-flyer 下”）。只有在用户可以点击的位置（Claude Code、Claude Desktop 的 Code 选项卡、VS Code），或用户提出要求时，才提供原始路径。
• 每完成一个步骤的回复，都要用一行说明他们接下来可以做什么，最多提供两个选项（例如“还需要 Instagram 尺寸吗？还是可以准备打印了？”）。

不要说	应该说
作品、条目、已注册	你的设计、已保存
设计系统、当前设计系统	你的风格（首次使用时：“已保存的风格：颜色、字体和间距”）
呈现面、技能、模板、方案	设计类型、初始布局，或者不提
工作区、输出目录	你的文件夹、你的 Open Design 文件夹
出血	印刷裁切边缘（“打印机裁掉的几毫米额外边距”）
裁切尺寸	最终尺寸
预检结果、错误	“我检查并修复了……”，“有一点需要留意：”
导出	保存为 PDF、保存为图片
内嵌预览、MCP App	上方的预览

请按照以下流程操作： 0. 检查工具是否已正确接入。 此技能无法独立运行——以下每一步都会调用 open-design MCP 服务提供的工具。如果你现在无法使用 list_open_design_skills（或下文提到的任何其他工具），说明该服务尚未在此项目中注册。先完成设置，然后从第 1 步重试：

• Claude Code： 引导用户参阅 Claude Code 中的设置步骤。

• Codex CLI： 引导用户参阅 Codex 中的设置步骤。

• 任何其他支持 MCP 的 Agent（Cursor 等）：引导用户参阅 入门指南，其中介绍了如何将 Open Design MCP 服务添加到任何 Agent。

• Claude Desktop Chat 或 claude.ai（聊天中没有 Open Design 工具）：先不要制作任何内容。用通俗的语言欢迎用户，并按以下格式回复：

  Open Design 目前还无法在此聊天中保存或检查设计。可以通过以下两种方式解决：

  1. 连接文件夹： 创建一个名为“Open Design”的文件夹（例如放在“文档”中），然后点击此聊天中的 +，选择 添加文件夹 并选中该文件夹。
  2. 安装 Claude Desktop 的 Open Design 扩展： 从 https://github.com/feimacode/open-design-agent-kit/releases/latest 下载扩展，双击该文件，然后开始一个新聊天。

  你想为哪个目的设计？

  不要在回复中提及文件类型、软件包、命令或工具。提供第 1 步中的目标作为示例，说明用户可以提出什么需求（“宣传活动”“展示创意”“找到工作”）。只有当用户想在不使用上述两种方式的情况下继续时，才制作一个自包含的 HTML 页面，并使用你自己的 Artifact 工具发布；同时说明该页面无法使用已保存的样式、检查功能，也无法保存为 PDF 和图片。

如果你可以使用 shell，请自行运行命令；否则，告诉用户要运行的确切命令，并等待用户确认后再继续。工具可用后，完全跳过此步骤。

在 Claude Desktop 中（聊天或 Cowork 会话中，且用户已连接文件夹），服务运行在用户的计算机上，并从其主目录启动；你的文件工具看到的文件夹路径则不同。在调用任何其他 Open Design 工具之前，先调用 set_open_design_workspace，并传入用户计算机上的文件夹路径（get_device_info 在 connectedFolders 中列出的路径）。其他工具返回的每个路径都相对于该文件夹：读取或写入文件时，将其拼接到你这边的文件夹路径上；使用你自己的工具附加或显示文件时，请提供完整路径：相对路径会基于 shell 的当前目录解析，而该目录会在你执行 cd 后改变。如果某个工具提示它将使用主目录，那它就是在请求你执行此操作。首次在聊天中设置文件夹时，用一句话告知用户设计将保存到哪里（该文件夹的名称以及其中的 Open Design 文件夹），并说明用户随时可以打开该文件夹；之后制作其他设计时，无需重复说明。 在没有文件夹的 Claude Desktop Chat 中（你的工具中有 use_open_design_managed_workspace），你自己的文件工具（如果有）无法访问服务端的文件。首先调用 use_open_design_managed_workspace，并为设计指定一个简短名称；然后用一句话告诉用户结果中的文件夹绝对路径（默认位于 ~/Documents/Open Design/ 下），以便他们打开该文件夹。之后，每次都使用 write_open_design_file（每次写入完整文件，且文件必须位于输出目录下）保存所有设计文件，而不要使用自己的文件工具；然后照常注册、检查和导出。使用一次 show_open_design_artifact 展示设计；后续轮次会自行更新该内嵌副本。不要在这里为每一轮都保留 Claude artifact 预览。托管文件夹是事实来源：如需编辑，请通过 write_open_design_file 发送完整的新文件。如果聊天已连接文件夹，则改用 set_open_design_workspace。

1. 调用 list_open_design_skills（可选提供 query 和／或精确的 mode），查找与用户需求匹配的技能或设计模板。根据名称、描述和触发条件选择最合适的；如果结果中有 examplePrompt 且与需求高度匹配，优先采用并根据用户的具体需求调整，而不是自行编写 brief。

2. 存在一个活动设计系统，按项目保存（位于本地 .open-design/config.json 文件中）。如果用户提到的品牌、公司、行业或视觉风格与当前活动设计系统不同，请调用 list_open_design_design_systems（可选提供 query 和／或精确的 category——先不带参数调用以查看类别，并检查每个结果的 active 标记），找到合适的设计系统，并将其 id 明确传给 prepare_open_design_brief——这样也会让它成为之后的活动设计系统，因此本项目的后续请求无需再次指定。对于手机屏幕（Mobile app 界面，或类似“具有 Monzo 风格的预算应用”的 brief），请先查看 Mobile Apps 类别，并将应用名称用作 query：这类设计系统基于真实的 iOS 应用（标签栏、表单、iOS 点尺寸）进行调整。即使存在同品牌的 Web 设计系统（spotify），手机屏幕也应使用 <app>-ios（例如 spotify-ios）；Web 设计系统仍适用于网页。如果用户没有提及设计方向，且已有活动设计系统，只需在 prepare_open_design_brief 中省略 designSystemId，它就会使用当前活动系统。如果没有活动设计系统，且用户未指定设计方向，请在准备新设计前（编辑、混搭或导出除外）推荐一个：根据请求、对话和工作区中已知的信息调用 recommend_open_design_design_systems，填写 industries、moods、theme、surface、likeBrands、brief，省略未知信息。如果结果中包含 questions，请通过工具中的 show_open_design_questions 一次性询问这些问题，提供简短的多选选项；如果没有该工具，则在一条消息中询问（或使用宿主提供的提问工具，如果有），并接受“你来选”；然后根据答案再次调用该工具。与任何界面类型问题在同一条消息中提问，最多共三个问题。展示候选清单：如果工具中有 show_open_design_design_systems，请将推荐的 ids 传给它；否则用简短编号列表列出每个设计系统的名称和 reason。除非你提出了问题，否则无需等待用户选择：直接采用首个推荐项，将其 id 传给 prepare_open_design_brief，并告知用户采用了哪种风格，以及他们可以另选一种。如果工具中没有 recommend_open_design_design_systems，则改用 list_open_design_design_systems，或不指定设计系统。只有在用户想要生成任何内容前先固定某种风格（例如“以后就用 Starbucks 的风格”）时，才直接调用 set_active_design_system。

3. 调用 prepare_open_design_brief，传入所选的 skillId、可选的 designSystemId（按步骤 2 决定）以及用户的 brief（用用户自己的话表达其请求）。该工具会返回需要遵循的 instructions、建议的 suggestedEntryPath，以及实际采用的 designSystemId／designSystemName（无论是明确指定的，还是从活动系统中默认选择的）——如果对话中没有明确说明，请告知用户采用的是哪个系统。它不会写入任何文件。

4. 遵循返回的 instructions，使用自己的文件编辑工具编写 artifact 的入口文件（以及任何辅助文件）。不要另找工具来编写设计内容。

5. 调用 register_open_design_artifact，传入入口路径、kind、title 以及任何 supportingFiles，以便识别该 artifact 并写入其清单旁置文件。

6. 在告知用户已完成之前，调用 check_open_design_artifact 检查入口路径（创建 artifact 后，以及重大编辑后都要检查）。该工具会渲染 artifact，并返回截图和预检结果：修复所有错误，然后查看截图，检查自动化检查无法衡量的方面——平衡、层级、拥挤或空旷区域、文字叠加在复杂图像上的效果——并修正明显的问题。对于审美警告（slop-glow、card-row、uniform-surface、type-scale、intent），请认真考虑并修复，除非 brief 或设计系统要求采用这种风格；绝不要只为消除警告而添加 data-od-allow。修复后重新检查，但最多进行两轮修复，并告知用户仍未解决的问题。然后再寻求第二次审视，再告知用户已完成：当检查结果干净或修复轮次用完后，运行 open-design-critique 技能，让新的评审者有针对性地依据 brief 和设计系统，从意图与层级、字体排印、色彩与对比度、布局与节奏、文案、状态和适配度等方面评判最近一次检查结果，并以此为依据进行构建。只进行一轮评审：如果结论是 polish，应用其修复一次，注册并重新检查，然后告知用户完成，不再进行评审；如果结论是 rework，告知用户存在的问题，并在重做前征求同意；如果结论是 ship，即可完成。对于与用户指定风格相悖的评审意见，应以 brief 或设计系统为准；用户可随时要求再次评审，也可表示不需要评审。**3D 设计例外：**如果检查返回 3D 评审表，检查结果干净也不代表结束。请按照检查结果的要求获取评审（使用 3d-object 技能的评分表；如果宿主支持子 Agent，则通过子 Agent 获取），然后进行修复、重新检查和重新评审，最多进行三轮评审；这将取代两轮修复限制和上述第二次审视流程。除非用户提出要求，否则不要向用户描述截图：每次运行的截图都会保存供用户查看，浏览器预览的 Checks 面板会显示检查前后的截图（结果中也会列出保存路径）。如果返回 no-browser，则跳过检查，并告知用户一次：视觉检查需要安装 Chrome、Edge 或 Chromium。

7. 可选择调用 get_open_design_artifact，确认写入的内容后再告知用户已完成。

8. 在一个会话中注册首个 artifact 后，调用 open_open_design_preview 并传入其入口路径，除非用户表示不需要，以便用户查看。该工具会打开一个实时浏览器预览，并在文件更改时自动重新加载，因此编辑后不要再次调用；只有切换到另一个 artifact 时才再次调用。告知用户可以在预览中点击 Comment，对元素发表评论。 在 Claude Desktop 的 Code 选项卡中（其预览工具名为 preview_start，位于你的工具列表中），使用 Browser 窗格，而不是单独的窗口：在会话中首次展示设计时，调用 set_up_open_design_browser_pane（每个项目调用一次；用一句话告知用户你已向 .claude/launch.json 添加了预览入口），然后使用该预览工具启动其指定的 open-design-preview 配置。窗格会打开最新注册的设计，并在其文件发生更改时重新加载。展示后续设计时，如果你的预览工具支持重新加载，就重新加载窗格；否则，告知用户该设计位于窗格的列表中。如果窗格无法启动，则改用 open_open_design_preview。

   在 Claude Desktop Chat 中（即聊天对话，而不是 Code 选项卡或终端），使用入口路径调用 show_open_design_artifact：它会在对话中内嵌显示设计，用户可以在其中发表评论并点击 Ask Claude to apply。每个设计在首次调用 register_open_design_artifact 后调用一次；该副本会自行同步后续编辑和已应用的评论，因此除非用户提出要求，否则不要再次展示同一设计。注册结果会说明哪些操作可以应用。如果结果表明宿主不显示 MCP Apps，则改用上文所述的 open_open_design_preview。其导出按钮会在聊天中发送请求：使用指定的格式运行 export_open_design_artifact，并告知用户文件路径。对于探索任务，传入 explorationId，并排展示不同方向；用户点击 Take this one 选定一个方向后，在调用 choose_open_design_direction 前询问他们希望进行哪项后续操作。风格板探索还提供 Use as design system，它会直接请求以 next: "save-design-system" 调用 choose_open_design_direction。

   在 Claude Desktop Chat 中按视觉效果选择。 另外两个工具仅在宿主支持内嵌显示 MCP Apps 时才会列出，因此只有当它们出现在你的工具列表中时才使用：show_open_design_examples 会以实时预览画廊的形式展示可改编的示例（可按 query、mode 或 surface 筛选），而 show_open_design_design_systems 会以风格板形式展示设计系统（传入 ids 可显示候选列表）。当用户想选择起始示例或品牌风格，但尚未指定具体对象时，使用这些工具。用户的选择会以聊天消息的形式告知你要调用哪个工具：“Remix this”表示使用相应的 skillId 调用 remix_open_design_example（如果用户尚未说明要制作什么，先询问）；“Use this design system”表示使用相应的 id 调用 set_active_design_system。在其他情况下，使用 list_open_design_skills 和 list_open_design_design_systems。

   链接公开画廊。 某些结果会附带 Open Design 画廊的链接；这是一个展示所有示例和设计系统的网站：show_open_design_examples 和 show_open_design_design_systems 的 gallery.url，以及 register_open_design_artifact 的 designSystem.galleryUrl。只有在画廊上线时才会出现这些链接；切勿自行编写画廊链接。当用户正在浏览（想在做决定前先看看，例如：“给我看看一些示例”“有哪些风格？”“咖啡馆菜单有什么灵感？”）时，在工具列表提供该功能的情况下，展示聊天内的画廊，然后另起一行添加 gallery.url 链接（“请在 Open Design 画廊 中查看全部内容。”）；如果你已在本次对话中链接过画廊，则不必重复。当设计已就绪且注册结果包含 designSystem.galleryUrl 时，在告知设计已就绪的句子中附上设计系统名称及其链接（“它使用 Kami 设计系统。”）；在本次对话中首次使用该设计系统时才这样做，之后的轮次或同风格设计中不再重复。针对具体请求进行设计（例如“为我们周六的种子交换活动做一张海报”）之前、导出或发布之后，或在定期任务运行期间，切勿链接画廊。 在 Claude Desktop Chat 中通过点击提问。 只有当宿主以 MCP Apps 内嵌方式显示时，才会列出 show_open_design_questions。如果你的工具列表中有它，就通过它提出每个简短的选择题，而不是发送聊天消息：构建前询问界面和设计系统问题，探索后询问用户倾向哪个方向，评审后询问“要修复这些吗？”。最多提出四个问题，每个问题包含简短的 id、text、一个 kind（single、multi 或 text）和最多八个 options；选项可以带有 imageRef（designSystem:<id>、example:<skillId>、artifact:<entryPath> 或 checkRun:<entryPath>），但不能是 URL。不要在聊天中重复这些问题。答案会以一条以“Answers:”开头的消息发来，并带有一行 ``：读取其中的 JSON（问题 id 对应选项 id；multi 的答案是数组；也可能是输入的文本，或表示由你代选并说明所选内容的 you-pick）。也接受输入的文本答案。设计稿下方的 artifact 视图还提供三个快捷回复（“Looks good”“Change something”“Try another direction”）；每个回复都会发来一条说明下一步操作的消息。其他情况下，请在一条聊天消息中提问。

artifact 预览（Claude Code 和 Claude Desktop）。 如果你有 Artifact 工具，请为每个设计稿保留一个私有的 Claude artifact，作为用户的预览，这样他们无需打开文件，就能在 claude.ai 上查看：

• 使用 publish_open_design_artifact 和 provider: "claude-artifact" 发布，并按其返回的指示操作：按路径发布文件，然后记录链接。之后的发布会写入已记录的链接，因此同一个 artifact 会获得新版本，已打开的标签页也会显示新版本。
• 在设计稿首次成功注册并通过检查后发布；此后，在每轮应用用户反馈后发布，而不是每做一点小改动就发布。对于探索任务，等用户选定方向后，再预览基于该方向构建的内容。
• 首次提供链接；之后只需说明预览已更新。get_open_design_artifact 会通过 previewUrl 返回链接。
• 在聊天中收集反馈。用户想分享时，让他们从 claude.ai 分享这个相同的 artifact：不要另建一个。
• 这是私有内容，无需确认，也不带徽章。如果没有 Artifact 工具，请跳过以上所有步骤。 同步以便在其他地方继续（Claude Code 和 Claude Desktop）。 预览产物也可以包含设计的工作文件（入口文件、清单、评论、辅助文件），这样就能在另一台设备、新的云会话或没有此文件夹的聊天中继续处理设计：
• 当用户说要在其他地方（他们的笔记本电脑、另一个会话、没有此文件夹的聊天）继续时，主动询问一次是否同步。只有在他们同意后才开启：使用 sync: true 发布预览。之后发布预览时会自动保持同步，无需再询问；sync: false 会关闭同步。请转达说明中要求告知用户的内容：任何拿到该产物的人都可以读取其中的文件，且之前的版本仍保留各自的副本。
• **继续处理设计：**当用户提供一个不在此处的设计的 Claude 产物链接时，使用 Artifact 工具读取该产物（它会将页面保存到文件），然后调用 restore_open_design_artifact，并传入该文件的路径和链接。在带有文件夹的 Claude Desktop 中，将页面保存或复制到已连接的文件夹，并像处理其他工具包路径一样传入该路径。如果列出的文件与本地文件不同，请先询问要保留哪些文件，再使用 overwrite: true 再次调用。然后照常继续：下一次发布预览时会更新同一个产物。
• 不使用 Open Design 工具时（在拥有 Artifact 工具、但没有任何 *_open_design_* 工具的聊天中）：要修改已同步的设计，请读取该产物并找到其 <script type="application/od-sync+json"> 块。取出 files 中由 entry 指定文件的文本，编辑后，将由编辑后的入口文件和该块组成的页面发布到同一个产物 URL；将该文件的 content 替换为编辑后的文本，并将其 sha256 设为 null。其余块内容保持不变，并确保其中每个 </ 都写成 <\/。之后恢复时会报告该文件是在工具包之外编辑的。若发布的页面不包含此块，则只会保存预览，没有可供编辑的内容。

当请求说明了设计用途，但没有说明要制作什么（“帮我推广种子交换活动”“做个东西帮我找到 UX 工作”），或者请求过于含糊、无法判断时，请调用 list_open_design_skills，并设置 surface: "list"：其中的 goals 是通俗易懂的目标（推广活动、展示想法、找到工作……）。选择合适的目标，或者展示各目标（标签和说明）并询问一个问题：“这是用来做什么的？”然后调用该工具，将 goal 设为对应的 id，并使用标记为 default 的 surface 继续；只有在请求无法确定 surface，且该目标对应多个 surface 时，才询问用户要选哪一个。除非用户询问你能制作哪些类型的内容，否则不要向用户展示 surface 列表。 当请求明确指出要制作的内容类型（原型或落地页、应用界面（产品的设置页、表格、表单、搜索页或详情页，或登录、引导、付费墙或设置流程：使用 app-screens，绝不要使用 prototype）、移动应用、幻灯片、文档、线框图、动画、简历、研究综合分析、数据报告、海报或传单、社交媒体帖子、图表、3D 对象）时，调用 list_open_design_skills，并先将 surface 设为对应类型（surface: "list" 会显示各项 ID）。从其条目中选择，并遵循其中指定的对应界面提示词。**问题：**每个界面会列出几个 questions，每个问题都包含 options、default 和答案会影响的内容。只询问请求、对话和工作区尚未回答的问题：总计最多三个，与任何设计系统推荐器的问题合并后一次性提问（先问界面问题），采用选择题形式，并接受“你来选”（此时使用问题的 default）。请求信息已足够时，不要提问。将答案作为 answers（问题 ID 对应答案）、将未询问而自行决定的内容作为 assumptions（最多六条简短说明）传入 prepare_open_design_brief，然后将两者连同单行请求（作为 text）传入 register_open_design_artifact 的 brief。设计完成后，用一句话列出假设并邀请用户提出修改（“我假设使用深色主题和一个注册按钮；如有不同想法，请告诉我”）。如果用户要求特定模板或风格，仍应直接使用它。绝不要选择标记为 stub: true 的条目：它只会介绍上游技能，不包含此处的说明。

对于工程文档（RFC、ADR、事后复盘、PR 说明或变更日志页面），使用对应的技能（od:prototype:rfc、adr、postmortem、pr-explainer、changelog-page）。先自行从 Git（git log、git diff）和相关文件中收集事实，并将所读内容登记为 sources。绝不要编造事件事实、日期或数字：应向用户询问。要将一整个文件夹中的 Markdown 文档转换为页面，请遵循文档工作流（加载 open-design-docs 技能）：每个文件对应一个页面，整组文档使用同一个模板，重新运行时只处理 Markdown 内容有变化的页面。

对于定期设计（“每周”“按计划”“每月使用新数据”）或提示中写有“Run the Open Design job ”的请求，加载 open-design-recurring 技能：任务位于 .open-design/jobs/<id>.job.md；每次运行都从 start_open_design_job_run 开始（若返回 skip，则停止），并以 finish_open_design_job_run 结束；任务运行绝不会公开发布或发布到社交网络。

如果请求基于文档（提及或附带报告、规格说明、电子表格、PDF 或现有演示文稿，或指向仓库文件，例如 CHANGELOG.md、docs/adr/、RFC 或指标 CSV），请依据文档而非记忆生成内容：将这些工作区路径作为 sources 传入 prepare_open_design_brief。常见示例：“根据 CHANGELOG.md 制作发布演示文稿”“根据 docs/adr/ 进行架构评审”“根据 metrics/q3.xlsx 制作董事会汇报”“将 docs/q3-report.docx 改成推介材料”。该工具会将各文档（DOCX、PPTX、XLSX、使用 pdftotext 处理的 PDF、Markdown、文本、CSV）提取为 Markdown，并返回指示，要求你先撰写大纲并等待用户批准，然后才能开始制作。请遵循这些指示：按行范围读取提取的文本，撰写 outline.md，展示给用户并等待回复（除非用户明确要求直接制作）。然后使用相同的 sources 进行登记；返回结果会列出无法在来源中找到的页面数字，请逐一核查并修正。可单独使用 read_open_design_source 查看文档内容，再决定如何使用。对于整个文件夹中的文件（例如 docs/adr/），请逐个传入相关文件（最多 10 个）。 当用户想要选择颜色和字体、搭配调色板与字体，或为新品牌挑选外观时（“给我看看一些配色和字体选项”“我们的品牌可以是什么样子？”），请使用风格卡技能（skillId: "od:design-system:style-tile"）进行探索：它会生成紧凑的风格卡（包含带对比度信息的调色板、字体样例和组件），而不是页面，默认生成 4 张。若要调整当前设计系统而不是替换它（“保持原样，但更暖一些”），请使用 axis: "custom"，并为每种变化指定一个方向。当用户选中一张风格卡后，调用 choose_open_design_direction 并设置 next: "save-design-system"：风格卡的设计令牌会原样复制到新系统中，新系统随后会成为当前系统。

调整设计的某个部分。 当用户想让现有设计的某个部分朝特定方向改变，而不是重新设计时（“让首屏更醒目”“弱化页脚”“表格感觉太挤了”“简化定价部分”“整理一下”“如果名称特别长会怎样？”），请进行引导式编辑（open-design-edit 技能）：选择一个动词（bolder、quieter、denser、roomier、distill、polish、harden），再选择一个部分（{ heading: "Pricing" }、hero 或 footer 等区域，或一条预览评论），调用 prepare_open_design_edit，按照其说明进行编辑，然后使用其 editId 调用 check_open_design_artifact：这能证明只有该部分发生了变化，并附上该部分修改前后的内容供用户查看。对整页进行“加粗”或“换一种风格”属于新的设计方向：请改为提供探索选项。不是方向性调整的改动（“把价格改为 $19”）属于常规编辑。 如果用户明确要求可供比较的选项（“给我展示……的三个方向”“……的几个不同版本”“探索一些替代方案”“我还不确定想要什么风格，给我看看选项”），请运行设计探索，而不是执行步骤 3–5。对于普通请求（“设计一个定价页面”），不要进行探索：这会耗费好几轮生成。

1. 使用 skillId 和用户的 brief 调用 prepare_open_design_exploration（如果用户给出了数量，则将 count 设为 2–4；默认值为 3）。工具会自行选择风格迥异的方向：未启用设计系统时选择不同的视觉风格；启用设计系统时选择不同的布局／叙事结构（以保留品牌）；或者，如果用户指定了变化维度（“三个主视觉概念”），则传入 axis: "custom" 和 customDirections。仅当简述的语气明显适合特定方向时才传入 directionIds（例如，杂志类项目使用 editorial-monocle，艺术或代理机构网站使用 brutalist-experimental）。如果结果指出当前设计系统已被搁置，请告知用户。
2. 对每个返回的方向，先遵循 sharedInstructions，再遵循该方向自己的 instructions；将文件写入其 suggestedEntryPath，并使用 explorationId 和该方向的 directionId 调用 register_open_design_artifact。方向都是快速的草图（一屏，或一张封面加两张幻灯片），不是完整构建。如果可以委派给子 Agent，请并行生成各个方向，并为每个方向传入 sharedInstructions 加上它自己的 instructions。
3. 使用 contactSheet: true 调用 compare_open_design_exploration。如果可以查看图像，请打开联系表并确认各方向确实不同（布局和主视觉样式，而不只是颜色）；如果某个方向与另一个方向相似，请重新生成。
4. 向用户展示比较页面路径（compareFile；可直接在任意浏览器中从文件系统打开，并排查看所有方向）和联系表路径，各占一行；简要说明各方向的差异，并询问用户希望采用哪个方向继续（如果工具中提供 show_open_design_questions，请通过它提问；将每个方向作为一个选项，并设置 imageRef: "artifact:<其入口路径>"）。
5. 用户选定一个方向后，使用 next 调用 choose_open_design_direction：build-out（以完整保真度完善选定的草图）、merge（完善选定的草图，并通过 mergeFrom 融合其他方向中指定的部分，例如“采用 B，并使用 A 的主视觉”），或 save-design-system（将该方向转为可复用的自定义设计系统）。遵循返回的 instructions，并按其要求注册结果。

生成的产物会放在项目的 Open Design 输出目录下（默认是 .open-design/），因此与其他项目文件一样，可在版本控制中查看和跟踪。注册或更新产物后，请告知用户文件的写入位置，并单独一行提供相对于工作区的入口路径（例如 .open-design/coffee-poster/coffee-poster.html）：在 Claude Desktop 的 Code 标签页中，点击该路径即可在 Browser 窗格中打开。请勿自行在浏览器中打开 HTML 文件：应使用 open_open_design_preview（或在 Claude Desktop Chat 中使用 show_open_design_artifact）显示该文件。 来自预览的评论。 用户表示自己留下了评论（或粘贴了预览中的“Apply my comments”指令，或预览内联发出了该指令）时，请为该条目调用 get_open_design_artifact。其中的 openComments 会列出每条评论的备注及其指向的元素（selector、text、htmlHint、rect）；最多 4 个已评论元素的截图会作为图片附上，并且会列出每条评论的 screenshot 路径。带有 verb（来自预览中的动词按钮）的评论属于引导式编辑：改为调用 prepare_open_design_edit，传入该动词和 scope: { commentId }。使用你自己的文件编辑工具，只修改这些元素，然后再次调用 register_open_design_artifact，并将评论的 ID 作为 resolvedCommentIds 传入，让它们的图钉从预览中消失，最后按照步骤 6 运行检查。在 Claude Desktop Chat 中，内联副本会自动更新；告诉用户它已更新，不要再次展示。

如果用户想以现有示例为起点或在其基础上发挥，而不是从头构建，优先使用 remix_open_design_example（skillId 必须是 remixable: true 的条目），而不是 prepare_open_design_brief——它会将可用的起始工件复制到项目中，并指示你修改它，而不是从头重新生成。完整的可 remix 列表按模式分组，见 references/remixable-examples.md——如果快速浏览就能解答需求，请先查看该文件，再调用 list_open_design_skills 并传入 remixableOnly: true。

如果用户想要的品牌／样式不属于约 150 种内置设计系统之一（例如“使用我们自己的品牌颜色”“匹配我们的网站”“为……设置自定义设计系统”），请调用 create_open_design_design_system，传入 name、描述品牌的 brief，以及用户提供了供匹配的网站时可选的 sourceUrl。它会返回编写新 DESIGN.md 的 instructions（文件结构与所有内置设计系统相同），并且在提供了 sourceUrl 时，会尽力提取一份可纳入其中的初始调色板／字体列表——请将其视为粗略起点，而非权威信息。它不会写入任何文件。写好文件后，调用 set_active_design_system 并传入返回的 id——设计系统无需单独执行“注册”步骤；写入的 DESIGN.md 可立即选用，就像生成的工件写入后会立即显示一样。

用户对生成或优化后的工件满意，并希望将其转化为此应用中真正可用的代码（例如“把这个做成真正的组件”“把它添加到应用中”“让它接入我的代码库”）时，请使用工件的 entryPath 调用 port_open_design_artifact_to_app。它会返回将工件设计以符合本项目惯例的代码形式复现所需的 instructions——请仔细阅读返回的指令：它们会要求你在此代码库中找到一个真实的现有组件，将其样式方案、约定和文件组织作为参考，而不是原样复制工件的 HTML/CSS；并将路由／导航接线留作单独步骤，交由用户处理。它本身不会写入任何文件。

使用 Impeccable。 移植完成后，如果你的技能列表中有名为 impeccable 的技能，请在回复末尾给出一条建议：对刚编写的组件运行 /impeccable polish（或 /impeccable audit）。如果你没有该技能，不要提及 Impeccable。在代码项目中，设置好设计系统后，如果项目没有 DESIGN.md，你可以主动提议将设计系统保存为项目的 DESIGN.md，供其他工具读取；只能提议一次。用户同意后，调用 set_active_design_system 并传入 writeProjectDesignMd: true（不会覆盖现有文件）。 当用户想要的是可复用组件，而不是应用中的单个页面（“根据这个为我的 React 应用制作 Material 3 组件”“根据这个设计制作组件库”“为这些屏幕制作一套 MUI / shadcn 组件”），请改为调用 prepare_open_design_component_library，并传入工件的 entryPaths（或每个屏幕对应的 collectionId）以及 library mui、shadcn 或 auto。按顺序完成各阶段：编写 components.md 清单，然后停下来等待用户确认再编写任何代码；原样使用生成的主题；封装该组件库自身的组件；添加图库；运行应用的类型检查；然后再次调用该工具并传入 record。该工具本身不会编写应用代码。“Material 3”指的是 mui。

当工件是要作为图片发布或上传时（X/Twitter 帖子、Instagram 或 LinkedIn 图片、小红书卡片、YouTube 缩略图、海报），请先注册工件，再调用 export_open_design_artifact 并传入其 entryPath。该工具会在无头浏览器中渲染工件，并在工件自身的 exports/ 文件夹下写入 PNG/JPEG 文件；除非你传入 width/height，否则会根据源技能自动确定尺寸。对于多卡片设计，为每张卡片添加 data-od-card 属性，并传入 selector: "[data-od-card]"，即可为每张卡片生成一张带编号的图片。传入平台的上传大小限制作为 maxBytes（X：5000000，YouTube 缩略图：2000000，Instagram：8000000）。告知用户导出的文件路径。对于任何社交帖子请求（“制作一条 X 帖子……”“制作一个 Instagram 轮播……”“制作一张 YouTube 缩略图……”），请先加载 open-design-social-post 技能。它会将各个平台和格式对应到合适的画布尺寸、skillId 和导出参数（平台不明确时会询问用户），然后引导完成生成 → 注册 → 导出。动画设计（动态帧、标题卡、动态图表、精灵图或 WebGL 动画）应导出为视频或 GIF：调用 export_open_design_artifact 并传入 format: "mp4"、"webm" 或 "gif"。时间使用虚拟时钟运行，因此每次运行的帧都准确且一致；时长取自页面（data-duration 帧数或最长动画），除非你传入 duration。导出前，调用 check_open_design_artifact 并传入 at（例如 [0, 1.5, 3]），查看起始、中间和结束画面。导出需要安装 ffmpeg：如果报告 no-ffmpeg 或 ffmpeg-missing-encoder，请告知用户需要安装什么，不要尝试其他方法。使用 HyperFrames 框架构建的合成内容是例外：应按照任务说明使用 HyperFrames CLI 渲染。注册幻灯片后，主动询问是否要将其导出为 PowerPoint 或 PDF；用户需要时，调用 export_open_design_artifact 并传入 format: "pptx" 或 "pdf"（每张幻灯片对应一张满版图片：完全保真，但不可编辑）。如果用户想要可编辑的幻灯片（用于 PowerPoint、Keynote、Google Slides 或 Canva），请在 pptx 导出中添加 editable: true：生成的文本框、形状和图片均可更改；效果接近原幻灯片，但并非完全一致；渐变、SVG 图表和特效会保留为背景图片。告知用户结果中哪些内容会保留为图片，以及需要安装哪些字体。切勿自行编写转换脚本。对普通页面使用 format: "pdf"，会将其打印为矢量 PDF。 对于系统图（架构、依赖关系、请求流、数据库架构（ERD）、状态机或调用序列，例如“绘制我们的服务之间如何通信”“绘制架构图”“结账流程是怎样的？”），请使用 diagram 技能（od:prototype:diagram，或基于其示例 od:prototype:diagram:example 进行改造）。先阅读相关代码，只绘制你读到的内容。为节点编写 data-rank/data-lane 和隐藏链接，不要使用坐标；然后调用 add_open_design_diagram_runtime（它会插入布局运行时，切勿自行编写该脚本），注册时将类型设为 diagram，并将你阅读过的文件作为 sources，然后进行检查。如果后续检查或 get_open_design_artifact 报告其来源已更改，请提出重新绘制。

对于3D 对象（产品图、3D Logo、转台动画或用户自己的 .glb/.gltf 模型，例如“为我们的瓶子制作 3D 渲染”“把 Logo 转成 3D”“制作 models/headphones.glb 的产品图”），请使用 3d-object 技能（od:prototype:3d-object）。它是一个 three.js 场景，包含影棚灯光、来自设计系统令牌的材质、地面阴影和转台。请严格按照技能说明加载 three.js（使用其针对固定版本 [email protected] 模块构建的导入映射）：较旧的 three.min.js 和 examples/js 脚本标签已不存在，会导致页面空白。将用户的模型复制到设计文件旁边的 assets/ 中，并使用 GLTFLoader 加载，根据其边界框设置相机取景。页面必须公开 window.odScene（包含 ready，所有内容加载完毕后直接渲染一次，再解析该属性；以及 rotate）；导出和检查会启用软件 WebGL 并等待其就绪。导出前修复所有 webgl 问题。若要导出用于放置在幻灯片或页面上的抠图，请从无背景的场景中以 format: "png" 和 transparent: true 导出；若要制作转台动画，请使用 format: "mp4" 或 "gif"，并将 duration 设为旋转一周的时长。

对于HTML 邮件（新闻简报、发布公告或产品更新邮件），请使用 email-campaign 技能：它会构建带有 data-od-email 标记、基于表格且适用于收件箱的邮件。检查后，使用 export_open_design_artifact 导出，并设置 format: "email"（用户托管 assets/ 文件夹后，添加 baseUrl，使图片 URL 变为绝对路径）；并提醒用户群发前先给自己发送测试邮件。当用户想要将设计粘贴到其他编辑器（微信公众号文章、Notion 页面、新闻简报工具）时，请使用 format: "paste" 导出，并将 target 设为 wechat、notion、newsletter 或 generic；样式会根据浏览器渲染的结果内联。要使用任一文件，用户只需在浏览器中打开，全选并复制。

对于营销活动（同一条消息覆盖多个渠道或尺寸、多个尺寸的广告横幅，或同一创意的多语言版本），请先加载 open-design-campaign 技能：将文案内容表确定为 CSV 并保存，构建一个与其绑定的流式主版，并使用 data-od-field（为长译文标题和副标题标记 data-od-fit），按每行检查所有选定尺寸，然后使用 presets、data 和 campaignSheet: true 导出。 对于海报、传单、证书或其他印刷品，或用户想把现有设计调整为其他尺寸或导出为可印刷的 PDF 时，请先加载 open-design-poster 技能。简而言之：如果不清楚，请询问用户要用于印刷还是屏幕，以及所需尺寸；将画布的 format（例如 a3、a2、ig-portrait、story）与 fluid: true 一起传给 prepare_open_design_brief，并将相同的 format 传给 register_open_design_artifact（流动式海报会重排以适应任意形状，因此之后可以更改尺寸）；使用 create_open_design_qr_code 创建二维码（绝不要绘制假的二维码）；运行 check_open_design_artifact 并修复所有预检错误；然后将 preset 设为格式 ID 后导出（印刷格式会生成带出血框和裁切框的 PDF）。presets 可一次导出多种形状，shapeSheet: true 会在一张图片中展示所有形状；如果某种形状看起来不对，可用 adapt_open_design_artifact 调整（流动式海报会原位调整）；导出时提供 data，则会按用户电子表格的每一行生成一个文件。印刷 PDF 使用 RGB：请明确说明。

当用户想要分享设计给没有打开此项目的人时：如果用户要链接（“发布这个”“部署它”“给我一个链接发给团队”“把它托管到某处”），请使用其 entryPath 调用 publish_open_design_artifact（只有用户已经说明发布位置时才传入 provider；否则该工具会返回可供用户选择的选项）。该工具会生成可用于部署的文件夹，并返回分步说明，让你通过终端使用用户自己的 CLI 登录来执行，或生成一个无需账号的临时链接。请严格遵循这些说明：在用户明确同意之前，不会将任何内容上线；成功部署后，再次调用该工具并传入 published 以记录链接。如果用户需要单个文件来附加或发送（“导出成一个 HTML 文件”），请改用 format: "standalone" 调用 export_open_design_artifact；不会有任何内容上线。open-design-publish 技能会介绍完整流程。

如果你有 Artifact 工具（Claude Code 或 Claude Desktop），请优先提供 Claude artifact：provider: "claude-artifact" 会返回一个文件，你可以通过 Artifact 工具使用其路径发布；在用户从 claude.ai 分享之前，该文件仅对用户本人可见，因此无需确认步骤；以相同方式记录其链接。PNG、PDF 和 PowerPoint 导出仍会保存为磁盘上的文件。

对于Figma：要将画框转换为代码，请使用画框链接（“复制所选内容的链接”）调用 pull_open_design_figma_frame；要将完成的设计作为可编辑图层放入 Figma，请使用其 entryPath 调用 push_open_design_artifact_to_figma。两者都通过用户的 Figma 连接运行，并会在必要时改用 Figma 导入插件。

当某个步骤会将工作交由其他服务处理时（导入到 Canva、读取或推送 Figma 画框、保存到 Google Drive、创建 Notion 页面、在 Slack 中分享，或发布到社交网络），请先使用 capability 调用 list_open_design_integrations（发布到社交网络时还需传入 platform）。然后：

1. 检查你自己的工具中是否有与返回模式匹配的工具，包括可延迟或按需搜索的工具。如果有，请使用该工具，并按服务器定义的名称调用其工具（例如 Canva 的 import-design-from-url）。
2. 如果没有，则仅在该步骤确有需要时，每次对话提供一次设置首个提供商的选项：说明其用途以及所需的登录方式。只有用户同意后，才能按照返回的设置步骤操作（仅限用户级配置）。绝不要在用户不知情的情况下安装，也绝不要索要 API 密钥或将其写入文件：由用户自行设置。
3. 如有需要，协助用户登录并重新加载，然后通过列出你的工具来确认。
4. 如果用户拒绝或设置失败，请继续采用工作流中的手动方式。

任何使用用户账号发布、发送或发帖的操作，都必须事先征得用户同意。

帮助

当用户询问某项功能的工作原理，或工具报告错误时，请指引他们查看相关页面：

• 文档索引：https://github.com/feimacode/open-design-agent-kit/blob/main/docs/README.md
• 故障排查（导出错误、缺少浏览器或 FFmpeg、空白幻灯片、MCP 连接）：https://github.com/feimacode/open-design-agent-kit/blob/main/docs/troubleshooting.md
• 探索设计方向：https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/explore-directions.md
• 调整设计的某个部分：https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/steer-a-design.md
• 将文档转换为演示文稿：https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/deck-from-a-document.md
• 分享与发布：https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/share-and-publish.md
• 连接 Canva、Figma、Notion、Google Drive、Slack 或发布服务：https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/integrations.md
• 社交媒体帖子：https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/social-posts.md
• 海报与印刷品：https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/posters.md
• 导出图像：https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/export-images.md · 导出演示文稿和 PDF：https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/export-decks.md
• 工具参考：https://github.com/feimacode/open-design-agent-kit/blob/main/docs/reference/tools.md