Build with prompts

A useful Misaki Studio prompt names the target, describes one bounded result, protects what must not change, and asks for evidence. The agent should inspect first, make the smallest coherent change, and verify the stored result instead of treating a successful tool call as completion.

Before the first write

1. Connect the agent and test the server with list-projects.

2. Select the intended project in the current MCP session.

3. Copy a current file or element reference, or ask the agent to discover the target with read operations.

4. Decide which effects are allowed. Creating project content is different from writing local files, pushing Git changes, or publishing a site.

For a visual Page, Component, screen, or Mockup task, the agent must call build-playbook once before it starts authoring. The playbook supplies the current construction, inspection, and verification rules; it is more reliable than a prompt that tries to reproduce those rules from memory.

The five parts of a strong prompt

• Part: Context · What to say: Name the exact project and file. · Why it matters: MCP project selection is separate from the project visible in the editor.

• Part: Result · What to say: Describe what the user should see or what behavior should work. · Why it matters: A goal is clearer than an unreviewed list of tool calls.

• Part: Scope · What to say: Name the elements or files the agent may change. · Why it matters: It prevents convenient changes elsewhere in the project.

• Part: Constraints · What to say: Preserve relevant children, variants, logic, timelines, and contracts. · Why it matters: A narrow visual change should not silently replace unrelated behavior.

• Part: Proof and stop · What to say: Require read-back, preview, interaction, diagnostics, or generated output, then stop. · Why it matters: Tool success alone does not prove the requested outcome.

Use this reusable shape:

In the Website project, inspect <current file or element reference> before changing it. Produce <bounded result>. Change only <allowed scope> and preserve <important constraints>. Verify the result with <appropriate evidence>, summarize exactly what changed, and then stop. Do not delete, move, rename, export, publish, push, or change another file.

Ask for the right build direction

Misaki Studio supports several directions that sound similar but produce different work:

• Use the ordinary visual-authoring tools when the Page or Component data is the product source.

• Use code-to-design when existing React or HTML is input that should be reconstructed as editable Misaki Studio design content. The build playbook still comes first.

• Use design-to-code when a Misaki Studio design is a specification for separately handwritten code.

• Use the ordinary export-code route when you want generated code from a supported design file. A Mockup is a visual reference and does not use that normal code-export route.

• Ask the agent to read logic-format before it writes non-trivial logic structures.

If the agent needs a low-level capability it cannot find, it can use list-operations, inspect a candidate with describe-operation, and invoke it with run-operation. Current generic operations support Component targets; other target types can be rejected as unsupported.

Build a structure, then refine it

For a planned nested subtree, add-tree is preferable to a long sequence of one-node additions. It creates the hierarchy as one intended construction step and returns identities the agent can use for targeted updates.

After the structure exists, ask for focused changes rather than replacing the whole tree. Re-read node IDs after deletion, replacement, conversion, or a large paste because old targets may no longer exist.

Example:

In the Website project, open the current FeatureCard Component target and call build-playbook before editing. Read its element tree. Add one Content container with a heading, description, and Learn more button as a planned subtree. Preserve every existing sibling, property, state, event, timeline, and responsive override. Read the new subtree back, show a preview screenshot at the base screen and the smallest configured screen, report any warnings, and stop.

Prompts for inspection and logic

An inspection request should explicitly deny mutation:

In the Website project, read the selected Component's tree, props, states, events, timelines, and generated code. Explain its public contract and current responsive behavior. Do not change project content or any external destination.

A logic request should name the trigger, branch, state change, and proof:

In the Website project, read logic-format and inspect <component reference>. On the existing Open event, set the isOpen state to true without changing any other event or branch. Read the logic back, run the relevant Preview interaction, show the resulting state, and stop.

Treat warnings and failures as uncertain state

The MCP wrapper reports ignored unknown top-level fields while still applying the recognized part of a call. A tool can therefore return a warning after making a real change. A handler failure is caught so the server can continue, but the attempted work is not guaranteed to have been rolled back.

When any write warns or fails:

1. Do not repeat the same mutation immediately.

2. Read the target's current tree, style, logic, or file state.

3. Compare that state with the requested result.

4. Correct only what is missing, using the connected tool's current schema.

5. Verify again.

Authorization stays narrow

A prompt to build or fix project content is not permission to:

• delete a file or project;

• overwrite an export destination;

• create a commit, branch, tag, or release;

• push to Git or publish a package or website;

• mutate an external database or service;

• expose credentials or a local MCP endpoint.

Ask separately for those actions, name the destination, and review their specific side effects first.

Verify the result

Match the proof to the change:

• read the tree and values for structure or metadata;

• use Preview interaction and interpreter state for behavior;

• use screenshots, computed styles, and measurements for rendering;

• inspect generated code and diagnostics for export-facing changes;

• inspect the destination independently for local, Git, package, or publishing work.

See Verify agent work for the full verification matrix.