stitch-mcp-generate-screen-from-text

Stitch Text-to-Screen Generation

Quick Start

1. "Generate a store appointment mobile page from the prepared prompt; provide a locally reviewable result first."
2. "Create an order desktop wireframe in a known project; preserve the existing scope and provenance."
3. "After a generation interruption, check whether a result already exists; mark the missing inputs and verification status."

For designers, front-end developers, and teams maintaining this workflow. Designers provide intent and assets, developers provide engineering/tooling, and the team preserves provenance and acceptance status during handoff.

Capability Boundaries

✅ Good At

• Generating a store appointment mobile page from a prepared prompt.
• Creating an order desktop wireframe in a known project.
• Checking whether a result already exists after a generation interruption.

⚠️ Requires Assets

• A real pure projectId string.
• A prompt with clear structure and no sensitive content.
• The target viewport and the current tool's live schema.

❌ Inapplicable Scenarios and Handoff

• Only writing or modifying prompts → stitch-design-spec.
• Modifying existing screens/generating variants → stitch-ui-execute.
• Outputting a runnable program → the corresponding component conversion skill, delivering the actual screen HTML.

Workflow

1. Read the current MCP schema, keep IDs as strings; send only the fields currently exposed by the schema, and when deviceType or modelId is not exposed, it must be omitted.
2. Verify the project and structure prompt; when a system has already been applied, follow architect's independent system channel.
3. Call generate_screen_from_text once, and record the returned session/outputComponents and the success or unknown status.
4. Via list_screens 's pure projectId , obtain the real screen ID, then use get_screen 's name: projects/{project}/screens/{screen} to read the result, and use get_project to verify ownership.
5. Verify screenshots and HTML; on interruption, do not resend the same write call—first reconcile with get_project/list_screens/get_screen; if there is no candidate, note the reason get_screen was not executed.
6. Use get_screen 's top-level deviceType、width、height to verify device fidelity: the provider may ignore the requested device (measured on 2026-09-14: three write paths requested TABLET and all returned DESKTOP 2560×2048). When the device does not match, stop and report truthfully; do not retry with edit_screens or generate_variants . The provider's dimensions are device pixels;390×884 returns 780×1768(2×), so do not treat it as a 1px discrepancy.

Order by dependency: provenance verification → local artifacts → authorized external operations → verification handoff. For multiple tasks, do the current main path first; when information is missing, first output a draft with assumptions, then precisely list what is missing and what it is for, without using vague prompts like "please provide more context."

Security and Result Verification

Do not read unrelated account configurations and do not collect user passwords; credentials are provided only by the environment or authorized connectors. Examples use demo data only; before uploading, replace customer names, phone numbers, and order numbers with demo values, and check HTML, screenshots, and file metadata. It is forbidden to write keys, session cookies, full base64 text, or signed download URLs into reports/repositories. Unverified parameters, visual effects, and business figures must not be fabricated; outputs must note sources, decision basis, actual execution, and parts not yet verified.

• Models and devices belong to the current schema rather than historical guesses.
• sessionId is not treated as screenId.
• Write success and asset download/visual verification are recorded separately.

Customizable: device, verified model, prompt, project, output asset directory. Value-added checks: real-time schema verification; session and screen distinction; write interruption recovery.

FAQ

Q1: What is the main deliverable? Local inputs projectId='123', Tablet 768x1024, three appointment prompts → a draft of parameters to be invoked containing only projectId/prompt; without a tool receipt, screenId is unconfirmed and must not be fabricated.

Q2: When should another entry point be used instead? Only writing or modifying prompts → stitch-design-spec; modifying existing screens/generating variants → stitch-ui-execute; outputting a runnable program → the corresponding component conversion skill, delivering the actual screen HTML.

Q3: What happens when inputs are missing? First provide a clearly marked local assumption draft, and list "Need to supplement: a real pure projectId string; a structurally clear prompt with no sensitive content; the target viewport and the current real-time schema." Write operations that depend on these inputs are not executed.

Q4: How do you determine completion? Models and devices belong to the current schema rather than historical guesses; sessionId is not treated as screenId; write success and asset download/visual verification are recorded separately.

Q5: How do you customize? Device, verified model, prompt, project, output asset directory; when not provided, use existing project values and mark the assumptions.

Q6: Does it automatically upload, install, or go live? Only perform actions covered by the current request and existing authorization; without a remote receipt, do not claim upload success, and without runtime verification, do not claim go-live. Additional installation or scope expansion requires first explaining the specific impact.

Reference on demand

• When executing detailed mappings, APIs, or templates, read Extended Flow。
• When encountering failures/abnormal inputs, read Anti-patterns and Gotchas。
• When edge cases, compatibility, customization, and authorization are involved, read In-depth FAQ。
• When complete input/output and verification scenarios are needed, read Local Application Examples。
• The local implementation basis is the current skill's accompanying source code and Fixed Upstream Snapshot; the structure follows the Agent Skills specification. The tool's current behavior is subject to the actual schema; when not connected, do not claim to have verified online behavior.

When to use

When the user needs to execute generation or write operations after clear inputs, budget, and delivery constraints Load this skill when: first extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: call Stitch generate_screen_from_text to generate a visual screen from the prepared page prompt; trigger when the user explicitly requests text generation with Stitch or the orchestrator enters the generation step. Prompt polishing, editing existing screens, and code implementation should go through their respective entry points..

Rules

• Read before write: first confirm the current state and actual capabilities, then perform actions that change external state.
• Least privilege: use only the files, tools, accounts, and network scope required to complete the current step.
• Evidence first: when run results, resource IDs, versions, hashes, or test outputs are missing, clearly mark them as NOT_VERIFIED。
• Idempotency first: retain the request identifier and phase status; when results are unclear, query first instead of blindly retrying.
• Privacy and security: logs, examples, receipts, and error messages must not contain tokens, cookies, keys, or personally sensitive data.

Workflow

Step 1: Clarify intent

Confirm whether this skill matches the goal; if it is only an adjacent need, hand it off to a more precise skill.

Step 2: Perform preflight

Validate inputs, model/tool capabilities, output paths, budget limits, and approval status; if any key condition is unknown, stop at the read-only stage.

Step 3: Form a plan

List the tools to be called, the objects that will be changed, the success criteria, and the safe exit method after failure.

Step 4: Execute actions

Execute per approval and record the request identifier; query ambiguous results instead of resubmitting; retain a traceable status or receipt for every external call.

Step 5: Verify delivery

Verify artifact existence, format, hash/identifier, cost status, and quality gates, and state facts, inferences, and unverified items separately.

Validation checklist

• The skill trigger conditions are consistent with user intent, and adjacent tasks were not misrouted to this skill.
• Inputs, target objects, versions, and output locations are all clear, and no required values were replaced with guessed values.
• All writes, payments, publications, or irreversible actions are within the scope of user authorization.
• Results have been verified with independent checks; "command succeeded" or "file exists" alone does not count as complete acceptance.
• The output includes actual evidence, failed/skipped items, remaining risks, and executable next steps.

Gotchas

1. Mistaking the plan for the result: a document or prompt does not equal actual execution; the actual execution level must be indicated.
2. Retrying on error: a timeout or lost response may already have produced remote state; query first before deciding whether to retry.
3. Implicit scope expansion: batch, full-scale, publish, overwrite, and paid operations are not a natural extension of ordinary reads and writes.
4. Version drift: when referencing external resources, record the version, tag, or commit; do not treat a mutable branch as release evidence.
5. Stale evidence: caches, old screenshots, and historical tests cannot prove the current environment; refresh key evidence before delivery.

Non-applicability and boundaries

Payments, publications, overwrites, uploads, or external writes must use the explicit authorization of the current task; do not automatically expand the number of times or the budget. If the request requires another skill, do not copy its body; hand off by skill name and preserve the current task context.

Progressive disclosure

• When input/output, state, and authorization points need to be determined, read references/workflow-contract.md。
• When a pre-delivery self-check is needed, read references/validation-checklist.md。
• When encountering timeout, partial success, or recovery scenarios, read references/error-recovery.md。
• For first run, privilege escalation refusal, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。