SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsstitch-mcp-get-screen

stitch-mcp-get-screen

Agents & models

View repository

Updated 10-15 21:48

About this skill

Get Screen Details

CRITICAL PREREQUISITE: You must ONLY use this skill when the user EXPLICITLY mentions "Stitch".

Retrieves the full details of a specific screen, including its HTML code and high-res screenshot.

Use Case

Invoke this skill when the user wants to "export" the code, view the full design details, or when the Agent needs to analyze the generated HTML structure.

Input Parameters

The skill expects you to extract the following information from the user request:

  • name (required): Full resource name projects/{project}/screens/{screen}.

CRITICAL: When both ID segments are available, construct the full name and call this read directly. Do not call stitch-mcp-get-project first.

Resource Path Parsing

If the user provides a resource path or URL, use the following rules to extract projectId and screenId:

  1. Format: web application/stitch/projects/{projectId}/screens/{screenId}

    • Logic: Extract projectId and screenId directly from the path segments.
    • Example: web application/stitch/projects/3492931393329678076/screens/2e22a9fb99ba49ddb6ce8907a1e74d60 -> projectId="3492931393329678076", screenId="2e22a9fb99ba49ddb6ce8907a1e74d60".

  2. Format: projects/{projectId}/screens/{screenId}

    • Logic: Extract projectId and screenId from the path segments.

Agent flow:

  1. Recognize the user input matches one of the above formats.
  2. Extract both ID segments as strings and construct the canonical resource name.
  3. Call get_screen with {"name": "projects/{project}/screens/{screen}"}.
  4. Use the returned htmlCode.downloadUrl, screenshot.downloadUrl, and metadata for design-to-code (e.g. stitch-design-md or a framework conversion skill).

Output Schema

Returns a Screen object:

  • htmlCode: The actual HTML/CSS code of the UI.
  • screenshot: High-resolution image URL.
  • figmaExport: Figma file asset.
  • width, height, deviceType.

Intent Recognition & Framework Conversion

After retrieving the screen details (HTML code), check if the user's request implies converting the design to a specific frontend framework.

Logic:

  1. Identify Framework: Look for specific keywords in user input (e.g., "uView", "uViewPro", "Vue", "React", "Flutter").
  2. Locate Skill: Search for and read the corresponding skill definition file to understand the "Design Contract" or conversion rules.

    • uViewPro / uni-app: If user mentions "uView", "uViewPro" or "UniApp", you MUST load and reference the complete context from the stitch-ui-uviewpro-components skill to ensure accurate code generation.

      • References: Read skills/stitch-ui-uviewpro-components/references/ (especially contract.md and tailwind-to-uviewpro.md) for core mapping rules.
      • API: Read skills/stitch-ui-uviewpro-components/api/component-api.md for component props and event definitions.
      • Examples: Read skills/stitch-ui-uviewpro-components/examples/usage.md for correct implementation patterns.
      • Resources: Read skills/stitch-ui-uviewpro-components/resources/architecture-checklist.md for design compliance.

    • uView (Standard): If user mentions "uView" (without "Pro") or "uView 2.0", load stitch-ui-uview2-components.

      • Context: Read references/ (contract, tailwind-to-uview), api/component-api.md, examples/usage.md, resources/architecture-checklist.md from stitch-ui-uview2-components.

    • Element Plus: If user mentions "Element Plus", "Element", "Vue Desktop", load stitch-ui-vue-element-plus-components.

      • Context: Read references/ (contract, tailwind-to-element-plus), api/component-api.md, examples/usage.md, resources/architecture-checklist.md from stitch-ui-vue-element-plus-components.

    • Vant UI: If user mentions "Vant", "Vue Mobile", load stitch-ui-vue-vant-components.

      • Context: Read references/ (contract, tailwind-to-vant), api/component-api.md, examples/usage.md, resources/architecture-checklist.md from stitch-ui-vue-vant-components.

    • Layui Vue: If user mentions "Layui", load stitch-ui-vue-layui-components.

      • Context: Read references/ (contract, tailwind-to-layui), api/component-api.md, examples/usage.md, resources/architecture-checklist.md from stitch-ui-vue-layui-components.

    • Bootstrap Vue: If user mentions "Bootstrap", load stitch-ui-vue-bootstrap-components.

      • Context: Read references/ (contract, tailwind-to-bootstrap), api/component-api.md, examples/usage.md, resources/architecture-checklist.md from stitch-ui-vue-bootstrap-components.

    • React / Tailwind: If user mentions "React" (standard), load stitch-ui-react-components.

      • Context: Hand off to stitch-ui-react-components. Install: npx skills add full-stack-skills/stitch-skills --skill stitch-ui-react-components.

    • Shadcn UI: If user mentions "Shadcn", "Next.js", "Radix", load stitch-ui-shadcn-components.

      • Context: Hand off to stitch-ui-shadcn-components. Install: npx skills add full-stack-skills/stitch-skills --skill stitch-ui-shadcn-components.

    • Other Frameworks: Search for matching stitch-ui-*-components skills and load their respective api, examples, and references directories.

  3. Apply Constraints: Use the rules defined in that framework's skill (e.g., component mappings, slot usage, unit conversion) to transform the raw HTML from Stitch into the target framework code.

Example Flow:

  • User: "Get screen X and convert to uViewPro code."
  • Agent:
    1. Call get_screen to get HTML.
    2. Detect intent: "uViewPro".
    3. Load Context: Read contract.md, component-api.md, usage.md, and architecture-checklist.md from stitch-ui-uviewpro-components.
    4. Generate code by applying uViewPro rules to the Stitch HTML.

Usage Example

User Input: "Give me the code for the login screen we just made."

Agent Action:

  1. Identify target screen.
  2. Call get_screen with {"name":"projects/37803.../screens/88805..."}.

References

When to use

Load this skill when the user needs read-only discovery, inspection, or summarization of the current resource state . First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: Retrieves the full details of a specific screen, including HTML code..

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 needed 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: Run prechecks

Confirm the query scope, identity context, pagination limit, and output fields; 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 bounded read-only queries and retain source identifiers; retain an associable state or receipt for every external call.

Step 5: Verify delivery

Return resource identifiers, query conditions, pagination state, and unverified items, 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 guessed values were used in place of required values.
  • All write, paid, publish, or irreversible actions are within the scope of user authorization.
  • 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. Treating the plan as the result: documentation or prompts do not equal actual execution; the actual execution level must be indicated.
  2. Retrying on 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, publish, overwrite, and paid actions 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 create, modify, or delete resources; if a write operation is needed later, first hand it to the corresponding write skill and reconfirm. 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, state, and authorization points need to be determined, 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 run, denial of privilege escalation, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。