# Perture: official product facts and practical guides

Updated: 2026-10-13. Published by Perture.

## What Perture does
Perture makes your brand, components, and design rules available to AI coding agents so you can build and refine interfaces directly in your project using your own design system.
Brand and Design System for AI.

A Brand Page organizes the approved brand and design system: assets, references, components, typography, colors, and rules. Connected coding workflows can retrieve the permitted context and use it while building or reviewing an interface. The implementation remains in the user's project.

## Problems Perture addresses
- AI-generated UI ignores existing components or uses generic visual defaults.
- Designers and developers repeat brand instructions in every coding-agent conversation.
- Teams maintain a design system, but AI coding tools cannot reliably find or apply it.
- Screens are mocked up and rebuilt even when their components already exist in code.
- Different coding tools interpret the same brand differently.
- Teams need to review generated interfaces against their own rules and existing implementation.

## Supported workflows
- Cursor
- Claude Code
- Codex
- MCP-compatible agents
Support and access depend on the installed integration and its permissions. An MCP connection supplies context or tools; it does not itself grant unrestricted code or account access.

## Current plans and billing
### Solo
Price: $25 USD per month.
One member, one Brand Page with 100 MB, official plugins, plugin MCP for brand context and checks, Logs, Brand Quality Index, and standard support.
Charged when you purchase. $25 USD per month. No free trial.

### Pro
Price: $249 USD per month.
Up to ten members and ten Brand Pages with 500 MB each, official plugins, plugin MCP, Logs, Brand Quality Index, Pro MCP editing, Team Workspace, Brand Page sharing and transfer, priority support, and one initial implementation.
Save your card first. The $249 USD monthly subscription starts after the included implementation is complete. No free trial.

No free plan or seven-day trial is offered. Solo has one Brand Page; new additional Brand Pages are not sold as Solo add-ons. Brand Page sharing and transfer belong to Pro. Pro's included implementation covers one existing brand, one supported coding workflow, and one initial interface validation. Future subscription renewals can be canceled; paid-period refund conditions are described in the Terms.

## Working with an existing design system
Give the coding agent the actual component source, import paths, supported props, tokens, patterns, and reference states. A screenshot can communicate appearance but cannot establish a component's API or runtime behavior. If source or a required variant is unavailable, identify the gap and agree how to handle it before creating a replacement.

## Review and limits
Reading brand context does not authorize code changes. Access requires the appropriate account and Brand Page permissions. Requested edits must stay within the authorized project and file scope. Review component usage, states, keyboard behavior, responsive layouts, and the rendered result. A successful build does not prove visual fidelity or usability. Perture does not guarantee that every generated interface will be correct, or that every Figma mockup can be removed from every workflow.

## Practical answers
### Why AI-generated UI ignores your design system — and how to fix it
Source: https://perture.co/blog/keep-ai-generated-interfaces-on-brand
When AI-generated UI looks generic, first check whether the coding agent can access your actual components, their import paths and props, and the rules that connect them. A brand description or screenshot alone leaves implementation decisions open. Reuse the existing component source, define the supported states and layouts, then review the rendered screen against the same system. Perture makes that approved context available inside connected AI coding workflows.
Find the missing information before rewriting the prompt
A request such as ‘make this match our brand’ rarely identifies which Button component to import, which radius token applies to a panel, or whether a form needs a compact variant. If the agent cannot locate those decisions, it may build plausible substitutes. The output can compile and still differ from the product.
Inspect one generated screen. List the elements that were recreated: buttons, cards, text fields, navigation, typography, and icons. For each, ask whether a matching implementation already exists and whether the agent received its source or a precise reference to it. This distinguishes missing context from an actual gap in the design system.


Provide a component contract, not only a visual example
A useful component reference includes the import path, allowed props, default state, variants, and constraints. Include an existing usage example. If a screenshot shows a loading state, identify the prop or state transition that produces it. Give the agent enough information to use the component without inventing its API.
For a new signup screen, the scope might be: use the existing page shell, FormField, Button, and typography tokens; preserve validation behavior; change only the new route and its composition. If a required component is missing, ask the agent to report that gap before implementing a new primitive.

Example:
Example task — replace the example paths with your repository's real paths:
Build the signup screen using the approved components in src/components/ui.
Inspect their source and existing usage before editing.
Reuse our typography, spacing, and color tokens.
Include default, invalid, submitting, and success states.
Report missing components instead of silently recreating them.
Stay within the signup route and its directly required files.

Review both the implementation and the experience
A passing build is useful evidence about the implementation, but it does not establish visual fidelity. A screenshot is useful evidence about appearance, but it does not prove interaction behavior. Keep both forms of review in the workflow.
- Check imports and props. Confirm the screen uses the intended components and supported variants.
- Exercise the states. Test loading, errors, empty data, and disabled controls with realistic content.
- Inspect responsive behavior. Look at narrow and wide viewports, long labels, and overflow.
- Use the keyboard. Check focus visibility, navigation order, and the action each control performs.
- Compare the rendered screen with the approved system. Record the concrete mismatch and its expected behavior.

Where Perture fits
Perture organizes your approved brand and design system in a Brand Page and makes the permitted context available to connected coding agents. This gives the next interface task a reusable reference instead of a new, manually reconstructed brand briefing.
The practical starting point is one real screen with existing components. Connect the workflow, ask the agent to retrieve the system, build within a bounded scope, and review the result. Use the problems found in that task to improve the component references and rules before expanding to more screens.
For one founder or designer, Perture Solo includes one Brand Page and the official plugins. For a team that needs sharing, Pro MCP editing, and the included implementation, Perture Pro provides the broader workflow. Choose the plan that matches who will maintain and use the system.


### How to use your design system with Codex
Source: https://perture.co/blog/brand-context-for-codex
To use your design system with Codex, make the actual component source and approved rules available before the interface task starts. Use repository instructions for local paths and constraints, connect the Perture integration for your permitted Brand Page context, and ask Codex to inspect existing usage before editing. Review component reuse, interaction states, and rendered output separately.
Start with the repository Codex will edit
Locate the component library, token files, layout primitives, and one or two screens that demonstrate the intended composition. If the design system is a separate package, confirm its installed version and exports. An example from another version may show props that are no longer supported.
Keep project instructions concrete. An AGENTS.md file can identify the component entry point, describe the file scope, and specify the checks expected before handoff. Prefer exact paths and observable rules to a long collection of adjectives. A rule such as ‘import the shared Button; do not implement another primary button’ is easier to act on than ‘make it premium’.

Example:
Example AGENTS.md excerpt — use your actual paths and commands:
## Interface work
- Inspect src/components/ui and an existing screen before composing a new one.
- Use src/styles/tokens.css for approved design values.
- Reuse existing component props and interaction behavior.
- Report a missing variant before adding a replacement component.
- Verify the requested states and responsive layout before handoff.

Connect Perture and confirm the selected Brand Page
The connection supplies permitted context. It does not replace the need to inspect the repository or grant permission to edit every file. Installation details can vary by host and integration version, so use the current Perture setup instructions rather than copying an unrelated MCP command.
- Install and connect the Perture integration supported by your Codex environment using the setup instructions in Perture.
- Choose the Brand Page for the product being edited. Confirm that the connected account can access it.
- Ask Codex to retrieve the relevant brand and design system context before starting the interface task.
- Confirm that the component references correspond to the source in the current repository. Resolve missing source or incompatible variants first.

Describe one screen and its acceptance criteria
Begin with a bounded task such as an account settings screen. State what the user should accomplish, which existing shell and controls should be reused, and which states are required. Identify the files Codex may change and any behavior that must be preserved.
Ask Codex to name the components it plans to use before it makes changes. If it proposes a new Card or Input while the repository already provides one, correct the mapping at this point. This avoids finishing a visually plausible screen that bypasses the system.

Example:
Use the connected Perture Brand Page for this product.
Build an account settings screen with our existing React components.
First inspect their source and a current settings screen.
Show the component and variant mapping, then implement within the requested route.
Include save-in-progress, validation error, and saved states.
Verify the rendered desktop and mobile result and report any remaining gaps.

Check the result before accepting the task
If context retrieval failed, treat the task as missing context instead of interpreting a finished-looking screen as proof that the connection worked. Perture is most useful when the reusable system and the actual implementation remain connected throughout the task.
- The imports point to the intended library rather than newly recreated primitives.
- Component variants and props exist in the current source.
- The requested loading and error states can actually be reached.
- Spacing and typography follow the approved tokens and page patterns.
- The report distinguishes source checks, build results, and rendered verification.

### How to make Claude Code follow your design system
Source: https://perture.co/blog/brand-guidelines-for-claude-code
Claude Code needs both implementation context and design context. Put concrete repository conventions in CLAUDE.md, connect the permitted Perture Brand Page through its supported integration, and reference the actual components and tokens used by the product. Ask Claude Code to retrieve the relevant rules, inspect existing usages, and verify the required interface states before handoff.
Separate repository conventions from brand decisions
Project instructions should tell Claude Code where the implementation lives and how work is verified. Examples include the component import root, the token stylesheet, the form library, and the commands used by the project. These references keep the work grounded in the repository being edited.
Brand context describes the approved identity and interface rules: typography, colors, component families, spacing, states, and patterns. Perture organizes those decisions in a Brand Page for connected coding workflows. Use the two sources together; neither a local instruction file nor a remote context connection automatically establishes the full implementation of a component.


Confirm the connection before generating UI
MCP is a way for a host to connect to context and tools. The connected service still controls which information and operations the requesting account can access. Review the permissions relevant to your task; a read operation and an edit operation have different effects.
- Connect Perture using the current setup instructions for your Claude Code environment.
- Confirm the selected Brand Page and the requesting account's access.
- Ask Claude Code which context it retrieved for the task and which component source it can inspect.
- If a required asset, component, or rule is unavailable, resolve that gap before requesting a complete screen.

Write an implementation brief with visible states
The brief names the work and the behavior to preserve. It also prevents a common omission: a generated screen may display a default state correctly but never show what happens during submission or failure. Provide realistic labels and data so these conditions are part of the implementation.
Use a small first task to test the mapping between the Brand Page and the repository. If a component reference points to a design artifact but does not include executable source, say so explicitly. A visual reference can guide review, but it should not be presented as a verified React implementation.

Example:
Use this product's connected Perture Brand Page.
Create the billing settings view using the existing page shell and form controls.
Inspect supported component props before editing.
Include current-plan, loading, validation-error, and confirmation states.
Keep plan-change behavior intact and stay within the named view.
Check keyboard use, narrow-screen layout, and the rendered result.

Turn corrections into reusable decisions
When the result differs from the system, report the specific mismatch: the wrong variant, unsupported spacing, a missing focus state, or a replaced component. Fix the screen and clarify the source of the approved decision. Avoid adding every one-off screen preference to permanent project instructions.
For the next task, confirm that the corrected reference is still available to Claude Code. Perture helps make the system reusable across conversations, while the repository remains the place where runtime behavior and component APIs can be checked.


### How to use your existing design system in Cursor
Source: https://perture.co/blog/design-system-for-cursor
To keep Cursor interface work consistent, identify the existing component and token source, use project rules for concrete repository conventions, and connect the permitted Perture context for approved design decisions. Ask the agent to inspect current component usage, compose the screen from those components, and verify the required states and responsive behavior.
Map the system to files the agent can use
Start by identifying the source of a button, input, modal, and page shell. Record their import paths and one working usage for each. Find the semantic color and typography tokens, and distinguish library components from screen-specific wrappers.
This map is more useful than a list of hex colors because it connects the visual decisions to executable behavior. For example, an approved input may already contain labeling, validation, and focus behavior. Recreating only its border and padding discards that behavior even when the result looks similar.


Use project rules for implementation constraints
Cursor project rules can hold repository instructions and apply them to relevant files. Keep the instructions short and specific: where components are exported, which tokens to use, which existing pattern to follow, and which changes require review. Confirm the rule is applicable to the files being edited.
A useful rule also explains what to do when the system has no matching component. Ask for the missing requirement and propose a scoped extension. Without this instruction, an agent may invent a parallel component library to finish the screen.

Example:
Example rule content — adapt to the real repository:
Use the approved exports from src/components/ui.
Use semantic tokens from src/styles/tokens.css.
Inspect one existing page using the requested pattern.
Keep existing accessibility and form behavior.
Identify missing variants before creating new primitives.
Verify all requested states and the narrow-screen layout.

Connect the approved brand context
Use the current Perture setup instructions for Cursor and select the appropriate Brand Page. Ask the agent to retrieve relevant design rules and references for the task, then compare those references with the files it can inspect in the repository.
If the brand specifies a component that is not installed in the current project, the connection has not solved the implementation gap. Install or implement the component through an explicitly scoped task, or choose an approved alternative. Do not treat a context response as proof that a component exists in code.


Compose and verify one screen
Perture helps reuse the approved context across interface tasks. Project rules keep the repository constraints close to the code. The combination works best when a reviewer can trace a generated UI decision back to an existing component or an explicit design rule.
- Name the user's goal and the existing page pattern to follow.
- Provide realistic content and the required empty, loading, error, and success states.
- Ask the agent to show the component mapping and inspect their source.
- Implement within the agreed files using supported props and tokens.
- Check the rendered page, keyboard behavior, and small viewport, then record concrete gaps.

### Reduce Figma-to-code rework with the components you already have
Source: https://perture.co/blog/figma-to-code-with-existing-components
You can reduce Figma-to-code rework when the screen uses components and patterns that already exist in the product. Give the coding agent their real source and approved rules, compose the screen in the project, and refine the working experience. Figma remains useful for exploring new visual directions and missing patterns. Perture connects the approved system to the coding workflow rather than requiring every screen to be mocked up and recreated.
Choose the starting point based on what is already defined
The useful question is whether the system already answers the implementation decisions for this screen. When it does, building another complete mockup can duplicate work. When it does not, visual exploration and system design still have a role.


Connect the Figma reference to the runtime component
A Figma component and a React component are different artifacts. The design reference communicates intended appearance and may include variants or interactions. The runtime component defines props, state, rendering, and integration with the application. Record how the two correspond instead of assuming that matching names establish parity.
For each reused family, identify the approved design, the source implementation, the supported variants, and the states that matter to the screen. If the source is missing, mark the mapping as incomplete. An image or SVG export should not be described as an executable component.
- Component name and repository import path
- Variant-to-prop mapping
- Token references for typography, color, and spacing
- Default, focus, disabled, loading, and error states where relevant
- Responsive and content constraints

Refine the experience in the working screen
Ask the coding agent to compose the page from the approved components, then use the actual interface. Try long labels, an empty list, an invalid form, and a narrow viewport. These conditions make layout and interaction problems visible while the screen is still being shaped.
Review a change as both a design decision and an implementation decision. A new spacing value may improve one screen but introduce a token exception. A visual simplification may accidentally remove a state users need. Keep the system and the user's task visible during refinement.

Example:
Build this screen directly in the project from our existing components.
Use the connected Perture system and inspect the runtime source.
Keep approved tokens and supported variants.
Let us review the working loading, empty, and error states.
Report any design requirement that the current components cannot satisfy.

Use Perture to keep the references available
Perture organizes the approved components and design rules for connected coding workflows. Its Figma integration can bring selected component references into the Brand Page; the agent still needs the actual implementation source to reuse a runtime component faithfully.
Start with one existing flow rather than an entirely new product direction. Compare the resulting screen with the system, exercise the interactions, and record the unresolved mappings. The goal is to remove repeated handoff work where the decisions are already made, while giving new decisions the review they need.


### Use MCP to give coding agents your design system context
Source: https://perture.co/blog/mcp-server-for-brand-guidelines
MCP can connect a coding-agent host to a service that provides design system context and permitted tools. For interface work, useful context includes component references, source locations, variants, tokens, patterns, and review rules. Perture uses connected integrations to supply the approved Brand Page context. The connection does not by itself guarantee faithful UI or authorize unrestricted edits.
Understand the host, connection, and system source
In an MCP workflow, the host is the environment where the agent works. A client connection communicates with a server that exposes resources or tools. For a design system, that server may supply approved references and operations that the host can use during a task.
Separate the transport from the content. A successful connection establishes that the host can communicate with a service. It does not establish that the selected Brand Page is correct, that a referenced component exists in the repository, or that the current account is allowed to edit the system. Verify those conditions independently.


Supply the decisions needed for the requested screen
Retrieve the context relevant to the task instead of sending the entire system into every conversation. A settings form needs its fields, buttons, typography, validation rules, and page pattern. Unrelated campaign assets add material to read without answering those implementation questions.


Verify retrieval before implementation
If retrieval fails or returns incomplete references, report the missing context before proceeding. Otherwise the agent may complete a screen using generic defaults while the team assumes the design system was applied.
- Connect Perture using the instructions for the chosen coding-agent host.
- Select the intended Brand Page and confirm the account's permitted access.
- Ask the agent to retrieve the rules and components relevant to one interface task.
- Inspect the component source in the project and resolve missing or incompatible references.
- Implement within the agreed scope, then review source usage and the rendered experience.

Keep reading context and editing it separate
A coding task may need read access to the system and permission to change a few repository files. Updating the approved Brand Page is a separate operation. State which operation is required and avoid treating a successful read as permission to modify the source of truth.
Perture Solo includes plugin MCP for brand context and checks. Pro adds Pro MCP editing for the Brand Page and agent settings, along with Team Workspace, Brand Page sharing, and transfer. Choose the plan and permissions for the operation the team actually needs.


Measure whether the connection improves the task
These checks provide concrete evidence of usefulness. A connected badge alone cannot show whether the next screen follows the product's design decisions.
- Can the agent identify the intended Brand Page and relevant rules?
- Does the implementation import approved components rather than recreate them?
- Are required variants and interaction states present?
- Can a reviewer trace visual choices to the system?
- Does the task report distinguish context access, code changes, and rendered verification?

## Canonical sources
- Product and pricing: https://perture.co/
- Guides: https://perture.co/blog
- Designers: https://perture.co/designers
- Privacy: https://perture.co/privacy
- Terms: https://perture.co/terms
- Support: https://perture.co/support