How to use your design system with Codex

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 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.^‡

1. 01

   Install and connect the Perture integration supported by your Codex environment using the setup instructions in Perture.

2. 02

   Choose the Brand Page for the product being edited. Confirm that the connected account can access it.

3. 03

   Ask Codex to retrieve the relevant brand and design system context before starting the interface task.

4. 04

   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.

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.