Generated Misaki Studio source is readable React and SCSS, but it follows the visual project's model rather than a handwritten component style guide. Read the exported symbols as the integration contract and treat element-level implementation details as generated internals.
Most generated files begin with:
// This file is generated by Misaki Studio. Do not edit.
That is the overwrite boundary. Fix the source Component or Page in Misaki Studio and export again. Put handwritten adapters and application-specific behavior in files outside that boundary.
User-authored Script files are exported without this header because their TypeScript source is intentionally written by the user. Do not assume every .ts file has the same ownership merely because it is inside the export tree.
A reusable visual Component can expose these symbols when the project uses the corresponding features:
Symbol: Props · Meaning: Type of authored Component properties.
Symbol: DefaultProps · Meaning: Default property values from the Component definition.
Symbol: Variants · Meaning: Map from authored variant names to generated style classes.
Symbol: Children · Meaning: Named React-node slots exposed by the Component.
Symbol: Component · Meaning: The generated React component used by consuming code.
The Component wrapper can accept:
Input: properties · Purpose: Values matching the generated Props type.
Input: variant · Purpose: An array of keys from the generated Variants map.
Input: children · Purpose: An object of named slots matching Children.
Input: className · Purpose: A caller-provided class added to the generated root.
Input: style · Purpose: Caller-provided React inline styles for the root.
Input: divProps · Purpose: Additional supported root-div properties through the Misaki runtime type.
Not every file emits every symbol. A Component with no variants or slots has no meaningful need for those parts. Inspect its current TSX instead of assuming another Component's API.
If a generated button defines a label property, an outline variant, and leftIcon/rightIcon slots, consuming code follows this shape:
<Button.Component
properties={{ label: "Save" }}
variant={["outline"]}
children={{
leftIcon: <SaveIcon />,
}}
divProps={{
"aria-label": "Save changes",
}}
/>
Use the names and required/optional types from the actual generated module. This example explains the structure; it does not define every Component's props.
A visual Page is emitted as a default React export so it can live at its configured project path, commonly under a Next.js pages/ tree. It can import other generated Components and its own SCSS module.
When a Page exposes external child regions, its module can also export an ExternalChildren type and a setExternalChildren function. Treat these as generated API: review their exact slot names and lifecycle implications before wiring application content through them.
Mockups do not produce a Page module. Their visual editor output is for composition and review rather than runtime export.
"use client"Generated visual modules can use React hooks, responsive measurement, event logic, state, and browser-facing runtime helpers, so the generator emits the client-module directive. In an existing Next.js application, account for that client boundary when composing generated Components into server-rendered code.
Do not remove the directive by hand; a later export will restore it, and the generated behavior may depend on it.
A visual module can import:
React;
misaki-studio-internal runtime helpers;
its .module.scss stylesheet;
other generated project or linked-library Components;
routing, environment, API, storage, CMS, database-client, or design-system modules when the authored file uses them.
Imports are generated from actual use. The output itself is the current dependency list; a boilerplate's older package.json is not proof that every import resolves at a compatible version.
Each visual file normally has a sibling .module.scss file. The TSX addresses styles through the imported CSS-module object.
Generated element classes use an E prefix plus a stable six-character hash derived from the element ID. They are intended to remain stable across ordinary re-exports and independent of element order, but they are still generator-owned identifiers—not semantic names for application code to depend on.
Styles can include:
layout, spacing, typography, fills, borders, and effects;
variant selectors that combine a variant class with an element class;
pseudo-state selectors;
container queries for authored responsive screens;
design-system custom properties and referenced assets.
Add integration styling through the generated root inputs or a wrapper. Avoid selecting generated internal hashes from handwritten global CSS unless you accept that coupling as a reviewed exception.
Generated responsive behavior is component/container based. A responsive root can use the runtime's responsive wrapper to calculate authored screen names, while the stylesheet contains matching container-query rules.
That means the Component can respond to the size of its own container rather than only the browser viewport. Test it inside the real layout where it will be mounted; a full-page preview and a narrow application column can select different responsive states.
Other supported files can emit project modules such as:
API type/config modules;
storage and CMS/data access modules;
environment types and values;
design-system tokens, themes, SVGs, and media helpers;
document and blog React modules;
database table/client modules;
user-authored Script TypeScript.
The folder exporter preserves the project file paths when creating these outputs. Imports between generated files therefore depend on a coherent whole-project export; copying one TSX file alone may omit modules and assets it references.
The selected file's TSX/SCSS preview does not include every whole-project artifact. A complete export can additionally write assets, SEO files, linked-library code, a database client, and an optional separate backend manifest.
The generated code also does not prove:
that required packages are installed at compatible versions;
that the destination's TypeScript, Sass, or Next.js configuration accepts it;
that API, storage, environment, or database endpoints exist;
that provider deployment settings are correct;
that every runtime interaction passes in the final application.
Use Export your code for the complete review and test sequence.
Coverage: MCP only for source-location lookup.
When a generated identifier or line is unclear, locate-source can rank the design nodes that emitted it.
In
<file path>, locate the source of this exported snippet:<distinctive identifier or line>. Report the matching node IDs, names, and paths. Do not edit the file.
Distinctive property, state, event, or element identifiers work better than punctuation or generic JSX. Use the returned node ID with the relevant read tool before changing the design.