stitch-mcp-create-project

When to use this skill

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

ALWAYS use this skill when:

• The user wants to start a new design task or app idea using Stitch.
• The user asks to "create a Stitch project", "start a new app in Stitch".
• The user switches context to a completely different domain (e.g., from "Medical App" to "Gaming App") and needs a clean slate.
• You need to obtain a projectId before generating screens.

Trigger phrases include:

• "Create a new Stitch project"
• "Start a new Stitch app"
• "Initialize Stitch workspace"

How to use this skill

1. Analyze the User Request: Extract a meaningful title for the project.

   • User: "Design a cyberpunk blog." -> Title: "Cyberpunk Blog"
   • User: "Make a login page." -> Title: "Login Page Project" (Generic)

2. Call the MCP Tool: Invoke create_project with the title.

   • If your client namespaces MCP tools, call mcp__<serverName>__create_project.

3. Handle the Output (CRITICAL):

   • The tool returns a name field (e.g., projects/123456).
   • YOU MUST EXTRACT THE NUMERIC ID.
   • Example: projects/123456 -> 123456.
   • Store BOTH the full name (projects/123...) and the numeric ID (123...) in your context.
   • Usage Rule:
   • Use Numeric ID (123...) for generate_screen_from_text and list_screens.
   • Use Full Name (projects/123...) for get_project.
   • Use Screen Full Name (projects/123.../screens/abc...) as the name for get_screen.

Best Practices

1. Meaningful Titles: Always try to infer a descriptive title. Avoid "Untitled Project".
2. One Project per Domain: Encourage users to keep related screens (Login, Home, Settings) in the same project. Only create a new project if the domain changes.
3. Context Persistency: Explicitly tell the user: "I've created project 'X' (ID: 123). I will use this for our design session."

Keywords

English keywords: create project, new project, start app, initialize, setup, workspace, container, new design, project id, stitch project

Chinese keywords: Create project, New project, Start designing, Initialize, Set up project, New app, Project ID, Launch project

References

• Examples

When to use

Load this skill when the user needs to perform a generation or write operation after clear inputs, budget, and delivery constraints are established . First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: Creates a new Stitch project container. Use this when starting a new design task, app idea, or fresh workspace.

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 outputs are missing, clearly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and phase status; 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, route it to a more precise skill.

Step 2: Perform prechecks

Validate inputs, model/tool capabilities, output paths, budget limits, and approval status; if any critical 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 once as approved and record the request identifier; for ambiguous results, query first instead of resubmitting; retain an associable status or receipt for every external call.

Step 5: Verify delivery

Verify artifact existence, format, hash/identifier, cost status, and quality gates, and state facts, inferences, and unverified items separately.

Validation checklist

• The skill trigger conditions are consistent with user 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: a document or prompt is not equal to actual execution; the actual execution level must be indicated.
2. Incorrect retry: 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 a natural extension of ordinary reads and writes.
4. Version drift: when referencing external resources, record the version, tag, or commit; do not treat mutable branches as release evidence.
5. Evidence expired: Caches, old screenshots, and historical tests cannot prove the current environment; refresh key evidence before delivery.

Non-Applicability and Boundaries

Paid actions, publishing, coverage, uploading, or external writes must use the explicit authorization of the current task; do not automatically expand the number of times or the budget. If the request requires another skill, do not copy its body text; hand off by skill name and preserve the current task context.

Progressive disclosure

• When it is necessary to determine inputs/outputs, states, and authorization points, read references/workflow-contract.md。
• When pre-delivery self-checks are needed, read references/validation-checklist.md。
• When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For first runs, privilege escalation refusal, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。