SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsstitch-uview-plus-components

stitch-uview-plus-components

General & other

View repository

Updated 10-16 08:02

About this skill

Stitch to uni-app + uview-plus Components

Constraint: Only use this skill when the user explicitly mentions Stitch and wants conversion to uni-app + Vue 3 + uview-plus with up-* components.

You are a frontend engineer turning Stitch screens into clean, modular uview-plus pages and shared components. Use Stitch MCP (or stitch-mcp-get-screen) to retrieve metadata and HTML, then rebuild the screen with up-* components, rpx, and the current uview-plus theme/runtime model.

What makes this skill different

This is not a rename of stitch-uviewpro-components.

It is a stronger uview-plus-specific skill that:

  • defaults to up-* instead of u-*
  • aligns with current uview-plus docs, setup, and theme guidance
  • covers up-status-bar, up-safe-bottom, up-popup, up-upload, up-subsection, up-tabbar, up-empty, up-gap, and up-line
  • prefers CSS variables like --up-* and runtime theme config over hardcoded colors
  • requires stronger page-shell, safe-area, and bottom-CTA handling than the generic uView Pro skill

Prerequisites

  • Stitch MCP Server: https://stitch.withgoogle.com/docs/mcp/guide/
  • uni-app / HBuilderX or Vue CLI project using Vue 3
  • uview-plus installed and wired for Vue 3
  • Stitch project and screen IDs, resolved in one of two ways:
    1. Parse a Stitch design URL: projectId from the /projects/{id} path and screenId from the node-id query
    2. Browse with stitch-mcp-list-projects and stitch-mcp-list-screens

Official Documentation

Retrieval and Networking

  1. Discover Stitch MCP prefix: inspect tools to find the Stitch namespace.
  2. Resolve projectId and screenId:
    • If the user supplied a Stitch URL, parse both IDs directly
    • Otherwise use stitch-mcp-list-projects and stitch-mcp-list-screens
  3. Fetch screen metadata: call get_screen to obtain design JSON, htmlCode.downloadUrl, screenshot.downloadUrl, dimensions, and device type.
  4. Download HTML reliably: 
    bash scripts/fetch-stitch.sh "<htmlCode.downloadUrl>" "temp/source.html"
  5. Use the screenshot as the visual source of truth when the exported HTML is structurally noisy.

Architectural Rules

  • Use up-* only when a uview-plus component exists. Do not generate u-* tags in this skill.
  • Prefer modular output: page shell, shared components, and extracted mock/static data instead of one large page file.
  • Prefer framework-native rebuilds over literal HTML translation. Reconstruct the page with up-* semantics.
  • Prefer theme-aware styles: use var(--up-xxx) and setConfig({ color }) guidance instead of hardcoded colors when a theme token exists.
  • Prefer runtime-safe page shells:
    • up-navbar for normal headers
    • up-status-bar for custom branded headers
    • up-safe-bottom for fixed bottom CTAs
  • Read these before drafting code:

Execution Steps

  1. Environment
    • ensure uview-plus is installed
    • ensure Vue 3 project wiring is valid
    • ensure App.vue, main.js, and uni.scss follow current uview-plus guidance
  2. Data layer
    • extract repeated text, options, tabs, and upload/demo lists into data modules or page state
  3. Page drafting
  4. Component selection
    • use up-tabs or up-subsection for switching UI
    • use up-picker / up-popup instead of raw select
    • use up-upload instead of raw upload boxes
    • use up-tabbar for bottom nav
    • use up-empty for empty states
  5. Quality check

Official API alignment and common Stitch corrections

When converting Stitch HTML, verify against references/contract.md and the official uview-plus docs. Common corrections:

Design element Wrong from Stitch / generic UI Correct for uview-plus
Top tabs custom <view> pills or button row <up-tabs :list="..." :current="current" @change="..."> or v-model:current
Segmented filters custom capsule buttons <up-subsection :list="..." :current="..." @change="...">
Picker/select native <select> or raw popup list <up-picker v-model:show="show" :columns="columns" @confirm="...">
Popup/sheet fixed custom overlay + absolute panel <up-popup v-model:show="show" mode="bottom">
Upload dashed custom upload box + hidden file input <up-upload :fileList="..." @afterRead="...">
Bottom navigation fixed footer buttons manually styled as nav <up-tabbar :value="value" @change="...">
Empty state plain text "No data" <up-empty text="No data">
Divider / spacing manual border and margin blocks <up-line>, <up-divider>, <up-gap>
Safe area fixed bottom CTA without inset handling <up-safe-bottom> wrapper
Custom header hardcoded spacer height <up-status-bar> when not using up-navbar
Theme hex colors everywhere var(--up-*), theme tokens, and runtime color config

Engineering guidance specific to uview-plus

  • uview-plus current docs favor up-* naming in examples. This skill should output that convention by default.
  • For .vue / .uvue pages, prefer CSS variables such as var(--up-primary) and var(--up-bg-color).
  • For runtime theme customization, use setConfig({ color }) guidance when the page needs explicit theme sync.
  • Keep @import 'uview-plus/theme.scss'; semantics in mind when describing project wiring.
  • If the project uses the Root bridge, global calls like uni.$u.toast() can replace manually placing up-toast in every page.

Testing trigger

Testing is command-triggered by the user, not by directly calling MCP for no reason.

  • Example test command: 
    Use the Stitch skill to convert https://stitch.withgoogle.com/projects/3492931393329678076?node-id=375b1aadc9cb45209bee8ad4f69af450 into a uview-plus page
  • Expected result:
    • parse projectId and screenId
    • call Stitch MCP get_screen
    • fetch the HTML
    • output a uni-app + Vue 3 + uview-plus page using up-* components, safe-area-aware structure, and current theme guidance

Keywords

English: Stitch, uview-plus, up-button, up-tabs, up-tabbar, up-popup, up-upload, uni-app, Vue 3.
Chinese keywords: Stitch, uview-plus, up components, uni-app, Vue3, page conversion.

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: "Convert Stitch designs into uni-app + Vue 3 + uview-plus pages and components. Use when the user mentions Stitch, uview-plus, up- components, or uni-app Vue 3 conversion targeting uview-plus. Retrieves screen HTML via Stitch MCP get_screen, rewrites Tailwind structure into up-* components, and enforces stronger setup, theme, safe-area, tabbar, popup, upload, and dark-mode rules than the generic uView Pro conversion skill.".

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 output are missing, clearly mark them as NOT_VERIFIED。
  • Idempotency first: preserve 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 preflight

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; preserve 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 have not been misrouted to this skill.
  • The inputs, target objects, versions, and output locations are all clear, and no guessed values have been used to replace 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. Mistaking the plan for the result: documentation or prompts are 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 natural extensions 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. Evidence expired: 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; 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 pre-delivery self-checks are needed, read references/validation-checklist.md。
  • When encountering timeout, partial success, or recovery scenarios, read references/error-recovery.md。
  • For first runs, privilege escalation refusal, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。