---
title: "Skill compatibility with providers"
description: "Why some skills only work with some providers, the skill-preflight gate, and how to fix incompatibility errors."
slug: guides/working-with-skills/skill-compatibility-with-providers
section: guides
subsection: working-with-skills
canonical_url: https://cerevisor.com/docs/guides/working-with-skills/skill-compatibility-with-providers
last_verified: 2026-05-18
last_verified_version: "1.2.0"
updated_at: 2026-05-18T15:08:18.053416+00:00
---

Most skills are **universal**; they work with any provider Cerevisor supports. But some skills are tied to specific providers because they rely on a feature only that provider has.

## The skill-preflight gate

Before any workflow runs, Cerevisor's **skill-preflight** check validates two things for every assigned skill:

1. **Existence**: the skill is present in your scanned skill folders.
2. **Compatibility**: the skill is compatible with the resolved provider for each agent that uses it.

If either check fails, the workflow won't start. The Execution Modal shows the specific agent + skill + provider combination that's broken, with a suggested fix (usually: switch the agent's provider, or remove the incompatible skill).

## Common incompatibilities

Most skills work everywhere. The ones that don't usually fall into these patterns:

### Skills using provider-specific tools

Skills that call out to provider-native tools (e.g. Anthropic's prompt caching, OpenAI's structured outputs) will be flagged as incompatible with providers that don't expose those tools.

### Skills using sub-agent spawning

Skills that internally use Cerevisor's `spawn_subagent` tool only work with providers that have a chat API, so they're flagged as incompatible with **Codex CLI** and **Cursor Agent** (both delegate to their own agent runtimes and don't expose `.chat()`).

### Skills calling external CLIs

A few skills shell out to external CLIs. If the CLI isn't installed on your machine, the skill will fail at runtime, preflight catches this for the common ones (it doesn't catch every possible CLI).

## How compatibility is declared

A skill can declare compatibility hints in its `SKILL.md` frontmatter:

```yaml
---
name: my-skill
description: ...
providers: ["anthropic", "openai-compatible"]
---
```

If the `providers` field is present, only those provider types are considered compatible. If absent, the skill is assumed universal.

The default seeded compatibility table inside Cerevisor covers the most common skills (docx, pptx, xlsx, recency-research, etc.); these are universally compatible. Custom skills you create in the Workshop default to universal unless you add the `providers:` field.

## Fixing an incompatibility

When preflight blocks a run, you have three options:

### 1. Switch the agent's provider

Open the agent's config, change the **Provider** chip to one that's compatible. Run again.

### 2. Remove the skill

If the skill isn't critical, remove it from the agent. Run again.

### 3. Update the skill's compatibility

If you're sure the skill should work with the provider being used (e.g. you're testing a skill against a new provider), edit the skill's `SKILL.md` frontmatter to add the provider to `providers:`.

## Mixing providers within one workflow

This is one of the main reasons Cerevisor lets you set a per-agent provider override. A workflow might have:

- A **research** agent on Anthropic Sonnet (great at long-form synthesis).
- A **writing** agent on a local Ollama model (private, free, good enough).
- A **publishing** agent on Anthropic Haiku (cheap, fast, one-shot task).

The skill-preflight gate runs per-agent, so the workflow runs successfully as long as each agent's assigned skills are compatible with *that agent's* provider.

## When in doubt

Read the skill's `description` in the Skill Viewer. Skills tied to a specific provider usually mention it in the description. If you can't tell from the description, try it, preflight will catch any compatibility issue cleanly before tokens are spent.