Where does a creative-direction brief live in Figma?

On the cover page of the team library file. The cover frame holds the brief synthesis as readable text plus the four axis positions as labeled blocks. Library users see the brief the moment they open the library, which keeps the brief present at the point components get used. A library file without a brief on the cover is one that drifts away from direction within a quarter.

How do design tokens map to axis positions?

Through Figma variables (the typed design-token primitive Figma exposes). Variables get organized into collections per axis, with axis-prefixed names like tone/professional/heading or aesthetic/restrained/space-large. The naming convention surfaces axis position at the point of use; an instance using tone/playful/heading is visibly outside a Professional brief and reviewers catch the drift in design review.

What pages does a brief-aware library file need?

A small fixed set: Cover (brief and axis labels), Foundations (variables and styles organized by axis), Components (the published library, organized by axis position when the components themselves are axis-bound), Patterns (combined components for common UI shapes), Don't use (deprecated components and explicit anti-patterns from the rejection list), and Examples (full screen mocks demonstrating the brief in action). Six pages, each load-bearing.

What is the most common Figma-specific failure of this integration?

Variables created without the axis prefix. The team configures color and space variables, names them by use (button-primary, space-large), and loses the axis traceability the convention provides. A reviewer in design review cannot tell at a glance whether a frame is using Professional-tone variables or Playful-tone variables, which means the design review cannot grade against the brief. The fix is to prefix variables on creation, even if the prefix feels noisy at first; the noise is the signal.

Integration · Figma

RampStack skills in Figma.

Briefs on the library cover. Variables prefixed by axis. Design review that grades against direction, not just polish.

Figma gives the team files, pages, frames, components, variants, and variables. The integration uses each one for a load-bearing role in keeping the brief present at the point components get consumed. The cover frame carries the brief synthesis. Variables carry the axis positions through the design tokens. Components live on pages organized by axis. Design review opens the cover before opening the working file.

View the orchestrator skill

How this works with the orchestrator skill

The skill produces the plan. Figma holds the visual library.

The integration-orchestrator skill outputs a phased delivery plan. This page shows how that plan implements in Figma specifically. Phases become the page structure across the team library file (Discovery moodboards, Direction tokens, Identity components, Production frames). Gates become review-status badges on frames; lock points become locked variable collections after the gate passes; handoffs become library publishes from one phase page to the next.

The 5-status taxonomy maps to a frame review-status convention (Draft / In review / Approved) plus the locked-collection state for tokens that survive a gate. Direction tokens lock after the Direction approval gate; Identity components lock after the Identity approval gate. Production frames stay open so designers can iterate without unlocking upstream decisions. See the platform-implementation reference on GitHub for the per-platform setup details.

Visual demonstration

What this looks like in practice.

Brand library v2.0

Figma

Discovery moodboards
- Reference brand 01 / AmanDraft
- Reference brand 02 / Soho HouseDraft
- Reference brand 03 / Ace HotelDraft
Direction tokens
- Color tokensApproved
- Type tokensApproved
- Spacing scaleApproved
Identity components
- Logo system / Primary lockupApproved
- Logo system / Stacked alternateApproved
- Logo system / Symbol-onlyApproved
- Brand patternsApproved
Production frames
- Homepage hero v3In review
- Reservations page v2In review
- About page v1Draft

The library file organized by phase. Discovery moodboards stay open for iteration; Direction tokens lock after the Direction approval gate; Identity components lock after the Identity approval gate; Production frames remain open. Lock state is what stops upstream phases from drifting under in-flight production work.

The orchestration shape is platform-agnostic. In Figma each phase corresponds to a page (or a small page group); each gate is a library publish that downstream phases consume. Lock points become locked variable collections after the gate passes.

Manual setup checklist (Figma Dev Mode + UI)

Figma's Dev Mode MCP server reads designs and surfaces dev-handoff data; it does not create files, pages, or components. Library setup happens in the Figma UI. The orchestrator skill outputs this checklist so a designer applies it directly.

Create the team library file. Add four phase pages (Discovery moodboards, Direction tokens, Identity components, Production frames).
On the Direction tokens page, create variable collections per axis: tone, aesthetic, relationship, sensory. Prefix variable names with the axis position (tone/professional/heading, aesthetic/restrained/space-large).
After the Direction approval gate, lock the Direction tokens collections (right-click collection, Lock). Repeat the gate-then-lock pattern at each phase boundary.
Publish the library after each gate. Downstream phase pages consume the published version, so upstream changes go through a publish event the team can audit.
In Production frames, set review-status badges (Draft / In review / Approved) on each frame as a description tag. Use the badges in design review to grade against the brief.

MCP integration

Figma Dev Mode MCP, read-only.

Figma launched a Dev Mode MCP server in 2025 designed for design-to-code handoff. It exposes selected frames, variable values, component metadata, and code-connect mappings to an agent. It is intentionally read-only for design content. Library architecture and file structure are not creatable via MCP; that work happens in the Figma UI.

What the MCP is good for: pulling token values into a code generation step, reading component variants and their applied variables, surfacing frame metadata for a design-review agent that grades against the brief, and running automated checks against deviations from the locked variable collections.

Reference: Figma Dev Mode MCP server guide. The orchestrator skill uses Figma MCP for read operations only and produces the manual checklist above for setup work.

CLI alternative

Figma REST API for token export.

Figma does not ship an official CLI. The Figma REST API plus a small script (or a community tool like Style Dictionary's Figma source) handles bulk token export, design-token-to-code pipelines, and CI integration for token drift detection. The orchestrator skill mentions the REST API path for teams that want token export automation outside the Dev Mode MCP read flow.

Library file creation, page structure, and variable definition still require the Figma UI. There is no CLI or API surface that creates a complete brief-aware library file; that initial setup is manual.

The shape

Brief into Figma library architecture.

The library file is the source. The Cover page presents the brief. The Foundations page organizes variables by axis. The Components page hosts published components. Working files consume the library; the brief reaches every consumer because the library is the consumer's entry point.

Six pages in the library file. Working files consume the library and inherit the axis-prefixed variables automatically.

The mapping

Brief artifacts to Figma primitives.

Brief artifact	Figma primitive	Notes
Brief synthesis	Cover frame, body text	Visible the moment a designer opens the library
Axis positions	Cover frame, four labeled blocks	Each block is a small frame with axis name + position
Tone position in tokens	Variables prefixed tone/[position]/	Color and typography variables
Aesthetic position in tokens	Variables prefixed aesthetic/[position]/	Spacing, layout, density variables
Sensory position in tokens	Variables prefixed sensory/[position]/	Motion duration, easing, opacity variables
Rejection list	Don't use page	Each rejected pattern as a frame with explanation
Inspiration references	Cover frame, References section	Embedded thumbnails plus link text
Component variants	Variant property values	Variants reflect axis when the component itself is axis-bound

Figma variables are the load-bearing primitive. Without prefixed variable names, axis position cannot be traced from a frame back to the brief. With prefixed names, a reviewer scanning a working file sees axis position at the variable picker and at the inspect panel; drift becomes visible at the point the design happens, not at the design review afterward.

Variants on a component reflect axis only when the component itself is axis-bound (an empty-state component with a Tone variant offering Conversational and Provocative versions, for example). Most components should pick one axis position at the variable level and not expose axis as a variant; the variant explosion otherwise gets unmanageable.

Templates

Copy these into the team library.

Library file page structure

Six pages, in this order. The order matters because it is the order a designer scans the file when they open it.

Library file: [Brand name] - Library

Page 1  Cover
        - Brief synthesis (large body text, ~3 paragraphs)
        - Four axis label blocks
            Tone: [position]
            Aesthetic: [position]
            Relationship: [position]
            Sensory: [position]
        - Three to five inspiration thumbnails with
          one-sentence captions

Page 2  Foundations
        - Color variables, organized by axis prefix
        - Typography variables, organized by axis prefix
        - Spacing variables, organized by aesthetic prefix
        - Motion variables, organized by sensory prefix

Page 3  Components
        - Atoms (buttons, inputs, labels)
        - Molecules (form rows, cards, list items)
        - Organisms (forms, headers, modals)
        - Each component using axis-prefixed variables

Page 4  Patterns
        - Combined components for common UI shapes
          (sign-up forms, empty states, error states,
           loading states)
        - Each pattern annotated with the axis position
          it answers

Page 5  Don't use
        - The rejection list rendered as visual examples
        - Each rejected pattern with a strikethrough or
          red overlay and a one-line explanation

Page 6  Examples
        - Three to five full-screen mocks demonstrating
          the brief in action
        - Annotation callouts pointing to specific
          choices and the axis position they reflect

Variable naming convention

Forward-slash hierarchy in variable names creates the folder structure Figma displays in the variable picker. The convention puts axis at the top.

Color variables

  tone/professional/heading        #1c1917
  tone/professional/body           #44403c
  tone/professional/accent         #0a0a0a
  tone/conversational/heading      #292524
  tone/conversational/body         #57534e
  tone/conversational/accent       #047857

(One color set per active tone position. The variable
modes feature can hold dark/light per token if needed,
but the axis prefix is the load-bearing layer.)

Typography variables

  tone/professional/display        Source Serif 4 / 56 / 1.05
  tone/professional/heading-lg     Source Serif 4 / 32 / 1.15
  tone/professional/body           Source Sans 3 / 16 / 1.6

Spacing variables

  aesthetic/restrained/space-xs    4
  aesthetic/restrained/space-sm    8
  aesthetic/restrained/space-md    16
  aesthetic/restrained/space-lg    32
  aesthetic/restrained/space-xl    96   (the generous gap
                                         restrained briefs reward)

  aesthetic/maximalist/space-xl    24   (different rhythm)

Motion variables

  sensory/considered/duration-fast    150ms
  sensory/considered/easing-standard  cubic-bezier(0.4, 0, 0.2, 1)
  sensory/resonant/duration-hero      720ms
  sensory/resonant/easing-emphatic    cubic-bezier(0.16, 1, 0.3, 1)

Frame organization pattern (the Components page)

Inside the Components page, frames are organized so axis position is visible at the file zoom level.

Components page layout

Section: Atoms
  Frame: Buttons
    Component: Button (variants: primary, secondary,
                       ghost. State variants: rest,
                       hover, focus, active, disabled.)
  Frame: Inputs
    Component: TextInput
    Component: Select
    Component: Checkbox

Section: Molecules
  Frame: Form rows
    Component: FormRow (variants: stacked, inline)
  Frame: Cards
    Component: Card (variants: default, featured,
                     compact)

Section: Organisms
  Frame: Forms
  Frame: Headers
  Frame: Modals

Each frame is auto-layout, top-to-bottom, with a
title and a one-line description above the
component. The description names the axis position
the component answers when relevant.

Design review checklist

Open the cover page first. Read the brief synthesis and the rejection list. Then open the working file and grade against the checklist.

Design review checklist

Brief alignment
  [ ] Did I re-read the brief synthesis before reviewing?
  [ ] Did I re-read the rejection list?
  [ ] Does this work answer the brief on the relevant
      axes?
        Tone:        yes / no / partial
        Aesthetic:   yes / no / partial
        Relationship: yes / no / partial
        Sensory:     yes / no / partial / N/A

Variables
  [ ] All color uses an axis-prefixed variable
  [ ] All spacing uses an axis-prefixed variable
  [ ] All motion uses an axis-prefixed variable
  [ ] No raw hex codes outside the Foundations page

Library hygiene
  [ ] All components are library instances, not
      detached
  [ ] No deprecated components are in use
  [ ] Component overrides are limited to text,
      not structural changes

Rejection list
  [ ] Nothing in the rejection list is reintroduced
  [ ] If something looks like a rejected pattern,
      it has been explicitly justified in the
      working file's notes

Component variant naming pattern

When a component is intentionally axis-bound (most brand components are not), expose the axis as a variant property so the variant picker shows position at the point of use.

Component: EmptyState

Variant properties

  Tone        professional / conversational
              / playful / provocative
  Severity    info / warning / error
  Action      none / primary / secondary

Use only when the component is genuinely axis-bound;
most components should pick one tone via variables and
omit Tone as a variant property.

Naming the component

  EmptyState/professional/info/primary
  EmptyState/professional/info/none
  EmptyState/conversational/info/primary

Figma assembles the variant matrix from the property
values. The forward-slash hierarchy controls how the
component is grouped in the assets panel.

Failure modes

Where the Figma integration goes wrong.

Variables created without the axis prefix. The team configures color and space variables, names them by use (button-primary, space-large), and loses the axis traceability. A reviewer cannot tell at a glance whether a frame uses Professional-tone variables or Playful-tone variables. Prefix variables on creation, even if the noise feels unnecessary; the noise is the signal.

Components created in working files instead of the library. Designers under pressure create components in their working file and forget to promote them to the library. Six weeks later, every working file has a slightly different button. Treat the library file as the only place new components are born; promote experimental components or delete them.

Variants created without considering axis positions. A button gets eight variants for size, state, and emphasis. The brief says Editorial Restrained but the button system suggests four sizes when two would do. The variant explosion produces work that satisfies every stakeholder and answers no brief. Cut variants aggressively; the brief should justify each one.

Design review assesses polish, not direction adherence. Reviewers grade the work on craft, ship it, and the brief drifts in silence. The design review checklist above is the operational fix; without it, the review degrades into “looks good to me.”

Composition

Which skills feed the Figma integration.

The brief comes from creative-direction. The variables, components, and motion principles come from brand-identity. The example mocks demonstrating the brief in action come from art-direction work that the brand-identity skill informs. The library file is the canonical artifact; every other Figma file consumes from it.

Continue reading.

For Figma platform mechanics (variables, modes, library publishing, component properties, variant matrices), Figma's official help center is the source of truth. Variables and modes require Figma's Professional plan or higher.

Frequently asked questions.

Where does a creative-direction brief live in Figma?: On the cover page of the team library file. The cover frame holds the brief synthesis as readable text plus the four axis positions as labeled blocks. Library users see the brief the moment they open the library, which keeps the brief present at the point components get used. A library file without a brief on the cover is one that drifts away from direction within a quarter.
How do design tokens map to axis positions?: Through Figma variables (the typed design-token primitive Figma exposes). Variables get organized into collections per axis, with axis-prefixed names like tone/professional/heading or aesthetic/restrained/space-large. The naming convention surfaces axis position at the point of use; an instance using tone/playful/heading is visibly outside a Professional brief and reviewers catch the drift in design review.
What pages does a brief-aware library file need?: A small fixed set: Cover (brief and axis labels), Foundations (variables and styles organized by axis), Components (the published library, organized by axis position when the components themselves are axis-bound), Patterns (combined components for common UI shapes), Don't use (deprecated components and explicit anti-patterns from the rejection list), and Examples (full screen mocks demonstrating the brief in action). Six pages, each load-bearing.
What is the most common Figma-specific failure of this integration?: Variables created without the axis prefix. The team configures color and space variables, names them by use (button-primary, space-large), and loses the axis traceability the convention provides. A reviewer in design review cannot tell at a glance whether a frame is using Professional-tone variables or Playful-tone variables, which means the design review cannot grade against the brief. The fix is to prefix variables on creation, even if the prefix feels noisy at first; the noise is the signal.

Cost considerations

Figma's MCP is included with the platform subscription.

Subscription included

No per-call cost; usage is bounded by the plan tier you already pay for. Lean on the MCP for exploratory work the way you would lean on the platform UI: the marginal cost of an extra call is zero, and the agent reads or writes the same data your team already has access to.

Figma plan covers Dev Mode MCP access. Read-only at present; no per-call cost.

Recommended patterns

Treat the MCP as a thin layer over the platform; permissions cascade from platform-side roles, not a separate MCP credential.
Plan-tier limits (seats, projects, environments, event volume) still apply; design agent workflows to live within them.
Audit the agent's writes the way you would audit any teammate's: subscription-included does not mean the changes are reversible.