Chai Studio MCP

Use this skill to make Chai Studio MCP the only source of truth for design context, audit rules, canvas planning, and journal documentation. Also supports Chrome DevTools MCP for evidence-driven website exploration and artifact creation.

First Move

For application-aware work, resolve an application with applications_get unless the user already provided an applicationId.

• If the MCP client is a coding agent with filesystem access and the user asks for code changes: use the local project contract — chai-studio.yaml identifies the application and design-studio.yaml is the synced source of truth.
• If the MCP client is a non-code assistant without a local filesystem: do not require chai-studio.yaml, design-studio.yaml, or local sync. Use applications_get to choose an application and applications_yaml_get/rulesets_get to fetch context directly.
• Non-code MCP clients can still create and edit canvases, inspect presets/rulesets, manage audit records, and create journal entries entirely through MCP tools.
• For codebase work: fetch or refresh design-studio.yaml with applications_yaml_get before redesigns, audits, canvas-to-code work, ruleset work, shadcn generation, or journal documentation.
• Do not invent Chai Studio IDs. Do not maintain separate local DESIGN.md, DESIGN-RULES.md, or design.yaml mirrors.
• If syncing local design-studio.yaml back to Chai Studio: call applications_yaml_sync with approved=false first, show the diff, then call approved=true only after explicit user approval.

Mandatory Sync Gate

For local codebase work, after project identity is resolved and before each Chai Studio operation that depends on local design context: