figma-component

name	figma-component
description	Сравнивать компоненты Plasma с точными нодами Figma, править существующие компоненты и создавать новые компоненты с нуля по существующему дизайну. Использовать, когда нужно изучить Figma-макет, сравнить его с существующим компонентом, реализовать новый компонент по Figma, добавить стили/токены/stories/тесты или исправить расхождения между компонентами Plasma и Figma-макетами.

Реализация компонента по Figma

Использовать этот skill, чтобы превратить конкретную Figma-ноду в компонент Plasma или точечные изменения существующего компонента без догадок о дизайне.

Обязательный порядок работы с Figma

1. Извлечь fileKey и nodeId из Figma URL. Преобразовать node-id=123-456 в 123:456.
2. Сначала вызвать Figma MCP get_design_context для точной ноды.
3. Затем вызвать Figma MCP get_screenshot для тех же fileKey и nodeId.
4. Если в URL нет конкретного node-id, запросить у пользователя ссылку на конкретную ноду до начала реализации.
5. Использовать сгенерированный Figma Tailwind или сырой React только как справочник. Переносить решение на архитектуру, токены, стили и соглашения этого репозитория.

Выбор сценария

После получения контекста Figma определить сценарий:

1. Правка существующего компонента: компонент уже есть в целевом пакете или в plasma-new-hope; нужно сравнить его с макетом и внести минимальные правки.
2. Новый компонент по существующему дизайну: подходящего компонента нет; нужно создать новый компонент, используя ближайшие существующие паттерны репозитория.

Если компонент похож на существующий, но отличается назначением или API, сначала проверить, можно ли выразить дизайн через props/config существующего компонента. Новый компонент создавать только когда переиспользование приведет к неестественному API, ломким overrides или смешению разных сущностей.

Изучение репозитория

Перед правками:

1. Найти целевой пакет и компонент:
   • Сначала искать существующие папки компонентов в packages/*/src/components/{Component}.
   • Проверять, живет ли общий примитив в packages/plasma-new-hope/src/components/{Component}.
   • Если компонент не найден, определить ближайшие аналоги по layout, слотам, токенам, интерактивности и story/test структуре.
2. Прочитать файлы компонента:
   • {Component}.config.ts
   • {Component}.ts или {Component}.tsx
   • {Component}.stories.tsx
   • component tests, если они есть
   • связанные shared tokens/styles/types в plasma-new-hope
   • для нового компонента: такие же файлы у 1-3 ближайших аналогов
3. Найти похожие компоненты или варианты в других пакетах до создания новых абстракций.
4. Сохранять публичный API и существующие паттерны, если макет явно не требует нового prop или нового компонента.
5. Для нового компонента проверить локальные export conventions:
   • packages/{pkg}/src/components/{Component}/index.ts
   • packages/{pkg}/src/index.ts
   • наличие *.config.ts, *.stories.tsx, *.component-test.tsx или *.update-test.component-test.tsx у соседних компонентов.

Правила маппинга дизайна

Маппить факты из Figma на конструкции репозитория:

• Типографика: использовать theme typography tokens, уже принятые в целевом пакете.
• Цвета: использовать theme color tokens или существующие CSS variables пакета.
• Размеры и отступы: задавать через component tokens в package config, если существующий примитив уже поддерживает эти значения.
• Layout: переиспользовать существующие slots и props, например contentLeft, contentRight, children, title, subtitle, label, stretching и props выравнивания.
• Иконки/assets: использовать существующие иконки репозитория только когда имя слоя в Figma или существующая конвенция однозначно определяет иконку. Если слой называется обобщенно, например icon, оставить его slot-based и отметить конкретный asset как неясный.
• Dividers/list behavior: переиспользовать существующие List, Divider или pseudo-element patterns, если такое поведение уже есть в репозитории.

Не хардкодить remote Figma asset URLs в исходный код. Они временные и не подходят для реализации в package.

Правила редактирования

Держать изменения узкими:

1. Предпочитать правки package config tokens вместо изменений shared primitive.
2. Менять shared-код plasma-new-hope только если целевой дизайн требует поведения, которое нельзя выразить через package config.
3. Обновлять stories, когда это самый понятный способ показать реализованное состояние дизайна.
4. Добавлять или обновлять тесты, когда меняется поведение, публичный API или visual contract.
5. Не придумывать отсутствующие детали дизайна. Добавлять короткий TODO или заметку в финальный ответ для всего, что осталось неясным.

При реализации нового компонента:

1. Выбрать базовую реализацию:
   • Если есть подходящий shared primitive в plasma-new-hope, создать package wrapper через component(mergeConfig(...)) и package config.
   • Если shared primitive отсутствует, создать минимальный новый primitive в наиболее подходящем слое только после проверки соседних компонентов и exports.
2. Следовать структуре ближайшего существующего компонента в целевом пакете.
3. Назвать props по существующим conventions репозитория, а не по случайным Figma layer names.
4. Экспортировать компонент из index.ts компонента и из package src/index.ts, если этого требует локальная конвенция.
5. Добавлять config, stories и focused tests по образцу соседних компонентов.
6. Для variants из Figma описывать размеры/виды через config variations и tokens, а не через ad hoc CSS в story.
7. Предпочитать wrappers/shared primitives из @salutejs/plasma-new-hope/styled-components, если они доступны.

Валидация

Запускать минимальные осмысленные проверки:

1. npm run lint --prefix packages/{target-package} для package edits.
2. npm run generate:typings --prefix packages/{target-package}, если могли измениться exported component types.
3. Запускать focused Cypress/component tests, если test files были добавлены или изменены.
4. Если command не удалось запустить, сообщать точную команду и причину сбоя.

Финальный ответ

Сообщать:

• Выполненные Figma calls: get_design_context и get_screenshot для точной ноды.
• Выбранный сценарий: правка существующего компонента или создание нового компонента.
• Измененные файлы.
• Важные design-to-code решения.
• Команды валидации и их результат.
• TODO для неясных деталей Figma, если они есть.