Stitch Skills: Google's Agent Skills Standard and Cross-Agent Plugin Architecture

Google Labs just shipped a library that wraps MCP servers in a standardized plugin format. Stitch Skills implements the Agent Skills open standard (agentskills.io) to create portable, composable agent capabilities that work across Codex, Claude Code, Cursor, and Gemini CLI. The repository hit 6,735 stars and #4 trending on GitHub for TypeScript because it addresses a real infrastructure gap: how to package and distribute agent tooling without locking into a single orchestration layer.

This is not another MCP server. Stitch Skills sits one layer above MCP, defining how agent capabilities are bundled, versioned, and installed across different coding agents. The sparse checkout patterns and three-tier plugin architecture reveal how Google thinks about skill boundaries and repository scale.

Agent Skills Standard vs. Raw MCP Tools

MCP defines tool schemas and transport protocols. The Agent Skills standard adds a plugin wrapper that includes:

Metadata layer: skill dependencies, compatibility matrix, installation targets
Lifecycle hooks: setup, teardown, and environment validation
Namespace isolation: skills declare their scope (project, workspace, global)
Marketplace discovery: skills are distributed via Git refs with sparse checkout support

Raw MCP tools are JSON-RPC endpoints. Agent Skills are installable packages with dependency graphs. The difference matters when you need to compose multiple capabilities or distribute tooling across teams.

Stitch Skills requires the Stitch MCP server to be running, but the plugin layer handles installation, versioning, and agent-specific configuration. You install a skill once, and it works in Codex, Claude Code, and Cursor without rewriting tool definitions.

Sparse Checkout Pattern for Skill Repositories

The installation commands use --sparse flags to limit clone scope:

codex plugin marketplace add google-labs-code/stitch-skills --ref main \
  --sparse .agents/plugins \
  --sparse plugins/stitch-design \
  --sparse plugins/stitch-build \
  --sparse plugins/stitch-utilities

This pattern reveals three things about managing agent skill repositories at scale:

Monorepo structure: all skills live in a single repository, but agents only pull what they need
Bandwidth optimization: a full clone would include documentation, tests, and unused skills
Namespace boundaries: each plugin category is a separate sparse path, enforcing clean separation

The .agents/plugins path contains marketplace metadata. The three plugins/* paths are the actual skill implementations. Omitting --sparse pulls the entire repository, which is fine for local development but wasteful in CI or multi-agent deployments.

Three-Tier Plugin Architecture

Stitch Skills organizes capabilities into three categories:

Plugin	Scope	Execution Context	Typical Use Case
`stitch-design`	Design-focused skills	UI prototyping, visual feedback loops	Generate component mockups, validate design tokens
`stitch-build`	Build and component skills	Code generation, asset pipelines	Scaffold components, run build steps
`stitch-utilities`	Helper and utility skills	Cross-cutting concerns	File operations, API calls, logging

These categories map to different agent execution contexts. Design skills run in environments where visual feedback matters (Codex with UI preview, Cursor with inline rendering). Build skills run in CI or local dev environments where code generation happens. Utilities are stateless and work everywhere.

The skill boundaries tell you something important: Google expects agents to specialize. A design agent does not need build skills. A CI agent does not need design skills. The sparse checkout pattern lets you install only the relevant tier.

Installation Flow and Scope Targeting

The CLI supports three installation scopes:

Project: skills are installed into the current project directory
Workspace: skills are installed into the workspace configuration (Cursor, VS Code)
Global: skills are available to all projects on the machine

# Claude Code: project scope
npx plugins add google-labs-code/stitch-skills --scope project --target claude-code

# Cursor: workspace scope
npx plugins add google-labs-code/stitch-skills --scope workspace --target cursor

The --target flag tells the installer which agent configuration to modify. Codex uses a marketplace model where you register the repository once, then install individual plugins. Claude Code and Cursor use a direct installation model where the entire skill library is added at once.

This split reveals a tension in the Agent Skills standard: some agents want fine-grained control (Codex), while others want batteries-included simplicity (Claude Code). The CLI abstracts the difference, but the underlying configuration files diverge.

Skill Dependencies and Selective Installation

The README warns that design skills have inter-dependencies. If you install skills selectively, you must include all required dependencies. The CLI does not resolve these automatically:

npx skills add google-labs-code/stitch-skills

This command shows available skills and lets you pick specific ones. The dependency graph is not enforced at install time. You will only discover missing dependencies when a skill fails at runtime.

This is a deliberate trade-off. Automatic dependency resolution requires a package manager (npm, pip, cargo). The Agent Skills standard avoids that complexity by treating skills as Git submodules with manual dependency tracking. It works for small skill libraries but will break at scale.

Marketplace Distribution Model

Codex treats Stitch Skills as a marketplace:

Register the repository with codex plugin marketplace add
Browse available plugins in the Codex UI
Install specific plugins (stitch-design, stitch-build, stitch-utilities)

This model assumes agents will have multiple skill marketplaces. The sparse checkout pattern makes sense here: you do not want to clone every marketplace in full. You want metadata (.agents/plugins) and the specific plugins you install.

Claude Code and Cursor skip the marketplace layer and install the entire library at once. This works for Google’s first-party skills but does not scale to third-party marketplaces. The Agent Skills standard will need a registry (like npm or crates.io) if it wants to support discovery and versioning at scale.

Failure Modes and Observability Gaps

The current implementation has three observable failure modes:

Missing MCP server: skills fail silently if the Stitch MCP server is not running
Dependency resolution: selective installation breaks when required skills are missing
Version conflicts: no mechanism to handle multiple versions of the same skill

The README says “make sure you have followed the Stitch MCP Setup,” but there is no runtime check. If the MCP server is down, skills will fail with opaque errors. The Agent Skills standard does not define health checks or observability hooks.

Dependency resolution is manual. If stitch-design depends on stitch-utilities, you must install both. The CLI does not validate this. You will only discover the issue when a skill tries to call a missing utility.

Version conflicts are unhandled. If two projects require different versions of stitch-design, the global installation will use whichever version was installed last. The sparse checkout pattern does not support multiple refs in the same repository.

Security Boundaries

Skills run with the same permissions as the agent. There is no sandboxing or capability-based security. A malicious skill can:

Read and write arbitrary files in the project directory
Make network requests to any endpoint
Execute shell commands with the agent’s privileges

The Agent Skills standard does not define a security model. It assumes skills are trusted. This works for first-party Google skills but breaks down with third-party marketplaces. The sparse checkout pattern provides some isolation (you only pull the plugins you install), but it does not prevent a compromised skill from accessing the entire filesystem.

The Git ref (--ref main) is the only versioning mechanism. There is no signature verification or checksum validation. If the main branch is compromised, all installations pull the malicious code.

Technical Verdict

Use Stitch Skills when:

You are building agents that need to share capabilities across Codex, Claude Code, and Cursor
You want a standardized plugin format without writing custom MCP server wrappers
You are comfortable with manual dependency tracking and Git-based distribution
You trust the skill authors and do not need sandboxing

Avoid Stitch Skills when:

You need automatic dependency resolution or version conflict handling
You require capability-based security or sandboxed skill execution
You are building a third-party marketplace and need a registry with discovery and versioning
You need observability into skill health and MCP server connectivity

The Agent Skills standard is the first serious attempt at cross-agent skill portability, but it punts on dependency resolution, security, and observability. The sparse checkout pattern is clever for monorepo distribution, but it will not scale to a decentralized marketplace without a registry layer. This is infrastructure-level plumbing that works for Google’s first-party skills but needs more guardrails before it can support a broader ecosystem.