Skip to main content

figma

Design-to-code workflow for Figma designs. Use when the user shares a Figma URL or asks to implement a design into the codebase.

Jump to install

Source facts

Repository
epam/ai-dial-ui-kit
Last source activity
May 14, 2026 at 17:59
Detected SKILL.md language
English
Stars
9
Forks
3

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
figma
description
Design-to-code workflow for Figma designs. Use when the user shares a Figma URL or asks to implement a design into the codebase.
# Figma Design-to-Code ## Overview Translate Figma designs into production-ready React components that match this repository's conventions: React 19, TypeScript, Tailwind CSS + SCSS, Storybook, and Vitest in `@epam/ai-dial-ui-kit`. ## When to Use - User shares a `figma.com` URL - User says "implement this design" or "build this screen" - User asks to match a Figma component or layout ## Workflow ### Step 1 — Fetch the design Call `get_design_context` with the `fileKey` and `nodeId` extracted from the URL. URL parsing rules: - `figma.com/design/:fileKey/...?node-id=:nodeId` → replace `-` with `:` in nodeId - `figma.com/board/:fileKey/...` → FigJam file, use `get_figjam` instead If the design context includes **Code Connect** snippets, prefer those — they map directly to codebase components. ### Step 2 — Map design to existing UI kit components first Before writing any new code, check whether existing components already cover the design: | Design need | Check first | | -------------------------------------- | ---------------------------------------------- | | Buttons, inputs, popups, tabs, loaders | `src/components/` | | Types and models | `src/types/` and `src/models/` | | Reusable behavior | `src/hooks/` and `src/utils/` | | Icons and icon wrappers | `src/assets/icons/` and `src/components/Icon/` | Search the codebase before building from scratch: ``` rg "Dial|ComponentName" src/components ``` ### Step 3 — Implement - Create or update files under `src/components/<ComponentName>/` - Keep exported component names prefixed with `Dial` (for example, `DialButton`) - Use TypeScript + TSX only - Use Tailwind classes and existing tokens/utilities; avoid inline styles and hardcoded design values - Use `mergeClasses` from `src/utils/merge-classes` when class composition is non-trivial - Keep accessibility parity with the design (labels, roles, keyboard interactions, focus handling) - Preserve existing visual language and patterns from nearby components ### Step 4 — Stories Add or update `Component.stories.tsx`. Every new prop and every Figma variant must have its own named story. Story checklist: - One story per Figma variant (e.g. `Info`, `Success`, `Warning`, `Error`, `Loading`) - One story per significant new prop (e.g. `WithTitle`, `Closable`) - An `AllVariants` render story showing every variant side-by-side - Add the new prop to `argTypes` with `control` and `description` - Add the new variant to any `options` array in `argTypes` Pattern: ```tsx export const MyVariant: Story = { args: { variant: MyVariantEnum.Value, message: 'Example text' }, }; export const AllVariants: Story = { render: () => ( <div className="flex flex-col gap-4 p-6"> <DialComponent variant={MyVariantEnum.A} message="A" /> <DialComponent variant={MyVariantEnum.B} message="B" /> </div> ), }; ``` ### Step 5 — Tests Add or update `Component.spec.tsx`. Cover every new prop and new variant. Test checklist: - Query by role first (`getByRole`), fall back to text only when no role applies - Test that new props render the expected output (e.g. title renders above message) - Test that new variants render their distinguishing element (e.g. spinner for Loading) - Test callback props are called with the correct event - Aim for ≥ 95% branch coverage on the component file Pattern: ```tsx test('Should render title above message when title is provided', () => { render(<DialComponent title="Heading" message="Body" />); const title = screen.getByText('Heading'); const message = screen.getByText('Body'); expect(title).toHaveClass('font-semibold'); expect(title.compareDocumentPosition(message)).toBe( Node.DOCUMENT_POSITION_FOLLOWING, ); }); test('Should render spinner for Loading variant', () => { render(<DialComponent variant="loading" message="Wait…" />); expect(screen.getByRole('status')).toBeInTheDocument(); }); ``` ### Step 6 — Verify 1. Export new public component/types in `src/index.ts` 2. Run `npm run typecheck` 3. Run `npm run lint` 4. Run `npm run test` ## Constraints - No breaking changes to existing component APIs unless explicitly requested - Do not introduce new dependencies unless necessary and approved - Do not copy raw Figma hex values; map to project tokens and existing theme primitives - Prefer semantic HTML and robust keyboard navigation over pixel-perfect but inaccessible markup - If Figma misses interaction states (hover, disabled, loading, error), implement sensible defaults and call out assumptions ## File Checklist For New Public Components When adding a new public component from Figma, include all of the following: - `src/components/<Name>/<Name>.tsx` - `src/components/<Name>/<Name>.stories.tsx` - `src/components/<Name>/<Name>.spec.tsx` - `src/index.ts` export updates (`export` and `export type` as needed)
View on GitHub