LUC4N3X Thalarch Design System
A strong site should look like one product, not a sequence of independently styled sections.
Use this skill to create a semantic design contract before implementation or to reverse-engineer one from an existing frontend.
1. Start with product character
Define:
- product/subject;
- audience;
- primary job;
- visual atmosphere;
- density: airy / balanced / dense;
- composition: ordered / asymmetric / expressive;
- motion: restrained / fluid / cinematic;
- one distinctive design idea that belongs to this product.
Avoid design adjectives that could describe any startup.
2. Extract before inventing
If an existing product already has UI or brand assets, inspect first:
- theme/tokens;
- CSS variables;
- Tailwind/theme configuration;
- component library;
- typography declarations;
- spacing/radius/shadow patterns;
- icons and imagery;
- screenshots or Figma/Stitch references when available.
Preserve stable identity unless redesign is explicitly requested.
2.5 External design-reference atlas
When the project/user does not already provide enough visual direction and external research is
available, use references/awesome-design-md.md.
That reference maps VoltAgent/awesome-design-md into Thalarch's workflow. The source is valuable
because its analyzed DESIGN.md files encode design systems as structured reasoning rather than
surface screenshots.
Use it selectively:
- choose one primary reference by task fit;
- use at most one secondary reference for a clearly distinct quality;
- extract only the relevant atmosphere, hierarchy, palette roles, type character, composition, material/depth, imagery treatment, responsive behavior, and guardrails;
- synthesize those qualities into the current project's own design contract;
- never let a famous reference outrank the user's brand or existing project truth.
For raster/image tasks, hand the compact reference capsule to thalarch-imagegen; do not dump a
whole external DESIGN.md into the generation prompt.
3. Semantic tokens
Define roles, not arbitrary values:
Color
- canvas / elevated surfaces;
- primary and secondary text;
- muted/supporting content;
- primary action;
- accent;
- borders/dividers;
- success/warning/error/info.
Use exact values in the implementation contract where known, but describe their visual role too.
Typography
Define:
- display face/character;
- body face/character;
- scale hierarchy;
- weights;
- line height;
- letter spacing;
- numeral/code treatment when relevant.
Do not default to the same fashionable font stack on every project.
Geometry
Define:
- spacing rhythm;
- radius philosophy;
- border weight;
- shadow/depth treatment;
- container widths;
- grid/gutter behavior.
4. Component behavior
Describe important components semantically:
- navigation;
- buttons/actions;
- cards/containers;
- forms;
- dialogs/sheets;
- lists/tables;
- media blocks;
- domain-specific components.
For each component, define hierarchy and states instead of styling every instance independently.
5. Layout system
Record:
- page frame and max widths;
- grid philosophy;
- whitespace strategy;
- alignment rules;
- section rhythm;
- when asymmetry/overlap is allowed;
- mobile reflow strategy;
- touch-target expectations.
Desktop design must not merely shrink on mobile.
6. Motion system
Motion must communicate hierarchy, continuity, or feedback.
Define:
- page-entry behavior;
- hover/focus/press behavior;
- section transitions;
- reduced-motion fallback;
- banned decorative motion.
Prefer a few choreographed moments over dozens of unrelated animations.
7. Imagery system
Define what kind of imagery belongs in the product:
- photography / illustration / 3D / abstract / none;
- crop and framing;
- contrast and saturation;
- texture/grain;
- relation to UI surfaces;
- icon/diagram language;
- whether generated imagery is allowed and where.
If generated assets are needed, hand them to thalarch-imagegen with this design
contract as the brand reference.
8. Anti-pattern contract
Write project-specific bans, such as:
- generic SaaS gradient hero;
- excessive cards-inside-cards;
- every section centered;
- decorative blobs without meaning;
- random glassmorphism;
- uniformly rounded everything;
- interchangeable AI-generated illustrations;
- multiple competing accent colors;
- fake dashboard data or placeholder lorem ipsum in final work.
Do not ban a style merely because it is popular. Ban it when it conflicts with the product's chosen direction.
9. Output
For non-trivial projects, maintain a concise DESIGN.md or repository-appropriate
design artifact containing:
- Product & audience
- Visual atmosphere
- Color roles
- Typography
- Geometry & spacing
- Components
- Layout & responsive rules
- Motion
- Imagery
- Accessibility constraints
- Anti-patterns
- Example implementation language
If the repository already uses a design-system document, update that instead of creating a competing source of truth.