Core Concepts

syllago manages AI coding tool content across multiple providers. This page covers the four concepts you need to understand how everything fits together: providers, content types, collections, and format conversion.

Providers

A provider is an AI coding tool that syllago supports. Each provider has its own file format and stores content in different locations on your system. syllago handles these differences automatically — you work with one set of content, and syllago adapts it to each provider’s requirements.

syllago supports the following providers:

Provider	Description
Claude Code	Anthropic’s CLI agent
Gemini CLI	Google’s CLI agent
Cursor	AI-powered code editor
Copilot CLI	GitHub’s CLI agent
Codex	OpenAI’s CLI agent
Kiro	AWS AI IDE
Windsurf	AI-powered code editor
OpenCode	Terminal-based AI agent
Roo Code	VS Code extension
Cline	VS Code extension
Amp	AI coding assistant
Zed	Editor with AI assistant

syllago auto-detects which providers are installed on your system. You don’t need to configure them manually.

For details on each provider’s capabilities and file locations, see Supported Providers.

Content Types

syllago manages six kinds of content:

Content Type	What it is
Rules	System prompts and custom instructions
Skills	Multi-file workflow packages
Agents	AI agent definitions and personas
MCP Configs	MCP server configurations
Hooks	Event-driven automation scripts
Commands	Custom slash commands

Not every provider supports every content type. For example, some providers have no concept of hooks, and others don’t support slash commands. syllago tracks the support matrix so you know what will work where.

For the full compatibility matrix and details on each type, see Content Types.

Collections

Content in syllago is organized into three collections, each serving a different purpose:

Library

Your personal content store, located at ~/.syllago/content/. This is read-write — it’s where your content lives.

Content arrives in the library when you add it from a provider:

syllago add --from <provider>     # pull content from an installed provider

Registries

Git-based repositories of shared content. A registry lets a team (or the community) publish and maintain a collection of rules, skills, agents, and other content that anyone can consume locally.

You add a registry to your system, sync it to pull updates, and browse its items:

syllago registry add <url>
syllago registry sync
syllago registry items <name>

When you’ve created content locally that you want to share back, you can publish it to a registry — syllago opens a PR against the registry repo:

syllago publish my-skill --registry team-registry

Or share directly with your team repo:

syllago share my-skill

Loadouts

A loadout is a bundled set of content that applies as a unit. Think of it as a named configuration profile — “my Python stack,” “frontend review setup,” or “security audit kit.”

syllago loadout create <name>      # define a loadout
syllago loadout apply <name>       # preview what would happen (default)
syllago loadout apply <name> --try # apply temporarily, auto-reverts on session end
syllago loadout apply <name> --keep # apply permanently
syllago loadout remove             # revert and clean up

Loadouts apply and revert cleanly, so you can switch contexts without leaving stale content behind.

For more on how these three collections work together, see Collections.

Format Conversion

This is the mechanism that makes everything else work. syllago uses a hub-and-spoke model for format conversion:

Source Provider  ──→  syllago format  ──→  Target Provider

syllago format is a provider-neutral representation of content. It’s the internal format syllago uses to store everything in your library, registries, and loadouts.

The conversion flow works in two directions:

Inbound — When you syllago add content from a provider, syllago reads the provider’s native format and converts it to syllago format for storage.
Outbound — When you install content to a provider (or convert it for sharing), syllago converts from syllago format to the provider’s native format.

This hub-and-spoke design means you add content once and install it anywhere. A rule written for Claude Code can be installed into Cursor, Windsurf, or any other supported provider — syllago handles the format translation automatically.

For implementation details, see Format Conversion.

These four concepts — providers as the tools you target, content types as the things you manage, collections as how content is organized, and format conversion as the translation layer — form the complete mental model for syllago. Every command in the CLI maps to an operation on one of these concepts.