stitch-ui-execute

Stitch Design Execution Orchestration

Quick Start

1. "Use Stitch to generate a tablet page for store appointments; first provide a locally reviewable result."
2. "Only modify the top search area of the existing order page; keep the existing scope and sources."
3. "Generate layout variants according to the approved count and verify assets; mark missing inputs and verification status."

For designers, frontend developers, and teams maintaining this workflow. Designers provide intent and materials, developers provide engineering/tools, and the team preserves sources and acceptance status during handoff.

Capability Boundaries

✅ Good At

• Use Stitch to generate a tablet page for store appointments.
• Only modify the top search area of the existing order page.
• Generate layout variants according to the approved count and verify assets.

⚠️ Requires Materials

• Target project and create/edit/variant intent.
• Interface requirements, devices, and existing design system.
• Available tool schema, target screens, and write scope.

❌ Not Applicable and Handoff

Local spec entries are loaded by name; when missing, explain dependencies. Installation instructions:npx skills add full-stack-skills/stitch-skills --skill stitch-design-spec。

• Only need page specs or copyable prompts → stitch-design-spec.
• Only generate DESIGN.md → stitch-design-md.
• Implement backend APIs or publish a website → target development/deployment workflow, deliver designs and assets.

Workflow

1. Detect actual tools; when there is no MCP, output prompt-only and clearly state that it was not generated.
2. Reuse the project, read the spec/framework contract as needed; uviewpro matching takes priority over uview.
3. Verify the applied designSystem; pass the new screen's system ID separately, do not repeat theme tokens in the prompt, and keep inline tokens for legacy/prompt-only.
4. Use architect's three-part prompt to dispatch generate_screen_from_text/edit_screens/generate_variants by intent; keep IDs as strings and parameters according to the current schema.
5. Obtain outputComponents, project, and screen assets, verify the actual images and save sources; for non-idempotent write interruptions, first run the three-item read probe, and do not resend unknown results.

Order by dependency: source verification → local artifacts → authorized external operations → verification handoff. For multiple tasks, do the current main path first; when information is missing, first output an assumption draft, then precisely list what is missing and its purpose. Do not use vague prompts like "please provide more context".

Security and Result Verification

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

• The selectedScreenIds for edit/variant come from actual queries.
• MOBILE/DESKTOP/TABLET are consistent with the request.
• Reconcile with get_project/list_screens/get_screen; if there are no candidates, record the reason.

Device fidelity must be judged by measured values

The basis for judgment is get_screen oftop-level deviceType、width、height；screenInstance is not guaranteed to carry these fields. After generation, read these three values first before deciding; do not just look at "call succeeded".

• The provider does not guarantee compliance with the requested device. Measured on 2026-09-14: three write paths (generate_screen_from_text、edit_screens、generate_variants) requested TABLET all returned DESKTOP 2560×2048; another MOBILE request likewise fell back to DESKTOP. When a fallback is hit,stopand report truthfully; do not switch to trying the other two paths—they will fall back the same way and only produce more useless artifacts.
• Provider dimensions are device pixels:390×884 viewport returns 780×1768(2×). This is scaling, not error; do not chase the 1px discrepancy shown on the web canvas.
• Decision rule: the device matches the request (when requesting AGNOSTIC , skip this item), and the width and height are integer multiples of the canvas with the same horizontal and vertical multiplier. Harness's validate_screen_device accordinglyfails closed; if it does not pass, it must not be marked complete, nor reported as a deliverable for that device.

Customizable: device, framework contract, generate/edit/variant mode, quantity, and asset directory. Value-added checks: intent routing; system token triage; interruption write reconciliation.

FAQ

Q1: What is the main deliverable? Offline edit request: only add a "Search orders" input before the avatar on the TABLET order page; keep the rest of the layout; prepare edit_screens parameters, with 0 actual remote calls.

Q2: When should a different entry point be used? If you only need page specs or copyable prompts → stitch-design-spec; to generate only DESIGN.md → stitch-design-md; to implement backend interfaces or publish a website → the target development/deployment process, delivering design and assets.

Q3: What happens when inputs are missing? First provide a clearly marked local assumption draft, and list "Needs to be supplemented: target project and new/edit/variant intent; interface requirements, device, and existing design system; available tool schemas, target screens, and write scope." Write operations that depend on these inputs are not executed.

Q4: How is completion determined? The selectedScreenIds for edit/variant come from actual queries; MOBILE/DESKTOP/TABLET match the request; get_project/list_screens/get_screen are reconciled, with reasons for any candidate records absent.

Q5: How to customize? Device, framework contract, generate/edit/variant mode, quantity, and asset directory; when not provided, follow existing project values and mark assumptions.

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

Reference as needed

• When executing detailed mappings, APIs, or templates, read Extended workflow。
• 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 inputs/outputs and verification scenarios are needed, read Local application examples。
• The local implementation basis is the source code accompanying the current skill and fixed upstream snapshot; the structure follows Agent Skills specification. The tool's current behavior is governed by the actual schema; when not connected, do not claim that online behavior has been verified.

When to use

Load this skill when the user needs to select and execute a verifiable, recoverable professional workflow for the current request . First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: orchestrate the creation, import, editing, or variant generation of Stitch screens; triggered when the user explicitly requests to actually create or modify a design with Stitch. Use stitch-design-spec for page specifications or prompts, and use stitch-design-md to extract the visual language from assets..

Rules

• Read before write: first confirm the current state and actual capabilities, then execute 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 output are missing, explicitly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and phase state; when the result is unclear, query first and do not retry blindly.
• 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 prechecks

Confirm the goal, inputs, constraints, available tools, success criteria, and failure boundaries; 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 change, the success criteria, and the safe exit method after failure.

Step 4: Execute actions

Execute in minimally sufficient steps, and record evidence at key state changes; retain a correlatable state or receipt for every external call.

Step 5: Verify delivery

Output the results, verification evidence, incomplete items, risks, and clear next steps, and state facts, inferences, and unverified items separately.

Validation checklist

• The skill trigger conditions are consistent with the user's intent, and adjacent tasks were not misrouted to this skill.
• The inputs, target objects, versions, and output locations are all clear, and no guessed values were used in place of required values.
• All write, paid, publish, or irreversible actions are within the scope of user authorization.
• The 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. Treating the plan as the result: a document or prompt is not the same as actual execution; the actual execution level must be indicated.
2. Erroneous retry: 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

Do not exceed the scope given by the user; writing, payment, publishing, and irreversible actions require explicit authorization. If a request requires another skill, do not copy its body text; hand off by skill name and preserve the current task context.

Progressive disclosure

• When inputs/outputs, states, 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 timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For first run, denial of privilege escalation, and failure recovery, refer to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。