stitch-mcp-list-screens

List Screens

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

Lists all screens contained within a specific project.

Use Case

Invoke this skill to browse the history of generated designs in a project or to find a specific screen to reference or iterate upon.

Input Parameters

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

• projectId (required): Bare project ID string, for example 123456; never add the projects/ prefix.

Output Schema

Returns an object with screens array:

• screens:
  • name: Resource identifier (e.g., projects/123/screens/abc).
  • title: Auto-generated title.
  • screenshot: Thumbnail URL.
  • deviceType: The device type of the screen.

Usage Example

User Input: "Show me all screens in this project."

Agent Action:

1. Extract project ID.
2. Call list_screens with the bare ID: {"projectId": "123456"}.

References

• Examples

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: Lists all screens contained within a specific project.

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, explicitly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and phase state; when results are unclear, query first and do not retry 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 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; for every external call, retain an associable state or receipt.

Step 5: Verify delivery

Return resource identifiers, query conditions, pagination status, 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. 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 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-scale, publish, overwrite, and paid operations 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 write operations are needed later, first hand off to the corresponding write skill and reconfirm. If the request requires another skill, do not copy its body; hand off by skill name and retain the current task context.

Progressive disclosure

• When you need to determine inputs/outputs, state, and authorization points, read references/workflow-contract.md。
• When you need a pre-delivery self-check, read references/validation-checklist.md。
• When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For the first run, privilege escalation refusal, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。