syllago

Convert, bundle, and share AI coding tool content across providers.

Why Syllago?

AI coding tools like Claude Code, Cursor, Gemini CLI, Copilot, and Amp each store rules, skills, agents, and configurations in their own format. Switching tools -- or rolling out configurations across a team -- means manual copy-pasting and format translation. Syllago automates that: add content once, install it anywhere, and organize it into shareable collections called loadouts.

• Portable content -- Add from one tool, install to another. Syllago canonicalizes everything into its own intermediate format, then converts to the target provider's native format automatically.
• Shared configurations -- Distribute AI tool content through git-based registries. Push updates once, and your team syncs automatically.
• Governed distribution -- Use privacy gates to keep internal content out of public registries. Evaluate untrusted hooks and MCP configs in sandbox isolation before they run. Pipe --json output into your CI pipelines and audit workflows.
• One library -- Your content lives in a single, provider-neutral library. No duplication across tools, no drift between copies.

For a deeper introduction, see the documentation site.

Prerequisites

• OS: Linux, macOS, or Windows (native via MSYS2/Git Bash, or WSL)
• Git: Required for registry operations and content sharing
• Go 1.25+: Only required for go install or building from source

Installation

Homebrew (macOS)

brew tap OpenScribbler/tap
brew install syllago

Install script (Linux, macOS, Windows)

curl -fsSL https://raw.githubusercontent.com/OpenScribbler/syllago/main/install.sh | sh

Downloads the latest release binary, verifies the SHA-256 checksum, and installs to ~/.local/bin. Override the install location with INSTALL_DIR:

INSTALL_DIR=/usr/local/bin sh install.sh

go install

go install github.com/OpenScribbler/syllago/cli/cmd/syllago@latest

From source

git clone https://github.com/OpenScribbler/syllago.git
cd syllago
make setup    # configure git hooks (gofmt pre-commit check)
make build

Quick Start

Scenario: You have Claude Code rules and skills you want to use in Cursor and Gemini CLI.

# Step 1: Initialize your syllago content repository (first time only)
syllago init

# Step 2: See what content Claude Code has
syllago add --from claude-code
# Discovered content from Claude Code:
#   Rules (3): my-coding-rules, typescript-standards, security-policy
#   Skills (2): research-skill, code-review
#   ...

# Step 3: Add all of it to your syllago library
syllago add --all --from claude-code

# Step 4: Install a rule to Cursor (auto-converts to .mdc format)
syllago install my-coding-rules --to cursor

# Step 5: Install a skill to Gemini CLI (auto-converts to Gemini's SKILL.md format)
syllago install research-skill --to gemini-cli

Or skip the CLI and browse everything interactively:

syllago   # launches the TUI

How It Works

Syllago uses a hub-and-spoke conversion model. When you add content from a provider, syllago converts it into its own canonical format -- a provider-neutral intermediate representation. When you install that content to a different provider, syllago converts from canonical to the target's native format. This means adding support for a new provider only requires two conversions (to/from canonical), not N-to-N mappings between every provider pair.

Specification files define how each content type looks in canonical form. See the canonical keys reference for details.

The library

Everything you add goes into your library (~/.syllago/content/). Your library is your single source of truth -- provider-neutral, deduplicated, and ready to install to any supported provider.

Commands

Syllago's CLI is organized around a content lifecycle:

For the full command reference, see syllago.dev/using-syllago/cli-reference/.

Supported Providers

Run syllago info providers to see this matrix for the version of syllago you have installed.

Content Types

Use syllago compat <item> to see which providers support a specific content item and what changes during conversion.

For the full provider-by-content-type matrix, see Compare providers.

Conversion Example

Syllago handles provider-specific format differences automatically. For example, a Cursor rule (.mdc) becomes a Claude Code rule (.md):

# Input (Cursor)                    # Output (Claude Code)
---                                 ---
description: TS conventions         paths:
alwaysApply: false                      - '*.ts'
globs: "*.ts, *.tsx"                    - '*.tsx'
---                                 ---

Use strict TypeScript.              Use strict TypeScript.

Cursor uses globs as a comma-separated string with alwaysApply. Claude Code uses a paths YAML array. The body content passes through unchanged.

Try it yourself: syllago convert ./my-rule.mdc --from cursor --to claude-code

For more conversion walkthroughs across providers (Windsurf, Copilot, Codex, Kiro, etc.), see Format conversion.

Collections

Collections let you organize and distribute content beyond individual items.

Library

Your library (~/.syllago/content/) stores everything you've added in syllago's canonical format. Install any item to any supported provider from here. The library lives locally on your machine.

Loadouts

A loadout bundles multiple content items and applies them as a unit. Package a complete AI tool setup (rules + skills + hooks + MCP configs) for a specific workflow or role. Pass --try to preview a loadout temporarily -- syllago auto-reverts when you're done.

Registries

A registry is a git repository that distributes syllago content. Push curated configurations to a registry; your team picks them up with syllago registry sync (refreshes the registry index) and syllago refresh (applies content updates to the local library). Mark registries as public or private — syllago's privacy gates block content from private registries from reaching public ones. Sign your registry and content with MOAT so consumers can verify provenance, not just retrieve files.

Features

• Cross-provider conversion — Add content from one tool, install to another. Syllago handles format differences (Cursor's .mdc, Codex's TOML, Kiro's JSON, Amp's AGENTS.md, etc.)
• Interactive TUI — Browse, search, install, and manage content with card grids, mouse support, and keyboard navigation
• Verifiable trust (MOAT) — Signed registries and signed publisher content using Sigstore + Rekor. Configurable trust tiers (Unsigned / Signed / Dual-Attested) with install-gate enforcement. See Trust and Supply Chain.
• Sandbox — Run AI CLI tools in isolated environments with filesystem, network, and environment filtering (Linux)
• Registry privacy — Syllago detects content from private registries and blocks it from reaching public ones
• --json output — Pipe any command's output into scripts, CI pipelines, or other automation

Trust and Supply Chain

AI tool content runs as code: hooks execute on every tool call, MCP servers shell out to external programs, and rules steer the model itself. When that content travels through git registries, "I trust the publisher" needs to be more than a vibe. Syllago implements MOAT — Model for Origin, Attestation, and Trust — to make registry and content integrity verifiable end-to-end.

The MOAT specification is community-owned and lives at github.com/OpenScribbler/moat. Syllago is the reference implementation.

Two layers of attestation

Signed registries. Each registry has a pinned signing identity bound to its source repository's GitHub OIDC numeric ID, not a mutable repo path. Renaming or transferring a registry repo to a different owner does not transfer its trust — the pinned identity won't match, and syllago registry sync blocks the update. New registries pin via TOFU on first add, or via a bundled allowlist for well-known operators.

Signed publisher content. Individual content items are signed by their publishers using Sigstore keyless signing — short-lived Fulcio certificates issued from OIDC identities (typically a GitHub Actions workflow), with the signature recorded in the Rekor transparency log. There are no long-lived keys to rotate or protect; revocation is verifiable through transparency-log lookups.

Trust tiers

The install gate enforces a configurable minimum tier. CI pipelines get specific exit codes for missing signatures, identity mismatches, and Rekor revocations so failures are unambiguous.

Operator commands

syllago moat trust status                     # show trusted root + per-registry identities
syllago registry add <url>                    # pin signing identity (TOFU or allowlist)
syllago registry add <url> --signing-identity # explicit identity for custom registries
syllago registry sync                         # verify signatures, refuse mismatched updates

Detailed walkthroughs: MOAT overview, Trust tiers, Pinning a signing identity.

Other supply-chain practices

• Signed syllago releases — release binaries signed with cosign keyless. Verify with cosign verify-blob --bundle checksums.txt.bundle checksums.txt.
• SHA-256 checksums — checksums.txt ships with every release.
• Pinned CI dependencies — all GitHub Actions pinned to full-length commit SHAs.
• Automated vulnerability scanning — govulncheck runs in CI; Dependabot patches dependency CVEs.
• Registry privacy gates — content tagged from a private registry is blocked from reaching a public one.
• Sandbox isolation — syllago sandbox run executes AI CLI tools inside bubblewrap with filesystem, network, and environment filtering (Linux).

See SECURITY.md for the full security policy, threat model, and how to report vulnerabilities.

CLI Reference

The lifecycle table at Commands covers the everyday verbs (add, install, convert, share). Beyond those, syllago ships commands for trust verification (moat), registry updates (refresh), inspection (inspect, list, compat, info, doctor), automation (sync-install), and more.

For the full command reference with flags, examples, and exit codes, see syllago.dev/using-syllago/cli-reference/. Every command has its own page; subcommands (e.g. loadout apply, registry sync, sandbox run) are documented individually.

You can also list every command locally:

syllago --help                  # top-level commands
syllago <command> --help        # flags and examples for any command

Global flags

--json        Output in JSON format
--no-color    Disable color output
-q, --quiet   Suppress non-essential output
-v, --verbose Verbose output

Interactive TUI

Run syllago with no arguments to launch the terminal UI. It supports keyboard navigation, mouse interaction (click cards, tabs, breadcrumbs, and modal buttons), live search (/), and contextual help (?).

For the full keyboard reference, see The TUI.

Configuration

Syllago uses two config files: ~/.syllago/config.json (global defaults) and .syllago/config.json (per-project). Run syllago init for first-time setup — the wizard handles provider selection and registry setup. Override default provider paths with syllago config paths.

For full configuration reference, see syllago config and Core concepts.

Accessibility

Every operation works through CLI commands with --json output for scripting and assistive technology. The TUI uses ANSI rendering; if you use a screen reader, we recommend running CLI commands directly. Disable colors with NO_COLOR=1 or --no-color. We're exploring a screen-reader-compatible TUI mode -- feedback welcome.

Telemetry

Syllago collects anonymous usage data (command names, exit codes, provider/content-type counts — no file contents, names, paths, or registry URLs) to help prioritize work. It's opt-out, not opt-in. Disable with syllago telemetry off. Full details, the property catalog, and deletion process: syllago.dev/telemetry and syllago telemetry status.

Roadmap

Recent and upcoming work:

• Privacy and integrity — registry privacy gates, content integrity hashes, audit trail (done)
• MOAT trust model — signed registries, signed publisher content, trust tiers (done)
• Distribution — bulk install, add --from shared, provider-to-provider conversion, SBOM (done)
• Platform — syllago doctor, enhanced syllago info, dependency review CI (done)
• Security — hook signing and verification, script scanning, policy engine (next)
• Multi-provider loadouts — define once, install to every detected agent or a specific list (next)
• Providers — VS Code Copilot, Qwen Code, Kimi CLI, Trae Agent, and more
• Specs — formal specs for all canonical formats (hooks spec is drafted)

See ROADMAP.md for the full roadmap with status tracking.

Contributing

We welcome ideas, bug reports, and feature suggestions -- open an issue to get started. We accept pull requests from vouched contributors. See CONTRIBUTING.md for details on how to get involved.

License

Apache 2.0 -- see LICENSE for full text.