Schemyx
Products/Docs/
Get Started

Schemyx docs

Builder reference

Theme Builder is the active Schemyx product today. Component Builder and API Builder are documented as under-construction roadmap areas so their intended shape is clear without presenting them as finished products.

Foundations

Available now

Theme Builder

Turns visual decisions into reusable tokens and component rules that every Schemyx surface can inherit.

UI patterns

Under construction

Component Builder

Planned builder for turning recurring UI patterns into component rules AI can follow when generating product interfaces.

Interface layer

Under construction

API Builder

Planned builder for creating contract-first API context so generated code knows the expected endpoints, schemas, auth, and error states.

Foundations

Available now

Theme Builder

Turns visual decisions into reusable tokens and component rules that every Schemyx surface can inherit.

Open Theme Builder

Inputs

  • themeConfig.json
  • brand colors
  • spacing density
  • radius scale
  • surface contrast

Outputs

  • CSS variables
  • Tailwind tokens
  • component sizing
  • surface states

Guardrails

  • Preserve background color values unless the theme config changes them.
  • Map token values before applying one-off component styles.
  • Keep button, card, badge, and panel treatment consistent across pages.

UI patterns

Under construction

Component Builder

Planned builder for turning recurring UI patterns into component rules AI can follow when generating product interfaces.

This builder is under construction. The details below describe the planned direction and expected documentation structure, not a completed product surface.

Inputs

  • component inventory
  • layout patterns
  • variant rules
  • interaction states
  • composition examples

Outputs

  • component playbook
  • usage rules
  • layout recipes
  • review checklist

Guardrails

  • Prefer existing components before creating new UI primitives.
  • Document when to use cards, forms, tables, modals, empty states, and page shells.
  • Attach visual review criteria so generated screens can be checked against known patterns.

Interface layer

Under construction

API Builder

Planned builder for creating contract-first API context so generated code knows the expected endpoints, schemas, auth, and error states.

This builder is under construction. The details below describe the planned direction and expected documentation structure, not a completed product surface.

Inputs

  • resource model
  • endpoint map
  • auth mode
  • request schema
  • response schema

Outputs

  • API contract
  • typed payloads
  • handler rules
  • integration notes

Guardrails

  • Define schemas before generating implementation details.
  • Keep auth, validation, and error behavior explicit.
  • Document generated contracts where builders and agents can reuse them.

Theme config

Config fields

`themeConfig.json` should stay the source of truth for shared visual behavior. The app maps these values into CSS variables before components consume them.

Current theme fields

fontFamily

Sets the app typeface used by the layout and shadcn-style primitives.

radius

Controls the shared corner radius for cards, panels, and surface framing.

cardPadding

Controls interior spacing for repeated card content.

backgroundColor

Sets the base page color and should stay stable for the current brand direction.

surfaceColor

Sets the card and panel base color.

accentColor

Sets highlight, ring, and subtle motion treatment.

Rule system

Rule structure

A rule should tell a builder what to preserve, what it may change, and how output will be reviewed. Rules should be specific enough to guide generated work.

01

Scope

Name the builder, surface, or contract the rule applies to.

02

Constraint

Describe the behavior, token, boundary, or schema that must be followed.

03

Review

Define what confirms the output stayed inside the rule.

Builder workflow

From input to reusable system context

Builder output should either solve the current task or become reusable context for future work. If it becomes reusable, promote it into the rule system.

Step 1

Collect inputs

Start with the builder inputs: theme values, component rules, or API contract details.

Step 2

Generate context

Normalize those inputs into a reusable config, policy, or contract before building UI or code.

Step 3

Apply guardrails

Check generated output against the builder guardrails before it becomes part of the platform.

Step 4

Promote reusable rules

When a decision repeats, move it into the shared rule system instead of leaving it inside one page.