跳转到内容

Prompts

Vibma includes 5 built-in MCP prompts that provide best-practice guidance to AI agents.

Best practices for working with Figma designs

Full prompt text

Figma design best practices:

  1. Discover First: document(method:“list”), styles(method:“list”), variables(method:“list”) — know what exists before creating.

  2. Design Tokens — Never Hardcode Colors:

    • Use fillStyleName/strokeStyleName (paint styles) or fillVariableName/strokeVariableName (variables)
    • Use textStyleName for typography. Only use raw fillColor/fontColor for one-off values.
  3. Auto-Layout First:

    • frames(method:“create”, type:“auto_layout”) for containers, components(method:“create”, type:“component”) for reusable elements.
    • A component IS a frame — create it directly with layout/fill/stroke params, then add children. No need to create a frame first and convert.
    • layoutSizingHorizontal/Vertical: “FILL” for responsive children, “HUG” to shrink-wrap.
  4. Naming: descriptive names for all elements. Property=Value pattern (e.g. “Size=Small”) for variant components.

  5. Lint After Every Section:

    • Run lint(method:“check”) after building. Always attempt to fix warnings unless you understand the specific warning and it’s intentional.
    • Each warning includes a fix instruction with the exact tool call to use — follow it.
    • Use lint(method:“fix”) to auto-convert frames to auto-layout.
    • Lint early and often — cheaper to fix during creation than after.

Best practices for reading Figma designs

Full prompt text

When reading Figma designs, follow these best practices:

  1. Start with selection:
    • First use selection(method: “get”) to understand the current selection
    • If no selection ask user to select single or multiple nodes

Systematic approach for replacing text in Figma designs

Full prompt text
  • Scan text nodes to understand the overall structure of the design
  • Use AI pattern recognition to identify logical groupings:
    • Tables (rows, columns, headers, cells)
    • Lists (items, headers, nested lists)
    • Card groups (similar cards with recurring text fields)
    • Forms (labels, input fields, validation text)
    • Navigation (menu items, breadcrumbs)
text(method: "scan", items: [{nodeId: "node-id"}])
frames(method: "get", id: "node-id", depth: 1) // optional
  • Divide replacement tasks into logical content chunks based on design structure
  • Use one of these chunking strategies that best fits the design:
    • Structural Chunking: Table rows/columns, list sections, card groups
    • Spatial Chunking: Top-to-bottom, left-to-right in screen areas
    • Semantic Chunking: Content related to the same topic or functionality
    • Component-Based Chunking: Process similar component instances together

3. Progressive Replacement with Verification

Section titled “3. Progressive Replacement with Verification”
  • Create a safe copy of the node for text replacement
  • Replace text chunk by chunk with continuous progress updates
  • After each chunk is processed:
    • Export that section as a small, manageable image
    • Verify text fits properly and maintain design integrity
    • Fix issues before proceeding to the next chunk
// Clone the node to create a safe copy
frames(method: "clone", id: "selected-node-id", x: [new-x], y: [new-y])
// Replace text chunk by chunk
text(method: "set_content", items: [
{ nodeId: "node-id-1", text: "New text 1" },
// More nodes in this chunk...
])
// Verify chunk with small, targeted image exports
frames(method: "export", nodeId: "chunk-node-id", format: "PNG", scale: 0.5)
  • For tabular content:
    • Process one row or column at a time
    • Maintain alignment and spacing between cells
    • Consider conditional formatting based on cell content
    • Preserve header/data relationships
  • Adaptively handle text based on container constraints:
    • Auto-detect space constraints and adjust text length
    • Apply line breaks at appropriate linguistic points
    • Maintain text hierarchy and emphasis
    • Consider font scaling for critical content that must fit
  • Establish a continuous feedback loop during replacement:
    • Real-time progress updates (0-100%)
    • Small image exports after each chunk for verification
    • Issues identified early and resolved incrementally
    • Quick adjustments applied to subsequent chunks
  • After all chunks are processed:
    • Export the entire design at reduced scale for final verification
    • Check for cross-chunk consistency issues
    • Verify proper text flow between different sections
    • Ensure design harmony across the full composition
  • Scale exports appropriately based on chunk size:
    • Small chunks (1-5 elements): scale 1.0
    • Medium chunks (6-20 elements): scale 0.7
    • Large chunks (21-50 elements): scale 0.5
    • Very large chunks (50+ elements): scale 0.3
    • Full design verification: scale 0.2

Sample Chunking Strategy for Common Design Types

Section titled “Sample Chunking Strategy for Common Design Types”
  • Process by logical rows (5-10 rows per chunk)
  • Alternative: Process by column for columnar analysis
  • Tip: Always include header row in first chunk for reference
  • Group 3-5 similar cards per chunk
  • Process entire cards to maintain internal consistency
  • Verify text-to-image ratio within cards after each chunk
  • Group related fields (e.g., “Personal Information”, “Payment Details”)
  • Process labels and input fields together
  • Ensure validation messages and hints are updated with their fields
  • Process hierarchical levels together (main menu, submenu)
  • Respect information architecture relationships
  • Verify menu fit and alignment after replacement
  • Preserve Design Intent: Always prioritize design integrity
  • Structural Consistency: Maintain alignment, spacing, and hierarchy
  • Visual Feedback: Verify each chunk visually before proceeding
  • Incremental Improvement: Learn from each chunk to improve subsequent ones
  • Balance Automation & Control: Let AI handle repetitive replacements but maintain oversight
  • Respect Content Relationships: Keep related content consistent across chunks

Remember that text is never just text — it’s a core design element that must work harmoniously with the overall composition. This chunk-based strategy allows you to methodically transform text while maintaining design integrity.

Guide to swap instance overrides between instances

Full prompt text

Transfer content overrides from a source instance to target instances.

  • Use selection(method: "get") to identify selected instances
  • Use frames(method: "list", types: ["INSTANCE"]) to find instances on the page
  • instances(method: "get", id: "source-instance-id")
  • Returns mainComponentId and per-child override fields (characters, fills, fontSize, etc.)
  • For text overrides: use text(method: "set_content") on matching child node IDs
  • For style overrides: use frames(method: "update") with fill/stroke/text/effects styleName fields
  • Match children by name path — source and target instances share the same internal structure
  • frames(method: "get", id: "target-id", depth: 1) on target instances
  • frames(method: "export", nodeId: "target-id") for visual verification

Why create or edit tools are missing and how to fix it

Full prompt text

If the user asks you to create or modify something in Figma but you cannot find create/edit methods on endpoint tools, the MCP server was started without the correct access tier flag.

Vibma filters available methods at startup based on CLI flags passed in the MCP config args array:

FlagMethods available
(none)Read-only (get, list, check, scan, export)
--createRead + creation methods (create, clone)
--editAll methods (read + create + update + delete)

Ask the user to add --edit (or --create) to their MCP config args:

{
"mcpServers": {
"Vibma": {
"command": "npx",
"args": ["-y", "@ufira/vibma@latest", "--edit"]
}
}
}

After updating, the user must restart their AI tool or reload MCP servers — stdio-based servers cannot hot-reload.