Skip to content llms.txt

Format Conversion

Syllago uses a hub-and-spoke model. Content in your library is stored in syllago format — a provider-neutral representation that syllago converts to and from each provider’s native format:

Source Provider -> syllago format -> Target Provider

When you run syllago install my-skill --to cursor or syllago convert my-rule --to windsurf, syllago:

  1. Reads the content from your library (already in syllago format)
  2. Converts to the target provider’s format
  3. Translates tool names, metadata, and frontmatter automatically
Content TypeCoverageNotes
RulesEvery providerFormat varies (Markdown, MDC) but content fully preserved
SkillsMost providersMetadata rendering varies by provider capability
AgentsMost providersCodex uses TOML format, Kiro uses Markdown with YAML frontmatter (auto-converted)
MCP configsEvery providerZed uses context_servers key (handled automatically)
HooksMany providersClaude Code, Gemini CLI, Copilot CLI, Cursor, Windsurf, Codex, Cline, Kiro
CommandsMany providersClaude Code, Gemini CLI, Cursor, Copilot CLI, Codex, OpenCode
LoadoutsClaude Code (v1)Additional provider emitters planned

Rules are converted to MDC (Markdown Component) format with .mdc extension. Frontmatter fields map to MDC metadata headers.

Agent definitions use TOML format. Syllago auto-converts between TOML and Markdown frontmatter.

Agent definitions use Markdown with YAML frontmatter (14 fields). Also supports a JSON CLI agent format with embedded MCP servers and lifecycle hooks. Rules and skills are Markdown steering files.

Rules use AGENTS.md format with globs array frontmatter. MCP configs use a provider-specific JSON key.

MCP server configs use the context_servers key instead of mcpServers. Syllago handles this mapping automatically.

Rules use YAML format. Syllago strips Markdown frontmatter and converts to OpenCode’s YAML structure.

  • Content body — always preserved in full
  • Metadata — mapped to provider-equivalent fields where possible
  • Tool names — automatically translated (e.g., Claude Code’s Read becomes Gemini’s read_file)
  • Frontmatter — converted to provider-appropriate format (YAML, TOML, JSON, or embedded as prose)

When metadata can’t be represented in the target format, it’s either embedded as a comment or note in the content body, or reported as a portability warning during conversion.

Both syllago convert and syllago install surface warnings when content uses features unsupported by the target provider. Warnings appear inline in text mode and in the warnings array in JSON mode.

Common warnings include:

  • Unsupported hook events (e.g., Gemini’s before_model has no Claude Code equivalent)
  • Missing capability support (e.g., input_rewrite not available on target)
  • Fields dropped during conversion (e.g., disabledTools on MCP servers)

The canonical format uses provider-neutral tool names:

CanonicalClaude CodeGemini CLICursor
file_readReadread_fileread_file
file_writeWritewrite_fileedit_file
file_editEditreplaceedit_file
shellBashrun_shell_commandrun_terminal_cmd
searchGrepgrep_searchgrep_search
findGlobglobfile_search
web_fetchWebFetchweb_fetch
agentAgent

Translation happens automatically during conversion. You never need to manually adjust tool names.

Terminal window
# Convert a specific item to stdout
syllago convert my-skill --to gemini-cli
# Save to a file
syllago convert my-rule --to windsurf --output ./windsurf-rule.md
# JSON output with portability warnings
syllago convert my-skill --to cursor --json
# Check compatibility across all providers
syllago compat my-skill

For hooks specifically, syllago uses the Hook Interchange Format as the canonical representation. This handles:

  • Event name translation between providers
  • Matcher type conversion (tool vocabulary, regex, MCP targeting)
  • Timeout unit normalization (seconds canonical, auto-converts to/from milliseconds)
  • Capability degradation (block, warn, or exclude based on target support)