stitch-ui-react-native-components

Stitch to React Native

Quick Start

1. "Convert the store appointment mockup to an iOS/Android form; first provide a locally reviewable result."
2. "Convert the operations list to a native FlatList; keep the existing scope and source."
3. "Sync the current Stitch theme to an existing RN project; flag missing inputs and validation states."

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

Capability Boundaries

✅ Good At

• Convert store appointment mockups to iOS/Android forms.
• Convert operations lists to native FlatList.
• Sync the current Stitch theme to an existing RN project.

⚠️ Requires Assets

• Target RN project and actual dependency versions.
• Selected Stitch screens or approved-for-reuse HTML/screenshots.
• Platform, navigation, and token constraints.

❌ Not Applicable Scenarios and Handoff

• React/Vite browser UI → stitch-ui-react-components.
• Jetpack Compose or SwiftUI implementation → corresponding platform development workflow, deliver design mapping.
• Real payment, login, or push integration → project business interface workflow, preserve UI state contract.

Workflow

1. Retrieve HTML/screenshots and metadata for the user-selected screen; use directly when cached sources are consistent and approved for reuse.
2. Extract current project tokens to src/theme.ts; preserve source and sync time.
3. Map div→View, text→Text, button→Pressable, long lists→FlatList; map using StyleSheet and current RN version capabilities.
4. Split components/data/hooks per project conventions, connect existing native navigation, preserve readonly Props, safe-area, and accessibility labels.
5. Use scripts for limited AST checks, then run existing type checks; record simulator acceptance separately, do not treat script passes as successful native runs.

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, output an assumption draft first, then precisely list what is missing and its purpose, without using vague prompts like "please provide more context."

Security and Result Verification

Do not read unrelated account configurations or collect user passwords; credentials are provided only 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. Do not write keys, session cookies, full base64 text, or signed download URLs into reports/repositories. Do not fabricate unverified parameters, visual effects, or business numbers; note sources, decision basis, actual execution, and unverified parts in output.

• No DOM elements/browser events and all text is inside Text.
• theme tokens come from the current source, and Image has dimensions.
• Check safe-area, navigation, and keyboard states on iOS/Android.

Customizable: target iOS/Android, project path, existing navigation, theme, and refresh scope. Value-added checks: Web→Native mapping; long list selection; platform differences and accessibility checks.

FAQ

Q1: What are the main deliverables? Input Confirm appointment → Confirm appointment; events are provided by the target onPress contract.

Q2: When should another entry point be used instead? React/Vite browser UI → stitch-ui-react-components; Jetpack Compose or SwiftUI implementation → the corresponding platform development process, delivering a design mapping; real payment, login, or push integration → the project business interface process, retaining the UI state contract.

Q3: What happens when inputs are missing? First provide a clearly marked draft of local assumptions, and list "Needed additions: target RN project and actual dependency versions; selected Stitch screen or approved reusable HTML/screenshot; platform, navigation, and token constraints." Write operations that depend on these inputs are not performed.

Q4: How is completion determined? No DOM elements/browser events and all text is in Text; theme tokens come from the current source, Image has dimensions; check safe-area, navigation, and keyboard state on iOS/Android.

Q5: How to customize? Target iOS/Android, project path, existing navigation, theme, and refresh scope; when not provided, use existing project values and mark assumptions.

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

Reference as needed

• When performing detailed mapping, API, or template work, read Extended Process。
• 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 source code accompanying the current skill and pinned upstream snapshot; the structure follows the Agent Skills specification. The current behavior of tools is subject to 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: Convert Stitch screens to React Native or synchronize existing native components; triggered when the target is iOS/Android View, Text, StyleSheet, and native navigation. React DOM or Vite web pages use stitch-ui-react-components..

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: retain request identifiers and stage status; 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 to a more precise skill.

Step 2: Perform precheck

Confirm the objective, 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 invoked, the objects that will be changed, 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; for every external call, retain an associable state or receipt.

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 required values were replaced with guessed values.
• All writes, payments, publications, or irreversible actions are within the scope authorized by the user.
• The results have been verified with independent checks; "the command succeeded" or "the 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: Documentation or prompts are not equal to actual execution; the actual execution level must be indicated.
2. Retrying after an 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-volume, publication, 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, publications, 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 inputs/outputs, 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, refusal of overreach, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。