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

stitch-uviewpro-components

Frontend & websites

View repository

Updated 10-15 21:48

About this skill

Stitch to uni-app + uView Pro Components

Constraint: Only use this skill when the user explicitly mentions "Stitch" and converting Stitch screens to uni-app + Vue 3 + uView Pro (pages/, components/, .vue or .uvue, u-* components).

You are a frontend engineer turning Stitch designs into clean, modular uni-app + uView Pro code. Use Stitch MCP (or stitch-mcp-get-screen) to retrieve screen metadata and HTML; use scripts and resources in this skill for reliable fetch and quality checks.

Prerequisites

  • Stitch MCP Server (https://stitch.withgoogle.com/docs/mcp/guide/)
  • uni-app / HBuilderX or Vue CLI for uni-app (Vue 3)
  • Stitch project and screen IDs — two ways: (1) From a Stitch design URL: parse projectId from path and screenId from node-id query (see stitch-mcp-get-screen). (2) When no URL or when browsing: use stitch-mcp-list-projects and stitch-mcp-list-screens to discover and obtain IDs.

Official Documentation

Retrieval and Networking

  1. Discover Stitch MCP prefix: Run list_tools to find the prefix (e.g. mcp_stitch__stitch:).
  2. Resolve projectId and screenId: (1) If the user provided a Stitch design URL, parse projectId from the path (segment after /projects/) and screenId from the node-id query parameter. (2) Otherwise, or when the user wants to choose a project/screen, call list_projects (e.g. filter view=owned) then list_screens with the chosen projectId to get screenIds.
  3. Fetch screen metadata: Construct name: projects/{project}/screens/{screen} from the string ID segments and call [prefix]:get_screen to get design JSON, htmlCode.downloadUrl, screenshot.downloadUrl, dimensions, deviceType.
  4. High-reliability HTML download: AI fetch tools can fail on Google Cloud Storage URLs. Use Bash to run the skill script: 
    bash scripts/fetch-stitch.sh "<htmlCode.downloadUrl>" "temp/source.html"
    Ensure the URL is quoted.
  5. Visual reference: Use screenshot.downloadUrl to confirm layout and details.

Architectural Rules

  • Modular pages/components: Split the design into pages under pages/ and shared components under components/; avoid one giant page.
  • Logic isolation: Use <script setup>; put event handlers and composables in appropriate modules.
  • Data decoupling: Move static text, image URLs, and lists into data/ or page data.
  • uView Pro only (use framework components when available): Use u-* components only; do not use raw <button>, <input>, <div> for buttons/inputs/modals when u-* exists. Use u-card for cards (use title when only a title, or u-section with #right when title + right content), u-text for label hints and tips (type="info"/"warning", size="24"), u-line / u-divider for dividers; do not use view/text + custom class (.card, .card-title, .label-optional, .tips-text, .unit). Tab bar must use u-tabs; do not use custom tab-header/tab-item. Before drafting a page, read references/component-index.md and references/contract.md for mapping rules, slot syntax (#label, #suffix, #right), and anti-patterns (Picker v-model + :range 1D; Radio value not name; no slot="...").
  • Project-specific: Omit third-party license headers from generated pages/components.

Execution Steps

  1. Environment: Ensure uni-app project has uView Pro installed and configured (Vue 3, main.js, uni.scss).
  2. Data layer: Create or update data sources (e.g. data/mockData.js) from the design content.
  3. Page drafting: Follow examples/usage.md and the architecture checklist; draft the actual page with uView Pro tags per contract. No page-template.vue is bundled.
  4. Wiring: Register pages in pages.json; add tabBar or navigation as needed.
  5. Quality check: Verify against resources/architecture-checklist.md; run in HBuilderX or CLI to confirm on simulator/device.

Official API alignment (avoid Stitch-style mistakes)

When converting Stitch HTML to uView Pro, verify against references/contract.md and uView Pro docs. Common corrections:

Element Wrong (often from Stitch/other UI) Correct (uView Pro)
Tab switcher Custom <view class="tab-header"> + <view class="tab-item"> Always use <u-tabs :list="..." :current="..." @change="...">; do not build tabs with raw views/divs
Tabs props lineColor, activeStyle, inactiveStyle, itemStyle :current, @change(index) (number), active-color, inactive-color
Picker :show="show", :columns="[['A','B']]" (2D) v-model="show"; mode="selector" + :range (1D array, e.g. ['A','B']); @confirm; do not use :columns
Radio name="opt1", customStyle, placement="row" value="opt1" (not name), label for text; no customStyle/placement
Slots (Vue 3) slot="label", slot="suffix" #label, #suffix, v-slot:label — never slot="..."
Form-item label slot="label" #label or v-slot:label
Input type=select — Pair with u-picker; use :select-open bound to picker visibility

Pre-generation checklist — before writing the template, ensure: (1) Card/section use u-card (with title or + u-section for title+right), not view.card + card-header + card-title. (2) Label hints and tips use u-text (type="info"/"warning", size="24"), not text with .label-optional/.tips-text/.unit. (3) Divider use u-line or u-divider, not view + border. (4) Tab switcher uses u-tabs, not custom divs. (5) All slots use #slotname or v-slot:slotname. (6) Picker uses v-model and :range (1D). (7) Radio uses value and label, not name/customStyle/placement.

Integration with This Repo

  • Get screen: Use stitch-mcp-get-screen with projectId and screenId. Obtain IDs either by parsing a Stitch design URL (projectId from path, screenId from node-id) or by using stitch-mcp-list-projects and stitch-mcp-list-screens when no URL is given or when the user needs to browse/select.
  • Design spec: If Stitch was generated with stitch-ui-design-spec-uviewpro constraints, map to uni-app pages and uView Pro components. If converting from Stitch HTML (e.g. htmlCode from get_screen), use references/stitch-html-patterns.md for page structure and form fields; references/tailwind-to-uviewpro.md for Tailwind utility → rpx/theme (spacing, typography, colors, borders, shadows); then references/contract.md for component API and anti-patterns.
  • Design system: If the project has DESIGN.md (from stitch-design-md), align colors and rpx spacing with that system when mapping to uView Pro tokens.

Troubleshooting

  • Fetch errors: Quote the URL in the bash command; ensure scripts/fetch-stitch.sh is executable.
  • Component mapping: Use references/component-index.md to pick the right u-* for each element; follow references/contract.md for layout (u-row, u-col, u-gap), forms (u-form, u-input), nav (u-navbar, u-tabs, u-tabbar), list (u-swipe-action, u-list), feedback (u-toast, u-modal, u-popup, u-empty, uni.$u). Do not substitute raw HTML for u-* components.

Skill testing (command-triggered)

Testing is triggered by user instruction, not by calling MCP directly. Flow: user pastes the test command below into the chat → Agent runs this skill → resolve URL → call get_screen → fetch/parse design → generate uView Pro code → output page file or full code.

  • Test command (paste into Cursor chat): 
    Use the Stitch skill to convert https://stitch.withgoogle.com/projects/3492931393329678076?node-id=375b1aadc9cb45209bee8ad4f69af450 into a uView Pro page
  • Expected: Parse the two ID segments from the URL → call Stitch MCP get_screen with name: projects/{project}/screens/{screen} → generate uni-app + uView Pro .vue per contract and stitch-html-patterns.

Keywords

English: Stitch, uni-app, uView Pro, Vue 3, u-button, u-navbar, rpx.
Chinese keywords: Stitch, uni-app, uView Pro, components.

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 and Vue 3 and uView Pro pages and components. Uses Stitch MCP get_screen for retrieval; high-reliability fetch via scripts; enforces uni-app page structure and uView Pro u-* component contracts, rpx, script setup..

Rules

  • Read before write: first confirm the current state and real 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, clearly mark them as NOT_VERIFIED。
  • Idempotency first: preserve request identifiers and phase state; when results are unclear, query first rather than retrying 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, route it to a more precise skill.

Step 2: Run 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 minimal 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, incomplete items, risks, and clear next steps, and state facts, inferences, and unverified items separately.

Validation checklist

  • The skill trigger conditions match the user's 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 by guesses.
  • All write, paid, publish, or irreversible actions are within the user's authorization scope.
  • 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: documents or prompts are not actual execution; the actual execution level must be stated.
  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-volume, 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. 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 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 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。