Edit Figma Design 是一个面向 Figma 设计创作的技能，核心作用是根据书面产品说明或 UI 描述，直接在 Figma 中创建或更新设计。它结合 Figma 库搜索与直接文件授权编辑，并在需要让设计更贴合产品或代码库时，才动用更广泛的相关能力。
用途方面，该技能适用于以下请求：根据文字描述在 Figma 中设计新屏幕、流程、组件或样稿；根据文本反馈改进或扩展现有 Figma 文件；直接创建第一版线框图或更高保真度的设计；让 Figma 设计对齐现有设计系统或产品词汇。它不适用于：从设计生成生产代码（应使用 implement-design）；将运行中的页面或应用捕获到 Figma（应使用 figma-generate-design）；仅查看或拉取现有 Figma 上下文（应使用 pull-figma-content）。
前提条件：Figma MCP 服务器必须已连接且可访问；需确认 search_design_system、create_new_file 和 use_figma 可用。开始前需掌握最少信息：要设计什么、使用已有 Figma 文件还是新建文件、结果是否需对齐现有设计系统或代码库。仅在用户信息不足时提问，问题应简短并尽量合并为一条消息。
工作流程按顺序执行，不得跳过。第一步，确认是 Figma 授权创作请求；若实际是要求实现，转向 implement-design；若是截图到 Figma 或网页捕获流程，转向 figma-generate-design。第二步，先确定目标文件：search_design_system 和 use_figma 都需要 fileKey，所以要在搜索或编辑前确定目标。若用户提供了现有 Figma URL 或文件键，则提取并使用该 fileKey，回复时复用提供的 URL。若需新建文件，则根据请求确定清晰的文件名；若用户已提供 planKey 则使用它；否则调用 Figma MCP 的 whoami 工具检查已认证用户和可用计划（注意不是 shell 的 whoami 命令）。若只有一个计划，使用其键；若有多个，询问用户使用哪个团队或组织。随后调用 create_new_file(editorType="design", fileName=..., planKey=...)，保存返回的 fileKey 和 URL，待第一版可用草稿完成后再分享 URL。
第三步，仅在需要时收集合适的上下文。若用户想要探索性概念、线框图或样稿，且不要求对齐代码库，则只在 Figma MCP 内操作。若用户希望设计匹配现有产品或设计系统，则有选择地使用更广泛的代理上下文：读取 AGENTS.md 和/或 WARP.md 中的项目规则；使用语义代码库搜索、grep 和文件读取，找出相关组件、产品词汇、布局模式和设计令牌来源；仅当提示直接依赖其他 MCP 来源或网络搜索时才使用它们，例如其他系统中的产品需求或明确的灵感请求。该技能常规流程中不编辑代码、不运行 REPL 命令、不使用 computer use。
第四步，创作前先搜索设计系统。在创建新组件或样式前，用已确定的 fileKey 调用 search_design_system。优先搜索最可复用的资产：组件和组件集、变量和类似令牌的值、颜色/字体/间距/效果样式。从用户领域术语以及从项目规则或代码库搜索中发现的名称开始；必要时用返回的库键缩小后续搜索，而非立即扩大范围。优先复用和导入匹配项，而非从零重建。
第五步，安全准备 use_figma。首次调用前规划编辑顺序并遵循该工具要求的 Plugin API 约束。保持增量式授权计划：创建页面和框架结构；建立布局和主要区块；复用或导入设计系统资产；应用变量、样式和字体；添加内容并润色；根据文件当前内容做针对性修改。
第六步，以小的 use_figma 步骤编辑设计。使用多次小调用而非一个巨大脚本。合适的步骤边界包括：创建页面和顶层框架；布置页眉、侧边栏、主视觉或内容区域；导入或放置一族可复用组件；绑定颜色、文本样式或间距变量；更新某区块的文案、状态或对齐。每步后检查结果，确认上一步成功后再继续。创建任何类似组件的内容时，优先使用第四步发现的可导入库资产。
第七步，交付设计及后续选项。第一版可用草稿就绪后：返回 Figma URL（若有）；高层概括创建或更新的内容；询问用户是否要在 Figma 中修改。若用户要求把已批准的设计实现为代码，停止使用该技能并转向 implement-design。
该技能还给出代理使用指导：应利用更广泛能力减少手动提示，而非增加不必要的工作。适合的用途包括：在仓库中查找已有组件名或设计令牌；读取约束布局、命名或品牌的项目规则；在用户明确依赖时从其他已连接系统拉取产品需求。通常不必要的包括：shell 命令或 REPL 访问、代码编辑、computer-use 验证、无特定用户请求的宽泛网络研究。
示例方面：示例一，从产品描述新建文件，例如“为桌面应用在 Figma 中设计账单概览屏幕，使用现有设计系统并新建文件”，流程为确认属于 Figma 创作、必要时 whoami 并 create_new_file、读取项目规则或按需搜索代码库、用账单相关查询调用 search_design_system、以小步 use_figma 构建屏幕、返回新文件 URL 并提议修改。示例二，更新现有文件，例如“向此 Figma 文件添加引导清单”，流程为从现有 URL 提取 fileKey、先搜索清单/卡片/徽章/进度资产、用增量 use_figma 添加新区块、返回同一 URL 并总结变更。示例三，纯探索性概念，例如“创建第一版移动健身计划器样稿，暂不需匹配代码库”，流程为按需新建文件、跳过代码库搜索和项目规则检查、仅用 search_design_system 复用相关 Figma 库资产、在 Figma 中小步构建、分享链接并询问下一步改进。
常见问题及应对：若用户未说明使用现有文件还是新文件，问一个直接问题确定目标，未拿到 fileKey 前不要开始 search_design_system 或 use_figma。若 create_new_file 有多个 Figma 计划可选，询问用户使用哪个团队或组织，不要猜测。若用户希望设计匹配现有产品约定但请求含糊，先读项目规则，再用有针对性的代码库搜索，只收集与请求界面相关的组件和约定。若用户同时要求 Figma 设计和实现，仅在请求主要以 Figma 授权为主时先创建或更新设计；若主要以实现为主，则转向 implement-design；设计获批后，实现可作为单独步骤进行。若 use_figma 失败或脚本过大，将任务拆分为更小的 use_figma 调用，优先结构，其次是样式，最后是针对性修改。
其他资源包括 Figma MCP 服务器文档以及 Figma MCP 服务器工具与提示。