@elyx-design/codex-plugin 0.0.0-bootstrap.0 → 0.0.1-nightly.16119.gf080cb874

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.
@@ -0,0 +1,127 @@
1
+ ---
2
+ name: elyx
3
+ description: Elyx is a design tool with local, AI-friendly `.elyx` files for screens, components, layouts, flows, and design systems. MANDATORY Use this skill before you read, reason about, or answer any question about Elyx or `.elyx` files. That includes authoring, editing, validating, inspecting, reviewing, refactoring, comparing, and recommending changes, and read-only analysis that produces no edit. Do not reason about `.elyx` files from source text alone. Imports, instances, overrides, and layout resolve only through the `elyx` CLI.
4
+ ---
5
+
6
+ ## How to work in Elyx
7
+
8
+ This skill uses the `elyx` command from the public `@elyx-design/cli` npm
9
+ package. Before you work with Elyx files, run `elyx --help` to confirm that
10
+ `elyx` is on your `PATH`. If it is not, ask the user to install it. For
11
+ example:
12
+
13
+ ```bash
14
+ npm install --global @elyx-design/cli
15
+ ```
16
+
17
+ For the authoritative list of flags, run `elyx --help` or `elyx <subcommand> --help`.
18
+
19
+ ### Use `find` and `tree` to see the resolved scene
20
+
21
+ Use `find` and `tree` to read the scene after imports, instances, overrides, layout, and geometry resolve:
22
+
23
+ - `find --ref`: get the final data and bounds of one layer by its exact ref.
24
+ `elyx find path/to/file.elyx --ref ctaButton`
25
+
26
+ - `find --at`: get the topmost rendered layer at a board-space point.
27
+ `elyx find path/to/file.elyx --at 420,180`
28
+
29
+ - `find --in`: get the layers that intersect a board-space rectangle, or that the rectangle contains.
30
+ `elyx find path/to/file.elyx --in 0,0,800,600`
31
+ `elyx find path/to/file.elyx --in 0,0,800,600 --contain --click-through`
32
+
33
+ - `tree`: get the semantic layer tree of a file, or of one internal source ref, with children, instance source references, layout, position, constraints, text, and style.
34
+ `elyx tree path/to/file.elyx --ref OnboardingWelcome`
35
+ `elyx tree path/to/file.elyx --ref OnboardingWelcome --depth full`
36
+
37
+ The results use these conventions:
38
+
39
+ - `localBounds` is geometry in the layer's own space. `absoluteBounds` is geometry in board space.
40
+ - In the tree, `position` is the resolved local placement. `constraints` are the stored values that drive layout.
41
+ - A value bound to a design token appears as `{"value": …, "token": "<file>#<group>.<member>"}`. The token is the same in every context.
42
+ - `instanceOf` gives an instance's source `file`, `symbol`, and `variant`.
43
+ - Slot nodes include `slot: true`. Other nodes omit it.
44
+ - The tree depth accepts `shallow`, `full`, or a non-negative integer. An integer limits how many instance boundaries the tree crosses.
45
+
46
+ ### Name things the way users do
47
+
48
+ When you describe or name Elyx objects, follow these rules:
49
+
50
+ - Say “layer”, “component”, or “screen” for visual design objects.
51
+ - The declaration symbol before `=` is the layer’s name. Make its leaf name semantic, valid Elyx syntax, and consistent with the project. Do not add a separate `name:` property.
52
+ - Say “symbol” for source identity, imports, references, arguments, and renames.
53
+ - Say “token” for design tokens. Say “variable” only for other reusable values that are not layers.
54
+
55
+ ### 1. Orient
56
+
57
+ Before you assume anything from source examples, use `elyx man` to learn Elyx syntax, concepts, properties, and component semantics. `elyx man` prints the overview manual. `elyx man <topic-or-schema-path>` prints one topic, such as `elyx man components`, `elyx man instance`, or `elyx man frame.width`. If you do not know the right path, run `elyx man --list`.
58
+
59
+ ### 2. Author
60
+
61
+ The project usually already has a design system and its own file vocabulary.
62
+ Reuse and import its existing building blocks. Do not build a parallel system.
63
+
64
+ Prefer composition to recreation. Import and instantiate existing components
65
+ instead of rebuilding them from raw layers.
66
+
67
+ To learn how Elyx projects are organized, run `elyx man project-structure`.
68
+ To learn component composition and override semantics, run `elyx man components`, `elyx man instance`, `elyx man variants`, and `elyx man slots`.
69
+
70
+ When you add or change structure, follow these rules:
71
+
72
+ - Before you write a property you have not used yet, read its documentation. Elyx ignores a property it does not know.
73
+ - Import shared components, tokens, and blocks where you can.
74
+ - Use stacks and `.auto` sizing for normal interface layout. The `frame.layout` documentation describes them.
75
+ - Keep overrides local and intentional.
76
+ - For icons and other vector artwork, write a small SVG file and import it as an asset. The `assets` documentation shows how, including tinting it with `fill`. Do not use Unicode symbols as icons, because the font may have no glyph for them.
77
+ - Rename symbols one source file at a time. Before you move on, repair the local references and all direct and transitive consumers.
78
+ - Before you reason about instances or overrides, read the resolved structure and geometry from the tree.
79
+
80
+ #### Leave space between canvas items
81
+
82
+ When you place separate screens, frames, or component examples on a board,
83
+ leave at least 48px between the edges of adjacent items. Aim for a gap of at
84
+ least 20% of the larger item’s size along the spacing direction. That is the
85
+ width for items side by side, and the height for items stacked vertically. For
86
+ example, two 1920px-wide screens side by side need about 384px or more between
87
+ them, not 48px.
88
+
89
+ The 20% target is a guideline, not a rigid rule. Keep spacing consistent
90
+ within groups, and leave room for frame titles. To measure gaps, use the
91
+ resolved bounds of the items. To review the arrangement, render it. This
92
+ guidance covers the space between distinct canvas items. It does not cover
93
+ padding or gaps inside a screen or component, or intentional overlaps. Do not
94
+ re-space unrelated content unless the user asks.
95
+
96
+ ### 3. Render the result
97
+
98
+ ```bash
99
+ rg -n --glob '*.elyx' '@context\s*\(' . # find the context axes and values in the workspace
100
+ elyx render path/to/file.elyx -o out.png
101
+ elyx render path/to/file.elyx --context theme=dark -o out-dark.png
102
+ elyx render path/to/file.elyx --context theme=dark --extra-file path/to/theme-dark.elyx -o out-dark.png
103
+ elyx render path/to/file.elyx --ref <name> --context theme=dark --context lang=pt -o out.png
104
+ ```
105
+
106
+ Use `render` whenever the visual result matters. Do not assume that a `.elyx` change is correct from its source text alone.
107
+
108
+ To render one layer, use `--ref <name>`. To render with custom contexts without changing the source file, repeat `--context axis=value`. To load files that the rendered file does not import, repeat `--extra-file <file>`. A `--context` selection changes the output only after the file that declares the context is loaded. Without the matching `--extra-file`, the render silently falls back to the default values. Before you render, search the workspace's `@context` annotations to learn the available axes and values.
109
+
110
+ The `render` scale defaults to 1. Add `--scale 2` only for fine detail, because it produces four times the pixels.
111
+
112
+ ### 4. Check the changed files
113
+
114
+ When your edits are done, normalize each changed file in place. Then check the
115
+ changed files for errors and warnings.
116
+
117
+ ```bash
118
+ elyx normalize -w path/to/file.elyx
119
+ elyx diagnostics path/to/file.elyx # with no target, checks the whole project
120
+ ```
121
+
122
+ Check the smallest scope that covers the changed files. Resolve every warning,
123
+ or account for it explicitly.
124
+
125
+ If normalization reports that it fell back to syntax-only formatting, the file
126
+ loaded with problems, so it was only formatted. Fix the problems it lists,
127
+ then normalize the file again.
@@ -0,0 +1,98 @@
1
+ ---
2
+ name: elyx-code
3
+ description: Translate between Elyx designs and web code. Use this skill to implement or update code from an Elyx design, to create or update an Elyx design from code, to import an existing app into Elyx, or to keep linked design and code in sync.
4
+ ---
5
+
6
+ # Elyx and code
7
+
8
+ For Elyx inspection, language documentation, authoring, and validation, use the `elyx` skill. For the target project's framework, components, and checks, follow its `AGENTS.md` and existing code conventions.
9
+
10
+ ## Establish the correspondence
11
+
12
+ - Identify the requested direction and scope: a component, a screen, a design system, or an app. For an update, inspect the changed side before you edit its counterpart, including its diff when one is available. Keep unrelated states and layers intact.
13
+ - Look for existing `meta.code` links, code backlinks, component implementations, tokens, assets, and nearby examples. Treat a link as a lead to verify on both sides, not as proof that everything still matches.
14
+ - For an existing Elyx target, run `elyx tree <file> --ref <ref> --depth shallow` and `elyx render <file> --ref <ref> -o out.png` with the relevant context. To see through instances, increase the tree depth. The tree shows inherited `meta` such as `meta.code`, token bindings, and `instanceOf` with its `variant`. Source text alone cannot show the final layout or overrides.
15
+ - To inspect or render a descendant inside an instance, reuse a non-null `target` from `find` or `tree` output. Pass its `filePath` as the input file, its `sourceRef` as `--ref`, and its `overridePath`, when present, as `--override-path`. Do not infer an instance occurrence from its display path.
16
+ - For feedback on the code side, look in the repo's scripts, docs, and nearby stories for an existing route, preview, or component harness that shows the relevant state. If one is practical to use, compare appearance and behavior with the browser or component tools you have. Accessibility and computed-style feedback can explain what a screenshot cannot. Do not add a browser dependency only for this step. If you cannot inspect the running code, work from source and the existing project checks, and say what you could not observe.
17
+
18
+ ## Elyx to web concept map
19
+
20
+ Use these analogies as a starting point. Then follow the target framework and the resolved design.
21
+
22
+ | Elyx | Web code analogy | Check |
23
+ | --- | --- | --- |
24
+ | Stack `layout: {direction: .row, item-gap: 8px}` | `display: flex; flex-direction: row; gap: 8px` | Preserve order, alignment, wrapping, and responsive behavior. Nested stacks or a grid may fit the code better. |
25
+ | Freeform children with `left` and `top` | A `position: relative` parent and `position: absolute` children for intentional overlap | Coordinates are relative to the parent. Canvas placement does not need to become app positioning. |
26
+ | `.auto`, percentages, `overflow` | Intrinsic sizing, parent-relative percentages, CSS overflow | Elyx clips by default. CSS overflow defaults to visible. A freeform frame without a size can collapse. |
27
+ | Tokens | CSS custom properties, Tailwind theme tokens, or the project's token system | Preserve roles, aliases, and units. |
28
+ | `@context` | Theme selectors, locale state, or responsive breakpoints | Inspect which tokens or structural variants change in that context. |
29
+ | Component instance (`frame : source`) | A component call, such as `<Card />` | Instance overrides become values that are passed or composed at that use site, not a copied implementation. |
30
+ | `@variant` | A prop, state, or style variant in the component API | The Elyx variant inherits its base. Inspect the actual code API before you choose a prop. |
31
+ | `slot: .true` on a frame | React `<Card>{content}</Card>` for one region. A named `header` prop or component composition for several regions. | Preserve the region's layout. Elyx source children are example content that instances start with. Decide whether the code supplies a default or leaves the content to callers. |
32
+ | `connections: {target: ...}` | Navigation or a transition to another screen, component, or state | The target records the intended destination. Inspect the code for the event, guard, and transition behavior. |
33
+
34
+ ## From Elyx to code
35
+
36
+ - Reuse the project's components and design tokens. Match a token's semantic role as well as its value. Where a corresponding code token exists, preserve the token binding. If none exists, add a suitable token by the project's conventions, or explain the unresolved mapping. Inspect a component's actual API before you choose props.
37
+ - Translate the layout intent into the project's normal responsive layout primitives. Preserve content, assets, typography, and the represented states. For interactive controls, use the project's behavior patterns to preserve selection rules, initial state, disabled behavior, and keyboard access.
38
+ - For a flow, read the `connections` declarations in the Elyx source, and follow their targets across files. Component inspection alone does not find them. Map each meaningful destination and branch to the project's routes or state transitions. Then verify in code the interaction that activates each one. A destination does not need to appear on the current board for its connection to be valid.
39
+ - For an update, follow the existing design-to-code correspondence. Change the affected implementation instead of recreating it.
40
+
41
+ ## From code to Elyx
42
+
43
+ - Before you create Elyx tokens, components, contexts, or links, inventory the relevant existing ones. Reuse them where they express the code's roles and structure. When you import a design system, set up the shared tokens and theme contexts before you bind components to them. Preserve the code's base and semantic token layers and its resolved lengths. Verify that representative aliases resolve in each theme.
44
+ - Use components for reused controls, variants for meaningful differences, slots for composable regions, and instances for screen composition. Use stacks for normal UI flow, and freeform placement for intentional overlap or canvas arrangement.
45
+ - Represent one specific, valid UI state. For conditional or data-driven UI, choose representative states. Do not combine branches into a screen that the app cannot show. Capture theme, language, and responsive differences with the project's existing conventions, and with Elyx contexts or variants where they fit.
46
+ - When the code has a meaningful flow between represented screens, panels, or states, put a connection on the source control, and target the corresponding Elyx layer. For example, after you import `"./checkout.elyx" as Checkout`, a continue button can use `connections: {target: Checkout.paymentScreen}`. Keep destinations as references, including across files. To see the whole flow at once, use an overview with `draw-connections: .true`.
47
+ - For an update, edit the linked declaration or instance that corresponds to the code change. Preserve the shared component and the other instances, unless the code change affects them too.
48
+
49
+ For example, this code defines a shared default, and one caller supplies a different title:
50
+
51
+ ```tsx
52
+ function PlanCard({ title = "Plan" }: { title?: string }) {
53
+ return <article>{title}</article>
54
+ }
55
+ <PlanCard title="Starter" />
56
+ ```
57
+
58
+ The linked Elyx component carries the default. The caller's value belongs on its instance:
59
+
60
+ ```elyx
61
+ export planCard = frame {
62
+ children: title,
63
+ title = text {contents: "Plan"}
64
+ }
65
+ starterCard = frame : planCard {
66
+ title {contents: "Starter"}
67
+ }
68
+ ```
69
+
70
+ If only that call site changes, update `starterCard`. If the component default changes, update `planCard`. Check the resolved instance before you edit either one.
71
+
72
+ ## Translation details that are easy to miss
73
+
74
+ Watch for these differences:
75
+
76
+ - A stacked child ignores `left` and `top`.
77
+ - When content intentionally extends beyond a frame, such as a shadow, use `overflow: .visible` in Elyx.
78
+ - Elyx text `letter-spacing` is a percentage of the font size. A positive `line-height` is a multiplier, and `0` means automatic.
79
+ - An Elyx variant is an instance of its base with overrides. `@context` selects alternate tokens or contextual variants. By itself, it does not define a web breakpoint or a component prop.
80
+
81
+ ## Link and check the result
82
+
83
+ - When you have verified the correspondence, put `meta.code` on the narrowest useful Elyx declaration. Use repo-relative paths and stable symbols, as in this pair.
84
+
85
+ In `elyx/design/blocks/planCard.elyx`, on the `planCard` declaration:
86
+
87
+ ```elyx
88
+ meta: {code: "src/components/blocks/plan-card.tsx#PlanCard"}
89
+ ```
90
+
91
+ If the project uses backlinks, above `PlanCard` in the code:
92
+
93
+ ```tsx
94
+ // @elyx elyx/design/blocks/planCard.elyx#planCard
95
+ ```
96
+
97
+ To go from design to code, open the linked implementation. To go from code to design, search for its backlink or a matching `meta.code`. When a path or symbol moves, update the link. Instances inherit source metadata, so do not copy the component link onto them.
98
+ - Render the affected states and contexts. When your edits are done, normalize the changed Elyx files and run full diagnostics on them. Run the project's relevant code checks. If a code preview is available, compare the changed state's appearance and behavior with the design. Report material gaps or unverified states.