stitch-ui-react-components

Stitch to React Components

Quick Start

1. "Convert the store appointment Stitch page to a React component; first provide a locally reviewable result."
2. "Fix the issue where the desktop brand logo does not return to the homepage; preserve the existing scope and sources."
3. "Sync the new design tokens to the existing React page; flag missing inputs and validation states."

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

Capability Boundary Description

✅ Good At

• Convert the store appointment Stitch page to a React component.
• Fix the issue where the desktop brand logo does not return to the homepage.
• Sync the new design tokens to the existing React page.

⚠️ Requires Assets

• Target React project and existing toolchain.
• Specified Stitch screens or cached assets with sources.
• Route table, theme, and component behavior contracts.

❌ Inapplicable Scenarios and Handoff

• React Native native UI → stitch-ui-react-native-components.
• shadcn primitive migration → stitch-ui-shadcn-components.
• Remotion walkthrough video → stitch-remotion, delivering the screen asset list.

Workflow

1. Retrieve the required screen HTML/screenshots, preserving ID strings and source timestamps; cache is reused or refreshed per authorization.
2. Extract tokens from the current HTML and DESIGN.md into the target project, avoiding overwriting the Skill's example assets.
3. Split components, data, and hooks, using readonly Props; follow the target project's conventions.
4. Integrate with existing routing; the brand logo and desktop navigation can return to the homepage, and the desktop still has an entry point when the mobile bottom bar is hidden.
5. Run script AST checks, project type/build checks, and view verification with appropriate proportions, reporting evidence at each layer separately.

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, without using vague prompts like "please provide more context."

Security and Result Verification

Do not read unrelated account configurations and do not collect user passwords; credentials are provided only by the environment or authorized connectors. Examples use only demo data; before uploading, replace customer names, phone numbers, and order numbers with demo values, and check HTML, screenshots, and file metadata. It is forbidden to write keys, session cookies, full base64 text, or signed download URLs into reports/repositories. Unverified parameters, visual effects, and business figures must not be fabricated; outputs must note sources, decision rationale, what was actually executed, and what has not yet been verified.

• AST only proves parsing, Props, and literal className hex checks.
• All theme roles come from the current design.
• Homepage links and each route have verifiable targets.

Customizable: page scope, target directory, router, theme mode, refresh strategy. Value-added checks: sync sources; desktop/mobile navigation verification; AST capability boundaries.

FAQ

Q1: What is the main deliverable? Enter the desktop top bar "Store Appointment" and route / → use the existing route Link to="/"; screenshots and HTML sources are recorded in .stitch; passing AST does not replace browser click testing.

Q2: When should other entry points be used instead? React Native native interfaces → stitch-ui-react-native-components; shadcn primitive migration → stitch-ui-shadcn-components; Remotion walkthrough videos → stitch-remotion, delivering a screen asset list.

Q3: What happens when inputs are missing? First provide a clearly marked local assumption draft, and list "needs to be supplemented: target React project and existing toolchain; specified Stitch screens or cached assets with provenance; routing table, theme, and component behavior contracts". Write operations that depend on these inputs are not executed.

Q4: How is completion determined? AST only proves parsing, Props, and literal className hex checks; all theme roles come from the current design; the home page link and every route have verifiable targets.

Q5: How to customize? Page scope, target directory, router, theme mode, refresh strategy; when not provided, follow existing project values and state assumptions.

Q6: Does it automatically upload, install, or go live? 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 explaining the specific impact first.

Reference as needed

• When executing detailed mappings, APIs, or templates, read extended workflows。
• When encountering failures or 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 current skill's accompanying source code and fixed upstream snapshot; the structure follows Agent Skills specification. The tool's current behavior is subject to the actual schema; when not connected, do not claim that online behavior has been verified.

When to use (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 or sync Stitch HTML/screens into React/Vite components; trigger when token, component Props, and navigation consistency validation are needed. shadcn primitive migration, data dashboards, React Native, or video use their own specification entry points..

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, clearly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and stage states; 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 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; 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; adjacent tasks were not misrouted to this skill.
• The inputs, target objects, versions, and output locations are all specified, and no required values were replaced with guessed values.
• All write, payment, publication, or irreversible actions are within the scope of user authorization.
• 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. Mistaking the plan for the result: A document or prompt is not the same as 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-scale, publication, overwrite, and payment 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; write, payment, publication, 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 it is necessary to determine inputs/outputs, state, and authorization points, read references/workflow-contract.md。
• When self-checking before delivery is needed, read references/validation-checklist.md。
• When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For first runs, refusal of privilege escalation, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。