Treat Misaki Studio as another source of application code with an explicit generation boundary. Before adopting an export, understand what the project owns, what the generator overwrites, which runtime and framework dependencies are required, and where your handwritten code should live.
Preview your work so the visual and behavioral result is known before export.
Inspect code preview for the selected file before configuring an external destination.
Read How export works and Choose an output.
Follow Export your code, then understand the generated output.
Use Re-export safely for every maintained destination; review the deeper dependency/compatibility guide as it is completed.
The rewritten boilerplate pages record the verified public-repository state as of their review date. Dependency versions, router assumptions, target behavior, and starter-repository defaults can change, so recheck the selected repository before installing or deploying.
Identify which properties, variants, events, children slots, data dependencies, and root-element pass-throughs the generated Component exposes. Confirm the actual output rather than inferring the API from the canvas.
Know which output files belong to Misaki Studio and are replaced on re-export. Keep adapters, wrappers, application services, tests, and handwritten business logic outside that generated boundary unless a verified workflow says otherwise.
Generated components can depend on Misaki Studio runtime helpers and framework packages. Verify current package names, versions, peer dependencies, stylesheet handling, routing assumptions, and client/server constraints for the chosen output before installation.
Local folder, Git, package, and website routes have different prerequisites and side effects. Local destinations require desktop filesystem access. Git and publishing affect external state and need a deliberate review and recovery plan.
Treat generated output as reviewable source. Use a clean target, inspect the diff, run the consuming application's typecheck/tests/build, and keep handwritten extensions in wrappers or adapters that a regeneration does not replace.
Coverage: UI + MCP for inspection and export configuration; exact parity depends on the destination.
Select my project and inspect the target Component. Generate or read its current code output without publishing or writing to an external target. Summarize its exported component API, generated files, imports, framework dependencies, and any diagnostics. Stop before changing settings.
For an existing application:
Inspect the configured export targets and the target application's integration boundary. Do not export yet. Report which folder would be overwritten, which generated imports are unresolved in the application, and which checks should run after export.
An agent should use code preview, export settings, diagnostics, and source-location operations where appropriate. It must not publish, push, or overwrite an external target merely because it can inspect one.
Misaki Studio currently maintains five public boilerplates: Website, npm package, backend, Cloudflare, and Vercel. They are for teams that want a prepared application, packaging, backend, or hosting shell. They are not required when an existing application already has a suitable build, routing, styling, and publishing environment.
Their readiness differs. The Cloudflare and Vercel starters document static-site deployment; the general Website starter needs additional review; the npm starter is unfinished for general use; and the public backend starter says its SQL action engine is not built. Read the individual guide before choosing one.