with one click
stitch-sdk-domain-design
// Design the domain model for the Stitch SDK. Use when mapping MCP tools to domain classes and bindings in domain-map.json. This is Stage 2 of the generation pipeline.
// Design the domain model for the Stitch SDK. Use when mapping MCP tools to domain classes and bindings in domain-map.json. This is Stage 2 of the generation pipeline.
Use the Stitch SDK to generate, edit, and iterate on UI screens from text prompts, manage projects, and retrieve screen HTML/images. Use when the user wants to consume the SDK in their application.
Generates a deeply contextual, progressive-disclosure briefing for any GitHub repository. It builds a mental model of the code before analyzing issues and PRs to provide actionable insights. Use when asked for a "GitHub report," "repo status," "daily briefing," or to "catch up on a codebase."
Develop the Stitch SDK. Covers the generation pipeline, dual modality (agent vs SDK), error handling, and Traffic Light (Red-Green-Yellow) implementation workflow. Use when adding features, fixing bugs, or understanding the architecture.
Find bugs in the Stitch SDK using a real API key. Covers standard functional edges and tricky situations.
Generate or update the README for the Stitch SDK. Use the Bookstore Test structure and source the current API from the codebase. Use when the README needs to be written or updated.
Run the full Stitch SDK generation pipeline. Use when a new tool is added, or the SDK needs to be regenerated end-to-end.
| name | stitch-sdk-domain-design |
| description | Design the domain model for the Stitch SDK. Use when mapping MCP tools to domain classes and bindings in domain-map.json. This is Stage 2 of the generation pipeline. |
This skill teaches you how to perform Stage 2 of the generation pipeline: reading tool schemas and producing domain-map.json ā the intermediate representation that drives codegen.
tools-manifest.json ā raw MCP tool schemas captured from the server (includes outputSchema)ir-schema.ts ā Zod schema defining valid domain-map structure (the canonical contract)domain-map.json ā the current IR (if extending, not starting fresh)stitch-sdk-development skill ā for understanding the pipeline contextA valid domain-map.json with two sections: classes and bindings, validated by ir-schema.ts.
[!IMPORTANT] Your output is validated twice by the codegen: structurally (Zod IR schema) and semantically (projection steps verified against
outputSchemafrom the tools-manifest).
Each class represents a domain entity. Ask: "What noun does the user interact with?"
{
"Stitch": {
"description": "Main entry point. Manages projects.",
"constructorParams": [],
"isRoot": true,
"factories": [
{ "method": "project", "returns": "Project", "description": "Create a Project handle from an ID." }
]
}
}
| Field | Purpose | Example |
|---|---|---|
constructorParams | Fields stored on the instance | ["projectId", "screenId"] |
fieldMapping | Per-field data source mapping with optional stripPrefix | See below |
parentField | Which param is injected from a parent class | "projectId" |
idField | Which param the .id getter aliases | "screenId" |
factories | Local factory methods (no API call) | [{ "method": "project", "returns": "Project" }] |
Use fieldMapping when a param needs a different source field, prefix stripping, or a fallback:
{
"constructorParams": ["projectId", "screenId"],
"fieldMapping": {
"projectId": { "from": "name", "stripPrefix": "projects/" },
"screenId": { "from": "id", "fallback": { "field": "name", "splitOn": "/screens/" } }
}
}
stripPrefix: Removes a resource name prefix from the valuefallback: If the primary field is missing, splits an alternate field on a delimiterEach binding maps one MCP tool to one class method. Ask: "Who owns this action?"
| Type | Meaning | Code generated |
|---|---|---|
self | From this.field | projectId: this.projectId |
param | From method parameter | prompt: prompt |
computed | Template interpolation | name: \projects/${this.projectId}/screens/${screenId}`` |
selfArray | Wrap self field as array | selectedScreenIds: [this.screenId] |
Optional params use "optional": true. Renamed params use "rename": "newName".
The returns.projection array tells codegen how to navigate the API response. Each step is a ProjectionStep:
{ prop: string; index?: number; each?: boolean; fallback?: string }
| Projection | Generated code | Use when |
|---|---|---|
[] (empty) | raw | Direct return (whole response) |
[{ "prop": "projects" }] | raw.projects | Array inside object |
[{ "prop": "outputComponents", "index": 0 }, { "prop": "design" }, { "prop": "screens", "index": 0 }] | raw.outputComponents[0].design.screens[0] | Deeply nested single item |
[{ "prop": "outputComponents", "each": true }, { "prop": "design" }, { "prop": "screens", "each": true }] | flatMap chain | Collect all items across arrays |
[{ "prop": "screenshot" }, { "prop": "downloadUrl" }] | raw.screenshot.downloadUrl | Navigate nested properties |
Decision: Use "index": 0 when extracting a single item. Use "each": true when collecting all items (array result). You cannot use both on the same step.
[!TIP] Every
propin a projection is validated against the tool'soutputSchemaat codegen time. If you typo a property name, codegen will fail with a diagnostic listing the available properties.
When returns.class is set, the extracted data is wrapped in a domain class constructor:
{ "returns": { "class": "Screen", "projection": [{ "prop": "screens" }], "array": true } }
The codegen automatically spreads parentField into the data if the child class declares one.
Add a cache field with a structured projection to check this.data before calling the API:
{
"cache": {
"projection": [{ "prop": "htmlCode" }, { "prop": "downloadUrl" }],
"description": "Use cached HTML download URL from generation response if available"
}
}
When the cached property is a nested object (like File with a downloadUrl), use multiple projection steps to drill into it.
Generated code:
if (this.data?.htmlCode?.downloadUrl) return this.data?.htmlCode?.downloadUrl;
// ... else call API
When mapping a new tool, answer these questions:
Which class? Look at which fields the tool requires. If it needs projectId from self, it belongs on Project or Screen. If it needs nothing from self, it belongs on Stitch.
Which method name? Use the verb from the tool name, simplified. generate_screen_from_text ā generate. edit_screens ā edit.
Arguments from self or param? If the caller already has the data (because they're calling a method on themselves), use self. If they need to provide it, use param.
How deep is the return? Check the tool's outputSchema in tools-manifest.json. Build the projection array step-by-step to navigate to the useful data.
Should it cache? If the data is available from a previous response (like generation), add a cache field with the projection path.
After editing domain-map.json:
bun scripts/generate-sdk.ts # Validates IR + projections, then generates
npx tsc --noEmit # Type check
npx vitest run # Unit tests
bun scripts/e2e-test.ts # E2E tests
bun scripts/validate-generated.ts # Lock integrity
If a projection is invalid, you'll see:
ā Binding "Project.generate" projection step 2:
property "screenz" not found in outputSchema.
Available properties: screens, components, metadata