Example prompts

These prompts teach safe, verifiable ways to work with Misaki Studio through MCP. Replace Website and every placeholder with your current project, file, or element. Keep the stopping conditions unless you intentionally want a broader effect.

Inspect a project without changing it

Call list-projects. Select Website only if that exact name exists; otherwise stop and show me the choices. Read its full project tree and summarize the file kinds and folder structure. Do not create, rename, move, duplicate, convert, export, publish, or delete anything.

Explain a visual target

In the selected Website project, inspect <component or element reference>. Read its hierarchy, base style, responsive overrides, variants, data-structure contract, logic, and timelines. Explain what it currently renders and how a parent can use it. Do not change anything.

Build a small Component

In the Website project, create a Component named StatusBadge in the correct atomic component folder. Call build-playbook before authoring. Give it a text property named label and component variants for success, warning, and error. Build the visual subtree efficiently, bind the text, style every variant, and preserve the project's existing design-system conventions. Verify the tree, all variant layers, a Preview screenshot for each variant, and generated TSX/SCSS. Do not export, publish, or change another file.

Make an existing Component responsive

In the Website project, inspect <component reference> and its configured screens. Preserve its base layout. On the smallest existing screen only, stack the content vertically and make the action fill the available width. Read the exact screen override layer back and show screenshots for the base and smallest screens. Do not add or delete a screen, variant, element, or file.

Add state-driven styling

In the Website project, inspect <component reference> and read logic-format. Add an internal boolean state named open only if an equivalent state does not already exist. On click of <trigger element reference>, toggle it. Use a per-node style variant to rotate <indicator element reference> when open is true; do not add a consumer-facing Component variant. Verify with preview-interact, including before/after screenshots and the Context delta, then inspect generated output and stop.

Add a timeline

In the Website project, inspect <component reference> and its existing timelines. Add one appear timeline that changes only opacity and vertical position on <target element reference>. Preserve all existing timelines and base styles. Read the timeline and keyframes back, preview the animation, and inspect generated output. Report any screen-specific export limitation; do not autoplay it unless I explicitly requested autoplay.

Use design-system values

In the Website project, inspect the current Colors, Spacing, Radius, Fonts, and Themes files. Reuse existing semantic values for <element reference> instead of creating duplicates. Show the exact resolved references and preview the affected theme states. Do not rename, delete, or reorganize any design-system entry.

Add bounded interaction logic

In the Website project, read logic-format and inspect <component reference>. Connect the existing Submit event so it sets the existing submitted state to true only when the existing validator is valid. Preserve every other branch and action. Read the logic back and use preview-interact to test both a valid and invalid case. Show state/Context evidence and do not call an external API or database action.

Inspect data without external mutation

In the Website project, inspect <Content or Table file reference>, including its schema, Views, and the Components that mount those Views. Explain which data is embedded at export time and which operation would run against a backend. Do not add, update, or delete a row; do not run an action; do not expose credentials.

Inspect generated output for integration

In the Website project, inspect <component reference> and export its current generated TSX and SCSS for review only. List its public props, events, variants, dependencies, design-system imports, and runtime assumptions. Run diagnostics, but clearly separate diagnostic results from a real consumer build. Do not write to a local folder, Git repository, package registry, or website.

Diagnose without fixing

In the Website project, investigate <observable problem>. Read the target's current structure, logic, Preview state, computed styles, console output, diagnostics, and generated code as relevant. State the most likely cause with evidence and propose the smallest correction. Do not change project content or any external destination.

Undo one confirmed design-file step

In the selected Website project, inspect <design-file reference>. If the most recent eligible content edit is exactly <unwanted change>, call undo once. Read and preview the result, then stop. If another edit is on top or the target is not a design file, do not undo anything; explain the recovery options.

Prepare an external action without executing it

In the Website project, inspect the current <local/Git/package/site> destination and generated output. Show the exact proposed files or remote effect, prerequisites, overwrite risk, and recovery plan. Do not export, commit, push, publish, deploy, or change the destination configuration.

What makes these prompts safe

Each example includes most of the same controls:

• an exact project and target;

• a read-before-write requirement;

• one bounded outcome;

• preservation constraints;

• proof matched to the result;

• a clear stop;

• explicit denial of unrelated destructive or external effects.

Read Build with prompts to adapt this pattern rather than copying an example blindly.