Docs

Overview MCP Theme Forge Component Forge API Builder Theme config Rule system Builder workflow

Schemyx docs

AI coding agent control reference

Schemyx MCP indexes repo-proven patterns and paradigms. When an agent prepares a task, Schemyx matches it to bounded, compatible context. Cross-agent skill normalization and enforceable generation guardrails are the beta direction.

Foundations

In development

Theme Forge

Turns visual decisions into portable tokens and rule files developers can give to coding agents as explicit input.

UI patterns

In development

Component Forge

Turns custom component decisions into 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

In development

Theme Forge

Turns visual decisions into portable tokens and rule files developers can give to coding agents as explicit input.

Open Theme Forge

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

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

In development

Component Forge

Turns custom component decisions into rules AI can follow when generating product interfaces.

Open Component Forge

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 contract
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.

MCP

Control AI coding agents where they write code

Schemyx MCP exposes repo paradigm indexing, task matching during preparation, compatibility filtering, review ambiguity, and guarded source fallback. Cross-agent skills and enforceable generation guardrails are being brought into the same system.

Request Beta Access

Task preparation workflow

`schemyx_prepare_task`
`schemyx_search_codebase`
`schemyx_get_codebase_recipe`
`schemyx_get_context_pack`
`schemyx_read_source_guarded`

MCP modes

Local workspace

Index repo paradigms, match prepared tasks to bounded context, and perform guarded source fallback inside the configured developer workspace.

Governed data plane

Connect a team-scoped Schemyx endpoint for account-backed project context without placing customer database credentials in MCP configuration.

Reversible cutover

Adopt the task-preparation path behind a reversible flag while existing MCP read contracts remain available during the beta transition.

What it serves

indexed repo paradigms, task-matched recipes, project rules, relationships, review warnings, and guarded source fallback.

What stays read-only

During task preparation, the MCP server matches bounded context. It does not yet force skill invocation, block model output, or mutate project code.

Why source fallback exists

Task context stays bounded. When evidence is incomplete or ambiguous, the agent can inspect scoped source instead of guessing.

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.

Scope

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

Constraint

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

Review

Define what confirms the output stayed inside the rule.

Builder workflow

From input to reusable project controls

Forge output should either solve the current task or become a portable standard for future work. Managed promotion, ownership, and approval are part of the governance direction.

Step 1

Collect inputs

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

Step 2

Define the controls

Turn those inputs into an explicit 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.