Examples

Use these examples to choose a representative Misaki Studio evaluation project. They are workflow blueprints, not yet a gallery of downloadable, runtime-verified templates. Public screenshots, project links, and generated-consumer results remain blocked until each example is exercised and reviewed.

1. A reusable responsive action Component

Result: a Button or call-to-action Component with typed label/icon inputs, named child slots, public variants, responsive screens, interaction states, and one small timeline.

This example should prove:

• hierarchy and design values remain editable on the canvas;

• the same hierarchy adapts across responsive screens;

• public properties, variants, and children appear in generated types;

• hover/focus/pressed behavior works in Preview;

• the animation survives export;

• a React consumer can render the generated contract.

Build it with Create reusable Components, Make a Component responsive, and Animate a Component.

2. A data-backed results Component

Result: a search or listing Component that mounts an API or View and presents loading, empty, success, and failure states without storing a secret in client output.

This example should prove:

• request or table fields have an explicit schema;

• Component logic supplies typed inputs and binds results;

• safe Preview cases cover the important runtime states;

• external write actions are not triggered accidentally;

• generated imports and deployed-origin requirements are understood.

Build it with Connect an API or Use CMS Content, then Preview, test, and debug.

3. A small responsive website

Result: a few Pages composed from reusable Components, project design-system tokens, images, navigation, and route/SEO output.

This example should prove:

• Pages and Components have distinct responsibilities;

• shared Components update consistently across routes;

• assets and generated paths work in the destination;

• responsive layouts survive a production build;

• publishing or provider deployment is reviewed separately from design completion.

Build it with Design a Component, Work with images and media, and Choose an output.

4. A package-ready component set

Result: a small group of reusable Components exported behind a stable handwritten package boundary and tested in a clean consumer.

This example should prove:

• exported contracts are intentional and typed;

• generated files are isolated from adapters and package metadata;

• the runtime dependency and CSS/assets are packaged correctly;

• re-export does not erase owned code;

• npm pack plus a clean consumer catches entry-point and declaration problems.

Use Export into an existing app and Re-export safely. The current public npm boilerplate is unfinished and should not be presented as an unchanged production example.

5. A UI-and-agent iteration

Result: one visible Component improvement made through a bounded MCP prompt, verified structurally and visually, then reviewed in the editor and undone or refined through the shared file history.

This example should prove:

• the agent selects the intended project independently from the visible editor;

• copied file/element references remove target ambiguity;

• activity marks help locate work without acting as proof;

• read-back, Preview, diagnostics, and consumer checks provide appropriate evidence;

• Undo covers the design-file content step, not external work.

Use Build with prompts, Verify agent work, and Undo agent changes.

What a publishable example must include

Every future gallery entry should contain:

1. a reviewed project or reproducible starting fixture;

2. the exact file and feature scope;

3. current editor and Preview screenshots;

4. the generated public contract and relevant file tree;

5. a verified consumer or hosted result;

6. tests/build commands and their observed outcome;

7. known limitations and external dependencies;

8. the last verification date.

Static marketing numbers, copied code excerpts, or screenshots without a reproducible project are not enough.

Current example status

The Website project is the documentation screenshot pilot for the Project UI plus one Component file. Its images and workflow evidence must be recaptured and reviewed before this page can claim it as a finished public example.