Quick Start
- "Use Stitch to take a look at my existing projects and screens."
- "Use Stitch to generate a mobile page and iterate."
- "Complete the full delivery of this page from generation and comparison to acceptance and archiving."
For designers, product, frontend developers, and delivery leads. This entry point is only responsible for determining paths, inputs, and authorization; it does not use successful routing as a substitute for downstream execution evidence.
Routing Table
| Intent | Selection |
|---|---|
| Local-only design specs, module prompts, fuzzy requirement polishing | stitch-design-spec |
| First use, missing credentials, authentication failure | stitch-local-setup |
| List projects | stitch-mcp-list-projects |
| Read project details | stitch-mcp-get-project |
| List screens | stitch-mcp-list-screens |
| Read single-screen details/assets | stitch-mcp-get-screen |
| Create, generate, edit, variants | stitch-ui-execute |
| Create, update, list, or apply design systems | stitch-manage-design-system |
| Prepare HTML/images locally without sending remote requests | stitch-extract-static-html or the target conversion Skill |
| Explicitly upload reviewed HTML/images or DESIGN.md | stitch-upload |
| Explicitly download single-screen HTML/screenshots | stitch-mcp-get-screen obtain the URL, then save to the specified directory according to authorization |
| Delete remote projects | stitch-delete-project |
| Full delivery of specs, two-image comparison, approval, and archiving | stitch-design-harness |
Capability Boundaries
✅ Good At
- Route read requests to the narrowest read-only Skill.
- Route write requests to the designer or design system manager, and preserve approval boundaries.
- Route full delivery requests to Harness, distinguishing generation from acceptance completion.
⚠️ Requires Materials
- The Stitch goal the user wants to complete and the current stage.
- Verifiable project/screen asset identifiers or the target to be created.
- The explicit scope and authorization required for writing, uploading, and deleting.
❌ Not Applicable Scenarios and Handoffs
- Only discussing general UI principles →
stitch-ui-guide。 - Only implementing frontend code for an existing design → the corresponding framework conversion Skill.
- ChatGPT web connector tasks → use the connector process authorized by that environment; local setup does not apply.
How It Works
Determine the intent first. Local-only specs/prompts are directly forwarded to stitch-design-spec, without executing authentication or setup; when missing, only explain the dependency. Installation instructions:npx skills add full-stack-skills/stitch-skills --skill stitch-design-spec. For other tasks requiring a remote connection, execute scripts/stitch_setup.py check; when missing, forward to stitch-local-setup, and do not infer the overall configuration from whether environment variables exist. Choose one primary route at a time; reads can be executed directly, remote writes follow the user's current explicit authorization, and deletion must be reconfirmed by a dedicated Skill. For unknown write results, read first to reconcile, and do not retry blindly.
FAQ
Q1: Why is a root route needed? It allows authentication, reading, writing, assets, and full delivery to use their respective security contracts.
Q2: Will just viewing projects call write tools? No, reads go through a dedicated read-only Skill.
Q3: What if credentials are missing? Forward to stitch-local-setup, and execute the configuration check and hidden input process.
Q4: Will local asset tasks be uploaded automatically? No. Local preparation goes through the extraction or conversion Skill; only when the user explicitly uploads and provides a target project does it enter stitch-upload. Markdown is transferred by that Skill to remote upload_design_md。
Q5: When to use Harness? When the user requests a complete verifiable delivery from specification to comparison, approval, and archiving.
Q6: Does routing completion equal task completion? No; the target Skill's actual receipt and acceptance evidence must prevail.
When explicitly downloading local assets, use stitch_local_download_assets; if list_screens does not return a screen list, resource names that have been validated by get_screen/ generated results and belong to the same project must be placed into screenNames. When uploading reviewed HTML/images, use stitch_local_upload_asset. Both belong to the local capabilities provided since 0.6.0; 0.7.4 adds auditable best-effort export of referenced resources and reconciliation without candidate IDs, 0.7.5 adds an explicit art decision gate after Stitch original acceptance, 0.7.6 removes parameters that could self-claim a user source and requires the user to strictly reply with the canonical option, 0.7.7 adds importable editable HTML sources, OCR drift failure, and deterministic semantic normalization receipts, 0.7.8 upgrades layout comparison to a coarse-grained edge algorithm that ignores texture and color enhancement, and 0.7.3 adds automatically opening the local Token page when credentials are missing. For real Provider Canary evidence, see within this skill live-canary-acceptance.md。
On-demand reference
- For complex combined requests, see routing workflows。
- For common misrouting, see anti-patterns。
- For edge cases, see in-depth FAQ。
- For offline routing examples, see local validation examples。
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: Stitch Design root routing; when the user wants to use Stitch to complete tasks from authentication, reading, generation, design systems, and asset processing to full delivery, choose the narrowest downstream Skill and do not directly expand remote write authorization..
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, explicitly mark them as
NOT_VERIFIED。 - Idempotency first: retain 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 to a more precise skill.
Step 2: Perform precheck
Confirm the goal, inputs, constraints, available tools, success criteria, and failure boundaries; if any key condition is unknown, stop at the read-only phase.
Step 3: Form a plan
List the tools to be called, objects that will change, 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 state or receipt for every external call.
Step 5: Verify delivery
Output results, verification evidence, incomplete items, risks, and clear next steps, and state facts, inferences, and unverified items separately.
Validation checklist
- The skill trigger conditions are consistent with user intent, and adjacent tasks are not misrouted to this skill.
- Inputs, target objects, versions, and output locations are all clear, and no required values have been replaced with guessed values.
- All writes, payments, publications, or irreversible actions are within the scope of user authorization.
- Results have been verified with independent checks; only "the command succeeded" or "the file exists" does not count as complete acceptance.
- The output includes actual evidence, failed/skipped items, remaining risks, and executable next steps.
Gotchas
- Treating a plan as a result: Documentation or prompts are not equivalent to actual execution; the actual execution level must be indicated.
- Retrying on error: A timeout or lost response may already have produced remote state; query first before deciding whether to retry.
- Implicit scope expansion: Batch, full-scale, publication, overwrite, and payment actions are not natural extensions of ordinary reads and writes.
- Version drift: When referencing external resources, record the version, tag, or commit; do not treat a mutable branch as release evidence.
- 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, publication, 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, status, 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 privilege escalation, and failure recovery, refer respectively to
examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。