stitch-code-to-design

Import frontend source code into Stitch

Quick start

1. "Import the WeCom appointment management web page into Stitch; first provide a locally reviewable result."
2. "Migrate the Vue store scheduling page together with the visual specification; preserve the existing scope and source."
3. "Generate a traceable import checklist for the two routes /orders and /settings; mark the missing inputs and verification status."

For designers, frontend developers, and teams maintaining this process. Designers provide intent and materials, developers provide engineering/tools, and the team preserves source and acceptance status during handoff.

Capability boundaries

✅ Good at handling

• Import the WeCom appointment management web page into Stitch.
• Migrate the Vue store scheduling page together with the visual specification.
• Generate a traceable import checklist for the two routes /orders and /settings.

⚠️ Requires materials

• Source code directory and a runnable URL or build artifact.
• The actual projectId and target route list.
• Upload scope and shareable desensitized page states.

❌ Inapplicable scenarios and handoff

• Save only local HTML → stitch-extract-static-html.
• Record only source design tokens → stitch-extract-design-md.
• Backend data migration or launch → hand off to the target project migration or deployment process, providing the route and asset list.

Workflow

1. Verify the routes, source commit, and target project; bound by the requested pages, do not expand to the entire application.
2. Generate standalone HTML for each route per stitch-extract-static-html, first checking asset closure and desensitization.
3. Generate .stitch/DESIGN.md from the current source per stitch-extract-design-md, preserving the YAML name/colors and source.
4. Within the existing upload authorization scope, use stitch-manage-design-system to establish the project system, recording the returned sourceScreen and instance id.
5. Use stitch-upload to upload the HTML, with title as the route and generated-by as stitch-extract-static-html; read the project/screen to confirm, then report the file, system, and screen mapping.

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 a draft of assumptions, 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, do not 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 the HTML, screenshots, and file metadata. Do not 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 should note the source, basis for decisions, what was actually executed, and what has not yet been verified.

• Every route has HTML, a source, and a real returned ID.
• DESIGN.md and HTML come from the same snapshot.
• When the upload status is unconfirmed, keep the local artifacts and stop subsequent writes.

Customizable: route list, viewport, theme, and output directory; for example, process only /orders, 1280×800, dark. Value-added checks: route-to-screen mapping; HTML/design system same-source check; phased recovery checklist.

FAQ

Q1: What are the main deliverables? Route /orders → local .stitch/orders.html; DESIGN.md source src/theme.css; remote state not executed, awaiting the authorized upload phase.

Q2: When should another entry point be used instead? To save only local HTML → stitch-extract-static-html; to record only source design tokens → stitch-extract-design-md; backend data migration or go-live → hand off to the target project's migration or deployment process, providing the route and asset list.

Q3: What happens if inputs are missing? First provide a clearly marked local assumptions draft, and list "needs to be supplied: source directory and runnable URL or build artifact; actual projectId and target route list; upload scope and shareable sanitized page state." Write operations that depend on these inputs are not performed.

Q4: How is completion determined? Every route has HTML, a source, and a real returned ID; DESIGN.md and the HTML come from the same snapshot; when upload status is unconfirmed, keep the local artifacts and stop subsequent writes.

Q5: How can it be customized? Route list, viewport, theme, and output directory; for example, process only /orders, 1280×800, dark; when not provided, use existing project values and state the assumptions.

Q6: Does it automatically upload, install, or go live? Perform only actions covered by the current request and existing authorization; without a remote receipt, do not claim upload success, and without runtime verification, do not claim go-live. Additional installation or scope expansion requires stating the specific impact first.

Reference as needed

• When executing detailed mappings, APIs, or templates, read Extended workflow。
• 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 is based on the source code accompanying the current skill and the pinned upstream snapshot; the structure follows the 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

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: migrate an existing frontend application into Stitch; triggered when the user requests importing or syncing pages such as React, Vue, or Angular as Stitch designs. When extracting only HTML or writing only DESIGN.md, use the corresponding extraction skill..

Rules

• Read before write: first confirm the current state and actual 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 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, hand it off to a more precise skill.

Step 2: Run prechecks

Confirm the goal, inputs, constraints, available tools, success criteria, and failure boundaries; when 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 the minimum sufficient steps, and record evidence at key state changes; retain an associable status 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, publishing, 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. Mistaking the plan for the result: documentation or prompts are not the same as actual execution; the actual execution level must be stated.
2. Retrying after errors: 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, publishing, overwriting, and paid actions 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, paid, publishing, and irreversible actions require explicit authorization. If the request needs 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 a 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 runs, privilege escalation refusals, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。