stitch-mcp-list-projects

List Stitch Projects

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

This skill lists all Stitch projects accessible to the user.

Use Case

Invoke this skill when the user wants to resume work on an existing project, or needs to check what projects are currently available.

Input Parameters

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

• filter (optional): Filter for projects to list. Defaults to "view=owned".
  • "view=owned": Projects owned by user.
  • "view=shared": Projects shared with user.

Output Schema

Returns an object containing a list of projects:

• projects: (Array of Project)
  • name: Resource ID (e.g., projects/123...).
  • title: Project title.
  • updateTime: Last modification time.
  • thumbnailScreenshot: Preview image of the project.

Usage Example

User Input: "Show me my existing projects."

Agent Action:

1. Identify the user wants to list projects.
2. Call list_projects tool with arguments {"filter": "view=owned"}.

References

• Examples

When to use (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 Stitch projects accessible to the user.

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: preserve request identifiers and phase state; when results are unclear, query first rather than blindly retrying.
• 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 limits, 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 path after failure.

Step 4: Execute actions

Execute bounded read-only queries and preserve source identifiers; keep an associable state or receipt for each external call.

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 no adjacent task was misrouted to this skill.
• Inputs, target objects, versions, and output locations are all explicit, and no guessed values were used in place of required values.
• All write, paid, publish, or irreversible actions are within the scope authorized by the user.
• 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 actionable next steps.

Gotchas

1. Mistaking the plan for the result: Documents or prompts are not equal to 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, publish, overwrite, and paid 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 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 preserve the current task context.

Progressive disclosure

• When inputs/outputs, 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 run, privilege escalation denial, and failure recovery, refer to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。