Choose an output

Choose where Misaki Studio's work should live before configuring an export. Preview, generated-code inspection, local export, Git export, package publication, hosted-site publication, and a self-owned boilerplate solve different problems and have different side effects.

Start with the result you need

• Goal: Check appearance and behavior · Use: Preview · What changes outside the project?: Nothing unless the authored interaction itself calls an external API, storage, or navigation effect.

• Goal: Inspect one Page or Component's generated React/SCSS · Use: Code preview or MCP export-code · What changes outside the project?: Nothing; generated code is returned for review.

• Goal: Write the complete frontend and assets into folders on this machine · Use: Local-folder export · What changes outside the project?: Rewrites generated output in every configured local-folder target. Desktop required.

• Goal: Put generated output in a repository · Use: Git export · What changes outside the project?: Clones, writes, commits, and pushes through the configured Git target.

• Goal: Distribute components for other applications to install · Use: Publish NPM or an npm-package boilerplate · What changes outside the project?: Builds and publishes package state to the configured registry/repository workflow.

• Goal: Put project Pages on a Misaki-hosted URL · Use: Publish Website · What changes outside the project?: Starts a project publishing job and changes hosted external state.

• Goal: Own the build and hosting configuration · Use: A boilerplate · What changes outside the project?: Writes into your clone; its scripts build, package, or deploy through infrastructure you control.

Do not begin with a publishing action when you only need evidence. Preview or inspect generated code first.

The export target model

Open the project's settings/export file. It contains GIT and LOCAL FOLDER target lists.

Each target can describe two independent output halves:

• UI field: REACT SRC PATH · Stored MCP field: path · Purpose: Generated frontend React/source tree.

• UI field: ASSET PATH · Stored MCP field: asset · Purpose: Generated images, fonts, and media.

• UI field: NODEJS SRC PATH · Stored MCP field: backendPath · Purpose: Optional generated Node.js/Express backend. Empty means no backend output.

A Git target also requires its repository URL, branch, username, email, and token. Keep credentials out of screenshots, prompts, committed files, and logs.

Current MCP security limitation: get-export includes a configured Git token in its text response. Treat the full result as secret-bearing output. Do not paste it into documentation, issues, chat transcripts, or agent prompts; redact the token before sharing or retaining the response. Prefer inspecting non-secret fields in the editor when a third party can see the agent transcript.

For a local boilerplate, the usual frontend mapping is:

React src path  → <clone>/src
Asset path      → <clone>/public
Node.js src path → empty, unless a separately verified backend shell is configured

The local folders must already exist. The Git exporter can create configured paths inside the checkout it owns.

Inspect before writing

Use code preview for the selected design file or ask an agent:

Select my project and resolve the target Page or Component. Run export-code for inspection only. Summarize the generated files, imports, diagnostics, and external runtime dependencies. Do not create an export target and do not write to Git, disk, a registry, or a hosted site.

export-code returns generated TSX and SCSS for a design file. Mockups do not generate code.

Configure a local target

Coverage: UI + MCP. Desktop required to write local folders.

In the editor, add a config under LOCAL FOLDER, then fill the frontend source and asset paths. Add a Node.js source path only when you deliberately want a backend artifact and have chosen a compatible backend shell.

For exact editor fields, MCP indices, Git differences, and token handling, read Configure local and Git export targets.

An agent can use get-export, add-export-target, update-export-target, and remove-export-target against the settings/export file.

Read my current export settings. If no local target points to this clone, add one with React source <clone>/src and assets <clone>/public; leave the backend path empty. Read the target back and stop before exporting.

If a Git target already contains a token, the agent must not quote the raw get-export response back to you. Ask it to report only the target kind, description, repository host, branch, and redacted paths needed for the decision.

Run a local-folder export

Coverage: UI + MCP. Desktop required.

The production MCP operation export-code-to-folder runs the same whole-project local-folder export as the app action. It writes to every configured local-folder target; it does not touch Git targets.

Before running it:

1. Read all current targets.

2. Confirm each source and asset folder exists and belongs to the intended clone.

3. Search the generated tree for HAND EDIT (not produced by the exporter) and move any required custom work outside the generated boundary.

4. Commit or otherwise snapshot the target repository.

After running it, inspect the complete diff. A successful export can legitimately rewrite many files, and hand edits inside generated files are not preserved.

Git and publishing need a separate decision

Configuring Git targets is exposed through UI and MCP, but pushing, package publication, and website publication are external mutations. Similar menu and tool names do not establish full parity. Their dedicated guides must document authentication, destination, concurrency, result URLs, failure handling, and recovery before they are approved.