SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsstitch-ui-guide

stitch-ui-guide

Agents & models

View repository

Updated 10-15 21:48

About this skill

Stitch UED Guidelines

This skill serves as a reference for User Experience Design (UED) guidelines when working with Stitch. It includes interaction principles, visual vocabulary, and prompt engineering strategies.

When to use this skill

Use this skill when:

  • The user asks about layout or style terms (e.g. Masonry, Glassmorphism, Sidebar) or device constraints (mobile vs desktop width, touch targets).
  • You need to structure or improve a Stitch prompt (Context → Layout → Component → Content) or ensure consistent UED wording.
  • You are coordinating with stitch-ui-execute and need UED/accessibility/design-system alignment alongside Stitch generation.

For transforming vague ideas into a full Stitch prompt, use stitch-design-spec; combine both when you want structure + vocabulary (this skill) and concrete prompt output (stitch-design-spec).

Design Modes (Model Selection)

Stitch operates in two distinct modes, which you should choose based on the user's need for speed vs. fidelity:

  • Standard Mode (Gemini 2.5 Flash)

    • Best for: Rapid iteration, wireframing, exploring multiple layout ideas quickly.
    • Features: Fast generation, Text-to-UI, Theme editing.
    • Use Case: "Show me 3 different layout options for a login screen."

  • Experimental Mode (Gemini 2.5 Pro)

    • Best for: High-fidelity design, complex logic, visual references.
    • Features: Image-to-UI (Sketch/Screenshot upload), richer details, smarter component logic.
    • Use Case: "Turn this napkin sketch into a production-ready dashboard."

Prompt Engineering Strategy

A perfect Stitch prompt follows this structure: [Context & Style] + [Layout Structure] + [Component Details] + [Content & Data]

1. Context & Style

  • Context: "Mobile fitness app for gym goers."
  • Style: "Dark mode with neon green accents (Cyberpunk). Rounded corners."
  • Reference: "Similar to Spotify's dark theme but for fitness."

2. Layout Structure

  • Mobile: "Bottom navigation bar, scrollable feed."
  • Desktop: "Left sidebar navigation, top header, main content area with data grid."
  • Grid: "3-column card grid with responsive behavior."

3. Component Details

  • Don't say: "A list."
  • Do say: "A vertical list of 'Workout Cards', each containing a map thumbnail, duration (e.g., '30 min'), and a 'Start' button."

4. Content & Data

  • Realism: Ask for realistic data. "User 'Alice', 'Morning Yoga', '300 kcal'."
  • State: "Active state for the 'Home' tab."

Quick checklist (before calling generate_screen_from_text):

  • Context & style defined? (device, app type, theme)
  • Layout defined? (nav position, main area structure)
  • Key components specific? (avoid "a list"; use e.g. "Workout Cards with map thumbnail, duration, Start button")
  • Sample content / state included? (real copy, active state)

Visual Vocabulary

Use these terms to control the look and feel:

Layout Patterns

  • Hero Section: Top area with main headline/image.
  • Split Screen: Left/Right division (common in Desktop Auth).
  • Masonry: Waterfall layout (Pinterest style).
  • Sidebar Navigation: Vertical nav on the left (SaaS standard).

Style Modifiers

  • Flat: No shadows, high saturation.
  • Material: Shadows, layers, paper metaphor.
  • Neomorphism: Soft shadows, extruded shapes.
  • Glassmorphism: Blurred transparency, frosted glass.
  • Brutalism: Raw, bold, high contrast, large typography.

Color & Theme Prompts

When describing Context & Style, use a clear color structure so Stitch produces consistent palettes. A strong pattern (inspired by AI Color Scheme Prompt — UI Color Scheme Guide):

Structure: [App type] + [Background hex] + [Primary hex] + [Secondary hex] + [Accent hex] + [Design system] + [Mood]. Optionally add semantic colors: success green, alert red, warning yellow.

Example — Dark productivity:

Modern productivity app dark theme, charcoal grey background #1a1a1a, primary blue #4A90E2, secondary teal #26D0CE, neutral greys #2d2d2d to #f5f5f5, accent orange #FF6B35 for CTAs, Material Design 3 inspired, high contrast for readability, professional and focused atmosphere.

Example — Bright desktop tool:

Project management app bright theme, clean white background #FFFFFF, primary royal blue #2563EB, secondary purple #7C3AED, soft grey cards #F9FAFB, green success #22C55E, red alerts #DC2626, yellow warnings #F59E0B, minimal design with subtle shadows, organized and efficient visual hierarchy.

Quick color checklist: Background defined? Primary/secondary/accent with hex? Semantic colors (success/alert/warning) if needed? Design system (Material 3, Fluent) or style (glassmorphism, minimal) mentioned?

More ready-to-use prompts: see docs/color-prompt-guide.md in this repo, or the original article for 20 curated prompts.

Device Guidelines

  • Mobile: ~375px width. Focus on thumb-friendly bottom navigation. Vertical scrolling is expected.
  • Desktop/Web: ~1440px width. Use horizontal space. Multi-column layouts.
  • Tablet: Hybrid. Often resembles desktop but with touch targets.

Accessibility & Inclusive Design

  • Contrast & readability: Prefer sufficient contrast (dark/light); avoid low-contrast text. In prompts, you can add "high contrast" or "clear text hierarchy."
  • Touch targets: For mobile/tablet, ask for touch-friendly controls (e.g. "buttons at least 44px tap area"). In Context or Component details, add "touch-friendly" when relevant.
  • Focus & keyboard: For desktop, mention "clear focus states" or "keyboard-navigable" when the design should support accessibility.
  • In prompts: Add phrases like "high contrast," "clear focus states," "touch-friendly buttons" in Context/Style or Component Details when UED or accessibility alignment is needed.

Controls & Variants

  • Variants: Stitch generates multiple options. You can ask to "Generate variants for the hero section" to A/B test designs.
  • Controls: Use the Interactive Chat to refine designs ("Make the button blue", "Move the logo to the center").

Related resources

  • Stitch Effective Prompting Guide: https://stitch.withgoogle.com/docs/learn/prompting/ — official best practices; consult for up-to-date recommendations.
  • Division of labor: stitch-ui-guide = structure and vocabulary (how to phrase, what terms to use). stitch-design-spec = transform vague ideas into a full, executable Stitch prompt (with DESIGN.md, framework contracts). Use both when you need consistent UED wording and concrete prompt output.
  • Vague → enhanced prompt: Use stitch-design-spec (Path A: enhance vague UI ideas with specificity, UI/UX keywords, DESIGN.md context). Use with stitch-design-md when visual language must be extracted; actual screen execution belongs to stitch-ui-execute.
  • Stitch skills in this repo (prefer these over official): design-md → stitch-design-md; enhance-prompt → stitch-design-spec (two paths + framework contracts); react-components → stitch-ui-react-components; stitch-ui-loop → stitch-ui-loop; remotion → stitch-remotion; shadcn-ui → stitch-ui-shadcn-components. Plus stitch-mcp-* (one skill per MCP tool: create-project, get-project, list-projects, generate-screen-from-text, get-screen, list-screens), stitch-ui-contract-* (Bootstrap, Element Plus, Layui, uView, uView Pro, Vant), stitch-ui-execute (orchestrator), and six Stitch→framework conversion skills (Vue + Element/Bootstrap/Layui/Vant, uni-app + uView/uView Pro). These skills reference each other and the same MCP; use stitch-mcp- names (e.g. get_screen → stitch-mcp-get-screen).

References

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: UED guidelines, visual vocabulary, and prompt structure for Stitch. Use when the user asks about layout/style terms, device constraints, or when structuring/improving Stitch prompts; combine with stitch-design-spec for vague→concrete prompts.

Rules

  • Read before write: first confirm the current state and real 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, explicitly mark them as NOT_VERIFIED。
  • Idempotency first: retain request identifiers and phase state; when results are unclear, query first and do not blindly retry.
  • 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 pre-checks

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 minimal sufficient steps, and record evidence at key state changes; retain an associable state or receipt for every external call.

Step 5: Verify delivery

Output the results, verification evidence, unfinished 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 authorized by the user.
  • 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 a plan as a result: a document or prompt is not the same as 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

Do not exceed the scope given by the user; writes, payments, publishing, and irreversible actions require explicit authorization. If the request requires another skill, do not copy its body text; 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 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 respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。