@newlogic-digital/core 4.1.11 → 4.1.12
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +9 -9
- package/skills/newlogic-ui/SKILL.md +14 -5
- package/skills/newlogic-ui/references/assets-guide.md +11 -9
- package/skills/newlogic-ui/references/project-guide.md +1 -1
- package/skills/newlogic-ui/references/scripting-guide.md +3 -18
- package/skills/newlogic-ui/references/styling-guide.md +4 -2
- package/skills/newlogic-ui/references/templating-guide.md +16 -9
- package/skills/figma-implement-design/SKILL.md +0 -246
- package/skills/figma-implement-design/agents/openai.yaml +0 -14
- package/skills/figma-implement-design/assets/figma-small.svg +0 -3
- package/skills/figma-implement-design/assets/figma.png +0 -0
- package/skills/figma-implement-design/assets/icon.svg +0 -28
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@newlogic-digital/core",
|
|
3
3
|
"type": "module",
|
|
4
|
-
"version": "4.1.
|
|
4
|
+
"version": "4.1.12",
|
|
5
5
|
"main": "index.js",
|
|
6
6
|
"bin": {
|
|
7
7
|
"newlogic-core": "./bin/newlogic-core.js"
|
|
@@ -24,20 +24,20 @@
|
|
|
24
24
|
"@vituum/vite-plugin-css-inline": "^2.1.0",
|
|
25
25
|
"@vituum/vite-plugin-latte": "^2.0.3",
|
|
26
26
|
"@vituum/vite-plugin-send": "^2.1.0",
|
|
27
|
-
"browserslist": "^4.29.
|
|
27
|
+
"browserslist": "^4.29.4",
|
|
28
28
|
"browserslist-to-esbuild": "^2.1.1",
|
|
29
29
|
"lightningcss": "^1.33.0",
|
|
30
|
-
"npm-check-updates": "^23.1.
|
|
31
|
-
"oxlint": "^1.
|
|
32
|
-
"postcss-custom-properties": "^15.0.
|
|
30
|
+
"npm-check-updates": "^23.1.1",
|
|
31
|
+
"oxlint": "^1.89.0",
|
|
32
|
+
"postcss-custom-properties": "^15.0.4",
|
|
33
33
|
"stylelint-config-standard": "^40.0.0",
|
|
34
34
|
"vituum": "^2.0.2"
|
|
35
35
|
},
|
|
36
36
|
"peerDependencies": {
|
|
37
|
-
"@tailwindcss/vite": "^4.
|
|
37
|
+
"@tailwindcss/vite": "^4.3.3",
|
|
38
38
|
"@vituum/vite-plugin-twig": "^2.0.1",
|
|
39
39
|
"fontless": "^1.0.0",
|
|
40
|
-
"vite": "^8.0
|
|
40
|
+
"vite": "^8.3.0"
|
|
41
41
|
},
|
|
42
42
|
"peerDependenciesMeta": {
|
|
43
43
|
"@vituum/vite-plugin-twig": {
|
|
@@ -54,8 +54,8 @@
|
|
|
54
54
|
"@tailwindcss/vite": "^4.3.3",
|
|
55
55
|
"@types/node": "^26.6",
|
|
56
56
|
"@vituum/vite-plugin-twig": "^2.0.1",
|
|
57
|
-
"fontless": "^1.
|
|
58
|
-
"rolldown": "^1.2.
|
|
57
|
+
"fontless": "^1.3.3",
|
|
58
|
+
"rolldown": "^1.2.15",
|
|
59
59
|
"typescript": "^6"
|
|
60
60
|
},
|
|
61
61
|
"files": [
|
|
@@ -5,9 +5,9 @@ description: This skill provides repo-specific rules for LLM agents working with
|
|
|
5
5
|
|
|
6
6
|
# Newlogic UI Skill
|
|
7
7
|
|
|
8
|
-
ALWAYS load `https://ui.newlogic.cz/llms
|
|
8
|
+
ALWAYS load `https://ui.newlogic.cz/llms.txt` before making changes in this framework. It is the index of the Newlogic UI docs and its links are relative to `https://ui.newlogic.cz`. Then load ONLY the pages relevant to the task, e.g. `https://ui.newlogic.cz/docs/components/button.md` when working with `x-button` or `https://ui.newlogic.cz/docs/usage.md` for the project structure. Do NOT load `llms-full.txt`.
|
|
9
9
|
|
|
10
|
-
ALWAYS read ALL local guides in `references/` before starting work. These guides are intentionally short and contain ONLY repo-specific rules that override, narrow, or clarify
|
|
10
|
+
ALWAYS read ALL local guides in `references/` before starting work. These guides are intentionally short and contain ONLY repo-specific rules that override, narrow, or clarify the Newlogic UI docs.
|
|
11
11
|
|
|
12
12
|
## Source Priority
|
|
13
13
|
|
|
@@ -15,13 +15,13 @@ Use this priority order when rules differ:
|
|
|
15
15
|
|
|
16
16
|
1. Existing files in this repository
|
|
17
17
|
2. Local guides in this skill
|
|
18
|
-
3. `https://ui.newlogic.cz/llms
|
|
18
|
+
3. Newlogic UI docs (`https://ui.newlogic.cz/llms.txt` and the pages it links to)
|
|
19
19
|
|
|
20
20
|
## Working Rule
|
|
21
21
|
|
|
22
|
-
Use
|
|
22
|
+
Use the Newlogic UI docs for framework behavior, available components, and implementation examples.
|
|
23
23
|
|
|
24
|
-
Use the local guides for repository conventions that MUST be followed even if a generic example from
|
|
24
|
+
Use the local guides for repository conventions that MUST be followed even if a generic example from the docs suggests another valid approach.
|
|
25
25
|
|
|
26
26
|
## Required Guides
|
|
27
27
|
|
|
@@ -31,3 +31,12 @@ Use the local guides for repository conventions that MUST be followed even if a
|
|
|
31
31
|
- [Styling Guide](references/styling-guide.md) - local CSS and component styling constraints
|
|
32
32
|
- [Theme Guide](references/theme-guide.md) - local theme token and theme file rules
|
|
33
33
|
- [Scripting Guide](references/scripting-guide.md) - local JS and Stimulus placement rules
|
|
34
|
+
|
|
35
|
+
## Verification
|
|
36
|
+
|
|
37
|
+
Before reporting the work as done:
|
|
38
|
+
|
|
39
|
+
- `npm run lint` MUST pass.
|
|
40
|
+
- `npm run build` MUST pass. It compiles the Latte templates and requires PHP.
|
|
41
|
+
- Generated `+.css` / `+.js` files are up to date and committed, see the Scripting and Styling guides.
|
|
42
|
+
- If a command cannot run in your environment, say so instead of claiming the work is verified.
|
|
@@ -28,11 +28,12 @@
|
|
|
28
28
|
|
|
29
29
|
- ALWAYS use SVG for icons.
|
|
30
30
|
- Prefer `<use>` for reusable icons.
|
|
31
|
-
- If adding reusable outline icons, place them in `src/icons/outline
|
|
32
|
-
- If adding reusable solid icons, place them in `src/icons/solid
|
|
33
|
-
- Brand icons are
|
|
34
|
-
-
|
|
35
|
-
-
|
|
31
|
+
- If adding reusable outline icons, place them in `src/icons/outline/` and reference them as `#icons-outline/<name>`.
|
|
32
|
+
- If adding reusable solid icons, place them in `src/icons/solid/` and reference them as `#icons-solid/<name>`.
|
|
33
|
+
- Brand icons are bundled with Newlogic Core (`node_modules/@newlogic-digital/core/icons/simpleicons/`: apple, facebook, google, instagram, linkedin, messenger, threads, whatsapp, x, youtube) as `#simpleicons-solid/<name>`. Add a brand icon to `src/icons/simpleicons/` ONLY when it is not bundled.
|
|
34
|
+
- The Newlogic logo is bundled as `#icons-solid/newlogic-logomark` and `#icons-solid/newlogic-logotype`.
|
|
35
|
+
- Heroicons are available through the build setup as `#heroicons-outline/<name>`, `#heroicons-solid/<name>`, `#heroicons-mini/<name>` (20×20) and `#heroicons-micro/<name>` (16×16), so do NOT duplicate them in `src/icons/`.
|
|
36
|
+
- The `<use href="...">` symbol definitions are generated automatically by the build setup into `public/icons.svg`.
|
|
36
37
|
- Icon IDs SHOULD generally follow Figma naming when possible.
|
|
37
38
|
- Inline `<svg>` without `<use>` is allowed ONLY for one-off icons that will NOT be reused.
|
|
38
39
|
|
|
@@ -59,8 +60,9 @@
|
|
|
59
60
|
### Icon Strategy Summary
|
|
60
61
|
|
|
61
62
|
1. Heroicons via `<use href="#heroicons-*/*">`
|
|
62
|
-
2.
|
|
63
|
-
3.
|
|
63
|
+
2. Bundled Newlogic Core icons via `#simpleicons-solid/*` and `#icons-solid/newlogic-*`
|
|
64
|
+
3. Project reusable icons via `src/icons/outline`, `src/icons/solid`, or `src/icons/simpleicons`
|
|
65
|
+
4. Inline `<svg>` without `<use>` for one-off icons ONLY
|
|
64
66
|
|
|
65
67
|
## Example
|
|
66
68
|
You are about to translate the Figma output into this project.
|
|
@@ -105,8 +107,8 @@ You are about to translate the Figma output into this project.
|
|
|
105
107
|
### Step 2 – Icon
|
|
106
108
|
- You check the width and height of the icon and decide if it is a brand icon, heroicon or other icon.
|
|
107
109
|
|
|
108
|
-
- If you identify the icon as a brand icon, you will check if it is already
|
|
109
|
-
- If it is not available, you will add it to `src/icons/simpleicons`.
|
|
110
|
+
- If you identify the icon as a brand icon, you will check if it is already bundled in `node_modules/@newlogic-digital/core/icons/simpleicons` or present in `src/icons/simpleicons`.
|
|
111
|
+
- If it is not available in either place, you will add it to `src/icons/simpleicons`.
|
|
110
112
|
- If it is available, you will use the existing icon.
|
|
111
113
|
- You will use the following markup in the HTML:
|
|
112
114
|
|
|
@@ -6,7 +6,7 @@
|
|
|
6
6
|
- Use kebab-case with `x-` prefix for component classes such as `x-button`, `x-hero-section`.
|
|
7
7
|
- ALWAYS check if the component class name matches the file name, e.g. `HeroSection.latte` and `x-hero-section` matches
|
|
8
8
|
- ALWAYS keep one primary `x-*` component per file.
|
|
9
|
-
- Use
|
|
9
|
+
- Use camelCase for generic JS files such as `initAfter.js` and lowercase for generic CSS files such as `breakpoints.css`.
|
|
10
10
|
|
|
11
11
|
## Placement
|
|
12
12
|
|
|
@@ -14,25 +14,10 @@
|
|
|
14
14
|
- Register one primary controller per file.
|
|
15
15
|
- Keep controller names aligned with existing `x-*` naming in this repo.
|
|
16
16
|
- If dynamic HTML is inserted into the DOM, ALWAYS re-initialize it with `src/scripts/utils/initAfter.js`.
|
|
17
|
-
-
|
|
18
|
-
|
|
19
|
-
**Local `initAfter` import pattern:**
|
|
20
|
-
|
|
21
|
-
```javascript
|
|
22
|
-
import { initAfter } from '../utils/+.js'
|
|
23
|
-
|
|
24
|
-
initAfter(document.querySelector('.newlyAppendedContent'))
|
|
25
|
-
```
|
|
26
|
-
|
|
27
|
-
**Aggregator pattern:**
|
|
28
|
-
|
|
29
|
-
```javascript
|
|
30
|
-
// src/scripts/components/(ui)/+.js
|
|
31
|
-
import './Button.js'
|
|
32
|
-
import './Dialog.js'
|
|
33
|
-
```
|
|
17
|
+
- `+.js` files are generated by the Vituum imports plugin only while `npm run dev` runs, never during `npm run build`, and are committed. Do NOT add imports manually; after adding or deleting files run `npm run dev` once and commit the updated `+.js` (a new directory needs one more dev server start).
|
|
18
|
+
- `src/scripts/main.js` is written by hand, so a new directory directly under `src/scripts/` must be imported there.
|
|
34
19
|
|
|
35
20
|
## Before Adding JS
|
|
36
21
|
|
|
37
|
-
- Prefer existing Winduum, Stimulus, or utility behavior from `llms
|
|
22
|
+
- Prefer existing Winduum, Webuum, Stimulus, or utility behavior from the Newlogic UI docs (`llms.txt`) before creating new custom JS.
|
|
38
23
|
- Do NOT introduce a second interaction pattern if the repo already has an established controller for the same problem.
|
|
@@ -3,9 +3,11 @@
|
|
|
3
3
|
## General
|
|
4
4
|
|
|
5
5
|
- ALWAYS prefer Tailwind utilities before writing custom CSS.
|
|
6
|
-
- Use custom CSS for defaults, complex states, or component-specific behavior that should
|
|
6
|
+
- Use custom CSS for defaults, very complex states, or component-specific behavior that should not live in templates.
|
|
7
7
|
- Follow nearby files before introducing a new styling pattern.
|
|
8
8
|
- Prefer responsive utilities such as `sm:`, `md:`, and `lg:` in templates. Use `@custom-media` only when writing custom CSS.
|
|
9
|
+
- `+.css` files are generated by the Vituum imports plugin only while `npm run dev` runs, never during `npm run build`, and are committed. Do NOT add imports manually; after adding or deleting files run `npm run dev` once and commit the updated `+.css` (a new directory needs one more dev server start).
|
|
10
|
+
- `src/styles/main.css` and `src/styles/emails/main.css` are written by hand, so a new directory directly under `src/styles/` must be imported there.
|
|
9
11
|
|
|
10
12
|
**Custom breakpoint example:**
|
|
11
13
|
|
|
@@ -26,7 +28,7 @@
|
|
|
26
28
|
- Define base sizing, padding, radius, font defaults, and default colors in CSS for UI components.
|
|
27
29
|
- In templates, only small layout utilities are allowed on UI components, such as width, flex, gap, order, or spacing adjustments.
|
|
28
30
|
- Do NOT redefine a UI component's base look directly in templates.
|
|
29
|
-
- Do NOT restyle existing `x-*` UI components from a large level CSS file when the change is really a button, badge, control, field, pagination, or other UI-component concern.
|
|
31
|
+
- Do NOT restyle existing `x-*` UI components from a large level CSS file (eg. main.css) when the change is really a button, badge, control, field, pagination, or other UI-component concern.
|
|
30
32
|
- If a Figma page introduces a new shared UI look, extend the relevant file in `src/styles/components/(ui)/` instead of creating specific overrides from a parent component for that component.
|
|
31
33
|
|
|
32
34
|
## Non-UI Components
|
|
@@ -7,10 +7,10 @@
|
|
|
7
7
|
|
|
8
8
|
## Data Sources
|
|
9
9
|
|
|
10
|
-
- Global data lives in `src/data
|
|
10
|
+
- Global data lives in `src/data/*.json`; every file is merged into every page (`main.json`, `nav.json`, `socials.json`).
|
|
11
11
|
- In this repo, global layout sections are typically defined through `head` and `foot` arrays in `src/data/main.json`.
|
|
12
12
|
- Page data lives in `src/pages/*.json` and inherits global data.
|
|
13
|
-
-
|
|
13
|
+
- Components listed in `head`, `body`, and `foot` are rendered through `src/templates/utils/components.latte`.
|
|
14
14
|
- Components referenced from page JSON are passed as `$control`.
|
|
15
15
|
- In this repo, `src/pages/*.json` is the composition layer for whole pages. Prefer assembling a page there instead of creating a wrapper `*Page.latte` component that just nests the entire page structure.
|
|
16
16
|
- Preserve the existing `head` and `foot` layout structure unless the user explicitly asks to change the layout contract.
|
|
@@ -32,8 +32,8 @@
|
|
|
32
32
|
**Layout asset access example:**
|
|
33
33
|
|
|
34
34
|
```latte
|
|
35
|
-
<link n:foreach="$assets->
|
|
36
|
-
<script src="{$assets->
|
|
35
|
+
<link n:foreach="$assets->links->main as $url" href="{$url->href|asset}" rel="{isset($url->rel) ? $url->rel}">
|
|
36
|
+
<script n:ifset="$assets->scripts->main" src="{$assets->scripts->main|asset}" type="module"></script>
|
|
37
37
|
```
|
|
38
38
|
|
|
39
39
|
## JSON Rules
|
|
@@ -41,7 +41,7 @@
|
|
|
41
41
|
- Do NOT store CSS class strings in JSON.
|
|
42
42
|
- JSON should contain semantic values and content, NOT presentation classes.
|
|
43
43
|
- If a template depends on an optional flag such as `active`, `dropdown`, or variant switches, define that flag explicitly in JSON.
|
|
44
|
-
- Keep repeated global UI data in `src/data
|
|
44
|
+
- Keep repeated global UI data in `src/data/`, in its own file such as `nav.json`, rather than duplicating it across page JSON files.
|
|
45
45
|
|
|
46
46
|
## Latte Rules
|
|
47
47
|
|
|
@@ -49,11 +49,14 @@
|
|
|
49
49
|
- Keep ad hoc `{var ...}` usage to a minimum.
|
|
50
50
|
- Use `{default}` for optional fallback values when needed.
|
|
51
51
|
- Do NOT combine `class` and `n:class` on the same element. Use one `n:class` expression that includes the base classes.
|
|
52
|
+
- Write `n:class` as a comma-separated list: base classes first, then conditional expressions such as `$cond ? 'a' : 'b'` or `$cond ? 'a'`.
|
|
53
|
+
- Reusable `(ui)` components accept extra classes through `$classAttribute` (see `Pagination.latte`); pass them from the include as `classAttribute: '...'`.
|
|
52
54
|
|
|
53
55
|
**`n:class` pattern:**
|
|
54
56
|
|
|
55
57
|
```latte
|
|
56
|
-
<
|
|
58
|
+
<nav n:class="'x-pagination flex gap-2', $classAttribute ?? ''">...</nav>
|
|
59
|
+
<a n:class="'x-button square sm', $iterator->first ? 'pointer-events-none' : 'muted'">1</a>
|
|
57
60
|
```
|
|
58
61
|
|
|
59
62
|
**`{default}` pattern:**
|
|
@@ -88,8 +91,9 @@
|
|
|
88
91
|
```
|
|
89
92
|
|
|
90
93
|
```latte
|
|
91
|
-
{
|
|
92
|
-
|
|
94
|
+
{* src/templates/utils/components.latte *}
|
|
95
|
+
{foreach $components as $component}
|
|
96
|
+
{include ('../' . $component->src), control => $component}
|
|
93
97
|
{/foreach}
|
|
94
98
|
```
|
|
95
99
|
|
|
@@ -101,6 +105,9 @@
|
|
|
101
105
|
|
|
102
106
|
**Direct include pattern:**
|
|
103
107
|
|
|
108
|
+
Include paths are resolved relative to the directory of the current template file, e.g. from `src/templates/layouts/default.latte`:
|
|
109
|
+
|
|
104
110
|
```latte
|
|
105
|
-
{include 'components/
|
|
111
|
+
{include '../components/(ui)/Toast.latte'}
|
|
112
|
+
{include '../components/(ui)/Pagination.latte', classAttribute: 'mt-8'}
|
|
106
113
|
```
|
|
@@ -1,246 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: figma-implement-design
|
|
3
|
-
description: Translate Figma nodes into production-ready code with 1:1 visual fidelity using the Figma MCP workflow (design context, screenshots, assets, and project-convention translation). Trigger when the user provides Figma URLs or node IDs, or asks to implement designs or components that must match Figma specs. Requires a working Figma MCP server connection.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Implement Design
|
|
7
|
-
|
|
8
|
-
## Overview
|
|
9
|
-
|
|
10
|
-
This skill provides a structured workflow for translating Figma designs into production-ready code with pixel-perfect accuracy. It ensures consistent integration with the Figma MCP server, proper use of design tokens, and 1:1 visual parity with designs.
|
|
11
|
-
|
|
12
|
-
## Prerequisites
|
|
13
|
-
|
|
14
|
-
- Figma MCP server must be connected and accessible
|
|
15
|
-
- User must provide a Figma URL in the format: `https://figma.com/design/:fileKey/:fileName?node-id=1-2`
|
|
16
|
-
- `:fileKey` is the file key
|
|
17
|
-
- `1-2` is the node ID (the specific component or frame to implement)
|
|
18
|
-
- **OR** when using `figma-desktop` MCP: User can select a node directly in the Figma desktop app (no URL required)
|
|
19
|
-
- Project should have an established design system or component library (preferred)
|
|
20
|
-
|
|
21
|
-
### Step 1: Get Node ID
|
|
22
|
-
|
|
23
|
-
#### Option A: Parse from Figma URL
|
|
24
|
-
|
|
25
|
-
When the user provides a Figma URL, extract the file key and node ID to pass as arguments to MCP tools.
|
|
26
|
-
|
|
27
|
-
**URL format:** `https://figma.com/design/:fileKey/:fileName?node-id=1-2`
|
|
28
|
-
|
|
29
|
-
**Extract:**
|
|
30
|
-
|
|
31
|
-
- **File key:** `:fileKey` (the segment after `/design/`)
|
|
32
|
-
- **Node ID:** `1-2` (the value of the `node-id` query parameter)
|
|
33
|
-
|
|
34
|
-
**Note:** When using the local desktop MCP (`figma-desktop`), `fileKey` is not passed as a parameter to tool calls. The server automatically uses the currently open file, so only `nodeId` is needed.
|
|
35
|
-
|
|
36
|
-
**Example:**
|
|
37
|
-
|
|
38
|
-
- URL: `https://figma.com/design/kL9xQn2VwM8pYrTb4ZcHjF/DesignSystem?node-id=42-15`
|
|
39
|
-
- File key: `kL9xQn2VwM8pYrTb4ZcHjF`
|
|
40
|
-
- Node ID: `42-15`
|
|
41
|
-
|
|
42
|
-
#### Option B: Use Current Selection from Figma Desktop App (figma-desktop MCP only)
|
|
43
|
-
|
|
44
|
-
When using the `figma-desktop` MCP and the user has NOT provided a URL, the tools automatically use the currently selected node from the open Figma file in the desktop app.
|
|
45
|
-
|
|
46
|
-
**Note:** Selection-based prompting only works with the `figma-desktop` MCP server. The remote server requires a link to a frame or layer to extract context. The user must have the Figma desktop app open with a node selected.
|
|
47
|
-
|
|
48
|
-
### Step 2: Fetch Design Context
|
|
49
|
-
|
|
50
|
-
Run `get_design_context` with the extracted file key and node ID.
|
|
51
|
-
|
|
52
|
-
```
|
|
53
|
-
get_design_context(fileKey=":fileKey", nodeId="1-2")
|
|
54
|
-
```
|
|
55
|
-
|
|
56
|
-
This provides the structured data including:
|
|
57
|
-
|
|
58
|
-
- Layout properties (Auto Layout, constraints, sizing)
|
|
59
|
-
- Typography specifications
|
|
60
|
-
- Color values and design tokens
|
|
61
|
-
- Component structure and variants
|
|
62
|
-
- Spacing and padding values
|
|
63
|
-
|
|
64
|
-
**If the response is too large or truncated:**
|
|
65
|
-
|
|
66
|
-
1. Run `get_metadata(fileKey=":fileKey", nodeId="1-2")` to get the high-level node map
|
|
67
|
-
2. Identify the specific child nodes needed from the metadata
|
|
68
|
-
3. Fetch individual child nodes with `get_design_context(fileKey=":fileKey", nodeId=":childNodeId")`
|
|
69
|
-
4. Run `get_variable_defs(fileKey=":fileKey", nodeId="1-2")` to get the variable definitions for the child nodes
|
|
70
|
-
|
|
71
|
-
### Step 3: Resolve Code Connect Mappings
|
|
72
|
-
|
|
73
|
-
Run `get_code_connect_map` on the same top-level node before implementation starts.
|
|
74
|
-
|
|
75
|
-
```
|
|
76
|
-
get_code_connect_map(fileKey=":fileKey", nodeId="1-2")
|
|
77
|
-
```
|
|
78
|
-
|
|
79
|
-
This step is mandatory for a correct design-system handoff.
|
|
80
|
-
|
|
81
|
-
**Interpretation rules:**
|
|
82
|
-
|
|
83
|
-
- If `nodeId="1-2"` is a page, frame, or large section, treat the returned map as the authoritative list of mapped descendant components that MUST be preserved in the final handoff.
|
|
84
|
-
- Do NOT assume the explicit `CodeConnectSnippet` wrappers shown in `get_design_context` are the full list. A page-level `get_code_connect_map` may return many more mapped descendants.
|
|
85
|
-
- `CodeConnectSnippet` wrapper elements are never part of final code. Use only the inner snippet or the actual mapped component in the codebase.
|
|
86
|
-
- Do NOT rename Code Connect classes, collapse modifier classes into new aliases, or replace mapped snippet APIs with custom helper classes just because the implementation is standalone or the classes do not exist yet. Implement the missing styles behind the mapped contract instead.
|
|
87
|
-
- If you must diverge from the mapped markup or class API for technical reasons, STOP and get explicit user approval first. Explain the exact incompatibility and the minimal required deviation.
|
|
88
|
-
|
|
89
|
-
### Step 3: Capture Visual Reference
|
|
90
|
-
|
|
91
|
-
Run `get_screenshot` with the same file key and node ID for a visual reference.
|
|
92
|
-
|
|
93
|
-
```
|
|
94
|
-
get_screenshot(fileKey=":fileKey", nodeId="1-2")
|
|
95
|
-
```
|
|
96
|
-
|
|
97
|
-
This screenshot serves as the source of truth for visual validation. Keep it accessible throughout implementation.
|
|
98
|
-
|
|
99
|
-
### Step 4: Download Assets
|
|
100
|
-
|
|
101
|
-
Download any assets (images, icons, SVGs) returned by the Figma MCP server, BUT ONLY if the user specifically asks, otherwise skip this step.
|
|
102
|
-
|
|
103
|
-
**IMPORTANT:** Follow these asset rules:
|
|
104
|
-
|
|
105
|
-
- NEVER invent, redraw, approximate, reconstruct, or substitute assets that already exist in the Figma payload. If Figma provides an icon, SVG, image, or vector, use that original asset or exact markup. If you are about to replace an existing asset ALWAYS STOP AND ASK the user first.
|
|
106
|
-
- If the original Figma code already contains the asset markup, preserve or translate that exact asset instead of recreating it by hand.
|
|
107
|
-
- Assets are served through the Figma MCP server's built-in assets endpoint
|
|
108
|
-
- If the user or other skill specifies to use placeholder assets, or icon packs, follow the provided guidelines and do NOT use figma assets.
|
|
109
|
-
- If an asset URL or payload cannot be consumed in the target runtime, treat that as a blocker for exact fidelity. Report the failure clearly and ask the user before recreating, approximating, or substituting the asset.
|
|
110
|
-
|
|
111
|
-
### Step 5: Translate to Project Conventions
|
|
112
|
-
|
|
113
|
-
Translate the Figma output into this project's framework, styles, and conventions.
|
|
114
|
-
|
|
115
|
-
**Key principles:**
|
|
116
|
-
|
|
117
|
-
- Treat the Figma MCP output (typically React + Tailwind) as a representation of design and behavior, not as final code style
|
|
118
|
-
- Treat Code Connect mappings as authoritative handoff requirements, not optional hints
|
|
119
|
-
- Review that the Tailwind utility classes are using the latest Tailwind conventions and patterns (MUST be version 4 and above)
|
|
120
|
-
- Always use Tailwind CSS v4. If the project does not already have a Tailwind build pipeline, use the browser build from `https://cdn.jsdelivr.net/npm/@tailwindcss/browser@4`. Do NOT use the legacy `https://cdn.tailwindcss.com` script.
|
|
121
|
-
- Reuse existing components (buttons, inputs, typography, icon wrappers) instead of duplicating functionality
|
|
122
|
-
- Search the codebase for mapped component sources before falling back to raw snippets
|
|
123
|
-
- Use the project's color system, typography scale, and spacing tokens consistently
|
|
124
|
-
- Respect existing routing, state management, and data-fetch patterns
|
|
125
|
-
- Preserve the original Figma layout and DOM structure as closely as possible. Do NOT redesign, simplify, restructure, or "improve" the layout unless responsiveness, technical constraints, or an explicit user request requires it.
|
|
126
|
-
- Responsiveness is the default exception: adapt layout only as much as needed for smaller breakpoints while keeping the desktop structure faithful to the original frame.
|
|
127
|
-
- If you are about to make a large structural change, invent missing structure, or replace original layout patterns with new ones, STOP and ASK the user first.
|
|
128
|
-
- If Code Connect provides raw HTML class contracts instead of framework components, preserve those contracts in the final output. Add CSS/Tailwind support for them if needed, but do not silently translate them into a different API.
|
|
129
|
-
|
|
130
|
-
### Step 6: Achieve 1:1 Visual Parity
|
|
131
|
-
|
|
132
|
-
Strive for pixel-perfect visual parity with the Figma design.
|
|
133
|
-
|
|
134
|
-
**Guidelines:**
|
|
135
|
-
|
|
136
|
-
- Prioritize Figma fidelity to match designs exactly
|
|
137
|
-
- Avoid hardcoded values - use design tokens from Figma where available
|
|
138
|
-
- When conflicts arise between design system tokens and Figma specs, prefer design system tokens but adjust spacing or sizes minimally to match visuals
|
|
139
|
-
- Follow WCAG requirements for accessibility
|
|
140
|
-
- Add component documentation as needed
|
|
141
|
-
|
|
142
|
-
### Step 7: Validate Against Figma
|
|
143
|
-
|
|
144
|
-
Before marking complete, validate the final UI against the Figma screenshot.
|
|
145
|
-
|
|
146
|
-
**Validation checklist:**
|
|
147
|
-
|
|
148
|
-
- [ ] Layout matches (spacing, alignment, sizing)
|
|
149
|
-
- [ ] Typography matches (font, size, weight, line height)
|
|
150
|
-
- [ ] Colors match exactly
|
|
151
|
-
- [ ] Interactive states work as designed (hover, active, disabled)
|
|
152
|
-
- [ ] Responsive behavior follows Figma constraints
|
|
153
|
-
- [ ] Assets render correctly
|
|
154
|
-
- [ ] Every descendant returned by `get_code_connect_map` on the top-level node is represented in the final code
|
|
155
|
-
- [ ] Accessibility standards met
|
|
156
|
-
|
|
157
|
-
### Step 8: Validate Against Browser
|
|
158
|
-
|
|
159
|
-
Use the /agent-browser skill if exists to validate the final UI in the browser.
|
|
160
|
-
|
|
161
|
-
- If the skill does not exist, skip this step.
|
|
162
|
-
- If the skill command fails, ask the user to manually validate the UI in the browser and skip this step.
|
|
163
|
-
|
|
164
|
-
## Implementation Rules
|
|
165
|
-
|
|
166
|
-
### Component Organization
|
|
167
|
-
|
|
168
|
-
- Place UI components in the project's designated design system directory
|
|
169
|
-
- Follow the project's component naming conventions
|
|
170
|
-
- Avoid inline styles unless truly necessary for dynamic values
|
|
171
|
-
|
|
172
|
-
### Design System Integration
|
|
173
|
-
|
|
174
|
-
- ALWAYS use components from the project's design system when possible
|
|
175
|
-
- ALWAYS preserve mapped Code Connect components in the final handoff when they exist
|
|
176
|
-
- When using mapped Code Connect snippets directly, preserve their public contract exactly: same tags, same classes, same attributes, same variant/modifier naming.
|
|
177
|
-
- Map Figma design tokens to project design tokens
|
|
178
|
-
- When a matching component exists, extend it rather than creating a new one
|
|
179
|
-
- Document any new components added to the design system
|
|
180
|
-
- If any workaround would change assets, mapped component contracts, markup structure, or visual composition in a way that is not explicitly present in Figma, STOP and get user approval first.
|
|
181
|
-
|
|
182
|
-
## Examples
|
|
183
|
-
|
|
184
|
-
### Example 1: Implementing a Button Component
|
|
185
|
-
|
|
186
|
-
User says: "Implement this Figma button component: https://figma.com/design/kL9xQn2VwM8pYrTb4ZcHjF/DesignSystem?node-id=42-15"
|
|
187
|
-
|
|
188
|
-
**Actions:**
|
|
189
|
-
|
|
190
|
-
1. Parse URL to extract fileKey=`kL9xQn2VwM8pYrTb4ZcHjF` and nodeId=`42-15`
|
|
191
|
-
2. Run `get_design_context(fileKey="kL9xQn2VwM8pYrTb4ZcHjF", nodeId="42-15")` and `get_code_connect_map(fileKey="kL9xQn2VwM8pYrTb4ZcHjF", nodeId="42-15")`
|
|
192
|
-
3. Run `get_screenshot(fileKey="kL9xQn2VwM8pYrTb4ZcHjF", nodeId="42-15")` for visual reference
|
|
193
|
-
4. Download any button icons from the assets endpoint
|
|
194
|
-
5. Check if project has existing button component
|
|
195
|
-
6. If yes, extend it with new variant; if no, create new component using project conventions
|
|
196
|
-
7. Map Figma colors to project design tokens (e.g., `primary-500`, `primary-hover`)
|
|
197
|
-
8. Validate against screenshot for padding, border radius, typography
|
|
198
|
-
|
|
199
|
-
**Result:** Button component matching Figma design, integrated with project design system.
|
|
200
|
-
|
|
201
|
-
### Example 2: Building a Dashboard Layout
|
|
202
|
-
|
|
203
|
-
User says: "Build this dashboard: https://figma.com/design/pR8mNv5KqXzGwY2JtCfL4D/Dashboard?node-id=10-5"
|
|
204
|
-
|
|
205
|
-
**Actions:**
|
|
206
|
-
|
|
207
|
-
1. Parse URL to extract fileKey=`pR8mNv5KqXzGwY2JtCfL4D` and nodeId=`10-5`
|
|
208
|
-
2. Run `get_metadata(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId="10-5")` to understand the page structure
|
|
209
|
-
3. Identify main sections from metadata (header, sidebar, content area, cards) and their child node IDs
|
|
210
|
-
4. Run `get_design_context(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId=":childNodeId")` and `get_code_connect_map(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId=":childNodeId")` for each major section
|
|
211
|
-
5. Run `get_screenshot(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId="10-5")` for the full page
|
|
212
|
-
6. Download all assets (logos, icons, charts)
|
|
213
|
-
7. Build layout using project's layout primitives
|
|
214
|
-
8. Implement each section using existing components where possible
|
|
215
|
-
9. Validate responsive behavior against Figma constraints
|
|
216
|
-
|
|
217
|
-
### Code Quality
|
|
218
|
-
|
|
219
|
-
- Avoid hardcoded values - extract to constants or design tokens
|
|
220
|
-
- Keep components composable and reusable
|
|
221
|
-
|
|
222
|
-
## Best Practices
|
|
223
|
-
|
|
224
|
-
### Always Start with Context
|
|
225
|
-
|
|
226
|
-
Never implement based on assumptions. Always fetch `get_design_context`, `get_code_connect_map` and `get_screenshot` first.
|
|
227
|
-
|
|
228
|
-
### Original Assets First
|
|
229
|
-
|
|
230
|
-
If Figma already provides an asset, vector, or exact SVG/code representation, use that original source. Do NOT redraw icons, invent substitute artwork, or replace provided assets with lookalikes.
|
|
231
|
-
|
|
232
|
-
### Incremental Validation
|
|
233
|
-
|
|
234
|
-
Validate frequently during implementation, not just at the end. This catches issues early.
|
|
235
|
-
|
|
236
|
-
### Ask Before Large Inventions
|
|
237
|
-
|
|
238
|
-
If the implementation required inventing significant structure, changing layout patterns, or making large visual/architectural decisions that were not explicitly requested, STOP and ask the user before proceeding.
|
|
239
|
-
|
|
240
|
-
### Reuse Over Recreation
|
|
241
|
-
|
|
242
|
-
Always check for existing components before creating new ones. Consistency across the codebase is more important than exact Figma replication.
|
|
243
|
-
|
|
244
|
-
### Design System First
|
|
245
|
-
|
|
246
|
-
When in doubt, prefer the project's design system patterns over literal Figma translation.
|
|
@@ -1,14 +0,0 @@
|
|
|
1
|
-
interface:
|
|
2
|
-
display_name: "Figma Implement Design"
|
|
3
|
-
short_description: "Turn Figma designs into production-ready code"
|
|
4
|
-
icon_small: "./assets/figma-small.svg"
|
|
5
|
-
icon_large: "./assets/figma.png"
|
|
6
|
-
default_prompt: "Implement this Figma design in this codebase, using mapped Code Connect components wherever available and matching layout, states, and responsive behavior."
|
|
7
|
-
|
|
8
|
-
dependencies:
|
|
9
|
-
tools:
|
|
10
|
-
- type: "mcp"
|
|
11
|
-
value: "figma"
|
|
12
|
-
description: "Figma MCP server"
|
|
13
|
-
transport: "streamable_http"
|
|
14
|
-
url: "https://mcp.figma.com/mcp"
|
|
@@ -1,3 +0,0 @@
|
|
|
1
|
-
<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" fill="currentColor" viewBox="0 0 16 16">
|
|
2
|
-
<path fill="#000" fill-rule="evenodd" d="M4.994 5.986a2.014 2.014 0 1 0 0 4.028h2.069V5.986H4.994Zm5.063-.98h.055a2.014 2.014 0 1 0 0-4.026h-2.07v4.027h2.015Zm1.697.49A2.994 2.994 0 0 0 10.112 0H4.994a2.994 2.994 0 0 0-1.642 5.498A2.99 2.99 0 0 0 2 8a2.99 2.99 0 0 0 1.352 2.503A2.99 2.99 0 0 0 2 13.007C2 14.663 3.358 16 5.008 16c1.665 0 3.035-1.349 3.035-3.02v-2.765a2.984 2.984 0 0 0 2.014.778h.055a2.994 2.994 0 0 0 1.642-5.496Zm-1.642.49h-.055a2.014 2.014 0 1 0 0 4.028h.055a2.014 2.014 0 1 0 0-4.028Zm-7.132 7.02c0-1.111.902-2.013 2.014-2.013h2.069v1.987c0 1.123-.924 2.04-2.055 2.04a2.026 2.026 0 0 1-2.028-2.013Zm4.083-8H4.994a2.014 2.014 0 1 1 0-4.026h2.069v4.027Z" clip-rule="evenodd"/>
|
|
3
|
-
</svg>
|
|
Binary file
|
|
@@ -1,28 +0,0 @@
|
|
|
1
|
-
<svg
|
|
2
|
-
width="400"
|
|
3
|
-
height="400"
|
|
4
|
-
viewBox="0 0 400 400"
|
|
5
|
-
fill="none"
|
|
6
|
-
xmlns="http://www.w3.org/2000/svg"
|
|
7
|
-
>
|
|
8
|
-
<path
|
|
9
|
-
d="M97.5 302.5C97.5 274.195 120.445 251.25 148.75 251.25H200V302.5C200 330.805 177.055 353.75 148.75 353.75C120.445 353.75 97.5 330.805 97.5 302.5Z"
|
|
10
|
-
fill="#0ACF83"
|
|
11
|
-
/>
|
|
12
|
-
<path
|
|
13
|
-
d="M200 200C200 171.696 222.945 148.75 251.25 148.75C279.554 148.75 302.5 171.695 302.5 200C302.5 228.305 279.554 251.25 251.25 251.25C222.945 251.25 200 228.304 200 200Z"
|
|
14
|
-
fill="#1ABCFE"
|
|
15
|
-
/>
|
|
16
|
-
<path
|
|
17
|
-
d="M97.5 200C97.5 228.305 120.445 251.25 148.75 251.25H200V148.75H148.75C120.445 148.75 97.5 171.695 97.5 200Z"
|
|
18
|
-
fill="#A259FF"
|
|
19
|
-
/>
|
|
20
|
-
<path
|
|
21
|
-
d="M200 46.25V148.75H251.25C279.555 148.75 302.5 125.805 302.5 97.5C302.5 69.1954 279.555 46.25 251.25 46.25H200Z"
|
|
22
|
-
fill="#FF7262"
|
|
23
|
-
/>
|
|
24
|
-
<path
|
|
25
|
-
d="M97.5 97.5C97.5 125.805 120.445 148.75 148.75 148.75H200V46.25L148.75 46.25C120.445 46.25 97.5 69.1954 97.5 97.5Z"
|
|
26
|
-
fill="#F24E1E"
|
|
27
|
-
/>
|
|
28
|
-
</svg>
|