@newlogic-digital/core 4.1.10 → 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 CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@newlogic-digital/core",
3
3
  "type": "module",
4
- "version": "4.1.10",
4
+ "version": "4.1.12",
5
5
  "main": "index.js",
6
6
  "bin": {
7
7
  "newlogic-core": "./bin/newlogic-core.js"
@@ -18,26 +18,26 @@
18
18
  },
19
19
  "dependencies": {
20
20
  "@minify-html/node": "^0.18.1",
21
- "@newlogic-digital/vite-plugin-heroicons": "^1.3.1",
21
+ "@newlogic-digital/vite-plugin-heroicons": "^1.4.1",
22
22
  "@stylistic/eslint-plugin": "^5.10",
23
23
  "@stylistic/stylelint-config": "^5.0.0",
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.28.4",
27
+ "browserslist": "^4.29.4",
28
28
  "browserslist-to-esbuild": "^2.1.1",
29
- "lightningcss": "^1.32.0",
30
- "npm-check-updates": "^22.2.9",
31
- "oxlint": "^1.72.0",
32
- "postcss-custom-properties": "^15.0.1",
29
+ "lightningcss": "^1.33.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.2.4",
37
+ "@tailwindcss/vite": "^4.3.3",
38
38
  "@vituum/vite-plugin-twig": "^2.0.1",
39
- "fontless": "^0.2.1",
40
- "vite": "^8.0.10"
39
+ "fontless": "^1.0.0",
40
+ "vite": "^8.3.0"
41
41
  },
42
42
  "peerDependenciesMeta": {
43
43
  "@vituum/vite-plugin-twig": {
@@ -51,11 +51,11 @@
51
51
  }
52
52
  },
53
53
  "devDependencies": {
54
- "@tailwindcss/vite": "^4.3.2",
55
- "@types/node": "^26.1",
54
+ "@tailwindcss/vite": "^4.3.3",
55
+ "@types/node": "^26.6",
56
56
  "@vituum/vite-plugin-twig": "^2.0.1",
57
- "fontless": "^0.2.1",
58
- "rolldown": "^1.1.4",
57
+ "fontless": "^1.3.3",
58
+ "rolldown": "^1.2.15",
59
59
  "typescript": "^6"
60
60
  },
61
61
  "files": [
@@ -79,5 +79,8 @@
79
79
  "repository": {
80
80
  "type": "git",
81
81
  "url": "git+https://github.com/newlogic-digital/core.git"
82
+ },
83
+ "allowScripts": {
84
+ "fsevents": true
82
85
  }
83
86
  }
@@ -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-full.txt` before making changes in this framework.
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 `llms-full.txt`.
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-full.txt`
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 `llms-full.txt` for framework behavior, available components, and implementation examples.
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 `llms-full.txt` suggests another valid approach.
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 available in `src/icons/simpleicons/`.
34
- - Heroicons are already available through the build setup, so do NOT duplicate them in `src/icons/`.
35
- - The `<use href="...">` symbol definitions are generated automatically by the build setup.
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. Project reusable icons via `src/icons/outline`, `src/icons/solid`, or `src/icons/simpleicons`
63
- 3. Inline `<svg>` without `<use>` for one-off icons ONLY
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 available in `src/icons/simpleicons`.
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 kebab-case for generic utility files such as `format-date.js` or `scrollbar.css`.
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
- - Follow the existing import aggregation pattern with `+.js` files when adding new controllers to an existing folder.
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-full.txt` before creating new custom JS.
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 NOT live in templates.
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/main.json`.
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
- - Section rendering is handled through `src/templates/utils/sections.latte`.
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->css->all as $url" href="{$url|asset}" rel="stylesheet">
36
- <script src="{$assets->js->main|asset}" type="module"></script>
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/main.json` rather than duplicating it across page JSON files.
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
- <a n:class="'base classes ' . ($isActive ? 'active' : 'idle')">Link</a>
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
- {foreach $sections as $section}
92
- {include ('../' . $section->src), control => $section}
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/Button.latte', text: 'Click me'}
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>
@@ -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>