Skip to contentllms.txt

Why syllago

If you’ve worked with more than one AI coding tool, you’ve felt this: each one wants its rules, skills, and configuration in a slightly different place, in a slightly different format. None of them know about the others. Sharing context across them is manual, fragile, and easy to get wrong.

Syllago exists to fix that.

The fragmentation problem

Section titled “The fragmentation problem”

A typical workflow today might involve Claude Code in the terminal, Cursor as the IDE, and Copilot CLI for shell commands. Each describes the same thing differently:

ToolRules go in…Skills go in…
Claude CodeCLAUDE.md, .claude/.claude/skills/
Cursor.cursorrules, .cursor/rules/*.mdc(no native equivalent)
Windsurf.windsurfrules, .windsurf/rules/.windsurf/workflows/
Copilot CLI.github/copilot-instructions.md(no native equivalent)
Kiro.kiro/steering/(no native equivalent)

Add Roo Code, Cline, Amp, Gemini CLI, Codex, OpenCode, Zed, Factory Droid, Crush, and Pi, and the table grows in every dimension. MCP servers compound it — each client wires them up its own way.

Without a manager, every team that uses more than one tool ends up with the same workarounds: shell scripts that copy files between locations, README sections explaining where to paste which thing, configuration drift between teammates who use different tools, broken toolchains when a provider renames a directory.

What syllago does

Section titled “What syllago does”

Syllago is a content manager for AI coding tools — think apt, brew, or npm, but for AI-assistant configuration. You maintain one canonical copy of each item. Syllago layers three things on top:

  1. Conversion. When you install a skill to Cursor, syllago translates it into a Cursor-compatible rule. The same skill installed to Kiro becomes a steering file. Intent carries forward; format adapts. See Format Conversion.
  2. Compatibility checking. syllago compat reports which providers can fully consume an item and where features will degrade in translation, so you know before you publish.
  3. Distribution. Git-based registries let you publish org-wide standards and pull updates with one command. Loadouts bundle related items so you apply a whole stack as a unit and revert it cleanly.

What you actually manage

Section titled “What you actually manage”

Syllago breaks AI-tool configuration into a small set of tool-agnostic primitives:

  • Rules — Markdown instructions governing style, architecture, and behavior.
  • Skills — Multi-file workflow packages the AI can call to perform actions.
  • Agents — Persona and steering definitions for the model.
  • MCP Configs — Provider-agnostic settings for Model Context Protocol servers.
  • Hooks — Event listeners that trigger behavior on local events.
  • Commands — Custom slash commands.

You define each item once. Syllago decides what to do with it on each provider.

Is syllago right for you?

Section titled “Is syllago right for you?”

Not every setup needs a content manager. Here’s the honest comparison.

Compared to maintaining files by hand

Section titled “Compared to maintaining files by hand”

Manual maintenance is fine — genuinely — if you use one AI tool, or two tools with a handful of rules that rarely change. Copying a file twice a month is not a problem worth new tooling.

The cost curve bends as tools and teammates multiply. Every copy is a chance to drift: you fix a rule in Claude Code and forget the Cursor version, a provider renames its config directory and your shell script silently writes to the old one, two teammates “share” a rule that diverged three edits ago. Syllago replaces N copies with one canonical item plus conversion, so an edit lands everywhere and syllago compat tells you where translation will degrade.

Rule of thumb: one tool, skip syllago. Two tools and light usage, either works. Three or more tools, or any team sharing, and a manager pays for itself.

Compared to rulesync

Section titled “Compared to rulesync”

rulesync is the main alternative, and it’s a good tool — mature, actively maintained, and supporting a substantially longer list of AI tools than syllago (40+ versus syllago’s 15). If provider coverage is your deciding factor, check both support lists before choosing.

The real difference is the model:

  • rulesync is a generator. You keep unified source files in a .rulesync/ directory, typically committed to each repo, and run rulesync generate to write the tool-specific configs. It also imports existing configs and converts between tools. Sharing happens through whatever you use to share the repo.
  • syllago is a package manager. You keep items in a library, install them to providers (symlinked by default, so library edits propagate without a regenerate step), distribute them through git registries, switch between sets with loadouts, and verify registry content with MOAT signing.

Choose rulesync if you want per-repo, committed, CI-regenerable configs with maximal tool coverage and an npm-based workflow. Choose syllago if you want a personal or team library that outlives any single repo, first-class distribution and trust for shared content, and installs that stay live without a build step.

When not to use syllago

Section titled “When not to use syllago”
  • You use one AI tool. Its native config format is simpler and better documented than any abstraction over it.
  • Your whole team is standardized on a single tool. Share the native files in a repo and move on.
  • Your provider isn’t supported. Check the provider matrix first; if your daily tool isn’t on it, syllago can’t help you yet.
  • You need configs generated in CI as repo artifacts. Syllago’s library-and-install model is machine-local; a generator like rulesync fits that pipeline more naturally.
  • You need API stability today. Syllago is pre-1.0. Commands and formats are settling, but breaking changes still happen between releases.

Where to go next

Section titled “Where to go next”