Stitch Skills: How Google's Agent Skills Standard Turns MCP Servers into Reusable Workflow Primitives

Google Labs just released stitch-skills, a library implementing the Agent Skills open standard. It sits one layer above MCP servers and turns individual tools into composable workflow primitives. The repository has 8.7K stars and demonstrates real cross-agent portability: the same skill definitions work in Codex, Claude Code, Cursor, Antigravity, Gemini CLI, and (with manual installation) OpenCode.

This is not another MCP server. It is a distribution format for agent workflows that consume MCP tools. The plumbing reveals how different coding agents handle skill discovery, installation, and metadata, and where the portability story breaks down.

The Agent Skills Standard: Workflow vs. Tool Boundary

An MCP tool is a primitive: read_file, execute_command, search_web. A skill is a multi-step workflow that chains tools together with prompt templates, state expectations, and validation logic.

The Agent Skills standard defines:

• Frontmatter metadata: name, description, version, author, tags
• Prompt structure: system instructions, user-facing templates, and context injection points
• Tool dependencies: which MCP tools the skill requires
• State contracts: what the skill expects in context and what it returns

Stitch Skills uses this to package workflows like generate-design (which calls design tools, validates output, and formats results) or scaffold-component (which reads templates, generates code, and writes files).

The boundary is clear: tools are stateless functions, skills are stateful orchestration. Skills can call other skills, but they resolve to tool invocations at execution time.

Plugin Distribution via Sparse Checkout

Stitch uses Git sparse checkout to optimize skill distribution. When you add the marketplace in Codex:

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

The --sparse flags tell Git to clone only specific paths. This avoids pulling the entire repository when you only need a subset of skills. The repository structure is:

plugins/
  stitch-design/
    skills/
      generate-design/
      refine-mockup/
  stitch-build/
    skills/
      scaffold-component/
      run-tests/
  stitch-utilities/
    skills/
      format-code/
      validate-output/
.agents/
  plugins/
    marketplace-index.json

Each plugin directory contains a skills/ folder with individual skill definitions. The .agents/plugins/ path holds marketplace metadata that Codex uses for discovery.

This pattern reveals two things:

1. Versioning is Git-native: you pin to a branch, tag, or commit. No package registry, no semver resolution.
2. Distribution is lazy: agents only fetch what they need, reducing clone size and install time.

The trade-off is that you lose atomic versioning across skills. If you install stitch-design and stitch-build separately, they might reference different commits.

Cross-Agent Installation Plumbing

Different coding agents handle skill installation differently. Here is how the same skill library works across three agents:

Codex and Claude Code use the same npx plugins CLI but target different directories. Cursor uses workspace scope instead of project scope. OpenCode does not support the npx tooling at all and requires manual file copying.

OpenCode also has different frontmatter requirements. While Codex and Claude accept name and description in any format, OpenCode requires the name field to match the skill directory name exactly. This breaks portability if you rename a skill folder without updating metadata.

Skill Metadata and Execution Flow

A typical skill definition looks like this:

---
name: generate-design
description: Generate a design mockup from a text prompt
version: 1.0.0
author: Google Labs
tags: [design, mockup, generation]
tools:
  - stitch:read_template
  - stitch:generate_image
  - stitch:validate_output
---

# System Instructions

You are a design generation assistant. Use the provided template and user prompt to create a mockup.

# Steps

1. Call `stitch:read_template` with the template ID
2. Merge the user prompt into the template
3. Call `stitch:generate_image` with the merged prompt
4. Validate the output with `stitch:validate_output`
5. Return the image URL and metadata

# Context Requirements

- `template_id`: string
- `user_prompt`: string

# Output

- `image_url`: string
- `metadata`: object

When an agent loads this skill:

1. It parses the frontmatter to extract dependencies
2. It checks that the required MCP tools are available
3. It injects the system instructions into the agent's context
4. It exposes the skill as a callable workflow

The agent does not execute the skill immediately. It waits for the user to invoke it, then follows the steps, calling MCP tools in sequence and managing state between calls.

Failure Modes and Observability Gaps

The Agent Skills standard does not define:

• Retry logic: if a tool call fails, does the skill retry or abort?
• State persistence: if the agent crashes mid-skill, can it resume?
• Observability hooks: how do you trace tool calls across skills?
• Security boundaries: can a skill call tools outside its declared dependencies?

Stitch Skills inherits these gaps. Each agent implements its own retry and state management. Codex retries failed tool calls up to three times. Claude Code aborts on first failure. Cursor has no documented retry behavior.

There is no standard observability format. You cannot trace a skill execution across multiple tool calls without agent-specific logging. This makes debugging multi-skill workflows difficult.

Security boundaries are also undefined. A skill declares its tool dependencies in frontmatter, but nothing prevents it from calling other tools at runtime. Agents trust skills to behave correctly.

Deployment Shape and Versioning

Stitch Skills uses Git as the distribution mechanism. This has implications:

• No central registry: you add marketplaces by URL, not by package name
• No dependency resolution: if two skills depend on conflicting tool versions, you get the latest
• No rollback: if a skill update breaks your workflow, you must manually revert the Git ref

The sparse checkout pattern optimizes for clone size but complicates versioning. If you install stitch-design today and stitch-build tomorrow, they might reference different commits. You cannot atomically update all skills in a marketplace.

The alternative is to fork the repository and pin your own ref. This gives you control but adds maintenance overhead.

When to Use This

Use the Agent Skills standard when:

• You want to share workflows across multiple coding agents
• You need to package multi-step orchestration logic
• You can tolerate Git-based versioning and manual dependency management

Avoid it when:

• You need atomic versioning across skills
• You require observability and tracing across tool calls
• You need security boundaries between skills and tools
• You want a central package registry with semver resolution

The standard is young. It solves cross-agent portability but punts on versioning, observability, and security. Stitch Skills is a reference implementation, not a production-ready framework.

Technical Verdict

The Agent Skills standard is a useful abstraction layer above MCP tools. It defines a clear boundary between primitives and workflows and provides a distribution format that works across multiple agents.

Stitch Skills demonstrates that cross-agent portability is possible, but the plumbing reveals gaps. Git-based distribution is simple but fragile. Metadata requirements differ across agents. Observability and security are undefined.

Use this if you are building internal workflows for a team that uses multiple coding agents. Avoid it if you need production-grade versioning, tracing, or security boundaries. The standard will mature, but right now it is a proof of concept with real adoption.

Source Links

• Stitch Skills Repository
• Agent Skills Standard