This is the full developer documentation for syllago
# Welcome to syllago
> The content manager for AI coding tools.
[Source](/)
[Installation ](/getting-started/installation.md)Install syllago and set up your first project.
[Quick Start ](/getting-started/quick-start.md)Get up and running in under 5 minutes.
[CLI Reference ](/using-syllago/cli-reference.md)Full reference for every syllago command.
[Supported Providers ](/using-syllago/providers.md)See every supported AI coding tool.
# Registry Privacy
> How syllago prevents accidental leakage of content from private registries to public destinations.
[Source](/advanced/registry-privacy/)
Syllago includes a privacy gate system to prevent accidental leakage of content from private registries to public destinations. This is a soft gate — it prevents mistakes, not intentional circumvention.
## How it works
The privacy gate operates in four layers:
### 1. Detection
When you add a registry, syllago determines its visibility:
* **API probes**: Checks GitHub, GitLab, or Bitbucket APIs for the repository’s privacy status
* **Manifest field**: An optional `visibility` field in `registry.yaml` provides explicit control
* **Default**: Unknown visibility defaults to **private** (safe default)
### 2. Tainting
Content imported from private registries receives permanent metadata:
```yaml
source_registry: my-private-registry
source_visibility: private
```
These fields persist through the content’s entire lifecycle in your library. They are not removed by editing, re-importing from a different path, or any other library operation.
### 3. Enforcement (four gates)
| Gate | Command | Behavior |
| ---- | ------------------------------- | ---------------------------------------------------------------------- |
| G1 | `syllago share --to ` | **Blocks** sharing tainted content to public registries |
| G2 | `syllago share` | **Blocks** sharing tainted content to public team repos |
| G3 | `syllago loadout create` | **Warns** when loadout contains private items |
| G4 | `syllago loadout publish` | **Blocks** publishing loadouts with private items to public registries |
The `sync-and-export` command also warns when installing private-tainted content.
### 4. Scope
Soft Gate
The privacy gate prevents accidental leakage through syllago commands. It does **not** prevent:
* Direct filesystem operations (copy/paste)
* Direct git commands
* Content modification after export
There is no override flag by design. To remove the taint, re-add the content from a public source.
## Removing taint
The only way to remove privacy taint is to re-add the content from a public source:
```bash
# Remove the tainted version
syllago remove my-private-skill
# Re-add from a public registry or provider
syllago add skills/my-skill --from claude-code
```
## Team workflows
### Private team registry
If your team uses a private registry for internal content:
1. Content added from the private registry is automatically tainted
2. Team members can freely install tainted content to their providers
3. Tainted content cannot be accidentally published to public registries
4. To share content publicly, create it fresh or re-add from a public source
### Mixed public/private
If you use both public and private registries:
```bash
# Check which registries are private
syllago registry list
# Inspect an item's taint status
syllago inspect my-skill --json | jq '.source_visibility'
```
## See also
* [Registries](/using-syllago/collections/registries.md) — managing git-based registries
* `syllago share` — contributing to registries or team repos
* [Team Setup](/advanced/team-setup.md) — configuring syllago for team use
# Sandbox
> Run AI CLI tools in bubblewrap isolation with filesystem, network, and environment variable filtering.
[Source](/advanced/sandbox/)
The sandbox runs AI CLI tools inside a [bubblewrap](https://github.com/containers/bubblewrap) (bwrap) container that restricts filesystem access, network egress, and environment variables. When an AI tool executes code — installing packages, running scripts, making API calls — the sandbox limits what that code can reach.
Linux only. macOS and Windows are not supported.
## What gets sandboxed
The sandbox enforces three boundaries:
**Filesystem.** The sandboxed process can only see your current working directory. The rest of the filesystem is hidden. This prevents AI-generated code from reading or modifying files outside the project.
**Network.** Outbound connections are blocked by default. You explicitly allow specific domains (for API calls) and localhost ports (for local dev servers). Everything else is denied.
**Environment variables.** Only env vars you explicitly allow are passed into the sandbox. API keys, tokens, and other secrets in your shell environment stay outside unless you opt them in.
## Prerequisites
Two system packages must be installed:
* **bubblewrap** (`bwrap`) >= 0.4.0 — the container runtime
* **socat** >= 1.7.0 — used for network proxying through the sandbox boundary
Install them with your system package manager:
```bash
# Debian / Ubuntu
sudo apt install bubblewrap socat
# Fedora
sudo dnf install bubblewrap socat
# Arch
sudo pacman -S bubblewrap socat
```
Verify everything is ready:
```bash
syllago sandbox check
```
To also verify that a specific provider works inside the sandbox:
```bash
syllago sandbox check claude-code
```
## Running a provider in the sandbox
Once prerequisites are in place, run any provider inside the sandbox:
```bash
syllago sandbox run claude-code
```
This starts the provider with filesystem, network, and env var restrictions active. The provider works normally from the user’s perspective, but its access is constrained to what you’ve allowed.
### One-off overrides
You can extend the sandbox for a single session without changing your saved configuration:
```bash
# Allow an extra domain for this session only
syllago sandbox run claude-code --allow-domain api.example.com
# Forward an extra env var into the sandbox
syllago sandbox run claude-code --allow-env MY_API_KEY
# Allow a localhost port (e.g., a local dev server)
syllago sandbox run claude-code --allow-port 3000
# Mount an additional path read-only
syllago sandbox run claude-code --mount-ro /usr/share/dict
# Block all network (no proxy at all)
syllago sandbox run claude-code --no-network
```
These flags can be combined and repeated.
## Configuring allowed access
The sandbox maintains persistent allowlists for domains, ports, and env vars. These apply every time you run `sandbox run`.
### Domains
Domains control which hosts the sandboxed process can reach over the network.
```bash
# Allow a domain
syllago sandbox allow-domain api.anthropic.com
# Remove a domain
syllago sandbox deny-domain api.anthropic.com
# List all allowed domains
syllago sandbox domains
```
### Localhost ports
Ports control which localhost services are reachable from inside the sandbox. Useful for local dev servers, databases, or other services running on your machine.
```bash
# Allow a port
syllago sandbox allow-port 8080
# Remove a port
syllago sandbox deny-port 8080
# List all allowed ports
syllago sandbox ports
```
### Environment variables
Env vars control which shell variables are passed into the sandbox. By default, none are forwarded — the sandbox starts with a clean environment.
```bash
# Allow an env var
syllago sandbox allow-env ANTHROPIC_API_KEY
# Remove an env var
syllago sandbox deny-env ANTHROPIC_API_KEY
# List all allowed env vars
syllago sandbox env
```
## Inspecting the configuration
To see the effective sandbox configuration (all allowed domains, ports, and env vars):
```bash
syllago sandbox info
```
To see the configuration that would apply to a specific provider:
```bash
syllago sandbox info claude-code
```
## Typical setup
A practical setup for using Claude Code in the sandbox:
```bash
# 1. Check prerequisites
syllago sandbox check claude-code
# 2. Allow the API endpoint
syllago sandbox allow-domain api.anthropic.com
# 3. Pass through the API key
syllago sandbox allow-env ANTHROPIC_API_KEY
# 4. Allow a local dev server if needed
syllago sandbox allow-port 3000
# 5. Run it
syllago sandbox run claude-code
```
After initial setup, step 5 is the only one you repeat. The allowlists persist across sessions.
## Related
* [CLI reference: sandbox commands](/using-syllago/cli-reference/sandbox.md) — full flag and option details for all sandbox subcommands
* [CLI reference: sandbox run](/using-syllago/cli-reference/sandbox-run.md) — all flags for `sandbox run`
* [CLI reference: sandbox check](/using-syllago/cli-reference/sandbox-check.md) — prerequisite verification
# Team Setup
> Share and standardize AI coding tool configurations across your team with syllago.
[Source](/advanced/team-setup/)
Teams use syllago to maintain consistent AI coding tool configurations — shared rules, skills, agents, and provider settings — without manual setup on each developer’s machine. The core workflow centers on registries for distribution, loadouts for onboarding, and project-level config for per-repo settings.
## Team registry
A [registry](/using-syllago/collections/registries.md) is a git repo that holds shared syllago content. This is the primary mechanism for distributing team standards.
### Setting up a team registry
1. Create a git repo (GitHub, GitLab, etc.)
2. Add syllago content — rules, skills, agents, hooks, MCP configs — following the standard directory layout
3. Push to your git host
4. Share the URL with your team
There is no special initialization or registry-specific metadata. Any git repo with syllago’s content structure works as a registry.
### Team members subscribe
Each team member adds the registry once:
```bash
syllago registry add https://github.com/your-org/syllago-registry.git
```
To pin everyone to a stable release:
```bash
syllago registry add https://github.com/your-org/syllago-registry.git --ref v1.0
```
### Staying up to date
Sync periodically to pull the latest content:
```bash
syllago registry sync
```
Syncing updates the local clone only — it does not modify anyone’s library or installed content. Team members choose when to pull updates into their own setup, keeping the workflow predictable.
## Contributing back
Registries are not read-only. When a team member creates content that belongs in the shared registry, they contribute it via PR:
```bash
syllago share useful-skill --to your-registry
```
This creates a branch in the registry clone, copies the content, commits, pushes, and opens a pull request if the `gh` CLI is installed. The registry maintainer reviews and merges through the normal PR workflow — no special tooling required on their end.
`syllago share` also works for arbitrary team repos that aren’t structured as registries — drop the `--to` flag and configure a default team repo target.
This means team standards can evolve from the bottom up. Individual developers experiment locally, and the best content gets published to the shared registry for everyone.
## Loadouts for onboarding
A [loadout](/using-syllago/collections/loadouts.md) bundles multiple content items into a single apply-as-a-unit configuration. For team onboarding, this turns a multi-step manual setup into one command.
### Creating a team loadout
A team lead or maintainer creates the loadout:
```bash
syllago loadout create team-standards
```
The interactive creator walks through selecting which content items to include — team rules, shared skills, standard MCP configs, etc.
### New member onboarding
A new team member’s setup becomes:
```bash
# 1. Add the team registry
syllago registry add https://github.com/your-org/syllago-registry.git
# 2. Sync to pull content
syllago registry sync
# 3. Apply the team loadout
syllago loadout apply team-standards --keep
```
The `--keep` flag writes the configuration permanently. Three commands replace what would otherwise be a checklist of individual content installations and provider configurations.
### Verifying the setup
After applying, team members can confirm what is active:
```bash
syllago loadout status
```
## Project-level config
Running `syllago init` in a project root creates `.syllago/config.json` with project-specific provider settings:
```bash
cd your-project
syllago init
```
Syllago detects which AI coding tools are in use and writes the config accordingly. Commit `.syllago/config.json` to the repo so all team members share the same provider settings without manual configuration.
This is separate from registry content. The registry holds the **what** (rules, skills, agents). The project config holds the **where** (which providers to target for this repo).
## CI/CD integration
Use `syllago sync-and-export` or `syllago install` in CI pipelines to automate content distribution. The `--json` flag produces machine-readable output suitable for scripting:
```bash
syllago install --to claude-code --json
```
Examples of CI use cases:
```bash
# Install all skills to a specific provider
syllago install --to cursor --type skills --json
# Sync registries and install in one step
syllago sync-and-export --to claude-code --json
# Install only rules
syllago install --to claude-code --type rules --json
```
This lets you enforce that project repos always have up-to-date provider configurations — for example, regenerating provider configuration files on every PR merge or as part of a dev environment setup script.
## Putting it together
A typical team workflow combines all of these:
```plaintext
Team registry (git repo)
├── Rules, skills, agents, hooks
├── Team members sync periodically
└── Contributors promote content via PR
Loadout (team-standards)
├── Bundles registry content
└── New members apply in one command
Project config (.syllago/config.json)
├── Committed to each repo
└── Sets provider targets per project
CI pipeline
└── Exports content on merge/deploy
```
The registry is the source of truth. Loadouts make it easy to apply. Project config ties it to specific repos. CI keeps everything in sync automatically.
## Related
* [Registries](/using-syllago/collections/registries.md) — full reference on adding, syncing, and browsing registries
* [Loadouts](/using-syllago/collections/loadouts.md) — creating, applying, and managing loadouts
* [`syllago init`](/using-syllago/cli-reference/init.md) — project initialization
* `syllago install` — installing content to providers
* `syllago share` — contributing content to a registry or team repo
# Troubleshooting
> Common issues, debug tools, and where to get help with syllago.
[Source](/advanced/troubleshooting/)
## Debug flags
syllago provides several flags to help diagnose problems. These work with any command.
| Flag | Description |
| ------------------ | -------------------------------------------------------------- |
| `--verbose` / `-v` | Verbose output showing what syllago is doing step by step |
| `--json` | Machine-readable JSON output for all commands |
| `--no-color` | Disable color output (also available via `NO_COLOR=1` env var) |
| `--dry-run` | Preview changes without writing (supported on select commands) |
Combine flags for maximum visibility:
```bash
syllago add --from claude-code --dry-run
```
***
## Common issues
### Provider not detected
`syllago init` doesn’t find your AI coding tool.
**Symptoms:**
* `syllago init` reports no providers found
* Provider missing from `syllago list` output
**Fix:**
1. Verify the tool is installed and available in your `PATH`:
```bash
which
```
2. If the tool is installed but not detected, add it manually:
```bash
syllago config add
```
3. Run [`syllago providers`](/using-syllago/cli-reference/providers.md) to see all supported providers.
***
### Content not appearing after add
You ran `syllago add` but can’t find the content.
**Symptoms:**
* Content missing from expected provider config
* `syllago list` shows fewer items than expected
**Fix:**
1. Run [`syllago list`](/using-syllago/cli-reference/list.md) to verify what’s actually imported.
2. Check the `--source` filter — content may be in a different source (registry vs library):
```bash
syllago list --source registry
syllago list --source library
```
3. Run `syllago list --verbose` for details on where each item came from.
***
### Format conversion issues
A conversion between providers fails or produces unexpected results.
**Symptoms:**
* Error during `syllago add`, `syllago install`, or `syllago convert`
* Content type mismatch warnings
**Fix:**
1. Check [`syllago providers`](/using-syllago/cli-reference/providers.md) to see which content types each provider supports.
2. Not all content types work with all providers. Verify your source and target are compatible.
3. Check the [format conversion reference](/using-syllago/format-conversion.md) for the compatibility matrix.
**Related error codes:**
* [CONVERT\_001](/errors/convert-001.md) — Conversion not supported
* [EXPORT\_001](/errors/export-001.md) — Export failed
***
### Registry sync failures
`syllago registry sync` fails to pull updates.
**Symptoms:**
* Sync command errors out
* Registry content is stale or missing
**Fix:**
1. Check network connectivity — registries are fetched over the network (typically git).
2. Verify you have access to the registry repository.
3. Run sync with verbose output for details:
```bash
syllago registry sync --verbose
```
4. Check [`syllago registry list`](/using-syllago/cli-reference/registry-list.md) to confirm the registry URL is correct.
**Related error codes:**
* [REGISTRY\_001](/errors/registry-001.md) — Registry not found
* [REGISTRY\_002](/errors/registry-002.md) — Registry sync failed
***
### Permission errors on install
syllago can’t write to the provider’s configuration directory.
**Symptoms:**
* “Permission denied” errors during import or sync
* Content fails to write to the target location
**Fix:**
1. Check file permissions on the provider’s config directory.
2. Ensure your user owns the directory, or has write access.
3. On macOS/Linux:
```bash
ls -la ~/.config//
```
**Related error codes:**
* [INSTALL\_001](/errors/install-001.md) — Installation failed
***
## Error codes
Every syllago error includes a code like `CONVERT_001` or `REGISTRY_002`. Each code has a dedicated page with explanations, common causes, and fixes.
See the full [error codes reference](/errors.md) for the complete list.
***
## Getting help
* **Inline docs:** Run `syllago --help` or `syllago --help` for usage information on any command.
* **CLI reference:** Browse the full [CLI reference](/using-syllago/cli-reference.md) for detailed documentation.
* **GitHub issues:** Report bugs or ask questions at [github.com/OpenScribbler/syllago/issues](https://github.com/OpenScribbler/syllago/issues).
# Error Codes
> Reference for all syllago error codes with explanations and fixes.
[Source](/errors/)
When syllago encounters an error, it displays a structured error with a code, message, and suggestion. Run `syllago explain ` for offline help, or click any code below for the full reference.
## Catalog Errors
| Code | Name | Description |
| ------------------------------------ | ------------------- | -------------------------------- |
| [CATALOG\_001](/errors/catalog-001.md) | Catalog Not Found | no syllago repo or library found |
| [CATALOG\_002](/errors/catalog-002.md) | Catalog Scan Failed | catalog scan returned an error |
## Config Errors
| Code | Name | Description |
| ---------------------------------- | ---------------- | -------------------------------------------------- |
| [CONFIG\_001](/errors/config-001.md) | Config Invalid | configuration file is malformed |
| [CONFIG\_002](/errors/config-002.md) | Config Not Found | configuration file does not exist |
| [CONFIG\_003](/errors/config-003.md) | Config Path | invalid path override (not absolute, unknown type) |
| [CONFIG\_004](/errors/config-004.md) | Config Save | failed to save configuration |
## Convert Errors
| Code | Name | Description |
| ------------------------------------ | --------------------- | ---------------------------------------- |
| [CONVERT\_001](/errors/convert-001.md) | Convert Not Supported | content type does not support conversion |
| [CONVERT\_002](/errors/convert-002.md) | Convert Parse Failed | parsing content for conversion failed |
| [CONVERT\_003](/errors/convert-003.md) | Convert Render Failed | rendering to target format failed |
## Export Errors
| Code | Name | Description |
| ---------------------------------- | -------------------- | ------------------------------------- |
| [EXPORT\_001](/errors/export-001.md) | Export Not Supported | export not supported for content type |
| [EXPORT\_002](/errors/export-002.md) | Export Failed | export operation failed |
## Import Errors
| Code | Name | Description |
| ---------------------------------- | ------------------- | -------------------------------------- |
| [IMPORT\_001](/errors/import-001.md) | Import Clone Failed | cloning import source failed |
| [IMPORT\_002](/errors/import-002.md) | Import Conflict | import conflicts with existing content |
## Init Errors
| Code | Name | Description |
| ------------------------------ | ----------- | --------------------------- |
| [INIT\_001](/errors/init-001.md) | Init Exists | project already initialized |
## Input Errors
| Code | Name | Description |
| -------------------------------- | -------------- | -------------------------------------------------- |
| [INPUT\_001](/errors/input-001.md) | Input Missing | required flag or argument not provided |
| [INPUT\_002](/errors/input-002.md) | Input Conflict | mutually exclusive flags used together |
| [INPUT\_003](/errors/input-003.md) | Input Invalid | flag value is invalid (wrong format, out of range) |
| [INPUT\_004](/errors/input-004.md) | Input Terminal | command requires interactive terminal |
## Install Errors
| Code | Name | Description |
| ------------------------------------ | ---------------------- | ------------------------------------------------- |
| [INSTALL\_001](/errors/install-001.md) | Install Not Writable | install path not writable |
| [INSTALL\_002](/errors/install-002.md) | Install Item Not Found | item not found in library for install |
| [INSTALL\_003](/errors/install-003.md) | Install Method Invalid | invalid install method for content type |
| [INSTALL\_004](/errors/install-004.md) | Install Conflict | active loadout or other conflict prevents install |
| [INSTALL\_005](/errors/install-005.md) | Install Not Installed | item is not currently installed |
## Item Errors
| Code | Name | Description |
| ------------------------------ | ----------------- | ---------------------------------- |
| [ITEM\_001](/errors/item-001.md) | Item Not Found | named item not found in library |
| [ITEM\_002](/errors/item-002.md) | Item Ambiguous | item name exists in multiple types |
| [ITEM\_003](/errors/item-003.md) | Item Type Unknown | unknown content type specified |
## Loadout Errors
| Code | Name | Description |
| ------------------------------------ | ----------------- | ---------------------------------------- |
| [LOADOUT\_001](/errors/loadout-001.md) | Loadout Not Found | loadout not found in library or registry |
| [LOADOUT\_002](/errors/loadout-002.md) | Loadout Parse | loadout.yaml is malformed |
| [LOADOUT\_003](/errors/loadout-003.md) | Loadout Conflict | another loadout is already active |
| [LOADOUT\_004](/errors/loadout-004.md) | Loadout Provider | loadout references unknown provider |
| [LOADOUT\_005](/errors/loadout-005.md) | Loadout No Items | no items selected for loadout |
## Moat Errors
| Code | Name | Description |
| ------------------------------ | -------------------------- | --------------------------------------------------------------------------------------- |
| [MOAT\_001](/errors/moat-001.md) | Moat Identity Unpinned | registry add has neither allowlist match nor —signing-identity |
| [MOAT\_002](/errors/moat-002.md) | Moat Identity Invalid | —signing-\* flags are incomplete or malformed |
| [MOAT\_003](/errors/moat-003.md) | Moat Identity Mismatch | manifest cert does not match pinned profile (numeric ID, issuer, or subject) |
| [MOAT\_004](/errors/moat-004.md) | Moat Invalid | manifest or bundle malformed, missing, or unreadable |
| [MOAT\_005](/errors/moat-005.md) | Moat Trusted Root Stale | bundled trusted root exceeded its 365-day cliff |
| [MOAT\_006](/errors/moat-006.md) | Moat Unsigned With Pin | registry has a pinned profile but no manifest/bundle found in checkout |
| [MOAT\_007](/errors/moat-007.md) | Moat Trusted Root Override | operator-supplied trusted\_root.json path (—trusted-root or reg.trusted\_root) unusable |
| [MOAT\_008](/errors/moat-008.md) | Moat Revocation Block | archival or live registry-source revocation refuses install (ADR 0007 G-8/G-15) |
| [MOAT\_009](/errors/moat-009.md) | Moat Tier Below Policy | resolved content trust tier is below the caller-configured policy floor |
## Privacy Errors
| Code | Name | Description |
| ------------------------------------ | ----------------------- | --------------------------------------------------- |
| [PRIVACY\_001](/errors/privacy-001.md) | Privacy Publish Blocked | private content cannot be shared to public registry |
| [PRIVACY\_002](/errors/privacy-002.md) | Privacy Share Blocked | private content cannot be shared to public repo |
| [PRIVACY\_003](/errors/privacy-003.md) | Privacy Loadout Warn | loadout contains private items (warning) |
## Promote Errors
| Code | Name | Description |
| ------------------------------------ | ------------------ | ------------------------------------------- |
| [PROMOTE\_001](/errors/promote-001.md) | Promote Dirty Tree | uncommitted changes in working tree |
| [PROMOTE\_002](/errors/promote-002.md) | Promote Validation | content validation failed before promote |
| [PROMOTE\_003](/errors/promote-003.md) | Promote Git Failed | git operation (branch, commit, push) failed |
## Provider Errors
| Code | Name | Description |
| -------------------------------------- | --------------------- | ----------------------------- |
| [PROVIDER\_001](/errors/provider-001.md) | Provider Not Found | unknown provider slug |
| [PROVIDER\_002](/errors/provider-002.md) | Provider Not Detected | provider not detected on disk |
## Registry Errors
| Code | Name | Description |
| -------------------------------------- | -------------------- | ------------------------------------------------ |
| [REGISTRY\_001](/errors/registry-001.md) | Registry Clone | git clone of registry failed |
| [REGISTRY\_002](/errors/registry-002.md) | Registry Not Found | named registry not in config |
| [REGISTRY\_003](/errors/registry-003.md) | Registry Not Allowed | URL blocked by allowedRegistries policy |
| [REGISTRY\_004](/errors/registry-004.md) | Registry Invalid | invalid registry name or structure |
| [REGISTRY\_005](/errors/registry-005.md) | Registry Duplicate | registry with this name already exists |
| [REGISTRY\_006](/errors/registry-006.md) | Registry Not Cloned | registry exists in config but not cloned locally |
| [REGISTRY\_007](/errors/registry-007.md) | Registry Sync Failed | git pull failed during sync |
| [REGISTRY\_008](/errors/registry-008.md) | Registry Save Failed | could not save registry config changes |
## System Errors
| Code | Name | Description |
| ---------------------------------- | -------------- | ----------------------------------- |
| [SYSTEM\_001](/errors/system-001.md) | System Homedir | cannot determine home directory |
| [SYSTEM\_002](/errors/system-002.md) | System IO | filesystem read/write/mkdir failure |
# CATALOG_001 — Catalog Not Found
> Syllago could not find a repository or library to work with. The catalog requires a `.syllago` directory to discover and manage content.
[Source](/errors/catalog-001/)
## What This Means
Syllago could not find a repository or library to work with. The catalog requires a `.syllago` directory to discover and manage content.
## Common Causes
* Running a syllago command outside of a project directory
* The `.syllago` directory is missing or was deleted
* You haven’t initialized syllago in this project yet
## How to Fix
1. Navigate to your project directory and run `syllago init` to create a new syllago repository.
2. If you already have a syllago project, make sure you’re running commands from within that directory (or a subdirectory of it).
## Example Output
```plaintext
Error CATALOG_001: no syllago repository found
Suggestion: run 'syllago init' to create one, or navigate to an existing syllago project
```
# CATALOG_002 — Catalog Scan Failed
> Syllago encountered an error while scanning the catalog for content items. The scan could not complete successfully.
[Source](/errors/catalog-002/)
## What This Means
Syllago encountered an error while scanning the catalog for content items. The scan could not complete successfully.
## Common Causes
* Corrupted or malformed content files (invalid YAML/JSON syntax)
* Permission issues on content directories or files
* Broken symlinks in the content tree
* Disk I/O errors
## How to Fix
1. Check file permissions on your `.syllago` directory and its contents: `ls -la .syllago/`
2. Validate the syntax of recently modified content files.
3. Look for broken symlinks: `find .syllago -xtype l`
4. If the issue persists, try removing and re-importing the problematic content.
## Example Output
```plaintext
Error CATALOG_002: failed to scan catalog
Suggestion: check file permissions and content file syntax in .syllago/
```
# CONFIG_001 — Config Invalid
> The syllago configuration file exists but contains invalid or malformed content and cannot be parsed.
[Source](/errors/config-001/)
## What This Means
The syllago configuration file exists but contains invalid or malformed content and cannot be parsed.
## Common Causes
* Syntax error in `.syllago/config.json` from manual editing
* Incomplete JSON (missing closing braces, trailing commas)
* File was corrupted or partially written
## How to Fix
1. Open `.syllago/config.json` and check for JSON syntax errors
2. Validate with `jq . < .syllago/config.json` to pinpoint the issue
3. Fix the syntax error, or if the file is beyond repair, delete it and re-initialize:
```plaintext
rm .syllago/config.json
syllago init
```
## Example Output
```plaintext
Error CONFIG_001: invalid configuration file ".syllago/config.json": unexpected end of JSON input
Suggestion: fix JSON syntax or re-initialize with 'syllago init'
```
# CONFIG_002 — Config Not Found
> Syllago could not find a configuration file. The command requires a syllago project to be initialized in the current directory or a parent directory.
[Source](/errors/config-002/)
## What This Means
Syllago could not find a configuration file. The command requires a syllago project to be initialized in the current directory or a parent directory.
## Common Causes
* Running a syllago command outside of a syllago project directory
* The `.syllago` directory was deleted or never created
* Running from a directory that is not within a syllago project tree
## How to Fix
Initialize a syllago project in the current directory:
```plaintext
syllago init
```
Or navigate to an existing syllago project directory before running the command.
## Example Output
```plaintext
Error CONFIG_002: configuration file not found
Suggestion: run 'syllago init' to create project configuration
```
# CONFIG_003 — Config Path
> A path override in the configuration is invalid. The path is either not absolute or references an unknown configuration path key.
[Source](/errors/config-003/)
## What This Means
A path override in the configuration is invalid. The path is either not absolute or references an unknown configuration path key.
## Common Causes
* A relative path was used where an absolute path is required
* An unknown or misspelled configuration path key was specified
* The path override was set manually with an invalid value
## How to Fix
1. Use absolute paths (starting with `/` on Linux/macOS or a drive letter on Windows) for all config path overrides
2. Check valid path keys:
```plaintext
syllago config paths show
```
3. Correct the path override to use a valid absolute path and recognized key
## Example Output
```plaintext
Error CONFIG_003: invalid path override: "library" path must be absolute, got "./my-library"
Suggestion: use absolute paths for config overrides; see 'syllago config paths show' for valid keys
```
# CONFIG_004 — Config Save
> Syllago was unable to write the configuration file to disk.
[Source](/errors/config-004/)
## What This Means
Syllago was unable to write the configuration file to disk.
## Common Causes
* Permission denied on the `.syllago/` directory or config file
* Disk is full or has insufficient space
* The `.syllago/` directory was deleted while syllago was running
* The filesystem is mounted as read-only
## How to Fix
1. Check write permissions on the `.syllago/` directory: `ls -la .syllago/`
2. Verify available disk space: `df -h`
3. If the directory is missing, re-initialize: `syllago init`
4. If permissions are wrong, fix with: `chmod u+w .syllago/`
## Example Output
```plaintext
Error CONFIG_004: failed to save configuration: permission denied
Suggestion: check write permissions on the .syllago/ directory
```
# CONVERT_001 — Convert Not Supported
> The content type you are trying to convert does not support conversion between the specified providers.
[Source](/errors/convert-001/)
## What This Means
The content type you are trying to convert does not support conversion between the specified providers.
## Common Causes
* The content type is provider-specific and has no equivalent in the target provider
* The conversion path between the source and target providers is not implemented
* The content type does not have a canonical format defined
## How to Fix
Check which conversion paths are supported:
```plaintext
syllago info formats
```
If the content type cannot be converted, you may need to manually recreate it for the target provider.
## Example Output
```plaintext
Error CONVERT_001: conversion not supported for content type "commands" (claude-code → gemini)
Suggestion: check 'syllago info formats' for supported conversion paths
```
# CONVERT_002 — Convert Parse Failed
> The source content could not be parsed during conversion. The file exists but its contents are not valid for the expected format.
[Source](/errors/convert-002/)
## What This Means
The source content could not be parsed during conversion. The file exists but its contents are not valid for the expected format.
## Common Causes
* Malformed source file with syntax errors
* YAML or JSON syntax errors (missing quotes, unclosed brackets, invalid indentation)
* File encoding issues (non-UTF-8 content)
* File is empty or contains only whitespace
## How to Fix
1. Open the source file and check for syntax errors
2. For YAML files, validate with a YAML linter or online validator
3. For JSON files, validate with `jq . < file.json` or an online JSON validator
4. Ensure the file uses UTF-8 encoding
## Example Output
```plaintext
Error CONVERT_002: failed to parse "rules/my-rule.yaml": yaml: line 5: mapping values are not allowed here
Suggestion: check the source file for syntax errors
```
# CONVERT_003 — Convert Render Failed
> The content was parsed successfully but could not be rendered into the target provider's format.
[Source](/errors/convert-003/)
## What This Means
The content was parsed successfully but could not be rendered into the target provider’s format.
## Common Causes
* The content uses features not supported by the target provider
* Encoding issues when writing the output format
* The target format has constraints that the source content violates (e.g., field length limits)
## How to Fix
1. Review the content for provider-specific features that may not translate
2. Simplify the content to use only features common across providers
3. Check provider compatibility with `syllago info formats`
4. Try converting to a different target provider to isolate the issue
## Example Output
```plaintext
Error CONVERT_003: failed to render content to gemini format: unsupported hook event type "on_tool_error"
Suggestion: simplify content or check target provider compatibility
```
# EXPORT_001 — Export Not Supported
> The content type you are trying to export is not supported for the specified target provider.
[Source](/errors/export-001/)
## What This Means
The content type you are trying to export is not supported for the specified target provider.
## Common Causes
* The content type has no equivalent in the target provider’s format
* The export path between the content type and target provider is not implemented
* The content type is internal to syllago and not exportable
## How to Fix
Check which export targets are supported for your content type:
```plaintext
syllago info formats
```
If the target provider is not supported, consider exporting to a different provider or manually adapting the content.
## Example Output
```plaintext
Error EXPORT_001: export not supported for content type "agents" to provider "gemini"
Suggestion: check 'syllago info formats' for supported export targets
```
# EXPORT_002 — Export Failed
> The export operation failed while writing content to the target location.
[Source](/errors/export-002/)
## What This Means
The export operation failed while writing content to the target location.
## Common Causes
* Write permission denied on the target directory
* The target directory does not exist
* Disk is full or has insufficient space
* The target path is on a read-only filesystem
## How to Fix
1. Ensure the target directory exists: `mkdir -p /path/to/target`
2. Check write permissions on the target directory: `ls -la /path/to/target`
3. Verify available disk space: `df -h`
4. If permissions are the issue, adjust with `chmod` or run from a writable location
## Example Output
```plaintext
Error EXPORT_002: failed to export "my-skill" to /home/user/.config/provider/skills/: permission denied
Suggestion: ensure the target directory exists and is writable
```
# IMPORT_001 — Import Clone Failed
> Syllago failed to clone the import source repository. The content could not be fetched from the specified location.
[Source](/errors/import-001/)
## What This Means
Syllago failed to clone the import source repository. The content could not be fetched from the specified location.
## Common Causes
* Invalid or mistyped repository URL
* Network connectivity issues (firewall, proxy, DNS resolution)
* The repository requires authentication (private repo)
* The repository no longer exists or has been moved
## How to Fix
1. Verify the import URL is correct and accessible in a browser
2. Check your network connectivity (`ping github.com` or equivalent)
3. For private repositories, ensure your Git credentials are configured
4. If the repository has moved, update the URL to the new location
## Example Output
```plaintext
Error IMPORT_001: failed to clone "https://github.com/org/repo": authentication required
Suggestion: verify the import URL is accessible and check network connectivity
```
# IMPORT_002 — Import Conflict
> The content you are importing conflicts with content that already exists in your library. An item with the same name is already present.
[Source](/errors/import-002/)
## What This Means
The content you are importing conflicts with content that already exists in your library. An item with the same name is already present.
## Common Causes
* An item with the same name was previously imported from a different source
* The same content was imported twice
* Locally created content has the same name as the import
## How to Fix
1. Check existing items with `syllago list` to find the conflict
2. Rename the existing item if you want to keep both
3. Remove the existing item first with `syllago remove` if you want to replace it
4. Use the `--force` flag if available to overwrite the existing item
## Example Output
```plaintext
Error IMPORT_002: import conflicts with existing item "team-rules" in library
Suggestion: rename or remove the existing item, or use --force to overwrite
```
# INIT_001 — Init Exists
> The project has already been initialized with syllago. A `.syllago` directory already exists in the current directory.
[Source](/errors/init-001/)
## What This Means
The project has already been initialized with syllago. A `.syllago` directory already exists in the current directory.
## Common Causes
* Running `syllago init` in a directory that was previously initialized
* A `.syllago` directory was manually created or left behind from a previous setup
## How to Fix
1. If the project is already initialized, no action is needed — you can use syllago normally
2. If you want to reinitialize from scratch, remove the `.syllago` directory first: `rm -rf .syllago`
3. Then run `syllago init` again
## Example Output
```plaintext
Error INIT_001: project already initialized
Suggestion: the project is already initialized; to reinitialize, remove the .syllago directory first
```
# INPUT_001 — Input Missing
> A required flag or positional argument was not provided for the command.
[Source](/errors/input-001/)
## What This Means
A required flag or positional argument was not provided for the command.
## Common Causes
* Running a command without its required arguments (e.g., `syllago install` with no item name)
* Omitting a required flag (e.g., `--to` when a target provider is needed)
## How to Fix
1. Check the command’s usage with `syllago --help`
2. Provide all required arguments and flags
## Example Output
```plaintext
Error INPUT_001: missing required argument: item name
Suggestion: see 'syllago install --help' for usage
```
# INPUT_002 — Input Conflict
> Two or more flags that cannot be used together were provided in the same command.
[Source](/errors/input-002/)
## What This Means
Two or more flags that cannot be used together were provided in the same command.
## Common Causes
* Using `--local` and `--registry` together when only one source is allowed
* Combining `--json` with interactive-only flags
* Specifying conflicting output or filter options
## How to Fix
1. Review the command help with `syllago --help` to understand which flags conflict
2. Use only one of the conflicting flags per invocation
## Example Output
```plaintext
Error INPUT_002: flags --local and --registry are mutually exclusive
Suggestion: use only one of the conflicting flags
```
# INPUT_003 — Input Invalid
> A flag or argument value has an invalid format or is out of the expected range.
[Source](/errors/input-003/)
## What This Means
A flag or argument value has an invalid format or is out of the expected range.
## Common Causes
* Invalid provider slug (e.g., `--to=not-a-provider`)
* Malformed argument value (e.g., a path with invalid characters)
* Numeric value out of expected range
## How to Fix
1. Check the expected format in the command help: `syllago --help`
2. For provider slugs, run `syllago info providers` to see valid values
3. Verify the argument value matches the expected format
## Example Output
```plaintext
Error INPUT_003: invalid provider slug "not-a-provider"
Suggestion: run 'syllago info providers' for valid provider slugs
```
# INPUT_004 — Input Terminal
> The command requires an interactive terminal (TTY) but is running in a non-interactive context.
[Source](/errors/input-004/)
## What This Means
The command requires an interactive terminal (TTY) but is running in a non-interactive context.
## Common Causes
* Running the TUI or an interactive command through a pipe (e.g., `echo | syllago`)
* Running syllago in a CI/CD pipeline without interactive support
* Redirecting stdin from a file
## How to Fix
1. Run the command in an interactive terminal
2. For scripted or CI usage, use `--json` or other non-interactive flags
3. Use specific CLI subcommands instead of the TUI for automation
## Example Output
```plaintext
Error INPUT_004: this command requires an interactive terminal
Suggestion: use --json or non-interactive flags for scripted usage
```
# INSTALL_001 — Install Not Writable
> Syllago cannot write to the target install path. The content cannot be installed because the destination is not writable.
[Source](/errors/install-001/)
## What This Means
Syllago cannot write to the target install path. The content cannot be installed because the destination is not writable.
## Common Causes
* Permission issues on the provider’s configuration directory
* The target path is on a read-only filesystem
* The directory is owned by another user or root
* SELinux or other security policies restricting write access
## How to Fix
1. Check permissions on the provider’s config directory: `ls -la `
2. Ensure your user owns the directory or has write access.
3. If the directory is owned by root, check if the provider was installed system-wide and adjust permissions accordingly.
## Example Output
```plaintext
Error INSTALL_001: install path not writable
Suggestion: check permissions on the provider config directory
```
# INSTALL_002 — Install Item Not Found
> The item you tried to install could not be found. It is not present in your local library or any configured registry.
[Source](/errors/install-002/)
## What This Means
The item you tried to install could not be found. It is not present in your local library or any configured registry.
## Common Causes
* Typo in the item name
* The item hasn’t been imported into your local library yet
* The item exists in a registry that hasn’t been added
* The item was removed or renamed
## How to Fix
1. List available items: `syllago list`
2. Check for typos in the item name.
3. If the item is in a registry, make sure the registry is added and synced: `syllago registry list`
4. Import the item first if it’s from an external source.
## Example Output
```plaintext
Error INSTALL_002: item "my-rule" not found
Suggestion: run 'syllago list' to see available items
```
# INSTALL_003 — Install Method Invalid
> The requested install method is not supported for this content type. Different content types require different installation strategies.
[Source](/errors/install-003/)
## What This Means
The requested install method is not supported for this content type. Different content types require different installation strategies.
## Common Causes
* Trying to symlink a content type that requires JSON merge (hooks, MCP configs)
* Specifying an install method that doesn’t exist for the content type
* Mismatched content type and provider capabilities
## How to Fix
1. Hooks and MCP configs are installed via JSON merge into provider settings files, not as filesystem symlinks.
2. Rules, skills, agents, commands, and prompts use filesystem installation (files, directories, or symlinks).
3. Let syllago choose the default install method by omitting the method flag.
## Example Output
```plaintext
Error INSTALL_003: invalid install method "symlink" for content type "hooks"
Suggestion: hooks use JSON merge — omit the method flag to use the default
```
# INSTALL_004 — Install Conflict
> The install cannot proceed because of a conflict with an active loadout or an already-installed item.
[Source](/errors/install-004/)
## What This Means
The install cannot proceed because of a conflict with an active loadout or an already-installed item.
## Common Causes
* An active loadout already manages this content, and installing directly would conflict
* A different version of the same item is already installed
* Two items would write to the same destination path
## How to Fix
1. If a loadout is managing this content, remove the loadout first: `syllago loadout remove `
2. If a conflicting item is already installed, uninstall it before installing the new one.
3. Check which loadouts are active: `syllago loadout list`
## Example Output
```plaintext
Error INSTALL_004: conflict with active loadout "dev-setup"
Suggestion: run 'syllago loadout remove dev-setup' first, then retry the install
```
# INSTALL_005 — Install Not Installed
> The item you are trying to uninstall is not currently installed in your system.
[Source](/errors/install-005/)
## What This Means
The item you are trying to uninstall is not currently installed in your system.
## Common Causes
* Trying to uninstall an item that was never installed
* The item was already removed in a previous operation
* Typo in the item name or identifier
## How to Fix
Check what is currently installed by running:
```plaintext
syllago list --source library
```
Verify the exact name of the item you want to remove and try again.
## Example Output
```plaintext
Error INSTALL_005: item "my-rule" is not installed
Suggestion: run 'syllago list --source library' to see installed items
```
# ITEM_001 — Item Not Found
> The specified item could not be found in your local library or any configured registries.
[Source](/errors/item-001/)
## What This Means
The specified item could not be found in your local library or any configured registries.
## Common Causes
* Typo in the item name
* The item does not exist in the local library
* The item exists in a registry that is not configured or has not been synced
* The item was removed or renamed
## How to Fix
1. Check the spelling of the item name
2. Run `syllago list` to browse available items in your library
3. Run `syllago registry items ` to browse items in a specific registry
4. If the item is in a registry, run `syllago registry sync` to pull the latest content
## Example Output
```plaintext
Error ITEM_001: item "my-ruel" not found
Suggestion: run 'syllago list' to browse available items; check spelling
```
# ITEM_002 — Item Ambiguous
> The item name matches content in multiple content types, so syllago cannot determine which one you mean.
[Source](/errors/item-002/)
## What This Means
The item name matches content in multiple content types, so syllago cannot determine which one you mean.
## Common Causes
* The same name is used for both a rule and a skill (e.g., `my-config` exists as both `rules/my-config` and `skills/my-config`)
* A registry contains duplicate names across different content types
## How to Fix
1. Qualify the item with its content type prefix: `syllago install rules/my-item` instead of `syllago install my-item`
2. Run `syllago list` to see all items grouped by type and identify the correct one
## Example Output
```plaintext
Error ITEM_002: item "my-config" is ambiguous: found in rules, skills
Suggestion: qualify with content type, e.g. 'syllago install rules/my-config'
```
# ITEM_003 — Item Type Unknown
> The specified content type is not recognized by syllago.
[Source](/errors/item-003/)
## What This Means
The specified content type is not recognized by syllago.
## Common Causes
* Typo in the content type (e.g., `--type=ruls` instead of `--type=rules`)
* Using a singular form instead of plural (e.g., `rule` instead of `rules`)
* Using a content type that does not exist in syllago
## How to Fix
1. Use one of the valid content types: `rules`, `skills`, `agents`, `commands`, `hooks`, `mcp`, `prompts`, `loadouts`
2. Check command help for accepted values: `syllago --help`
## Example Output
```plaintext
Error ITEM_003: unknown content type "ruls"
Suggestion: valid types are: rules, skills, agents, commands, hooks, mcp, prompts, loadouts
```
# LOADOUT_001 — Loadout Not Found
> The specified loadout could not be found in your local library or any configured registry.
[Source](/errors/loadout-001/)
## What This Means
The specified loadout could not be found in your local library or any configured registry.
## Common Causes
* Typo in the loadout name
* The loadout is not in your local library
* The loadout is not available in any configured registry
* The registry has not been synced recently
## How to Fix
1. Check available loadouts:
```plaintext
syllago loadout list
```
2. Verify the exact name of the loadout you are looking for
3. If the loadout is in a registry, ensure the registry is configured and synced
## Example Output
```plaintext
Error LOADOUT_001: loadout "kubernetes-setup" not found
Suggestion: run 'syllago loadout list' to see available loadouts
```
# LOADOUT_002 — Loadout Parse
> The loadout's `loadout.yaml` manifest file exists but contains invalid content and cannot be parsed.
[Source](/errors/loadout-002/)
## What This Means
The loadout’s `loadout.yaml` manifest file exists but contains invalid content and cannot be parsed.
## Common Causes
* YAML syntax errors (bad indentation, missing colons, unclosed quotes)
* Missing required fields (`name`, `provider`, `items`)
* Invalid content type references in the items list
* File encoding issues
## How to Fix
1. Open the `loadout.yaml` file and check for YAML syntax errors
2. Ensure all required fields are present:
```yaml
name: my-loadout
provider: claude-code
items:
- type: rules
path: my-rule.md
```
3. Validate YAML syntax with a linter or online validator
4. Ensure content type references match valid syllago content types
## Example Output
```plaintext
Error LOADOUT_002: failed to parse "my-loadout/loadout.yaml": yaml: line 3: did not find expected key
Suggestion: check YAML syntax and ensure required fields (name, provider, items) are present
```
# LOADOUT_003 — Loadout Conflict
> You are trying to apply a loadout, but another loadout is already active for the same provider. Only one loadout can be active at a time per provider.
[Source](/errors/loadout-003/)
## What This Means
You are trying to apply a loadout, but another loadout is already active for the same provider. Only one loadout can be active at a time per provider.
## Common Causes
* A previously applied loadout was not removed before applying a new one
* A loadout was applied in a different session and is still active
## How to Fix
1. Check which loadout is currently active:
```plaintext
syllago loadout list
```
2. Remove the current loadout before applying the new one:
```plaintext
syllago loadout remove
```
3. Apply the new loadout:
```plaintext
syllago loadout apply
```
## Example Output
```plaintext
Error LOADOUT_003: loadout "team-defaults" is already active for provider "claude-code"
Suggestion: run 'syllago loadout remove' before applying a new loadout
```
# LOADOUT_004 — Loadout Provider
> The loadout references a provider that syllago does not recognize or support.
[Source](/errors/loadout-004/)
## What This Means
The loadout references a provider that syllago does not recognize or support.
## Common Causes
* The `provider` field in `loadout.yaml` contains a typo (e.g., `cladue-code` instead of `claude-code`)
* The loadout was created for a provider that has since been removed or renamed
* The loadout was authored for a provider that your version of syllago does not support
## How to Fix
1. Open the loadout’s `loadout.yaml` and check the `provider` field
2. Run `syllago info providers` to see the list of supported provider slugs
3. Update the `provider` field to match one of the supported slugs
## Example Output
```plaintext
Error LOADOUT_004: loadout references unknown provider "cladue-code"
Suggestion: check the provider field in loadout.yaml; run 'syllago info providers' for supported providers
```
# LOADOUT_005 — Loadout No Items
> A loadout was created or modified with no content items selected.
[Source](/errors/loadout-005/)
## What This Means
A loadout was created or modified with no content items selected.
## Common Causes
* All items were deselected during interactive loadout creation
* A loadout was created programmatically with an empty items list
* Items were removed from a loadout without adding replacements
## How to Fix
1. When creating a loadout, select at least one content item (rule, skill, agent, etc.)
2. If using the TUI, ensure at least one item is checked before confirming
3. If editing `loadout.yaml` directly, ensure the `items` list is non-empty
## Example Output
```plaintext
Error LOADOUT_005: no items selected for loadout
Suggestion: select at least one content item when creating a loadout
```
# MOAT_001 — Moat Identity Unpinned
> You ran `syllago registry add` for a MOAT-signed registry, but syllago cannot find a signing identity to pin. Either the URL is not in the bundled ...
[Source](/errors/moat-001/)
## What This Means
You ran `syllago registry add` for a MOAT-signed registry, but syllago cannot find a signing identity to pin. Either the URL is not in the bundled allowlist and you did not pass `--signing-identity`, or you requested `--moat` without providing the required flags.
Syllago refuses to add MOAT registries without a pinned signing identity because silent “trust on first use” hides the most common supply-chain attack: an attacker-controlled first fetch establishing a fake root of trust.
## Common Causes
* The registry is newly published and not yet in the bundled allowlist.
* You forgot to pass `--signing-identity`, `--signing-repository-id`, or `--signing-repository-owner-id`.
* You passed `--moat` but did not supply the identity flags.
## How to Fix
Pick one of the three supported paths:
1. **Allowlist match** — if the registry is well-known, request an allowlist entry by opening a PR against syllago adding a new entry to `cli/internal/moat/signing_identities.json`.
2. **CLI flags** — pin the identity explicitly at add-time:
```plaintext
syllago registry add https://github.com/OWNER/REPO.git \
--signing-identity "https://github.com/OWNER/REPO/.github/workflows/moat.yml@refs/heads/main" \
--signing-repository-id "$(gh api repos/OWNER/REPO --jq '.id')" \
--signing-repository-owner-id "$(gh api repos/OWNER/REPO --jq '.owner.id')"
```
3. **Skip MOAT** — if you only need unsigned git content, omit `--moat` and the signing flags. Syllago will fall back to the legacy git-clone flow (no signature verification).
For the full workflow, see .
## Example Output
```plaintext
Error MOAT_001: registry at https://github.com/newteam/new-registry.git has no pinned signing identity
Suggestion: Pass --signing-identity and --signing-repository-id / --signing-repository-owner-id (required for GitHub Actions issuers), or request an allowlist entry.
Details: See https://syllago.dev/moat/registry-add-signing-identity/ for the full workflow and allowlist contribution process.
```
# MOAT_002 — Moat Identity Invalid
> You passed `--signing-identity` (or another `--signing-*` flag), but the flag set is incomplete. The most common case: the issuer is the GitHub Act...
[Source](/errors/moat-002/)
## What This Means
You passed `--signing-identity` (or another `--signing-*` flag), but the flag set is incomplete. The most common case: the issuer is the GitHub Actions OIDC issuer (the default) but one or both numeric repository IDs is missing.
Syllago requires numeric IDs for GitHub-signed identities because they are the only immutable anchor — an attacker who persuades GitHub to transfer an owner/repo name can re-register the human-readable subject SAN but cannot forge the numeric ID extensions on the OIDC certificate.
## Common Causes
* Missing `--signing-repository-id`.
* Missing `--signing-repository-owner-id`.
* Typo in the `--signing-issuer` value that bypasses the GitHub check.
## How to Fix
Look up the numeric IDs for the target repository:
```plaintext
gh api repos/OWNER/REPO --jq '.id, .owner.id'
```
Then re-run the add:
```plaintext
syllago registry add https://github.com/OWNER/REPO.git \
--signing-identity "https://github.com/OWNER/REPO/.github/workflows/moat.yml@refs/heads/main" \
--signing-repository-id 123456789 \
--signing-repository-owner-id 987654321
```
Non-GitHub issuers (custom OIDC providers, GitLab, Buildkite) do not require numeric IDs — those issuers have their own equivalent bindings that slice-3 will consume.
## Example Output
```plaintext
Error MOAT_002: GitHub Actions issuer requires --signing-repository-id and --signing-repository-owner-id
Suggestion: Find numeric IDs with `gh api repos/OWNER/REPO --jq '.id, .owner.id'`. See https://syllago.dev/moat/registry-add-signing-identity/.
```
# MOAT_003 — Moat Identity Mismatch
> Syllago fetched a MOAT registry's manifest and signing bundle, but the certificate on that bundle did not match the `signing_profile` you pinned fo...
[Source](/errors/moat-003/)
## What This Means
Syllago fetched a MOAT registry’s manifest and signing bundle, but the certificate on that bundle did not match the `signing_profile` you pinned for this registry. The most common cause is that the pinned `repository_id` or `repository_owner_id` does not match the numeric IDs baked into the GitHub OIDC certificate — exactly the repo-transfer scenario ADR 0007 exists to catch.
Syllago refuses to proceed on any mismatch because the whole point of pinning the numeric IDs is to make repo-rename / repo-transfer attacks impossible: the SAN subject string can be re-registered by an attacker who takes over the owner/repo name, but the numeric IDs cannot.
## Common Causes
* The pinned profile is stale — the owner/repo was legitimately transferred and never re-approved.
* An attacker captured the owner/repo name after the legitimate publisher released it, and is now signing with a different numeric repo ID.
* You pinned the wrong numeric IDs when running `registry add --signing-repository-id / --signing-repository-owner-id`.
* The registry publisher rotated to a different workflow subject or issuer without updating its profile.
## How to Fix
1. Confirm the current, legitimate owner of the registry — use an out-of-band channel (project homepage, existing contributor, prior CI logs).
2. Re-derive the numeric IDs from the canonical source:
```plaintext
gh api repos/OWNER/REPO --jq '.id, .owner.id'
```
3. Remove the existing registry, then re-add it with the refreshed profile:
```plaintext
syllago registry remove OWNER/REPO
syllago registry add https://github.com/OWNER/REPO.git \
--signing-identity "https://github.com/OWNER/REPO/.github/workflows/moat.yml@refs/heads/main" \
--signing-repository-id \
--signing-repository-owner-id
```
If you cannot verify the legitimacy of the transfer out-of-band, assume compromise: leave the registry uninstalled until you can.
## Example Output
```plaintext
Error MOAT_003: manifest cert does not match pinned profile for registry OpenScribbler/syllago-meta-registry
Suggestion: Re-verify the registry's signing identity out-of-band, then re-add with refreshed --signing-repository-id / --signing-repository-owner-id.
Details: MOAT_IDENTITY_MISMATCH: repository_id mismatch: got="9999999" want="1193220959"
```
# MOAT_004 — Moat Invalid
> Syllago tried to verify a MOAT registry but something about the manifest or its signing bundle is malformed, corrupt, or cryptographically invalid....
[Source](/errors/moat-004/)
## What This Means
Syllago tried to verify a MOAT registry but something about the manifest or its signing bundle is malformed, corrupt, or cryptographically invalid. This differs from MOAT\_003 (identity mismatch) — MOAT\_004 means the cryptographic machinery itself rejected the input, not that the identity disagreed.
Typical triggers: truncated `.sigstore` bundle, wrong media type, a manifest whose bytes don’t match the signed artifact digest, a certificate chain that does not terminate in the bundled Fulcio root, or a Rekor inclusion proof that does not verify.
Syllago fails closed on any of these because a silent accept would mean your install pipeline would pull content whose provenance cannot be proven.
## Common Causes
* The registry published a manifest but updated it without re-signing (bytes no longer match the signature).
* A CDN or proxy rewrote the manifest JSON in transit (whitespace normalization breaks signatures).
* The `.sigstore` bundle was generated by an old tool and uses a media type this version of syllago does not accept.
* The Publisher Action emitted a partial write — the bundle file exists but is truncated.
* Disk corruption or a partial git clone.
## How to Fix
1. `syllago registry sync ` to force a fresh clone / fetch of the manifest and bundle.
2. Inspect the raw files:
```plaintext
ls -la ~/.syllago/registries//manifest.json
ls -la ~/.syllago/registries//manifest.json.sigstore
```
Both files must exist and be non-empty.
3. If the manifest and bundle look intact but verification still fails, the registry publisher almost certainly re-uploaded the manifest without re-signing — file an issue against the registry.
4. If you trust the publisher and need an unsigned fallback while they fix their pipeline, remove the registry and re-add it without any `--signing-*` flags to drop back to legacy git-only mode (no verification).
## Example Output
```plaintext
Error MOAT_004: manifest signature invalid for registry OpenScribbler/syllago-meta-registry
Suggestion: Run `syllago registry sync` to refresh. If the error persists, the registry re-uploaded the manifest without re-signing — contact the registry operator.
Details: MOAT_INVALID: sigstore-go verify: signature does not verify against manifest bytes
```
# MOAT_005 — Moat Trusted Root Stale
> Syllago ships a snapshot of the Sigstore public-good trusted root — the Fulcio CA bundle plus Rekor public keys. That snapshot has a 365-day expira...
[Source](/errors/moat-005/)
## What This Means
Syllago ships a snapshot of the Sigstore public-good trusted root — the Fulcio CA bundle plus Rekor public keys. That snapshot has a 365-day expiration cliff baked in, which is how syllago ensures verifications keep working as Sigstore rotates its keys every 6-12 months.
MOAT\_005 means the bundled root crossed that cliff: it is more than 365 days old, and syllago refuses to verify against keys that old because any result (pass or fail) would be untrustworthy.
This is an operator action, not a registry action. Updating your syllago binary ships a fresher bundled root.
## Common Causes
* You have been running the same syllago binary for more than a year.
* Your syllago distribution channel (package manager, internal mirror) is not pushing updates.
* You built from an old git tag without a fresh `trusted_root.json` refresh.
## How to Fix
Run the updater to pick up the latest release, which always carries a refreshed trusted root:
```plaintext
syllago update
```
If your environment pins syllago to a specific version, bump that pin. You can also check staleness at any time without running a verify:
```plaintext
syllago moat trust status
```
which prints the current root’s issue date, age in days, and the cliff date.
For air-gapped environments, download a newer release artifact on an online machine and copy the binary into place. There is no supported path to refresh just the trusted root without updating the binary — reproducibility of signed releases depends on the root travelling with the client.
## Example Output
```plaintext
Error MOAT_005: bundled Sigstore trusted root expired
Suggestion: Run `syllago update` to refresh. The bundled root passed its 365-day cliff; verification refuses to proceed.
Details: MOAT_TRUSTED_ROOT_STALE: trusted root issued 2025-03-01, age 420 days, cliff 2026-03-01
```
# MOAT_006 — Moat Unsigned With Pin
> Syllago added this registry with a pinned signing identity (`signing_profile` in `config.json`), which means you explicitly opted into cryptographi...
[Source](/errors/moat-006/)
## What This Means
Syllago added this registry with a pinned signing identity (`signing_profile` in `config.json`), which means you explicitly opted into cryptographic verification on every add. But when it went to verify, the registry checkout on disk did not contain a `manifest.json` plus a `manifest.json.sigstore` bundle.
Once a profile is pinned, syllago refuses to silently fall back to unsigned git content. Either the publisher stopped signing, or the checkout is incomplete, or you pinned a profile against a registry that never published a manifest in the first place.
## Common Causes
* The registry was pinned optimistically but the operator never turned on the MOAT Publisher Action.
* A partial git clone or `.gitignore` accidentally excluded the manifest files.
* The manifest files live on a different branch or ref than the one you cloned.
* The registry moved to a different manifest location (e.g. a hosted URL instead of in-repo) without updating its README.
## How to Fix
Pick one of the following, depending on whether you expect this registry to be signed:
1. **You expected signatures.** Force a fresh checkout and check the branch:
```plaintext
syllago registry sync
ls ~/.syllago/registries//manifest.json
ls ~/.syllago/registries//manifest.json.sigstore
```
If the files still aren’t there, file an issue against the registry — the publisher needs to ship a MOAT manifest.
2. **You pinned optimistically and are OK with unsigned content.** Remove the registry and re-add it without any `--signing-*` flags:
```plaintext
syllago registry remove
syllago registry add
```
That drops back to legacy git-only mode with no verification.
3. **The manifest lives at a URL, not in the repo.** Wire the manifest URI into config (slice 3+ feature — track progress in ADR 0007 follow-ups).
## Example Output
```plaintext
Error MOAT_006: registry has a pinned signing profile but no signed manifest in checkout
Suggestion: Run `syllago registry sync` to refresh. If the registry does not publish a MOAT manifest, remove it and re-add without --signing-* flags.
Details: MOAT_UNSIGNED: expected manifest.json + manifest.json.sigstore under ~/.syllago/registries/OpenScribbler/syllago-meta-registry/
```
# MOAT_007 — Moat Trusted Root Override
> You (or your config) asked syllago to verify a registry's manifest against a specific Sigstore trusted root supplied from disk — either via `--trus...
[Source](/errors/moat-007/)
## What This Means
You (or your config) asked syllago to verify a registry’s manifest against a specific Sigstore trusted root supplied from disk — either via `--trusted-root ` on the command line, or via a `trusted_root` field on the registry in `config.json`. Syllago tried to load that file and could not.
This error fires *before* any signature verification happens. Rather than silently fall back to the bundled trusted root (which would be a trust downgrade you did not authorize), syllago refuses to proceed until the override is fixed or removed.
## Common Causes
* The path points at a file that does not exist, or has permissions that block reading.
* The file exists but is not valid JSON — e.g. a download got truncated, or someone hand-edited it and introduced a syntax error.
* The path is relative. Syllago requires absolute paths for trusted-root overrides because the resolved file would otherwise depend on the caller’s working directory.
* The file was replaced with the wrong thing (a certificate bundle, a keyring, a README).
## How to Fix
1. **Verify the path.** Make sure the file exists and is readable:
```plaintext
ls -l /etc/syllago/corp-trusted-root.json
cat /etc/syllago/corp-trusted-root.json | jq .mediaType
```
The file must be a Sigstore `trusted_root.json` — the `mediaType` should look like `application/vnd.dev.sigstore.trustedroot+json;version=0.1`.
2. **Refresh the file** from your internal trust-root distribution process (TUF mirror, shared secret, etc). Air-gapped deployments typically pin this file to a specific release — re-fetch against the current pin.
3. **If you want to drop the override**, either pass `--trusted-root ""` (CLI) or remove the `trusted_root` field from that registry’s entry in `config.json`. Verification then falls back to the bundled root shipped with syllago.
## Example Output
```plaintext
Error MOAT_007: trusted-root override unusable
Suggestion: Fix the path or remove it to fall back to the bundled trusted root.
Details: reading trusted-root override /etc/syllago/corp-trusted-root.json: open /etc/syllago/corp-trusted-root.json: no such file or directory
```
# MOAT_008 — Moat Revocation Block
> Syllago refused to install a content item because the registry manifest — or a prior install recorded in your lockfile — said the item is revoked. ...
[Source](/errors/moat-008/)
## What This Means
Syllago refused to install a content item because the registry manifest — or a prior install recorded in your lockfile — said the item is revoked. MOAT defines two revocation flavors (ADR 0007 G-8):
* **Registry-source revocation** — the registry operator marked the item revoked in the current manifest. This is a hard block: syllago will not install revoked content, even interactively.
* **Archival revocation (G-15)** — a prior install recorded the item, and your lockfile shows it was later superseded by a revoked manifest entry. Once archived as revoked, that exact `(registry, name, content_hash)` tuple can never be re-installed, even if a later manifest un-flags it.
This is intentional. A registry operator who has issued a revocation is telling you “do not run this content.” Syllago honors that without giving the caller a bypass, because the alternative — letting operators opt through revocations interactively — defeats the whole point of a revocation signal.
Note: publisher-source revocation is handled differently (warn-once, operator confirms interactively). That path uses MOAT\_004 on refusal, not MOAT\_008.
## Common Causes
* The registry operator revoked a release after discovering a vulnerability, supply-chain compromise, or accidental publish of unintended content.
* A content item in your lockfile was previously installed, then revoked upstream, and you are attempting to re-install the same `(name, content_hash)` pair.
* Your local clock is correct but the manifest contains an explicit `revoked: true` flag for this entry.
* You are attempting to install from a registry whose manifest uses a stricter revocation policy than your previous client version did.
## How to Fix
1. Do not bypass this error. Revocations are operational signals from the registry operator.
2. Check whether the registry has published a non-revoked replacement:
```plaintext
syllago registry sync
syllago registry items
```
Look for a superseding entry — often a higher version of the same content name.
3. Install the replacement instead of the revoked item.
4. If you genuinely need the old content and believe the revocation is in error, contact the registry operator. Do not try to work around syllago’s refusal — use a different content source.
## Example Output
```plaintext
Error MOAT_008: install refused — registry revoked item syllago-guide (source: registry)
Suggestion: The registry operator marked this item as revoked. Sync the registry and install the superseding entry.
Details: archival revocation: lockfile recorded install on 2026-04-12, current manifest revokes content_hash sha256:abc123...
```
# MOAT_009 — Moat Tier Below Policy
> Syllago refused to install a content item because its resolved MOAT trust tier is below the caller-configured minimum. MOAT defines three trust tie...
[Source](/errors/moat-009/)
## What This Means
Syllago refused to install a content item because its resolved MOAT trust tier is below the caller-configured minimum. MOAT defines three trust tiers (ADR 0007):
* **UNSIGNED** — no manifest, or the item is not attested. Lowest trust.
* **SIGNED** — the registry manifest entry is signed by an identity you pinned, and the signature verifies. Medium trust.
* **DUAL-ATTESTED** — signed at the registry level AND each source artifact carries a matching in-toto attestation whose subject digest matches the manifest’s `content_hash`. Highest trust.
When the caller (CLI flag, config policy, or programmatic installer) sets a minimum tier, syllago will refuse any item whose resolved tier falls below it. Unlike MOAT\_008, this is not a registry-operator signal — it’s your own policy floor rejecting an otherwise valid install.
Tier resolution is defensive: if attestation verification silently fails (G-13 `attestation_hash_mismatch`), syllago downgrades the effective tier rather than promoting unverified content. So an item the registry labels DUAL-ATTESTED can still be treated as SIGNED at gate time, which may fall below your policy floor.
## Common Causes
* You set `--min-tier DUAL_ATTESTED` but the item carries only a registry-level signature, no in-toto attestation on the source artifact.
* You set `--min-tier SIGNED` but the registry has no manifest yet (tier resolved as UNSIGNED).
* An attestation exists but its subject digest does not match the manifest’s `content_hash` — G-13 downgrade kicked in and demoted the effective tier.
* Your organization-wide policy file enforces a tier floor that this registry’s items do not meet.
## How to Fix
1. Confirm the tier you expected. `syllago registry items ` prints each entry’s resolved tier.
2. If the registry operator intended DUAL-ATTESTED but you’re seeing SIGNED, the attestation pipeline in their publisher is misconfigured — contact them.
3. If you deliberately set a strict floor and want to accept this item anyway, re-run without `--min-tier` (or lower it) — but only for content where you have an out-of-band reason to trust a weaker tier.
4. For production pipelines, prefer fixing the root cause (ask the publisher to dual-attest) over lowering your floor.
## Example Output
```plaintext
Error MOAT_009: install refused — trust tier SIGNED is below policy floor DUAL_ATTESTED for syllago-guide
Suggestion: The registry item does not meet your --min-tier policy. Either lower the policy or ask the publisher to dual-attest their release pipeline.
Details: MOAT_TIER_BELOW_POLICY: resolved tier=SIGNED, required=DUAL_ATTESTED
```
# PRIVACY_001 — Privacy Publish Blocked
> Content from a private registry cannot be shared to a public registry. The privacy gate prevents private content from leaking into public spaces.
[Source](/errors/privacy-001/)
## What This Means
Content from a private registry cannot be shared to a public registry. The privacy gate prevents private content from leaking into public spaces.
## Common Causes
* Running `syllago share --registry ` when the target registry is public and the content originates from a private (enterprise/team) registry
* The content’s source registry is marked as private in its configuration
## How to Fix
1. Share to a private registry instead
2. Or move the content to your local library first (which strips the private-origin metadata), then share from there
3. If the content should be public, copy it to your local library (removing the private origin) and share from there
## Example Output
```plaintext
Error PRIVACY_001: cannot share private content to public registry "community-rules"
Suggestion: move content to a public registry first, or share to a private registry
```
# PRIVACY_002 — Privacy Share Blocked
> Content from a private registry cannot be shared to a public repository. The privacy gate prevents accidental exposure of private content.
[Source](/errors/privacy-002/)
## What This Means
Content from a private registry cannot be shared to a public repository. The privacy gate prevents accidental exposure of private content.
## Common Causes
* Running `syllago share` targeting a public git repository with content that originates from a private registry
* The target repository is publicly accessible but the content’s source registry is private
## How to Fix
1. Share to a private repository instead
2. Or move the content to your local library first (which strips the private-origin metadata), then share from there
3. Verify the target repository’s visibility matches your intent
## Example Output
```plaintext
Error PRIVACY_002: cannot share private content to public repo "github.com/org/public-rules"
Suggestion: share to a private repository, or move content to your local library first
```
# PRIVACY_003 — Privacy Loadout Warn
> A loadout being created or applied includes items that originate from private registries. This is a warning, not a blocking error.
[Source](/errors/privacy-003/)
## What This Means
A loadout being created or applied includes items that originate from private registries. This is a warning, not a blocking error.
## Common Causes
* A loadout mixes items from both private and public registries
* A loadout is being created from items that include private registry content
* An existing loadout was updated and now references private items
## How to Fix
1. This is a warning — no action is required if mixing private and public content is intentional
2. Review the listed items to confirm you intend to include private content
3. If the loadout will be shared publicly, consider replacing private items with public equivalents
## Example Output
```plaintext
Error PRIVACY_003: loadout "my-setup" contains 2 items from private registries
Suggestion: review private items; this is a warning if mixing private/public content is intended
```
# PROMOTE_001 — Promote Dirty Tree
> The working tree has uncommitted changes that must be resolved before promoting content.
[Source](/errors/promote-001/)
## What This Means
The working tree has uncommitted changes that must be resolved before promoting content.
## Common Causes
* Modified files in the syllago library that have not been committed
* Untracked files in the content directory
* A previous promote operation was interrupted, leaving partial changes
## How to Fix
1. Run `git status` in your syllago library to see uncommitted changes
2. Commit your changes: `git add . && git commit -m "your message"`
3. Or stash them temporarily: `git stash`
4. Then retry the promote operation
## Example Output
```plaintext
Error PROMOTE_001: uncommitted changes in working tree
Suggestion: commit or stash your changes before promoting content
```
# PROMOTE_002 — Promote Validation
> The content failed validation checks that run before promotion. Content must be structurally valid before it can be shared.
[Source](/errors/promote-002/)
## What This Means
The content failed validation checks that run before promotion. Content must be structurally valid before it can be shared.
## Common Causes
* Missing required fields in content metadata (e.g., no `name` or `description`)
* Invalid YAML syntax in configuration files
* Content references files that do not exist
* Hook definitions with invalid event names or tool names
## How to Fix
1. Review the validation errors in the command output — each will describe the specific issue
2. Fix the structural issues in your content files
3. Run `syllago inspect - ` to verify the content is valid
4. Retry the promote operation
## Example Output
```plaintext
Error PROMOTE_002: content validation failed: missing required field "description" in rules/my-rule
Suggestion: fix validation errors shown above, then retry
```
# PROMOTE_003 — Promote Git Failed
> A git operation (creating a branch, committing, or pushing) failed during the promote process.
[Source](/errors/promote-003/)
## What This Means
A git operation (creating a branch, committing, or pushing) failed during the promote process.
## Common Causes
* No git remote configured for the repository
* Push was rejected (e.g., remote branch has diverged)
* Git authentication failed (expired token, missing SSH key)
* Network connectivity issues
## How to Fix
1. Verify a git remote is configured: `git remote -v`
2. Check that you have push access to the remote repository
3. If authentication failed, refresh your credentials (SSH key, personal access token, etc.)
4. If the remote branch has diverged, pull the latest changes first: `git pull --rebase`
## Example Output
```plaintext
Error PROMOTE_003: git push failed: authentication required
Suggestion: ensure git remote is configured and you have push access
```
# PROVIDER_001 — Provider Not Found
> The provider name you specified is not recognized by syllago. The slug does not match any supported AI coding tool provider.
[Source](/errors/provider-001/)
## What This Means
The provider name you specified is not recognized by syllago. The slug does not match any supported AI coding tool provider.
## Common Causes
* Typo in the provider name
* Using the full tool name instead of the slug (e.g., “Claude Code” instead of “claude-code”)
* The provider is not yet supported by syllago
## How to Fix
1. List supported providers: `syllago info providers`
2. Use the exact provider slug shown in the list.
3. Check for typos in the provider name you specified.
## Example Output
```plaintext
Error PROVIDER_001: unknown provider "claudecode"
Suggestion: run 'syllago info providers' to see supported providers
```
# PROVIDER_002 — Provider Not Detected
> The specified provider was not detected on your system. Syllago looks for provider-specific configuration directories to determine which AI coding ...
[Source](/errors/provider-002/)
## What This Means
The specified provider was not detected on your system. Syllago looks for provider-specific configuration directories to determine which AI coding tools are installed.
## Common Causes
* The AI coding tool is not installed on this machine
* The tool’s configuration directory is missing or in a non-standard location
* The tool was installed but hasn’t been run yet (config directory created on first run)
## How to Fix
1. Install the AI coding tool if you haven’t already.
2. Run the tool at least once so it creates its configuration directory.
3. Check if the provider’s config directory exists in the expected location (e.g., `~/.claude/` for Claude Code).
## Example Output
```plaintext
Error PROVIDER_002: provider "claude-code" not detected
Suggestion: install Claude Code or verify its config directory exists
```
# REGISTRY_001 — Registry Clone
> Syllago failed to clone a registry repository using git. The remote repository could not be fetched.
[Source](/errors/registry-001/)
## What This Means
Syllago failed to clone a registry repository using git. The remote repository could not be fetched.
## Common Causes
* Network connectivity issues
* Invalid or mistyped registry URL
* Private repository without proper authentication configured
* Git not installed or not in PATH
* Remote server is down or unreachable
## How to Fix
1. Verify the registry URL is correct and accessible: `git ls-remote `
2. Check your network connection.
3. For private registries, ensure your git credentials are configured (SSH key or token).
4. Verify git is installed: `git --version`
## Example Output
```plaintext
Error REGISTRY_001: failed to clone registry
Suggestion: check the registry URL and your network connection
```
# REGISTRY_002 — Registry Not Found
> The specified registry name was not found in your syllago configuration. No registry with that name has been added.
[Source](/errors/registry-002/)
## What This Means
The specified registry name was not found in your syllago configuration. No registry with that name has been added.
## Common Causes
* Typo in the registry name
* The registry has not been added yet
* The registry was previously removed
## How to Fix
1. List your configured registries: `syllago registry list`
2. Check for typos in the registry name you specified.
3. If the registry isn’t listed, add it: `syllago registry add `
## Example Output
```plaintext
Error REGISTRY_002: registry "my-reg" not found
Suggestion: run 'syllago registry list' to see available registries
```
# REGISTRY_003 — Registry Not Allowed
> The registry URL you tried to use is blocked by the `allowedRegistries` policy in your configuration. This is a security control that restricts whi...
[Source](/errors/registry-003/)
## What This Means
The registry URL you tried to use is blocked by the `allowedRegistries` policy in your configuration. This is a security control that restricts which registries can be used.
## Common Causes
* Your organization has configured an allowlist of approved registries
* The registry URL doesn’t match any entry in the `allowedRegistries` list
* A workspace or global config restricts registry sources
## How to Fix
1. Check the allowed registries in your config: look for `allowedRegistries` in `.syllago/config.json`.
2. If you believe this registry should be allowed, contact your administrator to update the policy.
3. Use a registry that is already on the approved list.
## Example Output
```plaintext
Error REGISTRY_003: registry URL not in allowedRegistries
Suggestion: check your allowedRegistries policy or contact your admin
```
# REGISTRY_004 — Registry Invalid
> The registry name or structure is invalid. Syllago requires registry names to follow a specific format and registry directories to contain the expe...
[Source](/errors/registry-004/)
## What This Means
The registry name or structure is invalid. Syllago requires registry names to follow a specific format and registry directories to contain the expected layout.
## Common Causes
* Registry name contains invalid characters (spaces, special characters)
* Registry directory is missing required structure or metadata
* Corrupted registry clone
## How to Fix
1. Use alphanumeric characters and hyphens for registry names (e.g., `my-registry`).
2. Verify the registry repository has the expected directory structure.
3. If the registry was partially cloned, try removing it and re-adding: `syllago registry remove ` then `syllago registry add `.
## Example Output
```plaintext
Error REGISTRY_004: invalid registry "my registry!"
Suggestion: use alphanumeric characters and hyphens only
```
# REGISTRY_005 — Registry Duplicate
> A registry with the specified name already exists in your configuration. Registry names must be unique.
[Source](/errors/registry-005/)
## What This Means
A registry with the specified name already exists in your configuration. Registry names must be unique.
## Common Causes
* Trying to add a registry that was previously added
* Using a name that collides with an existing registry
## How to Fix
1. List existing registries to confirm: `syllago registry list`
2. Choose a different name for the new registry.
3. If you want to replace the existing one, remove it first: `syllago registry remove `
## Example Output
```plaintext
Error REGISTRY_005: registry "community" already exists
Suggestion: use a different name or remove the existing registry first
```
# REGISTRY_006 — Registry Not Cloned
> The registry is listed in your configuration but its local clone is missing. Syllago knows about the registry but cannot access its content.
[Source](/errors/registry-006/)
## What This Means
The registry is listed in your configuration but its local clone is missing. Syllago knows about the registry but cannot access its content.
## Common Causes
* The local cache was cleared or deleted
* The registry directory was manually removed
* First run after importing a config from another machine
* The clone was interrupted and never completed
## How to Fix
1. Sync your registries to re-clone missing ones: `syllago registry sync`
2. If sync fails, try removing and re-adding the registry: `syllago registry remove ` then `syllago registry add `
## Example Output
```plaintext
Error REGISTRY_006: registry "community" not cloned
Suggestion: run 'syllago registry sync' to fetch missing registries
```
# REGISTRY_007 — Registry Sync Failed
> Syllago failed to update a registry's local clone during sync. The git pull operation did not complete successfully.
[Source](/errors/registry-007/)
## What This Means
Syllago failed to update a registry’s local clone during sync. The git pull operation did not complete successfully.
## Common Causes
* Network connectivity issues
* Merge conflicts in the local clone (local modifications)
* The remote branch was force-pushed, causing history divergence
* Remote server is temporarily unavailable
## How to Fix
1. Check your network connection.
2. Try syncing again: `syllago registry sync`
3. If the problem persists, remove and re-add the registry to get a fresh clone: `syllago registry remove ` then `syllago registry add `
## Example Output
```plaintext
Error REGISTRY_007: failed to sync registry "community"
Suggestion: check your network connection, or try removing and re-adding the registry
```
# REGISTRY_008 — Registry Save Failed
> Syllago could not save changes to the registry configuration file. The operation completed in memory but failed to persist to disk.
[Source](/errors/registry-008/)
## What This Means
Syllago could not save changes to the registry configuration file. The operation completed in memory but failed to persist to disk.
## Common Causes
* Permission issues on the config file or its parent directory
* Disk is full
* The config file is locked by another process
* The `.syllago` directory was deleted mid-operation
## How to Fix
1. Check write permissions on the config file: `ls -la .syllago/config.json`
2. Verify available disk space: `df -h .`
3. Ensure no other process has the file locked.
4. Check that the `.syllago` directory still exists.
## Example Output
```plaintext
Error REGISTRY_008: failed to save registry config
Suggestion: check write permissions on .syllago/config.json
```
# SYSTEM_001 — System Homedir
> Syllago could not determine the user's home directory, which is needed for locating configuration and content files.
[Source](/errors/system-001/)
## What This Means
Syllago could not determine the user’s home directory, which is needed for locating configuration and content files.
## Common Causes
* The `HOME` environment variable is not set
* Running under an unusual OS configuration or containerized environment without a home directory
* Running as a system user without a home directory assigned
## How to Fix
1. Set the `HOME` environment variable: `export HOME=/home/youruser`
2. Run syllago from a standard user account that has a home directory
3. In containers, ensure the `HOME` variable is set in the Dockerfile or entrypoint
## Example Output
```plaintext
Error SYSTEM_001: cannot determine home directory
Suggestion: set the HOME environment variable, or run from a standard user account
```
# SYSTEM_002 — System IO
> A filesystem operation (reading, writing, or creating directories) failed unexpectedly.
[Source](/errors/system-002/)
## What This Means
A filesystem operation (reading, writing, or creating directories) failed unexpectedly.
## Common Causes
* Permission denied on the target path
* Disk is full
* Path is too long for the filesystem
* Corrupted filesystem or inaccessible mount
* Another process holds a lock on the file
## How to Fix
1. Check available disk space: `df -h`
2. Verify permissions on the target path: `ls -la `
3. If permission denied, adjust ownership or permissions: `chmod` / `chown`
4. If the path is on a network mount, verify the mount is accessible
## Example Output
```plaintext
Error SYSTEM_002: failed to create directory "/home/user/.syllago/library": permission denied
Suggestion: check disk space and verify permissions on the target path
```
# For AI assistants
> Machine-readable documentation for AI coding assistants and LLMs to learn about syllago.
[Source](/for-ai-assistants/)
Syllago supports the [llms.txt](https://llmstxt.org/) standard — a convention that makes documentation machine-readable for Large Language Models.
## Available resources
These files are generated automatically from the same source as this documentation site.
| Resource | Description | Best for |
| --------------------------------- | ------------------------------------- | ----------------------------- |
| [llms.txt](/llms.txt) | Index of available documentation sets | Discovery |
| [llms-small.txt](/llms-small.txt) | Condensed documentation | Quick context, smaller models |
| [llms-full.txt](/llms-full.txt) | Complete documentation | Comprehensive understanding |
## How to use these
Feed these resources to your AI coding assistant when you need help working with syllago.
**Paste into a chat:** Copy the content of `llms-full.txt` into Claude, ChatGPT, or any LLM chat, then ask your question.
**Use with CLI tools:**
```bash
# Feed syllago docs to Claude Code
curl -s https://syllago.dev/llms-full.txt | pbcopy
# Use with any tool that accepts URLs
# Many AI tools can fetch URLs directly
```
**Context window tips:**
* Use `llms-small.txt` when you just need an overview or are working with smaller context windows
* Use `llms-full.txt` when you need detailed information about specific features
* The **Copy page** button (top-right of any page) copies individual page content for focused questions
# Core Concepts
> How syllago works — providers, content types, collections, and format conversion.
[Source](/getting-started/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 |
| Factory Droid | Factory’s CLI coding agent |
| Crush | Charm’s terminal AI agent |
| Pi | Terminal-based AI agent |
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](/using-syllago/providers.md).
## 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](/using-syllago/content-types.md).
## 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:
```bash
syllago add --from # 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:
```bash
syllago registry add
syllago registry sync
syllago registry items
```
When you’ve created content locally that you want to share back, use `syllago share` — pass `--to ` to open a PR against a registry repo, or omit it to share directly with a default team repo:
```bash
syllago share my-skill --to team-registry
```
### 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.”
```bash
syllago loadout create # define a loadout
syllago loadout apply # preview what would happen (default)
syllago loadout apply --try # apply temporarily, auto-reverts on session end
syllago loadout apply --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](/using-syllago/collections.md).
## Format conversion
This is the mechanism that makes everything else work. syllago uses a **hub-and-spoke model** for format conversion:
```plaintext
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](/using-syllago/format-conversion.md).
***
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.
# Installation
> Install syllago on Linux, macOS, or Windows.
[Source](/getting-started/installation/)
## System requirements
| Requirement | Details |
| ---------------- | ----------------------------------------------------- |
| **OS** | Linux, macOS, Windows (WSL or msys/mingw/cygwin) |
| **Architecture** | x86\_64 (amd64) or arm64 |
| **Go** | 1.26+ (only for `go install` or building from source) |
## Install script (recommended)
Downloads the latest release binary and verifies its SHA-256 checksum. Works on Linux, macOS, and Windows.
```bash
curl -fsSL https://raw.githubusercontent.com/OpenScribbler/syllago/main/install.sh | sh
```
Installs to `~/.local/bin` by default. To override the install directory:
```bash
curl -fsSL https://raw.githubusercontent.com/OpenScribbler/syllago/main/install.sh | INSTALL_DIR=/usr/local/bin sh
```
The install script creates a `syl` alias symlink automatically, so you can use either `syllago` or `syl` to run commands.
## Homebrew
```bash
brew install openscribbler/tap/syllago
```
## Go install
```bash
go install github.com/OpenScribbler/syllago/cli/cmd/syllago@latest
```
Requires Go 1.26+.
## From source
Requires Go 1.26+.
```bash
git clone https://github.com/OpenScribbler/syllago.git
cd syllago
make build
```
## Verify installation
```bash
syllago version
```
## Self-update
```bash
syllago update
```
Updates syllago to the latest release.
## Shell completions
syllago generates completions for bash, zsh, fish, and PowerShell.
* Bash
Current session:
```bash
source <(syllago completion bash)
```
Permanent (Linux):
```bash
syllago completion bash > /etc/bash_completion.d/syllago
```
Permanent (macOS):
```bash
syllago completion bash > $(brew --prefix)/etc/bash_completion.d/syllago
```
* Zsh
Current session:
```bash
source <(syllago completion zsh)
```
Permanent (Linux):
```bash
syllago completion zsh > "${fpath[1]}/_syllago"
```
Permanent (macOS):
```bash
syllago completion zsh > $(brew --prefix)/share/zsh/site-functions/_syllago
```
* Fish
Current session:
```bash
syllago completion fish | source
```
Permanent:
```bash
syllago completion fish > ~/.config/fish/completions/syllago.fish
```
* PowerShell
Current session:
```powershell
syllago completion powershell | Out-String | Invoke-Expression
```
## Next steps
Head to the [Quick Start](/getting-started/quick-start.md) to start managing your AI coding tool content.
# Quick Start
> Get up and running with syllago in under five minutes.
[Source](/getting-started/quick-start/)
This guide covers two paths to get started with syllago:
1. **Import from your existing tools** — pull in rules, skills, or context you already have configured in an AI coding tool
2. **Browse a registry** — discover and install shared content from a team or community registry
Both paths start with `syllago init`.
## Import from your existing tools
If you already have AI coding tools configured (Claude Code rules, Cursor rules, etc.), syllago can discover that content and bring it into your library.
### Initialize syllago
```bash
syllago init
```
This detects AI coding tools (providers) on your machine and creates your config at `.syllago/config.json`. Follow the interactive prompts, or pass `--yes` to accept defaults.
### Discover available content
```bash
syllago add --from claude-code
```
Without a positional argument, `add` runs in **discovery mode** — it shows what content the provider has available without importing anything.
### Add content to your library
Once you know what’s there, add it:
```bash
# Add all rules from a provider
syllago add rules --from claude-code
# Add a specific item
syllago add rules/security --from claude-code
```
Content is copied into your library (`~/.syllago/content/`), where syllago manages it independently of the original provider.
> **Tip:** Use `--dry-run` to preview what would be written without making changes. Use `--all` to add everything at once.
### See what you have
```bash
syllago list
```
Output is grouped by type (rules, skills, agents, etc.). Use `--source` to filter by origin and `--type` to filter by content type.
### Install to another provider
```bash
syllago install my-rule --to cursor
```
This installs the item from your library into Cursor’s expected location, converting the format automatically. By default, syllago uses a **symlink** so changes stay in sync. Pass `--method copy` if you need a standalone file.
```bash
# Preview what would happen without writing anything
syllago install my-rule --to cursor --dry-run
```
That’s it — you’ve moved content from one AI coding tool to another with format conversion handled for you.
## Browse a registry
Registries are git-based repos of shared content. Use them to pull in team standards, community collections, or curated configurations.
### Initialize syllago
Skip this if you already ran it above.
```bash
syllago init
```
### Add a registry
```bash
syllago registry add https://github.com/team/ai-configs.git
```
You can optionally pass `--name` to give it a short alias, or `--ref` to pin a specific branch or tag.
### Sync registry content
```bash
syllago registry sync
```
This pulls the latest content from all registered registries. To sync a specific one, pass its name: `syllago registry sync my-registry`.
### Browse available items
```bash
syllago registry items
```
Filter by type to narrow results:
```bash
syllago registry items --type skills
```
### Install from the registry
```bash
syllago install some-skill --to claude-code
```
Same `install` command as before — syllago resolves the item from your registries, converts the format for the target provider, and symlinks it into place.
### Or use the TUI
Launch the interactive terminal UI to browse and install content visually:
```bash
syllago
```
Running `syllago` with no arguments opens the TUI, where you can explore your library, registries, and providers in one place.
## Next steps
Now that you have content flowing between tools, learn how the pieces fit together in [Core Concepts](/getting-started/core-concepts.md).
# MOAT: Model for Origin Attestation and Trust
> How syllago implements MOAT — the open protocol for registry manifest attestation, revocation, and signing-identity verification — across registry sync, installs, trusted-root management, and the TUI.
[Source](/moat/)
[MOAT](https://github.com/OpenScribbler/moat) — the **Model for Origin Attestation and Trust** — is an open protocol for publishing, verifying, and revoking content through a signed manifest. Publishers attest to what they released, registries aggregate and re-attest, and clients verify the chain of custody against a Sigstore transparency log before trusting any content.
Syllago adopts MOAT as its provenance layer. This page describes the pieces of syllago that implement the protocol and the operator-facing surfaces that expose the results.
## Why Syllago uses MOAT
MOAT solves a problem that comes up the moment you have more than one registry and more than one publisher: **how does an operator know the content they just installed is what the publisher actually released?** The usual answers are central PKI, hosted package stores, or “trust the URL.” All three have known failure modes.
MOAT takes a different approach:
* **Keyless Sigstore signing.** Publishers sign with short-lived Fulcio certificates tied to an OIDC identity (a GitHub Actions workflow, an OIDC-federated CI job, etc.) and record the signature in the Rekor transparency log. No long-lived keys to rotate, lose, or steal.
* **Three tiers of attestation.** Unsigned, Signed, and Dual-Attested — with an explicit spec rule that *absence of a stronger signal is not a negative signal*. See [Trust Tiers](/moat/trust-tiers.md).
* **First-class revocation.** A manifest can carry revocations from either the registry or the publisher, and each source has different semantics (hard-block vs. warn).
* **No central registry of registries.** Each operator adds the registries they trust and pins the signing identity at add-time, so a repository rename or transfer cannot silently swap the source of content. See [Registry Signing Identity](/moat/registry-add-signing-identity.md).
For the full protocol, see the [MOAT specification](https://github.com/OpenScribbler/moat). The rest of this page documents what syllago implements.
## What syllago implements
### Trust tiers and the install gate
Every item syllago installs from a MOAT registry is classified as `Unsigned`, `Signed`, or `Dual-Attested`, based on the fields the manifest carries. The install gate evaluates the tier, revocation state, privacy flag, and policy floor and produces one of five outcomes:
| Gate decision | Behavior |
| ----------------- | ----------------------------------------------------------------------------------------- |
| `Proceed` | Tier meets policy, no revocation, not private — install continues. |
| `HardBlock` | Registry-source revocation. Install refuses; structured error surfaces the reason. |
| `PublisherWarn` | Publisher-source revocation. Interactive `Y/n` prompt; non-interactive callers exit `12`. |
| `PrivatePrompt` | `private_repo=true`. Interactive `Y/n`; non-interactive callers exit `10`. |
| `TierBelowPolicy` | Item tier is below the configured minimum. Install refuses. |
Each install emits telemetry tagging both the observed tier (`moat_tier`) and the gate decision (`moat_gated`), so operators can measure the trust distribution of their actual installs over time.
For the tier classification rules, badge presentation, and the revocation two-tier contract, see [Trust Tiers](/moat/trust-tiers.md).
### Registry signing identity
Syllago pins a cryptographic signing identity to every MOAT registry at `registry add` time. Well-known registries are covered by a bundled allowlist; others require `--signing-*` flags or a non-GitHub OIDC issuer. The pinning resists rename and transfer attacks by binding to the numeric repository and owner IDs, not just the URL.
See [Registry Signing Identity](/moat/registry-add-signing-identity.md) for the operator workflow, the three paths to pin an identity, and the escape hatch for air-gapped deployments.
### Trusted-root lifecycle
Syllago ships a bundled Sigstore trusted root and exposes its freshness through a dedicated command:
```bash
syllago moat trust status
```
The output is key=value lines (with a `--json` option for scripts). Exit codes are stable and CI-grep-friendly:
| Exit | State | Verification behavior |
| ---- | ----------------------------------- | ------------------------- |
| `0` | Fresh (age < 90 days) | Runs |
| `1` | Warn (90–179) / Escalated (180–364) | Runs, with stderr warning |
| `2` | Expired (365+), missing, or corrupt | Refuses |
Expired roots are resolved by running `syllago update`. Operators who pin their own trusted root via `--trusted-root` or `reg.trusted_root` take responsibility for refreshing it — the 365-day cliff applies only to the bundled root.
### Registry sync and non-interactive exit codes
Every `syllago registry sync` verifies the manifest against the pinned signing profile, merges revocations into the lockfile, and advances the last-fetched-at timestamp. When the sync cannot silently proceed in a pipeline, syllago exits with a distinct code so CI can branch on the exact condition:
| Exit | Condition | Recovery |
| ---- | --------------------------------------------------------------------------- | ---------------------------------------------------- |
| `10` | TOFU: first registry add requires human approval. | Run `syllago registry add` interactively. |
| `11` | `registry_signing_profile` has moved — possible key rotation or compromise. | Run `syllago registry approve ` interactively. |
| `12` | Publisher-source revocation hit during a non-interactive install. | Acknowledge interactively, or choose an alternative. |
| `13` | Manifest is stale (over 72 hours since last successful fetch). | Run `syllago registry sync` before the next install. |
Each exit is accompanied by a kebab-case label on stderr (`tofu-acceptance`, `signing-profile-change`, `publisher-revocation`, `manifest-stale`) so pipelines can grep the failure class without parsing the exit code.
The 72-hour staleness threshold is the MOAT default; a registry’s manifest can override it with an explicit `expires` field.
### TUI trust inspector
The syllago TUI interface surfaces trust state directly on each library row and registry card. A trust badge (`✓` Verified / `R` Recalled / none) sits next to every item, and the metadata panel shows the drill-down tier and recall reason.
For a full view, the **Trust Inspector** modal (reachable from both the library and registries tabs) shows:
* **Item scope:** tier, detail text, visibility, and any recall fields (source, reason, issuer, details URL).
* **Registry scope:** the aggregate — tier, issuer, subject, operator, manifest URI, last fetched-at, staleness, and item counts (total / verified / recalled / private).
The inspector is the same modal for both scopes, so the shape of the information is consistent regardless of where an operator opened it from. See [Trust Tiers](/moat/trust-tiers/#the-trust-inspector) for the full field list.
### Structured errors
Every MOAT failure mode maps to a stable error code with documented remediation. The seven codes in the `MOAT_*` band cover unpinned identity, malformed flags, mismatched certificates, malformed bundles, stale trusted roots, pinned-without-manifest mismatches, and unusable override roots. See the [MOAT error codes](/errors/#moat-errors) for the full list.
## Spec alignment
Syllago tracks MOAT **v0.6.x Draft**. The spec is pre-1.0; syllago follows it as it evolves, and signing-profile changes on existing registries may trigger a re-approval prompt (exit `11`) when a registry operator rotates their identity — which is the protocol working as designed.
Note
Syllago’s implementation stays intentionally close to the spec. Where syllago adds its own concept — like the catalog-layer `Unknown` label for non-MOAT content, or the closed-set exit-code band `10`–`13` for non-interactive failures — the deviation is documented and the reasoning recorded as an Architecture Decision Record (ADR) — see [ADR 0007](https://github.com/OpenScribbler/syllago/blob/main/docs/adr/0007-moat-slice-1.md).
# Registry Signing Identity
> How syllago pins cryptographic identities to registries at add-time so repository renames and forgeries cannot silently swap the source of your content.
[Source](/moat/registry-add-signing-identity/)
Syllago’s Model for Origin Attestation and Trust (MOAT) implementation verifies every registry manifest against a pinned cryptographic identity before content transitions into your library. The identity is pinned at registry-add time — not at every verify — so an attacker who later gains control of the registry’s repository or CI workflow cannot silently swap the source of your content.
This page covers the operator workflow for `syllago registry add` and the three ways to pin an identity. The protocol detail is captured in an Architecture Decision Record (ADR) — see [ADR 0007 in the syllago repo](https://github.com/OpenScribbler/syllago/blob/main/docs/adr/0007-moat-slice-1.md).
## Why pinning matters
GitHub lets an organization rename or transfer a repository at any moment, and the new owner inherits the old URL. Sigstore Fulcio certificates embed a **numeric** repository ID and owner ID alongside the human-readable URL. Pinning those numeric IDs at `registry add` time means:
* A repository rename or transfer flips the numeric IDs, verification fails loudly, and syllago refuses to add content.
* Two orgs with identical URLs (`example/tool` vs `example/tool` under a different parent after a transfer) are cryptographically distinguishable.
* You commit to a specific publishing identity the day you add the registry. No TOFU (trust-on-first-use) surprises months later.
The identity is persisted to `~/.syllago/config.json` in a `signing_profile` object on the registry entry. Subsequent syncs and adds verify against that pinned profile.
## Three paths to pin an identity
### 1. Well-known registries (nothing to do)
Syllago ships with a bundled allowlist covering the public meta-registry and a small number of other well-known syllago ecosystem registries. For those, `syllago registry add ` just works — the allowlist supplies the signing profile automatically.
```plaintext
syllago registry add https://github.com/OpenScribbler/syllago-meta-registry
Trust: signed (registry OpenScribbler/syllago-meta-registry, root: bundled)
```
If the URL matches an allowlist entry, syllago silently adopts its pinned profile. You do not need to pass `--signing-*` flags.
### 2. GitHub-hosted registries (pass numeric IDs)
For a GitHub-hosted registry not in the bundled allowlist, pass the identity explicitly:
```bash
syllago registry add https://github.com/acme/tools-registry \
--signing-identity 'https://github.com/acme/tools-registry/.github/workflows/moat-registry.yml@refs/heads/main' \
--signing-repository-id 1234567890 \
--signing-repository-owner-id 987654321
```
The `--signing-identity` value is the full GitHub Actions workflow identity that publishes the registry’s manifest. The numeric IDs come from the GitHub REST API:
```bash
gh api repos/acme/tools-registry --jq '{id, owner_id: .owner.id}'
# → {"id": 1234567890, "owner_id": 987654321}
```
Tip
Confirm the numeric IDs out-of-band with the registry’s publisher before adding. That is the whole point of pinning — if an attacker has already compromised the registry, the published numeric IDs could be wrong.
### 3. Non-GitHub OIDC issuers (slice-2 scope)
For registries signed against a non-GitHub OIDC issuer, pass `--signing-issuer` alongside `--signing-identity`:
```bash
syllago registry add https://git.internal.example/team/registry \
--signing-issuer https://oidc.internal.example \
--signing-identity 'ci@internal.example'
```
Numeric IDs are optional for non-GitHub issuers at slice-2 scope. Additional issuer support (GitLab, Azure, etc.) arrives in later slices.
## The trust label
Every successful `syllago add --from ` against a MOAT registry emits a trust label:
```plaintext
Trust: signed (registry acme/tools-registry, root: bundled)
```
The three-state label is intentional:
| Label | Meaning |
| ---------- | ---------------------------------------------------------------------------------- |
| `signed` | Manifest signature valid, pinned identity matched, trusted root fresh. |
| `unsigned` | Registry has no pinned profile and no manifest — slice-1 legacy mode. |
| `invalid` | Verification attempted but rejected. The add aborts and surfaces a `MOAT_*` error. |
The word `verified` is deliberately **not** used at slice 2. It is reserved for when revocation checking lands in a later slice.
## Escape hatch: `--trusted-root`
For enterprise or air-gapped deployments that pin a specific Sigstore trusted root, pass `--trusted-root` on `syllago add` or persist a `trusted_root` path on the registry in `config.json`:
```bash
syllago add loadout/daily --from acme/tools-registry \
--trusted-root /etc/syllago/corp-trusted-root.json
```
Precedence: the CLI flag wins over the per-registry config, which wins over the bundled default. Syllago emits an auditor-visible marker on stderr when an override is in use:
```plaintext
moat.trusted_root_path=/etc/syllago/corp-trusted-root.json (registry=acme/tools-registry)
```
Override roots are **not** staleness-gated — the 365-day cliff only applies to the bundled root that ships with the syllago binary. Operators who supply their own trusted root take responsibility for refreshing it.
## When verification fails
If any `--signing-*` flag is passed but verification cannot be satisfied, syllago returns a structured `MOAT_*` error and refuses to add content. No silent fall-back to unsigned mode — a pinned profile means the operator has opted into cryptographic gating.
| Code | Meaning |
| ------------------------------- | ---------------------------------------------------------------------- |
| [`MOAT_001`](/errors/moat-001.md) | No allowlist match and no `--signing-identity` supplied. |
| [`MOAT_002`](/errors/moat-002.md) | `--signing-*` flags are incomplete or malformed. |
| [`MOAT_003`](/errors/moat-003.md) | Manifest certificate does not match the pinned profile. |
| [`MOAT_004`](/errors/moat-004.md) | Manifest or bundle is malformed, missing, or unreadable. |
| [`MOAT_005`](/errors/moat-005.md) | Bundled trusted root exceeded its 365-day cliff. Run `syllago update`. |
| [`MOAT_006`](/errors/moat-006.md) | Pinned profile but no manifest/bundle in the checkout. |
| [`MOAT_007`](/errors/moat-007.md) | `--trusted-root` or `reg.trusted_root` path cannot be loaded. |
## FAQ
### Why not prompt interactively?
Hard-fail is defense-in-depth. An interactive prompt trains operators to mash `y` without actually confirming the numeric IDs out-of-band. A CI pipeline also cannot respond to a prompt — the only way to pass `--signing-*` flags is to hard-code the identity somewhere, which is exactly what you want. The failure is also CI-safe: the exit code is non-zero, so pipelines fail loudly rather than silently proceeding unsigned.
### What happens on registry rename?
Numeric IDs do not change on rename; they change on **transfer** to a new owner. After a rename, verification continues to succeed. After a transfer to a different owner, verification fails with `MOAT_003` and the operator must re-add against the new numeric IDs out-of-band.
### Can I change the pinned identity later?
Yes. Remove the registry and re-add it with updated `--signing-*` flags:
```bash
syllago registry remove acme/tools-registry
syllago registry add https://github.com/acme/tools-registry --signing-identity '…' …
```
There is no in-place edit by design — re-adding forces the operator to re-confirm the identity.
## Contributing to the bundled allowlist
If you operate a public registry and want bundled inclusion so users can add your registry without `--signing-*` flags, open an issue on the [syllago repo](https://github.com/OpenScribbler/syllago/issues/new) with:
* Your registry’s public repository URL.
* The numeric repository ID and owner ID.
* The full signing identity (workflow path + ref).
* A link to at least one published manifest signed with that identity.
Allowlist inclusion is reviewed against the same ADR 0007 criteria that apply to ad-hoc pinning — the goal is to reduce friction for well-known registries, not to shortcut the trust model.
# Trust Tiers
> How syllago classifies MOAT content into trust tiers, collapses them into user-facing badges, and handles revocation, private repos, and tier policy at install time.
[Source](/moat/trust-tiers/)
Every item syllago installs from a MOAT registry carries a **trust tier** — a classification of how much cryptographic evidence backs its origin. Syllago derives the tier from the registry’s manifest, presents it to operators through badges and a dedicated inspector modal, and uses it to decide whether an install proceeds, prompts, or refuses.
This page documents how syllago computes the tier, what badges an operator sees, and how the install gate reacts to revocation, private-repo content, and tier policy.
## The three MOAT tiers
MOAT v0.6.x defines three normative tiers based on which fields a manifest entry carries:
| Tier | Required fields | Meaning |
| --------------- | ------------------------------------------------------------ | ------------------------------------------------------------------- |
| `Unsigned` | none beyond `name` / `content_hash` | Registry makes no attestation claim for this item. |
| `Signed` | `rekor_log_index` present | The registry has attested the item in a Sigstore transparency log. |
| `Dual-Attested` | `rekor_log_index` **and** per-item `signing_profile` present | Both the registry and the publisher have independently attested it. |
Note
MOAT’s three-tier model is deliberate: *absence of a stronger signal is not a negative signal*. An `Unsigned` entry is not accused of being malicious — the registry has simply made no cryptographic claim about it. Syllago follows the spec’s guidance and renders no “failed” badge for `Unsigned`.
## How Syllago computes the tier
The tier is derived from the manifest entry at parse time. Logic (from `cli/internal/moat/manifest.go`):
1. No `rekor_log_index` → `Unsigned`.
2. `attestation_hash_mismatch=true` → **downgrade** to `Signed`, regardless of whether a publisher profile is present.
3. Publisher `signing_profile` present → `Dual-Attested`.
4. Otherwise → `Signed`.
The `attestation_hash_mismatch` downgrade exists because a publisher profile paired with a hash mismatch means the registry’s attestation cannot be safely combined with the publisher’s — the two signatures disagree on what was signed. Rather than reject outright, the registry’s own attestation is preserved as the weaker `Signed` claim.
### The `Unknown` Presentation Label
Syllago’s catalog layer adds one additional label — `Unknown` — that is **not** a MOAT tier. It marks content that was never sourced from a MOAT manifest in the first place (git registries, local content, legacy installs). It exists only so the catalog never has to guess a tier for content the protocol has no opinion about; the drill-down simply shows no trust claim rather than fabricating one.
## Trust badges in the UI
The normative three-tier classification is preserved internally and in JSON output, but the headline badge an operator sees in the library and registry tabs collapses to three user-facing states:
| Condition | Badge | Glyph |
| ------------------------------------ | -------- | --------- |
| `Dual-Attested` or `Signed` | Verified | `✓` |
| Item revoked (either source) | Recalled | `R` |
| `Unsigned`, `Unknown`, no revocation | *(none)* | *(empty)* |
Tip
The recalled glyph is the ASCII letter `R`, not the Unicode cross `✗`. Syllago already uses `✗` in the converter compatibility matrix and `capmon validate` output to mean “unsupported,” and overloading a single glyph across trust and capability surfaces would be a bug hazard. A plain `R` keeps recall semantics distinct at a glance and renders cleanly in any terminal.
The drill-down text preserves the full tier — “Verified (dual-attested by publisher and registry)” vs “Verified (registry-attested)” — so an operator who wants to know *why* an item is verified can see it on the detail surface without the badge row becoming noisy.
## The trust inspector
The syllago TUI interface exposes a reusable **Trust Inspector** modal that renders the full trust story for either an item or a whole registry. The same modal serves both scopes so the user sees a consistent shape regardless of where they opened it from.
**Item scope** shows:
* Tier (`Dual-Attested` / `Signed` / `Unsigned` / `Unknown`)
* Detail (the full drill-down description)
* Visibility (`Public` / `Private`)
* Recall fields (`Status`, `Source`, `Reason`, `Issuer`, `Details`), when present
**Registry scope** shows the aggregate trust summary:
* Tier (the registry’s signing tier)
* Issuer / Subject / Operator (from the pinned signing profile)
* Manifest URI and last fetched-at timestamp
* Status (Fresh / Stale / Missing)
* Item counts (total, verified, recalled, private)
## Revocation: Two-tier contract
MOAT lets a manifest carry revocations from either the **registry** or the **publisher**. Syllago treats the two sources differently because they mean different things. The behavior is specified in the project’s Architecture Decision Record (ADR) 0007:
| Source | Install gate | Exit code (non-interactive) | Recovery |
| ----------- | ------------------- | ---------------------------- | --------------------------------------------------------------------------------- |
| `registry` | Hard-block | *(structured error, exit 1)* | Permanent (ADR 0007 G-15 — see Spec Alignment below). Choose an alternative item. |
| `publisher` | Warn + prompt `Y/n` | `12` (non-interactive only) | Interactive acknowledgement, scoped to one install call. |
A registry-source revocation is the registry operator stating that the content is no longer trustworthy — malicious, compromised, deprecated, or policy-violating. Syllago refuses the install outright; there is no prompt.
A publisher-source revocation is the publisher’s own advisory. Operators running an interactive install see the reason and confirm with `Y/n`; pipelines without a TTY exit with code `12` so the failure is unambiguous in CI.
Revocation reasons are drawn from a closed set: `malicious`, `compromised`, `deprecated`, `policy_violation`.
## Private-repo prompt
Manifest entries carrying `private_repo=true` trigger an interactive `Y/n` before install, acknowledging that the content originates from a private source. Non-interactive callers exit with code `10` (the TOFU-acceptance code is reused because the semantic shape is identical: a trust decision requiring human judgment that a pipeline has no authority to make).
## Tier policy floor
The install gate accepts a minimum tier. When an item’s tier is below that floor, syllago emits a structured `moat_tier_below_policy` error and refuses the install. The default floor is `Unsigned` — every valid tier passes — so the policy is available for operators who want to enforce `Signed` or `Dual-Attested` once their registries support it.
## Related error codes
The install gate and manifest verification surface these MOAT errors when trust cannot be established:
| Code | Condition |
| ------------------------------- | --------------------------------------------------------------- |
| [`MOAT_003`](/errors/moat-003.md) | Manifest certificate does not match the pinned signing profile. |
| [`MOAT_004`](/errors/moat-004.md) | Manifest or bundle is malformed, missing, or unreadable. |
| [`MOAT_005`](/errors/moat-005.md) | Bundled trusted root has aged past its 365-day cliff. |
| [`MOAT_007`](/errors/moat-007.md) | `--trusted-root` or `reg.trusted_root` path cannot be loaded. |
For the full list and recovery steps, see the [MOAT error codes](/errors/#moat-errors).
# Agents Comparison
> Cross-provider comparison of Agents support — formats, install methods, discovery paths, and frontmatter fields.
[Source](/reference/agents-matrix/)
Agent definitions configure autonomous sub-processes with specific tools, models, and behaviors. Providers vary significantly in agent format and capability.
## Format and Install Method
How each provider stores and installs agents.
| Provider | Format | Install Method | Symlink |
| -------------------------------------------------------- | -------- | -------------- | :-----: |
| [Claude Code](/using-syllago/providers/claude-code.md) | Markdown | Symlink | Yes |
| [Gemini CLI](/using-syllago/providers/gemini-cli.md) | Markdown | Symlink | Yes |
| [Cursor](/using-syllago/providers/cursor.md) | Markdown | Symlink | Yes |
| [Codex](/using-syllago/providers/codex.md) | TOML | Symlink | Yes |
| [Copilot CLI](/using-syllago/providers/copilot-cli.md) | Markdown | Symlink | Yes |
| [Roo Code](/using-syllago/providers/roo-code.md) | YAML | Project scope | Yes |
| [OpenCode](/using-syllago/providers/opencode.md) | Markdown | Symlink | Yes |
| [Kiro](/using-syllago/providers/kiro.md) | Markdown | Symlink | Yes |
| [Factory Droid](/using-syllago/providers/factory-droid.md) | Markdown | Symlink | Yes |
## Discovery Paths
Where each provider looks for agents files. Paths with `~/` are relative to the user’s home directory; others are relative to the project root.
| Provider | Discovery Paths | Global Install Path |
| -------------------------------------------------------- | ----------------------------------------------------- | --------------------------- |
| [Claude Code](/using-syllago/providers/claude-code.md) | `.claude/agents` | `~/.claude/agents` |
| [Gemini CLI](/using-syllago/providers/gemini-cli.md) | `.gemini/agents` | `~/.gemini/agents` |
| [Cursor](/using-syllago/providers/cursor.md) | `.cursor/agents`, `AGENTS.md` | `~/.cursor/agents` |
| [Codex](/using-syllago/providers/codex.md) | `.codex/agents` | `~/.codex` |
| [Copilot CLI](/using-syllago/providers/copilot-cli.md) | `.copilot/agents`, `.github/agents`, `.claude/agents` | `~/.github/agents` |
| [Roo Code](/using-syllago/providers/roo-code.md) | — | — |
| [OpenCode](/using-syllago/providers/opencode.md) | `.opencode/agents` | `~/.config/opencode/agents` |
| [Kiro](/using-syllago/providers/kiro.md) | `.kiro/agents` | `~/.kiro/agents` |
| [Factory Droid](/using-syllago/providers/factory-droid.md) | `.factory/droids` | `~/.factory/droids` |
## Frontmatter Fields
Which frontmatter fields each provider recognizes in agents files. A checkmark means the provider parses and uses that field during conversion.
| Field | Claude Code | Gemini CLI | Cursor | Codex | Copilot CLI | Roo Code | OpenCode | Kiro | Factory Droid |
| -------------------- | :---------: | :--------: | :----: | :---: | :---------: | :------: | :------: | :--: | :-----------: |
| `allowedTools` | — | — | — | — | — | — | — | ✓ | — |
| `background` | ✓ | — | — | — | — | — | — | — | — |
| `color` | ✓ | — | — | — | — | — | ✓ | — | — |
| `customInstructions` | — | — | — | — | — | ✓ | — | — | — |
| `description` | ✓ | ✓ | ✓ | — | ✓ | — | ✓ | ✓ | ✓ |
| `disallowedTools` | ✓ | — | — | — | — | — | — | — | — |
| `effort` | ✓ | — | — | — | — | — | — | — | — |
| `groups` | — | — | — | — | — | ✓ | — | — | — |
| `hooks` | ✓ | — | — | — | — | — | — | ✓ | — |
| `includeMcpJson` | — | — | — | — | — | — | — | ✓ | — |
| `includePowers` | — | — | — | — | — | — | — | ✓ | — |
| `is_background` | — | — | ✓ | — | — | — | — | — | — |
| `isolation` | ✓ | — | — | — | — | — | — | — | — |
| `keyboardShortcut` | — | — | — | — | — | — | — | ✓ | — |
| `kind` | ✓ | ✓ | — | — | — | — | — | — | — |
| `maxTurns` | ✓ | — | — | — | — | — | — | — | — |
| `max_turns` | — | ✓ | — | — | — | — | — | — | — |
| `mcp-servers` | — | — | — | — | ✓ | — | — | — | — |
| `mcpServers` | ✓ | — | — | — | — | — | — | ✓ | — |
| `memory` | ✓ | — | — | — | — | — | — | — | — |
| `model` | ✓ | ✓ | ✓ | — | ✓ | — | ✓ | ✓ | ✓ |
| `name` | ✓ | ✓ | ✓ | — | ✓ | ✓ | ✓ | ✓ | ✓ |
| `permissionMode` | ✓ | — | — | — | — | — | — | — | — |
| `readonly` | — | — | ✓ | — | — | — | — | — | — |
| `resources` | — | — | — | — | — | — | — | ✓ | — |
| `roleDefinition` | — | — | — | — | — | ✓ | — | — | — |
| `skills` | ✓ | — | — | — | — | — | — | — | — |
| `slug` | — | — | — | — | — | ✓ | — | — | — |
| `steps` | — | — | — | — | — | — | ✓ | — | — |
| `target` | — | — | — | — | ✓ | — | — | — | — |
| `temperature` | ✓ | ✓ | — | — | — | — | ✓ | — | — |
| `timeout_mins` | ✓ | ✓ | — | — | — | — | — | — | — |
| `toolAliases` | — | — | — | — | — | — | — | ✓ | — |
| `tools` | ✓ | ✓ | — | — | ✓ | — | ✓ | ✓ | ✓ |
| `toolsSettings` | — | — | — | — | — | — | — | ✓ | — |
| `welcomeMessage` | — | — | — | — | — | — | — | ✓ | — |
| `whenToUse` | — | — | — | — | — | ✓ | — | — | — |
**Not supported by:** [Windsurf](/using-syllago/providers/windsurf.md), [Zed](/using-syllago/providers/zed.md), [Cline](/using-syllago/providers/cline.md), [Amp](/using-syllago/providers/amp.md), [Pi](/using-syllago/providers/pi.md), [Crush](/using-syllago/providers/crush.md).
## See Also
* [Agents Content Type](/using-syllago/content-types/agents.md)
* [Providers Overview](/using-syllago/providers.md)
* [Compare Providers](/reference/compare-providers.md)
*Generated from syllago 0.13.0 on 2026-05-08.*
# Canonical Keys
> Cross-provider canonical keys for AI coding tool content, grouped by content type.
[Source](/reference/canonical-keys/)
Canonical keys are syllago’s cross-provider equivalents — the normalized names for fields, behaviors, and conventions that different AI coding tools express in their own ways. Each key below links to a detail page showing how every provider implements (or does not implement) that concept.
See [format conversion](/using-syllago/format-conversion.md) for how keys translate between providers.
## Agents
| Key | Description |
| ----------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| [`agent_scopes`](/reference/canonical-keys/agent-scopes.md) | Where agent definitions can live and the priority ordering when definitions exist at multiple levels |
| [`definition_format`](/reference/canonical-keys/definition-format.md) | What format agent definitions use |
| [`invocation_patterns`](/reference/canonical-keys/invocation-patterns.md) | How agents are triggered |
| [`model_selection`](/reference/canonical-keys/model-selection.md) | Whether per-agent model overrides are supported, allowing different agents to use different AI models |
| [`per_agent_mcp`](/reference/canonical-keys/per-agent-mcp.md) | Whether agents can have their own MCP server configuration, scoping which external tools each agent can access |
| [`subagent_spawning`](/reference/canonical-keys/subagent-spawning.md) | Whether agents can spawn, delegate to, or resume other agents |
| [`tool_restrictions`](/reference/canonical-keys/tool-restrictions.md) | Whether agents can be restricted to specific tools via allowlists, denylists, tool categories, or per-tool configuration maps |
## Commands
| Key | Description |
| --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| [`argument_substitution`](/reference/canonical-keys/argument-substitution.md) | How user-provided arguments are injected into command templates |
| [`builtin_commands`](/reference/canonical-keys/builtin-commands.md) | Whether the provider ships default/built-in commands alongside user-defined custom commands |
## Hooks
| Key | Description |
| --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| [`async_execution`](/reference/canonical-keys/async-execution.md) | Whether hooks can run asynchronously without blocking the agent’s execution loop |
| [`context_injection`](/reference/canonical-keys/context-injection.md) | Whether hooks can inject messages, system prompts, or conversation context into the agent’s active session |
| [`decision_control`](/reference/canonical-keys/decision-control.md) | Which decision actions hooks can take on the triggering action |
| [`handler_types`](/reference/canonical-keys/handler-types.md) | What kinds of executors hooks support beyond shell commands |
| [`hook_scopes`](/reference/canonical-keys/hook-scopes.md) | Where hooks can be configured and the precedence model when multiple scopes define hooks for the same event |
| [`input_modification`](/reference/canonical-keys/input-modification.md) | Whether hooks can modify tool input arguments before the tool executes |
| [`json_io_protocol`](/reference/canonical-keys/json-io-protocol.md) | Whether hooks communicate with the host via structured JSON on stdin/stdout rather than plain text or exit codes alone |
| [`matcher_patterns`](/reference/canonical-keys/matcher-patterns.md) | Whether hooks can filter which tools or events they respond to using name matching, regex patterns, or structured criteria |
| [`permission_control`](/reference/canonical-keys/permission-control.md) | Whether hooks can make or influence permission decisions determining whether a tool is available for invocation |
## MCP
| Key | Description |
| --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| [`auto_approve`](/reference/canonical-keys/auto-approve.md) | Whether specific MCP tools or entire servers can be configured for automatic approval without per-invocation user confirmation |
| [`enterprise_management`](/reference/canonical-keys/enterprise-management.md) | Whether the provider supports organization-level MCP configuration management, including managed server lists, allowlists, and enterprise registries |
| [`env_var_expansion`](/reference/canonical-keys/env-var-expansion.md) | Whether MCP server configuration supports environment variable expansion |
| [`marketplace`](/reference/canonical-keys/marketplace.md) | Whether the provider offers an in-IDE MCP server discovery and installation experience |
| [`oauth_support`](/reference/canonical-keys/oauth-support.md) | Whether the provider supports OAuth 2 |
| [`resource_referencing`](/reference/canonical-keys/resource-referencing.md) | Whether MCP resources (not just tools) can be accessed, typically via @-mention syntax or similar referencing mechanisms |
| [`tool_filtering`](/reference/canonical-keys/tool-filtering.md) | Which per-server tool filtering mechanisms the provider supports |
| [`transport_types`](/reference/canonical-keys/transport-types.md) | Which MCP transport protocols the provider supports |
## Rules
| Key | Description |
| ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| [`activation_mode`](/reference/canonical-keys/activation-mode.md) | How rules decide when to load into context |
| [`auto_memory`](/reference/canonical-keys/auto-memory.md) | Whether the provider auto-generates persistent rules from conversation context |
| [`cross_provider_recognition`](/reference/canonical-keys/cross-provider-recognition.md) | Which rule file formats from other providers this provider recognizes |
| [`file_imports`](/reference/canonical-keys/file-imports.md) | Whether rules can reference or include content from other files |
| [`hierarchical_loading`](/reference/canonical-keys/hierarchical-loading.md) | Whether rules load from multiple directory levels with defined precedence |
## Skills
| Key | Description |
| --------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| [`canonical_filename`](/reference/canonical-keys/canonical-filename.md) | The required or conventional filename for this skill type |
| [`compatibility`](/reference/canonical-keys/compatibility.md) | Provider compatibility constraints — which AI tool versions or providers this skill is compatible with |
| [`custom_filename`](/reference/canonical-keys/custom-filename.md) | Whether the provider supports custom filenames (beyond the canonical filename convention) |
| [`description`](/reference/canonical-keys/description.md) | What the skill does |
| [`disable_model_invocation`](/reference/canonical-keys/disable-model-invocation.md) | When true, the AI cannot auto-invoke this skill; only the user can invoke it explicitly |
| [`display_name`](/reference/canonical-keys/display-name.md) | Human-readable display name for the skill |
| [`global_scope`](/reference/canonical-keys/global-scope.md) | Whether the skill can be installed at global/personal scope (applies across all projects for the current user) |
| [`license`](/reference/canonical-keys/license.md) | SPDX license identifier for the skill content |
| [`metadata_map`](/reference/canonical-keys/metadata-map.md) | Arbitrary key-value metadata attached to the skill |
| [`project_scope`](/reference/canonical-keys/project-scope.md) | Whether the skill can be installed at project scope (applies to current project only, typically committed to version control) |
| [`shared_scope`](/reference/canonical-keys/shared-scope.md) | Whether the skill can be installed at shared/enterprise scope (applies to all users in an organization or shared environment) |
| [`user_invocable`](/reference/canonical-keys/user-invocable.md) | When false, the skill is hidden from user-facing menus (e |
| [`version`](/reference/canonical-keys/version.md) | Semantic version string for the skill |
# activation_mode
> How rules decide when to load into context
[Source](/reference/canonical-keys/activation-mode/)
* Last verified
May 6, 2026
* Sources
22 across providers
* Support
6 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20rules%2Factivation_mode&body=**Canonical%20key%3A**%20%60activation_mode%60%0A**Content%20type%3A**%20%60rules%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
How rules decide when to load into context. Providers implement varying modes: always-on, conditional/glob-based, model-decision, and manual activation. Tracks which modes the provider supports and how they are configured.
**Type:** `object` **Content type:** `rules`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | Always-on (CLAUDE.md loads at every session start); conditional via paths frontmatter in .claude/rules/\*.md files (glob-based, triggers on file access) |
| [cline](/using-syllago/providers/cline.md) | ✓ | conditional\_rules\_paths: Cline supports path-conditional rules alongside always-on rules; conditions use glob patterns |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Four activation modes documented: Always (alwaysApply: true injects rule into every prompt), Apply to Specific Files (globs frontmatter matches edited files via glob syntax), Apply Intelligently (description frontmatter lets the Agent determine relevance), and Apply Manually (no frontmatter triggers, referenced explicitly with @ruleName). |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | kiro\_steering\_inclusion\_mode: Kiro steering files support always, conditional, auto, and manual inclusion modes |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | mode\_partitioned\_activation: rule files in mode-specific directories (.roo/rules-\/) activate only when that mode is active; files in .roo/rules/ activate for all modes |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | activation\_modes extension: always (unconditional), conditional (glob patterns), model (AI decides), manual (explicit toggle) |
| [amp](/using-syllago/providers/amp.md) | ✗ | Amp rule files load unconditionally; no conditional or model-decision activation documented |
| [codex](/using-syllago/providers/codex.md) | ✗ | Codex AGENTS.md files load unconditionally; no conditional or model-decision activation documented |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI rules load unconditionally at session start; no conditional or manual activation modes documented |
| [crush](/using-syllago/providers/crush.md) | ✗ | Crush rule files load unconditionally as project context; no conditional activation syntax documented |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✗ | Factory Droid rule files load unconditionally; no conditional or model-decision activation documented |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | Gemini CLI rule files load unconditionally; no conditional activation syntax documented |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | OpenCode rule files load unconditionally as context; no conditional activation syntax documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | Pi rule files load unconditionally; no conditional or model-decision activation documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | Zed rule files load unconditionally when present at project root; no conditional activation syntax documented |
# agent_scopes
> Where agent definitions can live and the priority ordering when definitions exist at multiple levels
[Source](/reference/canonical-keys/agent-scopes/)
* Last verified
May 6, 2026
* Sources
16 across providers
* Support
9 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20agents%2Fagent_scopes&body=**Canonical%20key%3A**%20%60agent_scopes%60%0A**Content%20type%3A**%20%60agents%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Where agent definitions can live and the priority ordering when definitions exist at multiple levels. Common scopes: project, user/personal, managed/enterprise, CLI-defined.
**Type:** `object` **Content type:** `agents`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | 5 scopes (highest-first): managed settings (org-wide, priority 1), CLI --agents flag (current session, priority 2), project (.claude/agents/, priority 3), user (\~/.claude/agents/, priority 4), plugin agents/ directory (priority 5); highest-priority wins on name collision |
| [codex](/using-syllago/providers/codex.md) | ✓ | built-in roles always available; user-defined roles in config.toml \[agents] section; user-defined roles override built-in roles of same name |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | project scope (.github/agents/ or .claude/agents/), personal (\~/.copilot/agents/), plugin (agents/); personal takes precedence over project |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Two scopes: project (.cursor/agents/) and user-global (\~/.cursor/agents/). |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | project (.factory/droids/) overrides personal (\~/.factory/droids/) on name collision — reverse of skills precedence; top-level files only, no recursion |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | Two scopes: project (.gemini/agents/\*.md) and user/global (\~/.gemini/agents/\*.md). Both directories are scanned at session start and merged into a single registry; explicit collision-precedence behavior is not documented upstream. |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | project (.kiro/agents/) + global (\~/.kiro/agents/); global overrides local on name collision — reverse of most Kiro content types |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | Two scopes: project (.opencode/agents/ or .opencode/agent/) and user-global (\~/.config/opencode/agents/). Both scopes are loaded and coexist. |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | Two scopes: project (.roomodes at the project root) and global (custom\_modes.yaml in Roo Code's settings dir); project entries override global entries with the same slug |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented |
| [cline](/using-syllago/providers/cline.md) | ✗ | not documented |
| [crush](/using-syllago/providers/crush.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# argument_substitution
> How user-provided arguments are injected into command templates
[Source](/reference/canonical-keys/argument-substitution/)
* Last verified
May 6, 2026
* Sources
11 across providers
* Support
6 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20commands%2Fargument_substitution&body=**Canonical%20key%3A**%20%60argument_substitution%60%0A**Content%20type%3A**%20%60commands%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
How user-provided arguments are injected into command templates. Mechanisms vary: $ARGUMENTS, {{args}}, positional $1/$2/${@:N}, and other interpolation syntaxes.
**Type:** `object` **Content type:** `commands`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | $ARGUMENTS (all args), $ARGUMENTS\[N] (Nth arg), $N (positional), ${CLAUDE\_SESSION\_ID} and other env vars; shared with skills argument substitution |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | $ARGUMENTS substitution in Markdown-type commands expands to text typed after the command name; argument-hint frontmatter field provides autocomplete usage hint; executable commands receive arguments as positional shell parameters |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | {{args}} placeholder injects all user-provided arguments; processed before shell injection (!{...}) and other substitutions; default argument handling collapses newlines |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | Commands support $ARGUMENTS (all arguments as a single string) and positional parameters $1, $2, $3, etc. for individual arguments; all placeholders are substituted from user input at invocation time |
| [pi](/using-syllago/providers/pi.md) | ✓ | positional expansion: $1, $2 (specific positions), $@ or $ARGUMENTS (all args joined), ${@:N} (args from position N), ${@:N:L} (L args starting at N); richer syntax than most providers |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | argument-hint frontmatter field documents expected arguments; user-supplied arguments are appended to the command body at invocation time |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented |
| [cline](/using-syllago/providers/cline.md) | ✗ | Workflow markdown files are plain prompt templates with no documented argument-substitution placeholder (no {{args}} or equivalent) |
| [codex](/using-syllago/providers/codex.md) | ✗ | no implementation details captured; only source is a redirect stub to external docs — cannot confirm argument substitution support |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | built-in slash commands accept literal positional arguments (e.g. /add-dir PATH, /skills info SKILL-NAME) but Copilot CLI does not document a user-authored custom-command mechanism with template-substitution syntax (no $ARGUMENTS, $1/$2, or {{args}} interpolation) |
| [crush](/using-syllago/providers/crush.md) | ✗ | not documented |
| [cursor](/using-syllago/providers/cursor.md) | ✗ | not documented |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | not documented |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | Cascade Workflows are plain Markdown prompt templates; no \`{{args}}\` or equivalent placeholder syntax is documented for user-provided arguments |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# async_execution
> Whether hooks can run asynchronously without blocking the agent's execution loop
[Source](/reference/canonical-keys/async-execution/)
* Last verified
May 6, 2026
* Sources
41 across providers
* Support
3 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20hooks%2Fasync_execution&body=**Canonical%20key%3A**%20%60async_execution%60%0A**Content%20type%3A**%20%60hooks%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether hooks can run asynchronously without blocking the agent’s execution loop. Fire-and-forget semantics.
**Type:** `bool` **Content type:** `hooks`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | hook\_async\_execution: async: true on command handlers runs hook in background without blocking; decisions ignored; systemMessage delivered on next turn; asyncRewake: true also wakes Claude on exit code 2 |
| [codex](/using-syllago/providers/codex.md) | ✓ | hook\_execution\_mode: Codex supports async hook execution mode for fire-and-forget background hook runs |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | Matching hooks for the same event execute concurrently (in parallel); deduplication consolidates identical commands automatically |
| [amp](/using-syllago/providers/amp.md) | ✗ | Amp hooks run synchronously; no async execution documented |
| [cline](/using-syllago/providers/cline.md) | ✗ | Cline hooks run synchronously before/after tool events; no async execution documented |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI hooks run synchronously; no async execution documented |
| [crush](/using-syllago/providers/crush.md) | ✗ | Hooks are synchronous; each fires before the tool executes and must complete within the configured timeout. |
| [cursor](/using-syllago/providers/cursor.md) | ✗ | Hooks run synchronously; no async/background flag documented. |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | Gemini CLI hooks run synchronously; no async execution documented |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Kiro hooks run synchronously; no async execution documented |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | Pi extension handlers are awaited synchronously in registration order; no fire-and-forget async execution documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | not documented |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | Windsurf hooks run synchronously; post\_cascade\_response and post\_cascade\_response\_with\_transcript fire asynchronously after the response but hooks themselves do not execute fire-and-forget |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# auto_approve
> Whether specific MCP tools or entire servers can be configured for automatic approval without per-invocation user confirmation
[Source](/reference/canonical-keys/auto-approve/)
* Last verified
May 6, 2026
* Sources
25 across providers
* Support
6 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20mcp%2Fauto_approve&body=**Canonical%20key%3A**%20%60auto_approve%60%0A**Content%20type%3A**%20%60mcp%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether specific MCP tools or entire servers can be configured for automatic approval without per-invocation user confirmation. Boundary: auto\_approve governs execution gating (user prompt suppression) for tools that are already visible; see tool\_filtering for tool visibility control.
**Type:** `bool` **Content type:** `mcp`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [cline](/using-syllago/providers/cline.md) | ✓ | always\_allow\_tools (execution-gating scope): Cline's always\_allow list suppresses per-invocation confirmation prompts for listed tools that are already visible |
| [codex](/using-syllago/providers/codex.md) | ✓ | mcp\_per\_tool\_approval: Codex supports per-tool approval configuration to suppress confirmation prompts for trusted tools |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Users can configure permanent permissions through permissions.json files so that specific MCP tools do not require per-invocation approval; auto-run functionality can also be enabled globally. |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | kiro\_mcp\_auto\_approve: Kiro supports per-server or per-tool auto-approval configuration to suppress confirmation prompts |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | always\_allow\_list: alwaysAllow tool names bypass confirmation prompts for that server |
| [zed](/using-syllago/providers/zed.md) | ✓ | agent.tool\_permissions.default: "allow" auto-approves all tool actions without prompting (v0.224.0+); individual tools can be targeted with mcp:\:\ key format. Default is "confirm"; "deny" blocks all tool actions. |
| [amp](/using-syllago/providers/amp.md) | ✗ | Amp does not document pre-configured auto-approval for specific MCP tools separate from tool filtering |
| [claude-code](/using-syllago/providers/claude-code.md) | ✗ | Claude Code does not support pre-configured auto-approval for specific MCP tools; all tool calls require user confirmation unless covered by session permission rules |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI does not document pre-configured auto-approval for MCP tools |
| [crush](/using-syllago/providers/crush.md) | ✗ | Crush does not document pre-configured auto-approval for specific MCP tools |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✗ | no auto-approve / always-allow field documented in Configuration Schema |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | Gemini CLI does not document pre-configured auto-approval for specific MCP tools |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | Windsurf does not support pre-configured auto-approval for specific MCP tools |
# auto_memory
> Whether the provider auto-generates persistent rules from conversation context
[Source](/reference/canonical-keys/auto-memory/)
* Last verified
May 6, 2026
* Sources
22 across providers
* Support
3 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20rules%2Fauto_memory&body=**Canonical%20key%3A**%20%60auto_memory%60%0A**Content%20type%3A**%20%60rules%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether the provider auto-generates persistent rules from conversation context. Distinct from user-authored rules — these are AI-created and stored separately.
**Type:** `bool` **Content type:** `rules`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | Auto memory saves Claude's accumulated notes to \~/.claude/projects/\/memory/MEMORY.md; first 200 lines or 25KB loaded at session start; requires CC v2.1.59+; enabled by default; disable via CLAUDE\_CODE\_DISABLE\_AUTO\_MEMORY=1; override storage location via autoMemoryDirectory setting (accepted from policy/user settings and --settings flag, not from project or local settings); subagents can also maintain their own auto memory |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | memory\_command: Gemini CLI /memory command saves notes that persist across sessions as rule-like content |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | auto\_generated\_memories: Windsurf AI generates persistent memories stored in \~/.codeium/windsurf/memories/ as rule-like files |
| [amp](/using-syllago/providers/amp.md) | ✗ | Amp does not have an AI-generated auto-memory system |
| [cline](/using-syllago/providers/cline.md) | ✗ | Cline does not have an AI-generated auto-memory system distinct from user-authored rules |
| [codex](/using-syllago/providers/codex.md) | ✗ | Codex does not have an AI-generated auto-memory system |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI does not have an AI-generated persistent memory system for rules |
| [crush](/using-syllago/providers/crush.md) | ✗ | No runtime memory/append command documented for Crush rule files |
| [cursor](/using-syllago/providers/cursor.md) | ✗ | Cursor does not document an AI-generated auto-memory system distinct from user-authored rules. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✗ | Factory Droid does not have an AI-generated auto-memory system |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Kiro does not have an AI-generated auto-memory system separate from user-authored steering files |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | No runtime command documented for persisting notes into rule files |
| [pi](/using-syllago/providers/pi.md) | ✗ | Pi does not have an AI-generated auto-memory system |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | No auto-append or persistent memory command documented for rule content |
| [zed](/using-syllago/providers/zed.md) | ✗ | Zed does not document a command that persists agent memory into the rules file |
# builtin_commands
> Whether the provider ships default/built-in commands alongside user-defined custom commands
[Source](/reference/canonical-keys/builtin-commands/)
* Last verified
May 6, 2026
* Sources
11 across providers
* Support
6 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20commands%2Fbuiltin_commands&body=**Canonical%20key%3A**%20%60builtin_commands%60%0A**Content%20type%3A**%20%60commands%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether the provider ships default/built-in commands alongside user-defined custom commands.
**Type:** `bool` **Content type:** `commands`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | 80+ built-in slash commands including /add-dir, /agents, /autofix-pr, /batch \[Skill], /branch, /btw, /chrome, /claude-api \[Skill], /clear, /color, /compact, /config, /context, /copy, /cost, /debug \[Skill], /desktop, /diff, /doctor, /effort, /exit, /export, /extra-usage, /fast, /feedback, /fewer-permission-prompts \[Skill], /focus, /heapdump, /help, /hooks, /ide, /init, /insights, /install-github-app, /install-slack-app, /keybindings, /login, /logout, /loop \[Skill], /mcp, /memory, /mobile, /model, /passes, /permissions, /plan, /plugin, /powerup, /privacy-settings, /recap, /release-notes, /reload-plugins, /remote-control, /remote-env, /rename, /resume, /review, /rewind, /sandbox, /schedule, /security-review, /setup-bedrock, /setup-vertex, /simplify \[Skill], /skills, /stats, /status, /statusline, /stickers, /tasks, /team-onboarding, /teleport, /terminal-setup, /theme, /tui, /ultraplan, /ultrareview, /upgrade, /usage; not user-modifiable; availability varies by platform and plan |
| [cline](/using-syllago/providers/cline.md) | ✓ | Built-in slash commands (e.g., /newtask, /smol alias /compact, /newrule, /deep-planning, /explain-changes in VS Code, /reportbug) are hardcoded and not user-modifiable; user-authored workflows are additive, invoked alongside built-ins |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | 60+ built-in slash commands documented in the 'Slash commands in the interactive interface' table of the CLI command reference, including: /add-dir, /agent, /ask, /allow-all, /changelog, /chronicle, /clear, /compact, /context, /copy, /cwd, /delegate, /diff, /downgrade, /env, /exit, /experimental, /feedback, /fleet, /help, /ide, /init, /instructions, /keep-alive, /list-dirs, /login, /logout, /lsp, /mcp, /model, /plan, /plugin, /pr, /remote, /rename, /research, /reset-allowed-tools, /restart, /resume, /review, /session, /share, /skills, /statusline, /tasks, /terminal-setup, /theme, /undo, /update, /usage, /user, /version. The 'Command-line commands' table covers top-level copilot subcommands (copilot, copilot completion, copilot help, copilot init, copilot login, copilot mcp, copilot plugin, copilot update, copilot version). |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | built-in slash commands include /commands reload (reload command files without restart) and /help; user-defined commands supplement but do not replace built-ins |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | OpenCode ships built-in commands including /init, /undo, /redo, /share, and /help; custom commands can override built-in commands if given the same name |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | Cascade exposes its own built-in chat slash commands (e.g. for conversation control) independently of user-authored Workflows; the \`/\\` namespace is reserved for user files |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented |
| [codex](/using-syllago/providers/codex.md) | ✗ | no implementation details captured; slash commands feature exists but format and capabilities are undocumented in cached sources |
| [crush](/using-syllago/providers/crush.md) | ✗ | not documented |
| [cursor](/using-syllago/providers/cursor.md) | ✗ | not documented |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✗ | no built-in slash commands documented; Factory commands are user-defined Markdown templates or executable scripts |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | pi prompt templates are entirely user-defined; no built-in slash commands documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | Roo Code commands are user-defined Markdown files in .roo/commands/ — no user-overridable built-in slash-command layer documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# canonical_filename
> The required or conventional filename for this skill type
[Source](/reference/canonical-keys/canonical-filename/)
* Last verified
May 6, 2026
* Sources
19 across providers
* Support
14 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20skills%2Fcanonical_filename&body=**Canonical%20key%3A**%20%60canonical_filename%60%0A**Content%20type%3A**%20%60skills%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
The required or conventional filename for this skill type. For example, “SKILL.md” for Claude Code skills.
**Type:** `string` **Content type:** `skills`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------- |
| [amp](/using-syllago/providers/amp.md) | ✓ | SKILL.md (required, fixed name) |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | Fixed filename SKILL.md required inside skill directory |
| [cline](/using-syllago/providers/cline.md) | ✓ | Fixed filename SKILL.md required inside a named skill directory |
| [codex](/using-syllago/providers/codex.md) | ✓ | Fixed filename SKILL.md required within each named skill directory (SKILLS\_FILENAME constant) |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | SKILL.md (fixed filename per Agent Skills open standard) |
| [crush](/using-syllago/providers/crush.md) | ✓ | SKILL.md (required, fixed name per the Agent Skills standard) |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | SKILL.md (required, fixed name per Agent Skills convention). |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | SKILL.md (fixed, required filename within the skill directory) |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | SKILL.md (required, fixed name) |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | Fixed filename POWER.md (required, all caps) |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | Fixed filename SKILL.md inside skill directory (Agent Skills spec) |
| [pi](/using-syllago/providers/pi.md) | ✓ | SKILL.md (required, fixed filename for directory-form skills) |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | SKILL.md (required, fixed name per Agent Skills standard) |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | Fixed filename SKILL.md required in each skill directory. All scopes (workspace, global, system) use this same convention. |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# compatibility
> Provider compatibility constraints — which AI tool versions or providers this skill is compatible with
[Source](/reference/canonical-keys/compatibility/)
* Last verified
May 6, 2026
* Sources
19 across providers
* Support
4 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20skills%2Fcompatibility&body=**Canonical%20key%3A**%20%60compatibility%60%0A**Content%20type%3A**%20%60skills%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Provider compatibility constraints — which AI tool versions or providers this skill is compatible with.
**Type:** `object` **Content type:** `skills`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ---------------------------------------------------------------------- |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | yaml frontmatter key: compatibility (optional). |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | yaml frontmatter key: compatibility (optional) |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | yaml frontmatter key: compatibility (optional) |
| [pi](/using-syllago/providers/pi.md) | ✓ | yaml frontmatter key: compatibility (optional, max 500 chars) |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented |
| [claude-code](/using-syllago/providers/claude-code.md) | ✗ | not documented |
| [cline](/using-syllago/providers/cline.md) | ✗ | not documented |
| [codex](/using-syllago/providers/codex.md) | ✗ | not documented |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | not documented |
| [crush](/using-syllago/providers/crush.md) | ✗ | not documented |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✗ | not documented |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | No compatibility frontmatter field observed in Roo Code skill examples |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# context_injection
> Whether hooks can inject messages, system prompts, or conversation context into the agent's active session
[Source](/reference/canonical-keys/context-injection/)
* Last verified
May 6, 2026
* Sources
41 across providers
* Support
7 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20hooks%2Fcontext_injection&body=**Canonical%20key%3A**%20%60context_injection%60%0A**Content%20type%3A**%20%60hooks%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether hooks can inject messages, system prompts, or conversation context into the agent’s active session.
**Type:** `bool` **Content type:** `hooks`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | Hooks return systemMessage field in JSON output to inject context into agent's active session |
| [cline](/using-syllago/providers/cline.md) | ✓ | context\_modification\_output: Cline hooks can inject additional context into the agent's session via hook output |
| [codex](/using-syllago/providers/codex.md) | ✓ | hook\_system\_message: Codex hooks can inject a system message into the agent's active session context |
| [crush](/using-syllago/providers/crush.md) | ✓ | The hook JSON response may include an optional context field; this content is injected into the agent context for the current turn. |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Hooks can inject context at session initialization via the sessionStart event, enabling custom context to be added to the agent's active session at startup. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | additionalContext field in PostToolUse, UserPromptSubmit, and SessionStart hook output injects information into the agent session; systemMessage field in JSON output provides session-level injection |
| [pi](/using-syllago/providers/pi.md) | ✓ | before\_agent\_start handlers return { message: { customType, content, display } } to inject a persistent message stored in session and sent to LLM; context handlers return { messages } to modify the message array before each LLM call |
| [amp](/using-syllago/providers/amp.md) | ✗ | Amp hooks cannot inject context into the agent session beyond the pre-execute 'send-user-message' action that cancels the tool call |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI hooks cannot inject context into the agent session |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | Gemini CLI hooks cannot inject context into the agent session |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Kiro hooks cannot inject context into the agent session |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | not documented |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | Windsurf hooks cannot inject context into the agent's active session |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# cross_provider_recognition
> Which rule file formats from other providers this provider recognizes
[Source](/reference/canonical-keys/cross-provider-recognition/)
* Last verified
May 6, 2026
* Sources
22 across providers
* Support
11 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20rules%2Fcross_provider_recognition&body=**Canonical%20key%3A**%20%60cross_provider_recognition%60%0A**Content%20type%3A**%20%60rules%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Which rule file formats from other providers this provider recognizes. Contents: recognized\_formats (list of filenames like AGENTS.md, .cursorrules, .windsurfrules). Minimum qualification: supported when the provider reads at least one rule-file format defined by a different provider.
**Type:** `object` **Content type:** `rules`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [cline](/using-syllago/providers/cline.md) | ✓ | multi\_source\_rule\_detection: Cline reads .clinerules/, .cursorrules, CLAUDE.md, and other provider rule files automatically |
| [codex](/using-syllago/providers/codex.md) | ✓ | agents\_md\_filename: Codex reads AGENTS.md files using the standard filename used by multiple providers |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | agents\_md\_instructions: Copilot CLI reads AGENTS.md files following the multi-provider shared format |
| [crush](/using-syllago/providers/crush.md) | ✓ | Crush reads AGENTS.md, CRUSH.md, CLAUDE.md, GEMINI.md (and .local variants) as context files. The active filename is controlled by the initialize\_as option (default: AGENTS.md); context\_paths allows configuring an arbitrary list of additional file paths. |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Cursor documents AGENTS.md as an officially supported alternative to .cursor/rules/\*.mdc — a plain markdown file without frontmatter metadata that is recognized and loaded alongside project rules. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | agents\_md\_format: Factory Droid reads AGENTS.md files in the shared multi-provider format |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | kiro\_agents\_md\_recognition: Kiro reads AGENTS.md files from other providers in addition to its own steering files |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | OpenCode reads AGENTS.md (cross-provider convention) and CLAUDE.md (Claude Code fallback) from project root and parent directories; \~/.config/opencode/AGENTS.md and \~/.claude/CLAUDE.md at global scope; CLAUDE.md compat can be disabled via OPENCODE\_DISABLE\_CLAUDE\_CODE env var |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | legacy\_clinerules\_fallback: Roo Code reads .clinerules/ as a backward-compatibility fallback when native .roo/rules/ is absent |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | agents\_md\_auto\_scoping: Windsurf reads both AGENTS.md and agents.md (case-insensitive) files from other providers and applies them with workspace-aware scoping |
| [zed](/using-syllago/providers/zed.md) | ✓ | Zed discovers rule files from multiple providers at project root using a priority-ordered list: .rules, .cursorrules, .windsurfrules, .clinerules, .github/copilot-instructions.md, AGENT.md, AGENTS.md, CLAUDE.md, GEMINI.md — the first matching file wins |
| [amp](/using-syllago/providers/amp.md) | ✗ | Amp reads its own rule format; no cross-provider rule file recognition documented |
| [claude-code](/using-syllago/providers/claude-code.md) | ✗ | Claude Code does not natively read rule files defined by other providers |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | Gemini CLI reads its own GEMINI.md format; no cross-provider rule file recognition documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | Pi reads its own rule format; no cross-provider rule file recognition documented |
# custom_filename
> Whether the provider supports custom filenames (beyond the canonical filename convention)
[Source](/reference/canonical-keys/custom-filename/)
* Last verified
May 6, 2026
* Sources
19 across providers
* Support
3 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20skills%2Fcustom_filename&body=**Canonical%20key%3A**%20%60custom_filename%60%0A**Content%20type%3A**%20%60skills%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether the provider supports custom filenames (beyond the canonical filename convention).
**Type:** `bool` **Content type:** `skills`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | Variable directory name: .claude/skills/\/SKILL.md — directory name is the skill identifier |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | skill.mdx is accepted as an alternative to SKILL.md within the skill directory |
| [pi](/using-syllago/providers/pi.md) | ✓ | Any .md filename at root of \~/.pi/agent/skills/ or .pi/skills/ (shorthand single-file form) |
| [amp](/using-syllago/providers/amp.md) | ✗ | not observed — amp requires SKILL.md as the fixed canonical filename |
| [cline](/using-syllago/providers/cline.md) | ✗ | Not applicable — Cline uses fixed SKILL.md canonical filename only |
| [codex](/using-syllago/providers/codex.md) | ✗ | not documented |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | not observed — Agent Skills standard uses fixed SKILL.md filename |
| [crush](/using-syllago/providers/crush.md) | ✗ | filename is fixed as SKILL.md per the Agent Skills standard |
| [cursor](/using-syllago/providers/cursor.md) | ✗ | Not observed — the skill filename is fixed as SKILL.md. |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | not observed — filename is fixed as SKILL.md |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Not observed — POWER.md is fixed |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | Filename is fixed as SKILL.md — no alternate filenames observed |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# decision_control
> Which decision actions hooks can take on the triggering action
[Source](/reference/canonical-keys/decision-control/)
* Last verified
May 6, 2026
* Sources
41 across providers
* Support
10 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20hooks%2Fdecision_control&body=**Canonical%20key%3A**%20%60decision_control%60%0A**Content%20type%3A**%20%60hooks%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Which decision actions hooks can take on the triggering action. Contents: {block: bool, allow: bool, modify: bool}. Mechanisms include exit code contracts, JSON decision fields, or cancel flags. Boundary: decision\_control governs whether a tool invocation proceeds; see permission\_control for whether a tool is available at all.
**Type:** `object` **Content type:** `hooks`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [amp](/using-syllago/providers/amp.md) | ✓ | Pre-execute 'send-user-message' action cancels the pending tool call and injects a user message; exit code 0 = allow, non-zero = block |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | block: exit code 2 or decision=block; allow: permissionDecision=allow in hookSpecificOutput; modify: updatedInput replaces tool input before execution; PermissionDenied event supports {retry: true} to allow model retry |
| [cline](/using-syllago/providers/cline.md) | ✓ | pre\_tool\_use\_cancellation: PreToolUse hooks can cancel (block) the tool invocation; no allow or modify sub-capabilities documented |
| [codex](/using-syllago/providers/codex.md) | ✓ | hook\_result\_abort: Codex hooks can abort (block) the triggering action; allow and modify sub-capabilities documented via hook result schema |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | pre\_tool\_use\_deny: Copilot CLI PreToolUse hooks can deny (block) the tool invocation; no allow or modify documented |
| [crush](/using-syllago/providers/crush.md) | ✓ | Hook subprocess exit code controls tool execution: exit code 2 blocks the tool call (deny). Other exit codes allow it. The hook may also return a JSON decision field with values allow, deny, or none. |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Exit codes drive decisions: exit code 2 blocks the action, exit code 0 allows it to proceed; JSON on stdout can also return structured decision fields. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | PreToolUse hooks return JSON with allow/deny/ask decision field; exit code 2 blocks with stderr fed back to Droid; non-zero non-2 shows stderr to user as non-blocking error |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | exit\_code\_semantics: Gemini CLI uses exit codes to signal block (non-zero) or allow (zero) decisions; no modify sub-capability documented |
| [pi](/using-syllago/providers/pi.md) | ✓ | tool\_call handlers return { block: true, reason? } to prevent tool execution; tool\_call errors also block the tool (fail-safe behavior) |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Kiro hooks are observational; no mechanism to block, allow, or modify tool invocations documented |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | not documented |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | Windsurf hooks are observational by default; pre-hooks can block via exit code 2 but cannot allow or modify the triggering action |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# definition_format
> What format agent definitions use
[Source](/reference/canonical-keys/definition-format/)
* Last verified
May 6, 2026
* Sources
16 across providers
* Support
9 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20agents%2Fdefinition_format&body=**Canonical%20key%3A**%20%60definition_format%60%0A**Content%20type%3A**%20%60agents%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
What format agent definitions use. Varies widely: Markdown with YAML frontmatter, JSON config files, TOML sections, or AGENTS.md plain markdown.
**Type:** `string` **Content type:** `agents`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | Markdown files with YAML frontmatter in .claude/agents/ (project) or \~/.claude/agents/ (user); file body becomes system prompt; only name and description are required |
| [codex](/using-syllago/providers/codex.md) | ✓ | TOML role config files referenced from config.toml \[agents] section; built-in roles (default/explorer/worker) always available without user config |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | .agent.md files with YAML frontmatter (description required); up to 30,000 chars of Markdown instructions as agent system prompt |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Markdown files with YAML frontmatter in .cursor/agents/ (project) or \~/.cursor/agents/ (user); the frontmatter declares name, description, model, readonly, and is\_background, and the Markdown body becomes the agent's system prompt. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | .md files in .factory/droids/ (project) or \~/.factory/droids/ (personal); single-file with YAML frontmatter (name, description, model, reasoningEffort, tools) and system prompt body |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | Markdown files with YAML frontmatter (delimited by ---) in .gemini/agents/\*.md (project) or \~/.gemini/agents/\*.md (user/global); the file body becomes the subagent's system prompt. |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | JSON config files in .kiro/agents/ (project) or \~/.kiro/agents/ (global); prompt field accepts inline string or file:// URI to external .md file |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | Markdown files with YAML frontmatter loaded from .opencode/agents/\*.md (project) and \~/.config/opencode/agents/\*.md (global). The loader glob accepts both agent/ and agents/ directory names and recurses. Frontmatter declares description, mode, model, temperature, top\_p, steps, permission, color, hidden, disable, variant, and prompt; the markdown body becomes the system prompt. Agents can also be defined inline in opencode.json under the agent key. |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | YAML file (.roomodes for project scope, custom\_modes.yaml for global scope) containing an array of custom mode entries with slug, name, roleDefinition, groups, and optional whenToUse, description, customInstructions fields |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented |
| [cline](/using-syllago/providers/cline.md) | ✗ | not documented |
| [crush](/using-syllago/providers/crush.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# description
> What the skill does
[Source](/reference/canonical-keys/description/)
* Last verified
May 6, 2026
* Sources
19 across providers
* Support
14 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20skills%2Fdescription&body=**Canonical%20key%3A**%20%60description%60%0A**Content%20type%3A**%20%60skills%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
What the skill does. Used by the AI to decide when to auto-invoke it. Also shown in skill listings and help text.
**Type:** `string` **Content type:** `skills`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [amp](/using-syllago/providers/amp.md) | ✓ | yaml frontmatter key: description (required) |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | yaml frontmatter key: description (recommended, not required; if omitted uses first paragraph of markdown content) |
| [cline](/using-syllago/providers/cline.md) | ✓ | yaml frontmatter key: description (required) — tells Cline when to use this skill, max 1024 characters |
| [codex](/using-syllago/providers/codex.md) | ✓ | YAML frontmatter key: description (required — empty string triggers MissingField error; max 1024 chars enforced after whitespace normalization) |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | yaml frontmatter key: description (required per Agent Skills open standard) |
| [crush](/using-syllago/providers/crush.md) | ✓ | yaml frontmatter key: description (required); documents what the skill does and when Crush should invoke it |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | yaml frontmatter key: description (required); documents what the skill does and when to use it. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | yaml frontmatter key: description (recommended, not required) |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | yaml frontmatter key: description (required); documents what the skill does and when Gemini should use it — drives auto-invocation decisions |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | yaml frontmatter key: description (required) |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | yaml frontmatter key: description (required) |
| [pi](/using-syllago/providers/pi.md) | ✓ | yaml frontmatter key: description (required, max 1024 chars) |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | yaml frontmatter key: description (required); documents what the skill does and when Roo should load it |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | yaml frontmatter key: description (required). Brief explanation shown to the model to help it decide when to auto-invoke the skill. Key field for automatic invocation matching. |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# disable_model_invocation
> When true, the AI cannot auto-invoke this skill; only the user can invoke it explicitly
[Source](/reference/canonical-keys/disable-model-invocation/)
* Last verified
May 6, 2026
* Sources
19 across providers
* Support
6 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20skills%2Fdisable_model_invocation&body=**Canonical%20key%3A**%20%60disable_model_invocation%60%0A**Content%20type%3A**%20%60skills%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
When true, the AI cannot auto-invoke this skill; only the user can invoke it explicitly. Default: false.
**Type:** `bool` **Content type:** `skills`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | yaml frontmatter key: disable-model-invocation (optional bool, default false); also prevents the skill from being preloaded into subagents via the skills frontmatter field |
| [codex](/using-syllago/providers/codex.md) | ✓ | openai.yaml companion file key: policy.allow\_implicit\_invocation (optional bool; false disables implicit/auto invocation; defaults to true when absent) |
| [crush](/using-syllago/providers/crush.md) | ✓ | yaml frontmatter key: disable-model-invocation (optional boolean) per the Agent Skills standard. Note: the Go Skill struct in skills.go does not have a corresponding field — behavior is inferred from the standard, not from explicit Crush source handling. |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | yaml frontmatter key: disable-model-invocation (optional bool, default false); when true, the skill is converted into an explicit slash command rather than a context-aware tool the model can auto-invoke. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | yaml frontmatter key: disable-model-invocation (optional bool, default: false) |
| [pi](/using-syllago/providers/pi.md) | ✓ | yaml frontmatter key: disable-model-invocation (optional bool); confirmed in SkillFrontmatter TypeScript interface as disable-model-invocation?: boolean |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented — no mechanism to prevent the model from auto-invoking a skill; the model always selects based on name and description match |
| [cline](/using-syllago/providers/cline.md) | ✗ | |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | No disable-model-invocation frontmatter field observed |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# display_name
> Human-readable display name for the skill
[Source](/reference/canonical-keys/display-name/)
* Last verified
May 6, 2026
* Sources
19 across providers
* Support
14 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20skills%2Fdisplay_name&body=**Canonical%20key%3A**%20%60display_name%60%0A**Content%20type%3A**%20%60skills%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Human-readable display name for the skill. If omitted, the directory name is used. Shown in skill listings and menus.
**Type:** `string` **Content type:** `skills`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [amp](/using-syllago/providers/amp.md) | ✓ | yaml frontmatter key: name (required) |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | yaml frontmatter key: name (optional, falls back to directory name; lowercase letters, numbers, hyphens only, max 64 characters) |
| [cline](/using-syllago/providers/cline.md) | ✓ | yaml frontmatter key: name (required) — must exactly match the directory name |
| [codex](/using-syllago/providers/codex.md) | ✓ | YAML frontmatter key: name (optional — falls back to parent directory name if absent or empty; max 64 chars enforced after whitespace normalization) |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | yaml frontmatter key: name (required per Agent Skills open standard) |
| [crush](/using-syllago/providers/crush.md) | ✓ | yaml frontmatter key: name (required); follows the Anthropic Agent Skills standard. Validated: must be alphanumeric with hyphens, max 64 chars. |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | yaml frontmatter key: name (required); matches the skill directory name per the Agent Skills convention. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | yaml frontmatter key: name (optional, defaults to directory name) |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | yaml frontmatter key: name (required); value should match the skill's directory name |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | yaml frontmatter key: name (required, slug-style identifier) |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | yaml frontmatter key: name (required) |
| [pi](/using-syllago/providers/pi.md) | ✓ | yaml frontmatter key: name (required, max 64 chars, lowercase a-z/0-9/hyphens, must match parent directory name) |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | yaml frontmatter key: name (required); identifies the skill and typically matches the directory name |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | yaml frontmatter key: name (required). Must be lowercase letters, numbers, and hyphens only (e.g., deploy-to-staging, code-review). Used in UI listings and for @-mentions. |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# enterprise_management
> Whether the provider supports organization-level MCP configuration management, including managed server lists, allowlists, and enterprise registries
[Source](/reference/canonical-keys/enterprise-management/)
* Last verified
May 6, 2026
* Sources
25 across providers
* Support
4 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20mcp%2Fenterprise_management&body=**Canonical%20key%3A**%20%60enterprise_management%60%0A**Content%20type%3A**%20%60mcp%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether the provider supports organization-level MCP configuration management, including managed server lists, allowlists, and enterprise registries.
**Type:** `bool` **Content type:** `mcp`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [amp](/using-syllago/providers/amp.md) | ✓ | enterprise\_registry\_allowlist: Amp supports organization-level MCP configuration with an enterprise registry and allowlist |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | mcp\_managed\_config: managed-mcp.json for exclusive control, or allowedMcpServers/deniedMcpServers in managed settings for policy-based control |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | Organizations can provide default MCP server configurations via a .well-known/opencode endpoint; users can override remote defaults in their local opencode.json; local config values take precedence over remote defaults |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | enterprise\_whitelist\_and\_registry: Windsurf supports organization-level MCP server allowlists and enterprise registries |
| [cline](/using-syllago/providers/cline.md) | ✗ | Cline does not document organization-level MCP configuration management |
| [codex](/using-syllago/providers/codex.md) | ✗ | Codex does not document organization-level MCP management |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI does not document organization-level MCP management |
| [crush](/using-syllago/providers/crush.md) | ✗ | Crush does not document organization-level MCP management |
| [cursor](/using-syllago/providers/cursor.md) | ✗ | Cursor does not document organization-level managed MCP policy controls beyond the general hook and rule enterprise scopes. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✗ | only user-level (\~/.factory/mcp.json) and project-level (.factory/mcp.json) configuration scopes documented; no organization/enterprise admin layer |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | Gemini CLI does not document organization-level MCP management |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Kiro does not document organization-level MCP management |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | No organization-level MCP management documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | Zed does not document org-level MCP management |
# env_var_expansion
> Whether MCP server configuration supports environment variable expansion
[Source](/reference/canonical-keys/env-var-expansion/)
* Last verified
May 6, 2026
* Sources
25 across providers
* Support
10 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20mcp%2Fenv_var_expansion&body=**Canonical%20key%3A**%20%60env_var_expansion%60%0A**Content%20type%3A**%20%60mcp%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether MCP server configuration supports environment variable expansion. Reduces the need for hardcoded secrets in config files.
**Type:** `bool` **Content type:** `mcp`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | mcp\_env\_var\_expansion: ${VAR} and ${VAR:-default} syntax in command, args, env, url, and headers fields of .mcp.json |
| [codex](/using-syllago/providers/codex.md) | ✓ | mcp\_env\_vars: Codex RawMcpServerConfig supports an env\_vars array of McpServerEnvVar entries; each entry is either a plain string or a structured object with name and optional source fields enabling named environment variable sourcing |
| [crush](/using-syllago/providers/crush.md) | ✓ | Crush MCP configuration supports environment variable references in server env blocks |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Server configuration supports variable interpolation using ${env:NAME} for environment variables, ${userHome} for the user's home directory, and ${workspaceFolder} for the workspace root — not limited to env blocks alone. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | stdio server add command accepts --env KEY=VALUE flags; env field documented in configuration schema for stdio servers |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | env\_variable\_expansion: Gemini CLI MCP configuration supports environment variable expansion for secrets and paths |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | kiro\_mcp\_env\_var\_expansion: Environment variables referenced dynamically using ${VARIABLE\_NAME} syntax within MCP config values; recommended pattern for secrets instead of hardcoded values |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | Remote MCP server headers and OAuth fields support {env:VAR\_NAME} syntax for environment variable interpolation; local servers accept an environment object with key-value pairs |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | env\_variable\_expansion: server env blocks accept environment variables so secrets can be referenced from the shell environment |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | config\_interpolation: Windsurf MCP configuration supports ${env:VAR\_NAME} and ${file:/path} interpolation for environment variables and file contents |
| [amp](/using-syllago/providers/amp.md) | ✗ | Amp MCP configuration does not document environment variable expansion |
| [cline](/using-syllago/providers/cline.md) | ✗ | Cline MCP configuration does not document environment variable expansion syntax |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI MCP configuration does not document environment variable expansion |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | no automatic environment variable expansion documented in Zed MCP env blocks |
# file_imports
> Whether rules can reference or include content from other files
[Source](/reference/canonical-keys/file-imports/)
* Last verified
May 6, 2026
* Sources
22 across providers
* Support
5 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20rules%2Ffile_imports&body=**Canonical%20key%3A**%20%60file_imports%60%0A**Content%20type%3A**%20%60rules%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether rules can reference or include content from other files. Mechanisms vary: @-import syntax, @file.md directives, @path/to/file references.
**Type:** `bool` **Content type:** `rules`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | @path/to/file syntax in CLAUDE.md files; relative and absolute paths; recursive up to 5 hops; requires per-project approval |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | MDC rule bodies may reference other files via @path syntax that inlines the referenced file into the rule context. |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | file\_imports extension: Gemini CLI supports including external file content into rule files via import directives |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | kiro\_steering\_file\_references: Kiro steering files can reference other files using @file syntax |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | The instructions array in opencode.json (or \~/.config/opencode/opencode.json) lists additional rule files by relative path, glob pattern, or remote URL; all are combined with AGENTS.md and loaded into context |
| [amp](/using-syllago/providers/amp.md) | ✗ | No file import syntax documented for Amp rule files |
| [cline](/using-syllago/providers/cline.md) | ✗ | No file import/include syntax documented for Cline rule files |
| [codex](/using-syllago/providers/codex.md) | ✗ | No file import syntax documented for Codex AGENTS.md files |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | No @-import or file inclusion syntax documented for Copilot CLI rule files |
| [crush](/using-syllago/providers/crush.md) | ✗ | No file import directive documented for context files in Crush |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✗ | No file import syntax documented for Factory Droid rule files |
| [pi](/using-syllago/providers/pi.md) | ✗ | No file import syntax documented for Pi rule files |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | No import directive syntax documented — rule files are loaded as plain markdown bodies |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | No @-import or file inclusion syntax documented for Windsurf rule files |
| [zed](/using-syllago/providers/zed.md) | ✗ | no import directive documented for Zed's .rules file |
# global_scope
> Whether the skill can be installed at global/personal scope (applies across all projects for the current user)
[Source](/reference/canonical-keys/global-scope/)
* Last verified
May 6, 2026
* Sources
19 across providers
* Support
13 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20skills%2Fglobal_scope&body=**Canonical%20key%3A**%20%60global_scope%60%0A**Content%20type%3A**%20%60skills%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether the skill can be installed at global/personal scope (applies across all projects for the current user).
**Type:** `bool` **Content type:** `skills`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [amp](/using-syllago/providers/amp.md) | ✓ | skill directory placed under \~/.config/agents/skills/\/, \~/.config/amp/skills/\/, or \~/.claude/skills/\/ |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | \~/.claude/skills/\/SKILL.md in user home directory |
| [cline](/using-syllago/providers/cline.md) | ✓ | Skills stored in \~/.cline/skills/\/SKILL.md (macOS/Linux) |
| [codex](/using-syllago/providers/codex.md) | ✓ | Skills directory at $HOME/.agents/skills/ or the user config layer's skills/ subdir ($CODEX\_HOME/skills, deprecated but kept for backward compatibility) (SkillScope::User) |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | skill directory under \~/.copilot/skills/\/ or \~/.agents/skills/\/ in the user home directory |
| [crush](/using-syllago/providers/crush.md) | ✓ | \~/.config/crush/skills/\/SKILL.md (XDG-compliant native path) and \~/.agents/skills/\/SKILL.md (cross-provider convention) |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | \~/.agents/skills/\/SKILL.md and \~/.cursor/skills/\/SKILL.md for user-level scope; both paths are documented. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | \~/.factory/skills/\/SKILL.md |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | \~/.gemini/skills/\/SKILL.md |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | cross-provider convention at \~/.config/opencode/skills/\/SKILL.md |
| [pi](/using-syllago/providers/pi.md) | ✓ | \~/.pi/agent/skills/\/SKILL.md or \~/.agents/skills/\/SKILL.md |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | \~/.roo/skills/\/SKILL.md |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | Skill directory at \~/.codeium/windsurf/skills/\/. Available in all workspaces on the user's machine; not committed to version control. Also discovered at \~/.agents/skills/\/ and (if Claude Code config reading is enabled) \~/.claude/skills/\/. |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# handler_types
> What kinds of executors hooks support beyond shell commands
[Source](/reference/canonical-keys/handler-types/)
* Last verified
May 6, 2026
* Sources
41 across providers
* Support
6 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20hooks%2Fhandler_types&body=**Canonical%20key%3A**%20%60handler_types%60%0A**Content%20type%3A**%20%60hooks%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
What kinds of executors hooks support beyond shell commands. May include HTTP endpoints, LLM prompt evaluation, multi-turn agent handlers, or TypeScript extensions.
**Type:** `object` **Content type:** `hooks`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [amp](/using-syllago/providers/amp.md) | ✓ | command-only: hook 'action' field runs a shell command; no HTTP, LLM, or agent handler types documented |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | Five types: command (shell), http (POST to URL), mcp\_tool (MCP tool call), prompt (LLM evaluation), agent (subagent with tools, experimental); prompt/agent restricted to subset of events |
| [codex](/using-syllago/providers/codex.md) | ✓ | hook\_handler\_types: Codex supports shell command and LLM prompt handler types; TypeScript extension type also documented |
| [crush](/using-syllago/providers/crush.md) | ✓ | Hooks are shell commands (command field in HookConfig). Each hook fires a subprocess with the tool context passed on stdin. |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Two handler types documented: command (shell scripts communicating over stdio via JSON) and prompt (LLM-evaluated natural language conditions for policy enforcement without custom scripting). |
| [pi](/using-syllago/providers/pi.md) | ✓ | pi\_extension\_typescript\_native: Pi hooks support TypeScript/native extension handler type beyond shell commands |
| [cline](/using-syllago/providers/cline.md) | ✗ | Cline hooks execute shell commands only; no HTTP, LLM prompt, or agent handler types documented |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI hooks execute shell commands only; no HTTP, LLM prompt, or agent handler types documented |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✗ | Factory Droid hooks execute shell commands only (type: command); no other handler types documented |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | Gemini CLI hooks execute shell commands only; no HTTP, LLM prompt, or agent handler types documented |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Kiro hooks execute shell commands or predefined agent prompts; no HTTP, LLM-as-hook, or TypeScript extension handler types documented |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | not documented |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | Windsurf hooks execute shell commands only; no HTTP, LLM prompt, or agent handler types documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# hierarchical_loading
> Whether rules load from multiple directory levels with defined precedence
[Source](/reference/canonical-keys/hierarchical-loading/)
* Last verified
May 6, 2026
* Sources
22 across providers
* Support
9 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20rules%2Fhierarchical_loading&body=**Canonical%20key%3A**%20%60hierarchical_loading%60%0A**Content%20type%3A**%20%60rules%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether rules load from multiple directory levels with defined precedence. Enables project-root rules plus subdirectory-scoped overrides.
**Type:** `bool` **Content type:** `rules`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | CLAUDE.md files load from all ancestor directories up to repo root (ancestor files load in full at launch; subdirectory CLAUDE.md files beyond 200 lines threshold load on demand when Claude reads files in those subdirectories); .claude/rules/ files discovered recursively; user-level rules (\~/.claude/rules/) load before project rules; rules without paths frontmatter load unconditionally |
| [codex](/using-syllago/providers/codex.md) | ✓ | hierarchical\_agents\_md: Codex loads AGENTS.md from subdirectories with defined precedence (deeper overrides higher) |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | Copilot CLI supports repo-wide instructions plus path-specific and personal instruction layers with defined precedence |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Rules can live in nested .cursor/rules/ directories within a project; rules in a subtree apply when working with files under that subtree, enabling monorepo-style scoping. AGENTS.md also supports nested files in subdirectories for granular context-specific guidance. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | Factory Droid loads global and project rule layers; innermost (most specific) layer takes precedence |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | hierarchical\_context\_loading: Gemini CLI loads GEMINI.md files from multiple directory levels with defined precedence |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | OpenCode traverses up from the current directory collecting AGENTS.md (or CLAUDE.md fallback) at each level; global files at \~/.config/opencode/AGENTS.md and \~/.claude/CLAUDE.md are appended; all matching files are combined into context |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | mode\_scoped\_loading: files under .roo/rules/ load universally; files under .roo/rules-\/ load conditionally based on the active mode |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | rules\_hierarchical\_discovery: Windsurf discovers .windsurf/rules/ directories in the current workspace, all sub-directories, and parent directories up to the git root; rules from all levels are merged and deduplicated |
| [amp](/using-syllago/providers/amp.md) | ✗ | Amp rule files are project-scoped; no subdirectory hierarchy documented |
| [cline](/using-syllago/providers/cline.md) | ✗ | Cline rules are project-scoped or global; no per-subdirectory loading hierarchy documented |
| [crush](/using-syllago/providers/crush.md) | ✗ | Crush documents context files at the project root only; no hierarchical/subdirectory loading documented |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Kiro steering files are project-scoped; no multi-level subdirectory hierarchy documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | Pi rule files are not documented as supporting multi-level directory loading |
| [zed](/using-syllago/providers/zed.md) | ✗ | Zed loads rule files from the project root only; no multi-tier hierarchical loading documented |
# hook_scopes
> Where hooks can be configured and the precedence model when multiple scopes define hooks for the same event
[Source](/reference/canonical-keys/hook-scopes/)
* Last verified
May 6, 2026
* Sources
41 across providers
* Support
8 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20hooks%2Fhook_scopes&body=**Canonical%20key%3A**%20%60hook_scopes%60%0A**Content%20type%3A**%20%60hooks%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Where hooks can be configured and the precedence model when multiple scopes define hooks for the same event. Common scopes: global/user, project, workspace, managed/enterprise.
**Type:** `object` **Content type:** `hooks`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | Six scopes: user (\~/.claude/settings.json), project (.claude/settings.json), local (.claude/settings.local.json), managed policy, plugin (hooks/hooks.json), component frontmatter (skill/agent) |
| [cline](/using-syllago/providers/cline.md) | ✓ | global\_and\_project\_hooks: Cline supports global (user-wide) and project-level hook configuration |
| [codex](/using-syllago/providers/codex.md) | ✓ | hook\_scope: Codex hooks can be scoped to global/user or project configuration |
| [crush](/using-syllago/providers/crush.md) | ✓ | Hooks are configured in crush.json under the hooks key, which applies at the project or user-global config level (same config file scope as MCP and other settings). |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Four scopes documented in priority order: Enterprise (system-wide MDM-managed), Team (cloud-distributed for Enterprise plans), Project (.cursor/hooks/ in the repository), and User (global personal configuration at \~/.cursor/hooks/). |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | Four scopes documented: user-level (\~/.factory/settings.json), project-level (.factory/settings.json), local-uncommitted (.factory/settings.local.json), and enterprise managed policies |
| [pi](/using-syllago/providers/pi.md) | ✓ | Extensions load from global scope (\~/.pi/agent/extensions/) and project-local scope (.pi/extensions/); both scopes are auto-discovered and can be combined |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | three\_config\_scopes: global (user-wide), workspace, and managed/enterprise hook configuration scopes |
| [amp](/using-syllago/providers/amp.md) | ✗ | Project only: hooks live in a single 'amp.hooks' array inside '.amp/settings.json' (or user-scope settings); no multi-scope layering documented |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI hooks are configured at a single scope level; no multi-scope configuration documented |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | Gemini CLI hooks are project-scoped; no multi-scope configuration documented |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Kiro hooks are project-scoped; no multi-scope configuration documented |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# input_modification
> Whether hooks can modify tool input arguments before the tool executes
[Source](/reference/canonical-keys/input-modification/)
* Last verified
May 6, 2026
* Sources
41 across providers
* Support
5 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20hooks%2Finput_modification&body=**Canonical%20key%3A**%20%60input_modification%60%0A**Content%20type%3A**%20%60hooks%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether hooks can modify tool input arguments before the tool executes. Safety-critical capability — silent degradation creates false security. Minimum qualification: supported when the provider provides any mechanism to modify tool input arguments before execution (e.g., hookSpecificOutput.updatedInput, plugin-mutable args, or equivalent).
**Type:** `bool` **Content type:** `hooks`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | hook\_input\_modification: PreToolUse returns updatedInput in hookSpecificOutput; entire input object replaced; compatible with all permissionDecision values except defer |
| [cline](/using-syllago/providers/cline.md) | ✓ | context\_modification\_output: Cline PreToolUse hooks can return modified context/input before tool execution |
| [codex](/using-syllago/providers/codex.md) | ✓ | hook\_updated\_input: Codex PreToolUse hooks return modified input arguments that replace the original tool input |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | PreToolUse hooks return updatedInput in JSON output to modify tool parameters before execution |
| [pi](/using-syllago/providers/pi.md) | ✓ | tool\_call handlers mutate event.input in place to modify tool arguments before execution; later handlers see prior mutations |
| [amp](/using-syllago/providers/amp.md) | ✗ | Amp hooks cannot modify tool input before execution; only substring match and cancel-with-message are documented |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI hooks cannot modify tool input before execution |
| [crush](/using-syllago/providers/crush.md) | ✗ | Hooks receive tool context on stdin and can return context to the agent, but modifying tool input parameters is not documented. |
| [cursor](/using-syllago/providers/cursor.md) | ✗ | Cursor hooks are not documented to rewrite tool input before execution. |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | Gemini CLI hooks cannot modify tool input before execution |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Kiro hooks cannot modify tool input before execution |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | not documented |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | Windsurf hooks cannot modify tool input arguments before execution |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# invocation_patterns
> How agents are triggered
[Source](/reference/canonical-keys/invocation-patterns/)
* Last verified
May 6, 2026
* Sources
16 across providers
* Support
9 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20agents%2Finvocation_patterns&body=**Canonical%20key%3A**%20%60invocation_patterns%60%0A**Content%20type%3A**%20%60agents%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
How agents are triggered. Mechanisms include natural language detection, @-mention syntax, slash commands, CLI flags, or automatic delegation.
**Type:** `object` **Content type:** `agents`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | natural language (Claude auto-delegates), @agent-\ @-mention from typeahead, or --agent flag at startup for session-wide agent; plugin subagents appear as \:\ in typeahead |
| [codex](/using-syllago/providers/codex.md) | ✓ | spawn-agent tool at LLM discretion; LLM selects role from dynamically-built role descriptions combining built-in and user-defined roles |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | /agent slash command, natural language instruction, auto-inference (suppressible with disable-model-invocation), or --agent flag; 4 patterns |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Custom agents are invoked through the Cursor IDE agent picker; background-enabled agents can also run concurrently via the background agents UI. Subagents can be spawned by other agents for parallel execution workstreams. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | exposed as subagent\_type targets for the Task tool; primary assistant delegates mid-session; droids enabled by default with live progress streaming in UI |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | Two patterns: (1) automatic delegation by the main agent based on task relevance and the subagent's description, (2) explicit @-mention at the start of a prompt (e.g., '@codebase\_investigator review this'); /agents list/enable/disable/configure manages the registry. |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | keyboard shortcut binding for IDE invocation; welcomeMessage shown on agent start; manual selection via agent picker |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | Primary agents are cycled via the Tab key or the switch\_agent keybind. Subagents are invoked automatically by primary agents for specialized tasks based on their description, or manually by @-mentioning the subagent name in a message. Agent name derives from the filename (configEntryNameFromPath). |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | Users switch modes via the mode selector or /mode command; each mode is a distinct operating persona with its own roleDefinition and tool groups |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented |
| [cline](/using-syllago/providers/cline.md) | ✗ | not documented |
| [crush](/using-syllago/providers/crush.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# json_io_protocol
> Whether hooks communicate with the host via structured JSON on stdin/stdout rather than plain text or exit codes alone
[Source](/reference/canonical-keys/json-io-protocol/)
* Last verified
May 6, 2026
* Sources
41 across providers
* Support
8 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20hooks%2Fjson_io_protocol&body=**Canonical%20key%3A**%20%60json_io_protocol%60%0A**Content%20type%3A**%20%60hooks%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether hooks communicate with the host via structured JSON on stdin/stdout rather than plain text or exit codes alone.
**Type:** `bool` **Content type:** `hooks`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | Command hooks receive event JSON on stdin; respond with JSON on stdout (exit 0); structured fields: continue, stopReason, suppressOutput, systemMessage, hookSpecificOutput |
| [cline](/using-syllago/providers/cline.md) | ✓ | Hooks receive a JSON object via stdin (taskId, hookName, clineVersion, timestamp, workspaceRoots, userId, model, plus hook-specific fields) and return JSON to stdout with cancel (bool), contextModification (string), and errorMessage (string); debug output goes to stderr |
| [codex](/using-syllago/providers/codex.md) | ✓ | Codex hooks communicate via structured JSON on stdin (typed per-event payload conforming to the event input schema) and stdout (typed response conforming to the event output schema); exit codes alone are not the protocol |
| [crush](/using-syllago/providers/crush.md) | ✓ | Hooks receive a JSON object on stdin containing tool name and parameters. The hook subprocess may return a JSON object with decision (allow/deny/none) and optional context fields. |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Command hooks receive event data as JSON on stdin and may return structured JSON on stdout to signal decisions and supply output fields. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | Hooks receive JSON via stdin containing session\_id, transcript\_path, cwd, permission\_mode, hook\_event\_name, and event-specific fields; hooks return JSON output with continue, stopReason, suppressOutput, systemMessage, and event-specific fields |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | hook\_io\_protocol: Gemini CLI hooks receive event data as JSON on stdin and return structured JSON responses on stdout |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | json\_stdin\_context: Windsurf hooks receive event context as JSON on stdin |
| [amp](/using-syllago/providers/amp.md) | ✗ | Amp hooks signal decisions via exit codes and declarative action types; no JSON stdin/stdout protocol documented |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI hooks communicate via exit codes; no JSON stdin/stdout protocol documented |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Kiro hooks communicate via exit codes; no JSON stdin/stdout protocol documented |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | Pi hooks communicate via TypeScript extension API; no JSON stdin/stdout protocol for shell hooks |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# license
> SPDX license identifier for the skill content
[Source](/reference/canonical-keys/license/)
* Last verified
May 6, 2026
* Sources
19 across providers
* Support
4 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20skills%2Flicense&body=**Canonical%20key%3A**%20%60license%60%0A**Content%20type%3A**%20%60skills%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
SPDX license identifier for the skill content. Typically “MIT”, “Apache-2.0”, etc.
**Type:** `string` **Content type:** `skills`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ---------------------------------------------------------------- |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | yaml frontmatter key: license (optional). |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | yaml frontmatter key: license (optional) |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | yaml frontmatter key: license (optional) |
| [pi](/using-syllago/providers/pi.md) | ✓ | yaml frontmatter key: license (optional) |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented |
| [claude-code](/using-syllago/providers/claude-code.md) | ✗ | not documented |
| [cline](/using-syllago/providers/cline.md) | ✗ | not documented |
| [codex](/using-syllago/providers/codex.md) | ✗ | not documented |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | not documented |
| [crush](/using-syllago/providers/crush.md) | ✗ | not documented |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✗ | not documented |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | No license frontmatter field observed in Roo Code skill examples |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# marketplace
> Whether the provider offers an in-IDE MCP server discovery and installation experience
[Source](/reference/canonical-keys/marketplace/)
* Last verified
May 6, 2026
* Sources
25 across providers
* Support
5 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20mcp%2Fmarketplace&body=**Canonical%20key%3A**%20%60marketplace%60%0A**Content%20type%3A**%20%60mcp%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether the provider offers an in-IDE MCP server discovery and installation experience.
**Type:** `bool` **Content type:** `mcp`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [cline](/using-syllago/providers/cline.md) | ✓ | mcp\_marketplace: Cline has an in-IDE MCP server discovery and installation experience |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Cursor ships an in-IDE MCP Marketplace for discovering and installing community MCP servers with one-click installation. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | Quick Start: Add from Registry via /mcp command — 40+ pre-configured servers (Figma, Linear, Sentry, Notion, Supabase, Stripe, Vercel, Playwright, HubSpot, MongoDB) organized into categories |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | mcp\_marketplace: Windsurf has an in-IDE MCP server discovery and one-click installation experience |
| [zed](/using-syllago/providers/zed.md) | ✓ | Zed exposes an in-app MCP server gallery (zed: extensions filtered to context-servers, or Agent Panel > View Server Extensions) where servers can be browsed and installed |
| [amp](/using-syllago/providers/amp.md) | ✗ | Amp does not have an in-IDE MCP marketplace |
| [claude-code](/using-syllago/providers/claude-code.md) | ✗ | Claude Code does not have an in-IDE MCP marketplace for discovery and installation |
| [codex](/using-syllago/providers/codex.md) | ✗ | Codex does not have an in-IDE MCP marketplace |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI does not have an in-IDE MCP marketplace |
| [crush](/using-syllago/providers/crush.md) | ✗ | Crush does not have an in-app MCP marketplace |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | Gemini CLI does not have an in-IDE MCP marketplace |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Kiro does not have an in-IDE MCP marketplace |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | No in-app MCP marketplace documented |
# matcher_patterns
> Whether hooks can filter which tools or events they respond to using name matching, regex patterns, or structured criteria
[Source](/reference/canonical-keys/matcher-patterns/)
* Last verified
May 6, 2026
* Sources
41 across providers
* Support
7 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20hooks%2Fmatcher_patterns&body=**Canonical%20key%3A**%20%60matcher_patterns%60%0A**Content%20type%3A**%20%60hooks%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether hooks can filter which tools or events they respond to using name matching, regex patterns, or structured criteria.
**Type:** `bool` **Content type:** `hooks`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [amp](/using-syllago/providers/amp.md) | ✓ | Amp hooks filter firing via 'input.contains' — exact literal substring match against tool input |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | hook\_matcher\_patterns: exact string, pipe-separated list, or JavaScript regex; matches on tool\_name or event-specific fields; if field uses permission-rule syntax for per-subcommand filtering |
| [codex](/using-syllago/providers/codex.md) | ✓ | hook\_matcher: Codex hooks support pattern matching to filter which tools or events trigger the hook |
| [crush](/using-syllago/providers/crush.md) | ✓ | HookConfig has a matcher field: a regex pattern tested against the tool name. An empty matcher matches all tools. |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Hook entries accept a matcher string that filters which tool or event fires the hook (for example a specific shell command or tool name). |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | PreToolUse and PostToolUse hooks use matcher strings supporting exact tool names, regex patterns (Edit\|Create, Notebook.\*), MCP tool patterns (mcp\_\_\\_\_\), and wildcard (\*) to match all tools |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | hook\_matchers: Gemini CLI hooks support event and tool name matching to filter when hooks fire |
| [cline](/using-syllago/providers/cline.md) | ✗ | Cline hooks fire on configured lifecycle events; no per-tool pattern matching documented |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI hooks fire on all events of their configured type; no per-tool filtering documented |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Kiro hooks fire on configured lifecycle events; no per-tool name filtering or regex matching documented |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | Pi hooks fire on configured lifecycle events; no per-tool name filtering at the subscription level — tool discrimination is done in handler code |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | not documented |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | Windsurf hooks fire on all events of their configured type; no per-tool or regex matching documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# metadata_map
> Arbitrary key-value metadata attached to the skill
[Source](/reference/canonical-keys/metadata-map/)
* Last verified
May 6, 2026
* Sources
19 across providers
* Support
4 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20skills%2Fmetadata_map&body=**Canonical%20key%3A**%20%60metadata_map%60%0A**Content%20type%3A**%20%60skills%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Arbitrary key-value metadata attached to the skill. Provider-specific semantics; often used for tooling or automation metadata.
**Type:** `object` **Content type:** `skills`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | --------------------------------------------------------------------------- |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | yaml frontmatter key: metadata (optional map of arbitrary key/value pairs). |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | yaml frontmatter key: metadata (optional map) |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | yaml frontmatter key: metadata (optional map) |
| [pi](/using-syllago/providers/pi.md) | ✓ | yaml frontmatter key: metadata (optional, arbitrary key-value mapping) |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented |
| [claude-code](/using-syllago/providers/claude-code.md) | ✗ | not documented |
| [cline](/using-syllago/providers/cline.md) | ✗ | not documented |
| [codex](/using-syllago/providers/codex.md) | ✗ | not documented |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | not documented |
| [crush](/using-syllago/providers/crush.md) | ✗ | not documented |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✗ | not documented |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | No metadata frontmatter key observed in Roo Code skill examples |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# model_selection
> Whether per-agent model overrides are supported, allowing different agents to use different AI models
[Source](/reference/canonical-keys/model-selection/)
* Last verified
May 6, 2026
* Sources
16 across providers
* Support
8 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20agents%2Fmodel_selection&body=**Canonical%20key%3A**%20%60model_selection%60%0A**Content%20type%3A**%20%60agents%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether per-agent model overrides are supported, allowing different agents to use different AI models.
**Type:** `bool` **Content type:** `agents`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | model frontmatter field accepts sonnet/opus/haiku alias, full model ID (e.g. claude-opus-4-7), or inherit (default); resolution order: CLAUDE\_CODE\_SUBAGENT\_MODEL env var > per-invocation model param > frontmatter model > main conversation model |
| [codex](/using-syllago/providers/codex.md) | ✓ | role config\_file can override model and model\_reasoning\_effort; caller's current profile and model\_provider preserved unless explicitly overridden |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | model field in frontmatter overrides default model for that agent |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | model frontmatter field selects a specific model for the agent, overriding the session default. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | model field accepts inherit (use parent session model) or a specific model identifier; custom BYOK models use custom: prefix; reasoningEffort (low/medium/high) is an additional per-droid field ignored when model is inherit |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | model frontmatter field (string); accepts a specific model id (e.g., 'gemini-3-preview') or 'inherit' (default) which uses the parent session's model. Optional 'temperature' field (0.0-2.0, default 1) sets per-subagent sampling temperature. |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | model field in agent JSON config overrides workspace default for that agent; falls back to default if specified model is unavailable |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | Frontmatter model field selects a specific model using provider/model-id format, overriding the session default. Primary agents use the globally configured model if not specified; subagents use the invoking primary agent's model if not specified. |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented |
| [cline](/using-syllago/providers/cline.md) | ✗ | not documented |
| [crush](/using-syllago/providers/crush.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | No per-mode model selection field documented in the mode schema |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# oauth_support
> Whether the provider supports OAuth 2
[Source](/reference/canonical-keys/oauth-support/)
* Last verified
May 6, 2026
* Sources
25 across providers
* Support
9 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20mcp%2Foauth_support&body=**Canonical%20key%3A**%20%60oauth_support%60%0A**Content%20type%3A**%20%60mcp%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether the provider supports OAuth 2.0 authentication for remote MCP servers, including token storage and automatic refresh.
**Type:** `bool` **Content type:** `mcp`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [amp](/using-syllago/providers/amp.md) | ✓ | oauth\_support: Amp supports OAuth 2.0 authentication for remote MCP servers |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | mcp\_oauth\_authentication: OAuth 2.0 for HTTP MCP servers; dynamic client registration or CIMD auto-discovery; token storage in macOS keychain or credentials file; auto-refresh; oauth.scopes pins requested scope set; authServerMetadataUrl overrides discovery chain |
| [codex](/using-syllago/providers/codex.md) | ✓ | mcp\_oauth\_support: Codex supports OAuth 2.0 authentication for remote MCP servers |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Remote servers using the streamable-http transport support OAuth authentication; static client credentials can be used instead of dynamic registration. The documentation explicitly notes OAuth as a streamable-http capability. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | OAuth authentication supported for HTTP servers; tokens stored globally in system keyring rather than per-project; managed via /mcp interactive manager |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | oauth\_authentication: Gemini CLI supports OAuth 2.0 for remote MCP servers via SSE or HTTP transports; authProviderType selects dynamic\_discovery, google\_credentials, or service\_account\_impersonation; tokens stored in \~/.gemini/mcp-oauth-tokens.json and auto-refreshed |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | Remote MCP servers support OAuth 2.0 authentication with Dynamic Client Registration (RFC 7591). OpenCode auto-detects 401 responses and initiates the OAuth flow, storing tokens in \~/.local/share/opencode/mcp-auth.json. Pre-registered client credentials can be supplied via the oauth object (clientId, clientSecret, scope). OAuth can be disabled per-server by setting oauth: false. |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | Windsurf supports OAuth for each transport type (stdio, Streamable HTTP, and SSE) for remote MCP server authentication |
| [zed](/using-syllago/providers/zed.md) | ✓ | When a remote MCP server is configured with a url but no Authorization header, Zed prompts the user to authenticate using the standard MCP OAuth flow |
| [cline](/using-syllago/providers/cline.md) | ✗ | Cline MCP does not document OAuth 2.0 authentication for remote servers |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI MCP does not document OAuth 2.0 authentication |
| [crush](/using-syllago/providers/crush.md) | ✗ | Crush MCP does not document OAuth 2.0 authentication for remote servers |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Kiro MCP does not document OAuth 2.0 authentication; remote server auth uses static headers |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | No OAuth 2.0 authentication flow documented for Roo Code MCP servers |
# per_agent_mcp
> Whether agents can have their own MCP server configuration, scoping which external tools each agent can access
[Source](/reference/canonical-keys/per-agent-mcp/)
* Last verified
May 6, 2026
* Sources
16 across providers
* Support
4 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20agents%2Fper_agent_mcp&body=**Canonical%20key%3A**%20%60per_agent_mcp%60%0A**Content%20type%3A**%20%60agents%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether agents can have their own MCP server configuration, scoping which external tools each agent can access.
**Type:** `bool` **Content type:** `agents`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | mcpServers frontmatter field: list of server names referencing already-configured workspace servers or inline server definitions; ignored for plugin subagents |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | mcp-servers inline config in frontmatter; available for cloud agent only; workspace MCP config shared by default |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | mcpServers object in frontmatter; declares inline MCP server configurations scoped to this subagent. Each entry follows the same shape as the global mcpServers config and is isolated to the subagent's invocation. |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | inline mcpServers map per agent config; includeMcpJson boolean controls whether workspace .kiro/settings/mcp.json is merged into agent's server set |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented |
| [cline](/using-syllago/providers/cline.md) | ✗ | not documented |
| [codex](/using-syllago/providers/codex.md) | ✗ | MCP configuration is workspace-wide; no per-role MCP scoping mechanism |
| [crush](/using-syllago/providers/crush.md) | ✗ | not documented |
| [cursor](/using-syllago/providers/cursor.md) | ✗ | Cursor custom agents do not document a per-agent mcpServers field; they inherit the workspace MCP configuration. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✗ | no per-droid MCP configuration documented; MCP is workspace-wide; droids can use MCP tools via the mcp tool category |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | OpenCode agent frontmatter does not document a per-agent mcpServers field; agents inherit the workspace MCP configuration. Per-agent tool access to MCP tools is controlled via the permission map (e.g., mymcp\_\*: deny) rather than a separate MCP config. |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | Custom modes do not declare their own MCP server lists — MCP configuration is global per the .roo/mcp.json and global MCP settings |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# permission_control
> Whether hooks can make or influence permission decisions determining whether a tool is available for invocation
[Source](/reference/canonical-keys/permission-control/)
* Last verified
May 6, 2026
* Sources
41 across providers
* Support
5 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20hooks%2Fpermission_control&body=**Canonical%20key%3A**%20%60permission_control%60%0A**Content%20type%3A**%20%60hooks%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether hooks can make or influence permission decisions determining whether a tool is available for invocation. Minimum qualification: supported when the provider allows hooks to return permission decisions of any kind (grant, deny, or ask). Boundary: permission\_control governs whether a tool is available; see decision\_control for invocation-flow control.
**Type:** `bool` **Content type:** `hooks`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [amp](/using-syllago/providers/amp.md) | ✓ | amp.permissions ordered first-match-wins rule list returns one of allow / reject / ask / delegate for every tool invocation before execution; default fallback is ask on the main thread and reject in sub-agents |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | hook\_permission\_update\_entries: PermissionRequest hooks return updatedPermissions with addRules/replaceRules/removeRules/setMode entries |
| [codex](/using-syllago/providers/codex.md) | ✓ | hook\_permission\_decision: Codex hooks can return permission decisions that grant or deny tool availability |
| [crush](/using-syllago/providers/crush.md) | ✓ | Hooks run before permission checks. Exit code 2 blocks the tool call entirely, taking effect before the built-in permission gate. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | PreToolUse hooks return allow, deny, or ask in the JSON decision field to bypass, block, or escalate tool permission decisions |
| [cline](/using-syllago/providers/cline.md) | ✗ | Cline hooks can cancel tool invocations (decision\_control) but cannot grant/deny tool availability |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI hooks can deny tool invocations (decision\_control) but do not govern tool availability |
| [cursor](/using-syllago/providers/cursor.md) | ✗ | Cursor hooks control allow/block via exit codes but do not govern tool availability through permission rule updates. |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | Gemini CLI hooks control invocation flow via exit codes but do not govern tool availability |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Kiro hooks do not participate in permission decisions |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | Pi extensions cannot make availability decisions for tools; tool\_call block controls invocation flow but does not remove a tool from the available set; setActiveTools() is available but is not a hook return mechanism |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | not documented |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | Windsurf hooks do not participate in permission decisions |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# project_scope
> Whether the skill can be installed at project scope (applies to current project only, typically committed to version control)
[Source](/reference/canonical-keys/project-scope/)
* Last verified
May 6, 2026
* Sources
19 across providers
* Support
14 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20skills%2Fproject_scope&body=**Canonical%20key%3A**%20%60project_scope%60%0A**Content%20type%3A**%20%60skills%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether the skill can be installed at project scope (applies to current project only, typically committed to version control).
**Type:** `bool` **Content type:** `skills`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [amp](/using-syllago/providers/amp.md) | ✓ | skill directory placed under .agents/skills/\/ or .claude/skills/\/ within the project root |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | .claude/skills/\/SKILL.md committed to version control |
| [cline](/using-syllago/providers/cline.md) | ✓ | Skills stored in .cline/skills/\/SKILL.md (recommended path) |
| [codex](/using-syllago/providers/codex.md) | ✓ | Skills directory at \/skills/ (SkillScope::Repo) or any .agents/skills/ directory between project root and cwd (monorepo traversal) |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | skill directory under .github/skills/\/, .claude/skills/\/, or .agents/skills/\/ in project repository |
| [crush](/using-syllago/providers/crush.md) | ✓ | .crush/skills/\/SKILL.md (native) and .agents/skills/\/SKILL.md (cross-provider convention) |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | .cursor/skills/\/SKILL.md for Cursor-native project scope; .agents/skills/\/SKILL.md is also recognized via the cross-provider Agent Skills convention. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | \/.factory/skills/\/SKILL.md |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | .gemini/skills/\/SKILL.md |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | Self-contained directory installed via Kiro Powers panel (UI installation, no fixed filesystem path) |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | cross-provider SKILL.md convention at .opencode/skill/\/SKILL.md |
| [pi](/using-syllago/providers/pi.md) | ✓ | .pi/skills/\/SKILL.md or .agents/skills/\/SKILL.md (checked in cwd and ancestor directories up to git repo root, or filesystem root) |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | .roo/skills/\/SKILL.md |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | Skill directory at .windsurf/skills/\/. Committed with the repo; current workspace only. For cross-agent compatibility, also discovered at .agents/skills/\/ and (if Claude Code config reading is enabled) .claude/skills/\/. |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# resource_referencing
> Whether MCP resources (not just tools) can be accessed, typically via @-mention syntax or similar referencing mechanisms
[Source](/reference/canonical-keys/resource-referencing/)
* Last verified
May 6, 2026
* Sources
25 across providers
* Support
3 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20mcp%2Fresource_referencing&body=**Canonical%20key%3A**%20%60resource_referencing%60%0A**Content%20type%3A**%20%60mcp%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether MCP resources (not just tools) can be accessed, typically via @-mention syntax or similar referencing mechanisms.
**Type:** `bool` **Content type:** `mcp`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | mcp\_resources: MCP resources accessible via @server:protocol://path syntax; appear in @ autocomplete; auto-fetched when referenced |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | MCP resources (structured data sources) are documented as a supported protocol capability alongside tools, prompts, roots, elicitation, and Apps. |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | resource\_referencing: Gemini CLI supports accessing MCP resources in addition to tools |
| [amp](/using-syllago/providers/amp.md) | ✗ | Amp does not document MCP resource referencing |
| [cline](/using-syllago/providers/cline.md) | ✗ | Cline does not document @-mention or equivalent access to MCP resources |
| [codex](/using-syllago/providers/codex.md) | ✗ | Codex does not document MCP resource referencing |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | Copilot CLI does not document MCP resource referencing |
| [crush](/using-syllago/providers/crush.md) | ✗ | MCP resource referencing (as distinct from tool calls) not documented in Crush |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✗ | no @-mention or resource referencing syntax for MCP resources documented |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | Kiro does not document MCP resource referencing |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | MCP resource referencing is not documented as a first-class feature in Roo Code |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | Windsurf does not document @-mention or equivalent access to MCP resources |
| [zed](/using-syllago/providers/zed.md) | ✗ | MCP resource referencing via @-style syntax is not documented |
# shared_scope
> Whether the skill can be installed at shared/enterprise scope (applies to all users in an organization or shared environment)
[Source](/reference/canonical-keys/shared-scope/)
* Last verified
May 6, 2026
* Sources
19 across providers
* Support
4 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20skills%2Fshared_scope&body=**Canonical%20key%3A**%20%60shared_scope%60%0A**Content%20type%3A**%20%60skills%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether the skill can be installed at shared/enterprise scope (applies to all users in an organization or shared environment).
**Type:** `bool` **Content type:** `skills`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | Managed settings deployment for organization-wide distribution |
| [codex](/using-syllago/providers/codex.md) | ✓ | Admin scope at /etc/codex/skills on Unix (SkillScope::Admin) — machine-level shared skills readable by all local users; injected via System config layer |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | .agents/skills/\/SKILL.md cross-provider convention directory read alongside .roo/skills/ |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | OS-specific system path deployed by enterprise IT; read-only for end users. macOS: /Library/Application Support/Windsurf/skills/\/; Linux/WSL: /etc/windsurf/skills/\/; Windows: C:\ProgramData\Windsurf\skills\\\\\. |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented — only project-scope (.agents/skills/) and user-wide (\~/.config/agents/skills/) are described; no enterprise or shared scope exists |
| [cline](/using-syllago/providers/cline.md) | ✗ | |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | organization-level and enterprise-level skills explicitly stated as 'coming soon' in source |
| [crush](/using-syllago/providers/crush.md) | ✗ | |
| [cursor](/using-syllago/providers/cursor.md) | ✗ | |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✗ | |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# subagent_spawning
> Whether agents can spawn, delegate to, or resume other agents
[Source](/reference/canonical-keys/subagent-spawning/)
* Last verified
May 6, 2026
* Sources
16 across providers
* Support
6 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20agents%2Fsubagent_spawning&body=**Canonical%20key%3A**%20%60subagent_spawning%60%0A**Content%20type%3A**%20%60agents%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether agents can spawn, delegate to, or resume other agents. Enables multi-agent coordination patterns.
**Type:** `bool` **Content type:** `agents`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | main-thread agents spawn subagents via Agent tool; subagents cannot spawn further subagents; Agent(type) in tools allowlist restricts which subagent types are allowed; Agent without parentheses allows spawning any subagent; omitting Agent from tools list blocks all spawning |
| [codex](/using-syllago/providers/codex.md) | ✓ | multi-agent V2 feature flag; max\_threads and max\_concurrent\_threads\_per\_session control concurrent agent count, max\_depth controls nesting depth; spawn-agent tool initiates delegation |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | agents run as subagents with isolated context windows; Git-SHA-based versioning ensures consistency across PR interactions |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Since Cursor 2.5, subagents can launch child subagents to create a tree of coordinated work. Nested launches require Task tool access and can be restricted by hooks or tool policies. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | droids exposed as subagent\_type targets for Task tool delegation; /droids menu (I key) imports Claude Code .claude/agents/\*.md to droid format with field mapping and model family translation |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | Agents with mode: subagent (or mode: all) can be invoked from other agents via the Task tool; delegation is driven by the callee's description field. Task permissions (permission.task) on the orchestrating agent control which subagents it is allowed to invoke. |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented |
| [cline](/using-syllago/providers/cline.md) | ✗ | not documented |
| [crush](/using-syllago/providers/crush.md) | ✗ | not documented |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | Recursion is explicitly prevented — subagents cannot invoke other subagents even when granted the '\*' tool wildcard. The documentation states this is to avoid infinite loops and excessive token usage. |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | no subagent spawning mechanism documented for Kiro custom agents |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | Custom modes are switched-to by the user rather than spawned as subagents; Roo Code's orchestrator mode delegates to other modes at runtime but mode files themselves do not spawn peers |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# tool_filtering
> Which per-server tool filtering mechanisms the provider supports
[Source](/reference/canonical-keys/tool-filtering/)
* Last verified
May 6, 2026
* Sources
25 across providers
* Support
12 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20mcp%2Ftool_filtering&body=**Canonical%20key%3A**%20%60tool_filtering%60%0A**Content%20type%3A**%20%60mcp%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Which per-server tool filtering mechanisms the provider supports. Contents: {allowlist: bool, blocklist: bool, disable\_flag: bool}. Controls which server tools are exposed to the agent. Boundary: tool\_filtering governs tool visibility (what appears in the agent’s available tool set); see auto\_approve for execution gating of visible tools.
**Type:** `object` **Content type:** `mcp`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [amp](/using-syllago/providers/amp.md) | ✓ | per\_tool\_enable\_disable: Amp supports per-tool enable/disable configuration to control which MCP tools are exposed to the agent |
| [cline](/using-syllago/providers/cline.md) | ✓ | always\_allow\_tools (visibility scope): Cline's always\_allow list controls which MCP tools are exposed in the agent's available tool set without per-invocation prompts |
| [codex](/using-syllago/providers/codex.md) | ✓ | mcp\_enabled\_disabled\_tools: Codex supports per-server tool enable/disable configuration controlling which tools are exposed to the agent |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | mcp\_tool\_allow\_deny\_flags: Copilot CLI supports per-tool allow and deny flags to control which MCP tools are exposed |
| [crush](/using-syllago/providers/crush.md) | ✓ | MCPConfig has a disabled\_tools array (list of tool names to exclude from a specific server). This enables per-server tool filtering at the configuration level. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | per-server tool disable via disabledTools field in Configuration Schema |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | tool\_filtering: Gemini CLI supports per-server tool filtering to control which MCP tools are exposed to the agent |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | kiro\_mcp\_disabled\_tools: Kiro supports per-server tool disable configuration to control which MCP tools are available to the agent |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | MCP tools are filtered via the global tools map in opencode.json using the server name as a prefix (e.g., mymcpservername\_\*: false); glob patterns (\* and ?) are supported; per-agent tool access is controlled via the agent's permission or tools map |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | per\_server\_tool\_filtering: alwaysAllow and disabledTools arrays on each server entry filter which MCP tools are exposed and which bypass confirmation |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | tool\_limit\_100: individual MCP tools can be toggled on or off per server via the Cascade panel UI; disabled tools are tracked in a disabledTools array separate from whitelist matching |
| [zed](/using-syllago/providers/zed.md) | ✓ | Per-profile per-server tool enable/disable maps are supported via context\_servers.\.tools in agent profile config; enable\_all\_context\_servers: false allows disabling all servers except those explicitly listed in the profile |
| [claude-code](/using-syllago/providers/claude-code.md) | ✗ | Claude Code exposes all tools from connected MCP servers; no per-server tool allowlist or blocklist for individual tool visibility |
| [cursor](/using-syllago/providers/cursor.md) | ✗ | Cursor does not document per-server tool allowlists or blocklists for MCP servers. |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
# tool_restrictions
> Whether agents can be restricted to specific tools via allowlists, denylists, tool categories, or per-tool configuration maps
[Source](/reference/canonical-keys/tool-restrictions/)
* Last verified
May 6, 2026
* Sources
16 across providers
* Support
8 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20agents%2Ftool_restrictions&body=**Canonical%20key%3A**%20%60tool_restrictions%60%0A**Content%20type%3A**%20%60agents%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Whether agents can be restricted to specific tools via allowlists, denylists, tool categories, or per-tool configuration maps.
**Type:** `bool` **Content type:** `agents`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | tools allowlist and disallowedTools denylist in frontmatter; if both set, disallowedTools applied first then tools resolved against remaining pool; Agent(type) syntax in tools allowlist restricts which subagent types a main-thread agent can spawn |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | tools field with cross-provider alias system (execute/shell/Bash, read/Read, edit/Edit, etc.); \["\*"] grants all tools; unrecognized names silently ignored |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | readonly frontmatter flag restricts an agent to read-only tools; fine-grained per-tool allow/deny lists are not documented. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | tools field accepts a category string (read-only, edit, execute, web, mcp), an explicit array of tool IDs (\["Read", "Edit", "Execute"], case-sensitive), or omission for all tools; TodoWrite is automatically included for all droids |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | tools array in frontmatter; supports wildcards: '\*' for all built-in and MCP tools, 'mcp\_\*' for all MCP tools, 'mcp\_\\_\*' for tools from a single MCP server. If omitted, the subagent inherits the full tool set from the parent session. |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | tools array with exact names, wildcards (computer\_\*), or MCP-namespaced refs (@server\_name); allowedTools list for tools requiring no user approval; toolsSettings map for per-tool behavioral config |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | The permission frontmatter map configures ask/allow/deny per tool using named permission keys (read, edit, bash, glob, grep, list, task, external\_directory, todowrite, webfetch, websearch, lsp, skill, question, doom\_loop) or wildcard glob patterns against tool names. Keys that support fine-grained control (read, edit, glob, grep, list, bash, task, external\_directory, lsp, skill) accept either a shorthand action string or an object of glob/pattern → action. |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | groups array declares which tool groups (e.g., read, edit, browser, command, mcp) the mode may use; group entries may be strings or objects with fileRegex restrictions |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented |
| [cline](/using-syllago/providers/cline.md) | ✗ | not documented |
| [codex](/using-syllago/providers/codex.md) | ✗ | role config layers override model/settings but no explicit tool allowlist or denylist in role definitions |
| [crush](/using-syllago/providers/crush.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# transport_types
> Which MCP transport protocols the provider supports
[Source](/reference/canonical-keys/transport-types/)
* Last verified
May 6, 2026
* Sources
25 across providers
* Support
12 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20mcp%2Ftransport_types&body=**Canonical%20key%3A**%20%60transport_types%60%0A**Content%20type%3A**%20%60mcp%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Which MCP transport protocols the provider supports. Common transports: stdio (local process), SSE (Server-Sent Events), HTTP/streamable-HTTP (stateless or streaming).
**Type:** `object` **Content type:** `mcp`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | mcp\_transport\_types: stdio (local process), SSE (deprecated, still supported), HTTP/streamable-HTTP (recommended for remote) |
| [cline](/using-syllago/providers/cline.md) | ✓ | sse\_transport\_support: Cline supports SSE transport alongside stdio; HTTP transport support follows MCP protocol adoption |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | Copilot CLI supports both local (stdio) and remote (HTTP/SSE) MCP server types, confirmed in concepts/context/mcp.md |
| [crush](/using-syllago/providers/crush.md) | ✓ | Crush documents stdio, http, and sse transports in its JSON schema for MCP server configuration; default transport is stdio |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | Cursor documents three MCP transports: stdio for local processes managed by Cursor, sse for Server-Sent Events (local or remote, multi-user), and streamable-http for HTTP-based servers (local or remote, multi-user) with OAuth authentication support. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | two transports documented: http (remote cloud endpoints, droid mcp add \ \ --type http) and stdio (local processes, droid mcp add \ '\' \[--env KEY=VALUE...]) |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✓ | transport\_types: Gemini CLI documents supported MCP transport protocols including stdio and HTTP |
| [kiro](/using-syllago/providers/kiro.md) | ✓ | Kiro supports stdio (local process via command + args) and remote (HTTPS endpoint or localhost HTTP via url + optional headers) server types |
| [opencode](/using-syllago/providers/opencode.md) | ✓ | OpenCode supports two transport types: local (type: local, launched via command array with stdio communication) and remote (type: remote, connected via URL supporting HTTP/SSE streamable-HTTP) |
| [roo-code](/using-syllago/providers/roo-code.md) | ✓ | transport\_types: stdio, sse, and streamable-http are supported and selected via the type field on each server entry |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | three\_transport\_types: Windsurf supports stdio, SSE, and HTTP/streamable-HTTP transports |
| [zed](/using-syllago/providers/zed.md) | ✓ | Zed supports both stdio (local command + args + env) and HTTP/HTTPS (remote URL + headers) transports. Stdio servers use the command/args/env shape; remote servers use url + optional headers. Both use the same MCP protocol initialization. |
| [amp](/using-syllago/providers/amp.md) | ✗ | Amp MCP transport types not documented beyond basic MCP support |
| [codex](/using-syllago/providers/codex.md) | ✗ | Codex MCP transport types not documented beyond basic MCP support; likely stdio only |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
# user_invocable
> When false, the skill is hidden from user-facing menus (e
[Source](/reference/canonical-keys/user-invocable/)
* Last verified
May 6, 2026
* Sources
19 across providers
* Support
5 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20skills%2Fuser_invocable&body=**Canonical%20key%3A**%20%60user_invocable%60%0A**Content%20type%3A**%20%60skills%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
When false, the skill is hidden from user-facing menus (e.g., the / command menu). The AI can still invoke it. Default: true.
**Type:** `bool` **Content type:** `skills`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [claude-code](/using-syllago/providers/claude-code.md) | ✓ | yaml frontmatter key: user-invocable (optional bool, default true); controls /menu visibility only, not Skill tool access |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✓ | slash-prefixed skill name in user prompt (e.g. /frontend-design) |
| [cursor](/using-syllago/providers/cursor.md) | ✓ | When disable-model-invocation is true, the skill becomes an explicit slash command invocable by the user rather than auto-invoked by the model. |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✓ | yaml frontmatter key: user-invocable (optional bool, default: true) |
| [windsurf](/using-syllago/providers/windsurf.md) | ✓ | Explicit @mention by skill name in Cascade input (e.g., @deploy-to-production). Always available regardless of auto-invocation eligibility. |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented — no mechanism to hide skills from user-facing menus is described; skills are managed via 'amp skill' CLI and command palette, not a slash-command invocation menu |
| [cline](/using-syllago/providers/cline.md) | ✗ | |
| [codex](/using-syllago/providers/codex.md) | ✗ | |
| [crush](/using-syllago/providers/crush.md) | ✗ | |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | No user-invocation flag observed — skills are auto-loaded based on description matching |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# version
> Semantic version string for the skill
[Source](/reference/canonical-keys/version/)
* Last verified
May 6, 2026
* Sources
19 across providers
* Support
0 of 15 providers
[Report issue](https://github.com/OpenScribbler/syllago/issues/new?title=%5Bcapmon%5D%20Incorrect%20capability%20data%3A%20skills%2Fversion&body=**Canonical%20key%3A**%20%60version%60%0A**Content%20type%3A**%20%60skills%60%0A**Data%20generated%3A**%202026-05-08%0A%0A**What%20is%20incorrect%3A**%0A%0A%3C!--%20Describe%20the%20incorrect%20data%20and%20provide%20a%20source%20URL%20if%20available%20--%3E&labels=capmon)
Semantic version string for the skill. Used for update detection and compatibility checks.
**Type:** `string` **Content type:** `skills`
## Provider Support
| Provider | Supported | Mechanism |
| -------------------------------------------------------- | --------- | -------------- |
| [amp](/using-syllago/providers/amp.md) | ✗ | not documented |
| [claude-code](/using-syllago/providers/claude-code.md) | ✗ | not documented |
| [cline](/using-syllago/providers/cline.md) | ✗ | not documented |
| [codex](/using-syllago/providers/codex.md) | ✗ | not documented |
| [copilot-cli](/using-syllago/providers/copilot-cli.md) | ✗ | not documented |
| [crush](/using-syllago/providers/crush.md) | ✗ | not documented |
| [cursor](/using-syllago/providers/cursor.md) | ✗ | not documented |
| [factory-droid](/using-syllago/providers/factory-droid.md) | ✗ | not documented |
| [gemini-cli](/using-syllago/providers/gemini-cli.md) | ✗ | not documented |
| [kiro](/using-syllago/providers/kiro.md) | ✗ | not documented |
| [opencode](/using-syllago/providers/opencode.md) | ✗ | not documented |
| [pi](/using-syllago/providers/pi.md) | ✗ | not documented |
| [roo-code](/using-syllago/providers/roo-code.md) | ✗ | not documented |
| [windsurf](/using-syllago/providers/windsurf.md) | ✗ | not documented |
| [zed](/using-syllago/providers/zed.md) | ✗ | not documented |
# Capabilities Matrix
> Cross-provider support matrix for canonical skill frontmatter keys.
[Source](/reference/capabilities-matrix/)
This matrix shows which providers support each canonical skill key and where to find details. Each key name links to a detail page with the mechanism each provider uses.
*Generated from capabilities.json on 2026-05-08.*
## Agents
| Key | amp | claude-code | cline | codex | copilot-cli | crush | cursor | factory-droid | gemini-cli | kiro | opencode | pi | roo-code | windsurf | zed |
| ---------------------------------------------------------------------- | :-: | :---------: | :---: | :---: | :---------: | :---: | :----: | :-----------: | :--------: | :--: | :------: | :-: | :------: | :------: | :-: |
| [agent\_scopes](/reference/canonical-keys/agent-scopes.md) | — | ✓ | — | ✓ | ✓ | — | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ | — | — |
| [definition\_format](/reference/canonical-keys/definition-format.md) | — | ✓ | — | ✓ | ✓ | — | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ | — | — |
| [invocation\_patterns](/reference/canonical-keys/invocation-patterns.md) | — | ✓ | — | ✓ | ✓ | — | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ | — | — |
| [model\_selection](/reference/canonical-keys/model-selection.md) | — | ✓ | — | ✓ | ✓ | — | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✗ | — | — |
| [per\_agent\_mcp](/reference/canonical-keys/per-agent-mcp.md) | — | ✓ | — | ✗ | ✓ | — | ✗ | ✗ | ✓ | ✓ | ✗ | — | ✗ | — | — |
| [subagent\_spawning](/reference/canonical-keys/subagent-spawning.md) | — | ✓ | — | ✓ | ✓ | — | ✓ | ✓ | ✗ | ✗ | ✓ | — | ✗ | — | — |
| [tool\_restrictions](/reference/canonical-keys/tool-restrictions.md) | — | ✓ | — | ✗ | ✓ | — | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ | — | — |
## Commands
| Key | amp | claude-code | cline | codex | copilot-cli | crush | cursor | factory-droid | gemini-cli | kiro | opencode | pi | roo-code | windsurf | zed |
| -------------------------------------------------------------------------- | :-: | :---------: | :---: | :---: | :---------: | :---: | :----: | :-----------: | :--------: | :--: | :------: | :-: | :------: | :------: | :-: |
| [argument\_substitution](/reference/canonical-keys/argument-substitution.md) | — | ✓ | ✗ | ✗ | ✗ | — | — | ✓ | ✓ | — | ✓ | ✓ | ✓ | ✗ | — |
| [builtin\_commands](/reference/canonical-keys/builtin-commands.md) | — | ✓ | ✓ | ✗ | ✓ | — | — | ✗ | ✓ | — | ✓ | ✗ | ✗ | ✓ | — |
## Hooks
| Key | amp | claude-code | cline | codex | copilot-cli | crush | cursor | factory-droid | gemini-cli | kiro | opencode | pi | roo-code | windsurf | zed |
| -------------------------------------------------------------------- | :-: | :---------: | :---: | :---: | :---------: | :---: | :----: | :-----------: | :--------: | :--: | :------: | :-: | :------: | :------: | :-: |
| [async\_execution](/reference/canonical-keys/async-execution.md) | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | — | ✗ | — | ✗ | — |
| [context\_injection](/reference/canonical-keys/context-injection.md) | ✗ | ✓ | ✓ | ✓ | ✗ | ✓ | ✓ | ✓ | ✗ | ✗ | — | ✓ | — | ✗ | — |
| [decision\_control](/reference/canonical-keys/decision-control.md) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ | — | ✓ | — | ✗ | — |
| [handler\_types](/reference/canonical-keys/handler-types.md) | ✓ | ✓ | ✗ | ✓ | ✗ | ✓ | ✓ | ✗ | ✗ | ✗ | — | ✓ | — | ✗ | — |
| [hook\_scopes](/reference/canonical-keys/hook-scopes.md) | ✗ | ✓ | ✓ | ✓ | ✗ | ✓ | ✓ | ✓ | ✗ | ✗ | — | ✓ | — | ✓ | — |
| [input\_modification](/reference/canonical-keys/input-modification.md) | ✗ | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | — | ✓ | — | ✗ | — |
| [json\_io\_protocol](/reference/canonical-keys/json-io-protocol.md) | ✗ | ✓ | ✓ | ✓ | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | — | ✗ | — | ✓ | — |
| [matcher\_patterns](/reference/canonical-keys/matcher-patterns.md) | ✓ | ✓ | ✗ | ✓ | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | — | ✗ | — | ✗ | — |
| [permission\_control](/reference/canonical-keys/permission-control.md) | ✓ | ✓ | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | — | ✗ | — | ✗ | — |
## MCP
| Key | amp | claude-code | cline | codex | copilot-cli | crush | cursor | factory-droid | gemini-cli | kiro | opencode | pi | roo-code | windsurf | zed |
| -------------------------------------------------------------------------- | :-: | :---------: | :---: | :---: | :---------: | :---: | :----: | :-----------: | :--------: | :--: | :------: | :-: | :------: | :------: | :-: |
| [auto\_approve](/reference/canonical-keys/auto-approve.md) | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | ✗ | ✗ | ✓ | — | — | ✓ | ✗ | ✓ |
| [enterprise\_management](/reference/canonical-keys/enterprise-management.md) | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | — | ✗ | ✓ | ✗ |
| [env\_var\_expansion](/reference/canonical-keys/env-var-expansion.md) | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ | ✓ | ✗ |
| [marketplace](/reference/canonical-keys/marketplace.md) | ✗ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ | — | — | ✗ | ✓ | ✓ |
| [oauth\_support](/reference/canonical-keys/oauth-support.md) | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | ✓ | ✓ | ✓ | ✗ | ✓ | — | ✗ | ✓ | ✓ |
| [resource\_referencing](/reference/canonical-keys/resource-referencing.md) | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✓ | ✗ | — | — | ✗ | ✗ | ✗ |
| [tool\_filtering](/reference/canonical-keys/tool-filtering.md) | ✓ | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ | ✓ | ✓ | ✓ | — | ✓ | ✓ | ✓ |
| [transport\_types](/reference/canonical-keys/transport-types.md) | ✗ | ✓ | ✓ | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ | ✓ | ✓ |
## Rules
| Key | amp | claude-code | cline | codex | copilot-cli | crush | cursor | factory-droid | gemini-cli | kiro | opencode | pi | roo-code | windsurf | zed |
| ------------------------------------------------------------------------------------- | :-: | :---------: | :---: | :---: | :---------: | :---: | :----: | :-----------: | :--------: | :--: | :------: | :-: | :------: | :------: | :-: |
| [activation\_mode](/reference/canonical-keys/activation-mode.md) | ✗ | ✓ | ✓ | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | ✓ | ✗ | ✗ | ✓ | ✓ | ✗ |
| [auto\_memory](/reference/canonical-keys/auto-memory.md) | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ |
| [cross\_provider\_recognition](/reference/canonical-keys/cross-provider-recognition.md) | ✗ | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ | ✓ | ✗ | ✓ | ✓ | ✓ |
| [file\_imports](/reference/canonical-keys/file-imports.md) | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ |
| [hierarchical\_loading](/reference/canonical-keys/hierarchical-loading.md) | ✗ | ✓ | ✗ | ✓ | ✓ | ✗ | ✓ | ✓ | ✓ | ✗ | ✓ | ✗ | ✓ | ✓ | ✗ |
## Skills
| Key | amp | claude-code | cline | codex | copilot-cli | crush | cursor | factory-droid | gemini-cli | kiro | opencode | pi | roo-code | windsurf | zed |
| --------------------------------------------------------------------------------- | :-: | :---------: | :---: | :---: | :---------: | :---: | :----: | :-----------: | :--------: | :--: | :------: | :-: | :------: | :------: | :-: |
| [canonical\_filename](/reference/canonical-keys/canonical-filename.md) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — |
| [compatibility](/reference/canonical-keys/compatibility.md) | — | — | — | — | — | — | ✓ | — | — | ✓ | ✓ | ✓ | ✗ | — | — |
| [custom\_filename](/reference/canonical-keys/custom-filename.md) | ✗ | ✓ | ✗ | — | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | — | ✓ | ✗ | — | — |
| [description](/reference/canonical-keys/description.md) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — |
| [disable\_model\_invocation](/reference/canonical-keys/disable-model-invocation.md) | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✓ | ✓ | ✗ | ✗ | — | ✓ | ✗ | — | — |
| [display\_name](/reference/canonical-keys/display-name.md) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — |
| [global\_scope](/reference/canonical-keys/global-scope.md) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ | ✓ | ✓ | ✓ | — |
| [license](/reference/canonical-keys/license.md) | — | — | — | — | — | — | ✓ | — | — | ✓ | ✓ | ✓ | ✗ | — | — |
| [metadata\_map](/reference/canonical-keys/metadata-map.md) | — | — | — | — | — | — | ✓ | — | — | ✓ | ✓ | ✓ | ✗ | — | — |
| [project\_scope](/reference/canonical-keys/project-scope.md) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — |
| [shared\_scope](/reference/canonical-keys/shared-scope.md) | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | — | ✗ | ✓ | ✓ | — |
| [user\_invocable](/reference/canonical-keys/user-invocable.md) | ✗ | ✓ | ✗ | ✗ | ✓ | ✗ | ✓ | ✓ | ✗ | ✗ | — | ✗ | ✗ | ✓ | — |
| [version](/reference/canonical-keys/version.md) | — | — | — | — | — | — | — | — | — | — | — | — | — | — | — |
## See Also
* [Providers Overview](/using-syllago/providers.md)
* [Compare Providers](/reference/compare-providers.md)
# Commands Comparison
> Cross-provider comparison of Commands support — formats, install methods, discovery paths, and frontmatter fields.
[Source](/reference/commands-matrix/)
Commands are user-invokable shortcuts (like slash commands). Only some providers support them, and frontmatter fields differ substantially.
## Format and Install Method
How each provider stores and installs commands.
| Provider | Format | Install Method | Symlink |
| -------------------------------------------------------- | -------- | -------------- | :-----: |
| [Claude Code](/using-syllago/providers/claude-code.md) | Markdown | Symlink | Yes |
| [Gemini CLI](/using-syllago/providers/gemini-cli.md) | Markdown | Symlink | Yes |
| [Windsurf](/using-syllago/providers/windsurf.md) | Markdown | Symlink | Yes |
| [Codex](/using-syllago/providers/codex.md) | Markdown | Symlink | Yes |
| [Copilot CLI](/using-syllago/providers/copilot-cli.md) | Markdown | Symlink | Yes |
| [Cline](/using-syllago/providers/cline.md) | Markdown | Symlink | Yes |
| [Roo Code](/using-syllago/providers/roo-code.md) | Markdown | Symlink | Yes |
| [OpenCode](/using-syllago/providers/opencode.md) | Markdown | Symlink | Yes |
| [Factory Droid](/using-syllago/providers/factory-droid.md) | Markdown | Symlink | Yes |
| [Pi](/using-syllago/providers/pi.md) | Markdown | Symlink | Yes |
## Discovery Paths
Where each provider looks for commands files. Paths with `~/` are relative to the user’s home directory; others are relative to the project root.
| Provider | Discovery Paths | Global Install Path |
| -------------------------------------------------------- | ------------------------------------------------------------- | -------------------------------------- |
| [Claude Code](/using-syllago/providers/claude-code.md) | `.claude/commands` | `~/.claude/commands` |
| [Gemini CLI](/using-syllago/providers/gemini-cli.md) | `.gemini/commands` | `~/.gemini/commands` |
| [Windsurf](/using-syllago/providers/windsurf.md) | `.windsurf/workflows`, `~/.codeium/windsurf/global_workflows` | `~/.codeium/windsurf/global_workflows` |
| [Codex](/using-syllago/providers/codex.md) | `.codex/commands` | `~/.codex` |
| [Copilot CLI](/using-syllago/providers/copilot-cli.md) | `.copilot/commands` | `~/.copilot/commands` |
| [Cline](/using-syllago/providers/cline.md) | `.clinerules/workflows`, `~/Documents/Cline/Workflows` | `~/Documents/Cline/Workflows` |
| [Roo Code](/using-syllago/providers/roo-code.md) | `.roo/commands`, `~/.roo/commands` | `~/.roo/commands` |
| [OpenCode](/using-syllago/providers/opencode.md) | `.opencode/commands` | `~/.config/opencode/commands` |
| [Factory Droid](/using-syllago/providers/factory-droid.md) | `.factory/commands` | `~/.factory/commands` |
| [Pi](/using-syllago/providers/pi.md) | `.pi/prompts` | `~/.pi/agent/prompts` |
## Frontmatter Fields
Which frontmatter fields each provider recognizes in commands files. A checkmark means the provider parses and uses that field during conversion.
| Field | Claude Code | Gemini CLI | Windsurf | Codex | Copilot CLI | Cline | Roo Code | OpenCode | Factory Droid | Pi |
| -------------------------- | :---------: | :--------: | :------: | :---: | :---------: | :---: | :------: | :------: | :-----------: | :-: |
| `agent` | ✓ | — | — | — | ✓ | — | — | ✓ | — | — |
| `allowed-tools` | ✓ | — | — | — | — | — | — | — | — | — |
| `argument-hint` | ✓ | — | — | ✓ | ✓ | — | — | — | — | — |
| `context` | ✓ | — | — | — | — | — | — | — | — | — |
| `description` | ✓ | ✓ | — | ✓ | ✓ | — | — | ✓ | — | — |
| `disable-model-invocation` | ✓ | — | — | — | — | — | — | — | — | — |
| `effort` | ✓ | — | — | — | — | — | — | — | — | — |
| `model` | ✓ | — | — | — | ✓ | — | — | ✓ | — | — |
| `name` | ✓ | ✓ | — | — | ✓ | — | — | — | — | — |
| `prompt` | — | ✓ | — | — | — | — | — | — | — | — |
| `subtask` | — | — | — | — | — | — | — | ✓ | — | — |
| `tools` | — | — | — | — | ✓ | — | — | — | — | — |
| `user-invocable` | ✓ | — | — | — | — | — | — | — | — | — |
**Not supported by:** [Cursor](/using-syllago/providers/cursor.md), [Zed](/using-syllago/providers/zed.md), [Kiro](/using-syllago/providers/kiro.md), [Amp](/using-syllago/providers/amp.md), [Crush](/using-syllago/providers/crush.md).
## See Also
* [Commands Content Type](/using-syllago/content-types/commands.md)
* [Providers Overview](/using-syllago/providers.md)
* [Compare Providers](/reference/compare-providers.md)
*Generated from syllago 0.13.0 on 2026-05-08.*
# Compare Providers
> Interactive side-by-side comparison of AI coding tool providers — content type support, hook events, MCP transports, rules formats, and more.
[Source](/reference/compare-providers/)
Pick two or three providers to compare their capabilities side by side. Use the dropdowns to swap providers, or click **+ Add** to compare a third.
Claude Code (claude-code)Cursor (cursor) + Add
| Feature | Claude Code | Cursor |
| -------------------- | ------------------------------ | ----------------------------------- |
| General | | |
| Config directory | `~/.claude` | `~/.cursor` |
| Emit path | `CLAUDE.md` | `.cursor/rules/syllago-context.mdc` |
| Content Type Support | | |
| Rules | Markdown · Symlink | MDC · Symlink |
| Skills | Markdown · Symlink | Markdown · Symlink |
| Agents | Markdown · Symlink | Markdown · Symlink |
| MCP Configs | JSON · JSON merge | JSON · JSON merge |
| Hooks | JSON · JSON merge | JSON · JSON merge |
| Commands | Markdown · Symlink | — |
| Hooks | | |
| Hook events | 24 events | 14 events |
| Hook types | `command``http``prompt``agent` | `command` |
| Hook config | `.claude/settings.json` | `.cursor/settings.json` |
| MCP | | |
| Transports | stdio, sse, streamable-http | stdio, sse, streamable-http |
| MCP config file | `.mcp.json` | `.cursor/mcp.json` |
| Rules | | |
| Format | Markdown | MDC |
| Frontmatter fields | `paths` | `description``alwaysApply``globs` |
## What you’re comparing
* **Content Type Support** — Which content types each provider can handle (rules, skills, agents, MCP configs, hooks, commands, loadouts) and how they’re installed
* **Hooks** — How many hook events are mapped, what handler types are available, and where hooks are configured
* **MCP** — Supported transports and configuration file location
* **Rules** — File format, frontmatter fields, and primary rules file
For a full cross-provider hook event breakdown, see the [Hook Event Matrix](/reference/hook-events.md).
# Hook Event Matrix
> Cross-provider comparison of hook events — which canonical events each provider supports and their native names.
[Source](/reference/hook-events/)
Syllago maps each provider’s native hook event names to **canonical events** — a shared vocabulary that makes hooks portable across tools. This page shows which events each provider supports and what they call them.
## How to read this table
* **Canonical name**: The syllago-standard event name used in `.syllago.yaml`
* **Provider columns**: The native event name each provider uses, or `—` if unsupported
* **Category**: Groups related events (lifecycle, tool, context, etc.)
## Collaboration
Multi-agent coordination events. Fires when teammate agents become idle or available.
| Canonical Event | Claude Code | Gemini CLI | Cursor | Windsurf | Copilot CLI | Kiro | Factory Droid | Pi |
| --------------- | -------------- | ---------- | ------ | -------- | ----------- | ---- | ------------- | -- |
| `teammate_idle` | `TeammateIdle` | — | — | — | — | — | — | — |
## Config
Configuration file change detection. Fires when settings files are modified during a session.
| Canonical Event | Claude Code | Gemini CLI | Cursor | Windsurf | Copilot CLI | Kiro | Factory Droid | Pi |
| --------------- | -------------- | ---------- | ------ | -------- | ----------- | ---- | ------------- | -- |
| `config_change` | `ConfigChange` | — | — | — | — | — | — | — |
## Context
Events related to context management — compaction, instruction loading, and context window maintenance.
| Canonical Event | Claude Code | Gemini CLI | Cursor | Windsurf | Copilot CLI | Kiro | Factory Droid | Pi |
| --------------------- | -------------------- | ------------- | ------------ | -------- | ----------- | ---- | ------------- | ------------------------ |
| `after_compact` | `PostCompact` | — | — | — | — | — | — | — |
| `before_compact` | `PreCompact` | `PreCompress` | `PreCompact` | — | — | — | `PreCompact` | `session_before_compact` |
| `context_update` | — | — | — | — | — | — | — | `context` |
| `instructions_loaded` | `InstructionsLoaded` | — | — | — | — | — | — | — |
## Interaction
User-facing prompts and dialogs. Fires when the agent asks questions or presents choices.
| Canonical Event | Claude Code | Gemini CLI | Cursor | Windsurf | Copilot CLI | Kiro | Factory Droid | Pi |
| -------------------- | ------------------- | ---------- | ------ | -------- | ----------- | ---- | ------------- | -- |
| `elicitation` | `Elicitation` | — | — | — | — | — | — | — |
| `elicitation_result` | `ElicitationResult` | — | — | — | — | — | — | — |
## Lifecycle
Session and agent lifecycle boundaries — start, stop, errors, subagents, and task completion.
| Canonical Event | Claude Code | Gemini CLI | Cursor | Windsurf | Copilot CLI | Kiro | Factory Droid | Pi |
| ---------------- | ------------------ | -------------- | ------------------ | ----------------------- | --------------------- | --------------------- | ------------------ | -------------------- |
| `after_task` | — | — | — | — | — | `Post Task Execution` | — | — |
| `agent_stop` | `Stop` | `AfterAgent` | `Stop` | `post_cascade_response` | `agentStop` | `stop` | `Stop` | `agent_end` |
| `before_prompt` | `UserPromptSubmit` | `BeforeAgent` | `UserPromptSubmit` | `pre_user_prompt` | `userPromptSubmitted` | `userPromptSubmit` | `UserPromptSubmit` | `input` |
| `before_task` | — | — | — | — | — | `Pre Task Execution` | — | — |
| `error_occurred` | `ErrorOccurred` | — | — | — | `errorOccurred` | — | — | — |
| `session_end` | `SessionEnd` | `SessionEnd` | `SessionEnd` | `session_end` | `sessionEnd` | — | `SessionEnd` | `session_shutdown` |
| `session_start` | `SessionStart` | `SessionStart` | `SessionStart` | `session_start` | `sessionStart` | `agentSpawn` | `SessionStart` | `session_start` |
| `stop_failure` | `StopFailure` | — | — | — | — | — | — | — |
| `subagent_start` | `SubagentStart` | — | `SubagentStart` | — | — | — | `SubagentStart` | `before_agent_start` |
| `subagent_stop` | `SubagentStop` | — | `SubagentStop` | — | `subagentStop` | — | `SubagentStop` | — |
| `task_completed` | `TaskCompleted` | — | — | — | — | — | — | — |
## Model
Model invocation boundaries. Fires before/after LLM calls and tool selection decisions.
| Canonical Event | Claude Code | Gemini CLI | Cursor | Windsurf | Copilot CLI | Kiro | Factory Droid | Pi |
| ----------------------- | ----------- | --------------------- | --------------------- | -------- | ----------- | ---- | ------------- | --------------- |
| `after_model` | — | `AfterModel` | `afterAgentResponse` | — | — | — | — | — |
| `before_model` | — | `BeforeModel` | `beforeAgentResponse` | — | — | — | — | — |
| `before_tool_selection` | — | `BeforeToolSelection` | `beforeToolSelection` | — | — | — | — | — |
| `message_end` | — | — | — | — | — | — | — | `message_end` |
| `message_start` | — | — | — | — | — | — | — | `message_start` |
| `model_select` | — | — | — | — | — | — | — | `model_select` |
| `turn_end` | — | — | — | — | — | — | — | `turn_end` |
| `turn_start` | — | — | — | — | — | — | — | `turn_start` |
## Output
Events for agent output like notifications and status messages.
| Canonical Event | Claude Code | Gemini CLI | Cursor | Windsurf | Copilot CLI | Kiro | Factory Droid | Pi |
| ------------------- | -------------- | -------------- | ------ | --------------------------------------- | ----------- | ---- | ------------- | -- |
| `notification` | `Notification` | `Notification` | — | — | — | — | — | — |
| `transcript_export` | — | — | — | `post_cascade_response_with_transcript` | — | — | — | — |
## Security
Permission and authorization checkpoints. Fires when the agent requests elevated permissions.
| Canonical Event | Claude Code | Gemini CLI | Cursor | Windsurf | Copilot CLI | Kiro | Factory Droid | Pi |
| -------------------- | ------------------- | ---------- | ------ | -------- | ----------- | ---- | ------------- | -- |
| `permission_request` | `PermissionRequest` | — | — | — | — | — | — | — |
## Tool
Fired before and after tool/function calls. Use these to validate, log, or transform tool inputs and outputs.
| Canonical Event | Claude Code | Gemini CLI | Cursor | Windsurf | Copilot CLI | Kiro | Factory Droid | Pi |
| --------------------- | -------------------- | ------------ | -------------------- | -------- | --------------- | ------------- | ------------- | ------------- |
| `after_tool_execute` | `PostToolUse` | `AfterTool` | `PostToolUse` | — | `postToolUse` | `postToolUse` | `PostToolUse` | `tool_result` |
| `before_tool_execute` | `PreToolUse` | `BeforeTool` | `PreToolUse` | — | `preToolUse` | `preToolUse` | `PreToolUse` | `tool_call` |
| `tool_use_failure` | `PostToolUseFailure` | — | `postToolUseFailure` | — | `errorOccurred` | — | — | — |
| `user_bash` | — | — | — | — | — | — | — | `user_bash` |
## Workspace
Git worktree creation and removal. Fires when the agent manages isolated working copies.
| Canonical Event | Claude Code | Gemini CLI | Cursor | Windsurf | Copilot CLI | Kiro | Factory Droid | Pi |
| ----------------- | ---------------- | ---------- | --------------- | --------------------- | ----------- | ------------- | ------------- | -- |
| `file_changed` | `FileChanged` | — | `afterFileEdit` | — | — | `File Save` | — | — |
| `file_created` | — | — | — | — | — | `File Create` | — | — |
| `file_deleted` | — | — | — | — | — | `File Delete` | — | — |
| `worktree_create` | `WorktreeCreate` | — | — | `post_setup_worktree` | — | — | — | — |
| `worktree_remove` | `WorktreeRemove` | — | — | — | — | — | — | — |
## Coverage Summary
| Provider | Hook Events | Hook Types |
| -------------------------------------------------------- | :---------: | ------------------------------------ |
| [Claude Code](/using-syllago/providers/claude-code.md) | 24 | `command`, `http`, `prompt`, `agent` |
| [Gemini CLI](/using-syllago/providers/gemini-cli.md) | 11 | `command` |
| [Cursor](/using-syllago/providers/cursor.md) | 14 | `command` |
| [Windsurf](/using-syllago/providers/windsurf.md) | 6 | `command` |
| [Copilot CLI](/using-syllago/providers/copilot-cli.md) | 9 | `command` |
| [Kiro](/using-syllago/providers/kiro.md) | 10 | `command` |
| [Factory Droid](/using-syllago/providers/factory-droid.md) | 9 | `command` |
| [Pi](/using-syllago/providers/pi.md) | 15 | `command` |
**Hooks supported, event mappings pending:** [Codex](/using-syllago/providers/codex.md), [Cline](/using-syllago/providers/cline.md), [Amp](/using-syllago/providers/amp.md). These providers support hooks, but syllago does not yet map their event names. Hook conversion is best-effort.
## See Also
* [Hooks Content Type](/using-syllago/content-types/hooks.md)
* [Providers Overview](/using-syllago/providers.md)
*Generated from syllago 0.13.0 on 2026-05-08.*
# Hook Interchange Format Specification
> Provider-neutral interchange format for AI coding tool hooks (v0.1.0)
[Source](/reference/hooks-v1/)
Initial Development
This specification is in initial development (v0.1.0). Per Semantic Versioning, anything MAY change at any time. The public interface should not be considered stable until version 1.0.
**Version:** 0.1.0 | **License:** CC-BY-4.0
This specification defines a provider-neutral interchange format for AI coding tool hooks. It enables hook authors to write lifecycle hooks once and deploy them across multiple AI coding tool providers through a canonical representation, capability model, and conversion pipeline.
For a user-friendly overview, see [Hooks content type](/using-syllago/content-types/hooks.md). This page is the full technical specification.
***
## 1. Introduction
AI coding tools provide hook systems that let developers run custom logic at lifecycle points: before a tool executes, when a session starts, after the agent stops. These hooks enforce policy, audit actions, inject context, and customize behavior.
Every provider’s hook system is different. Event names, JSON schemas, output contracts, matcher syntax, timeout units, and configuration file layouts vary across providers. A hook written for one tool cannot run on another without manual adaptation.
This specification defines a **canonical hook format** that serves as an interchange representation between providers. It does not replace any provider’s native format. Instead, it provides a neutral hub through which hooks are converted: decode from a source provider’s format into canonical, then encode from canonical into a target provider’s format.
### What this spec defines
* A canonical JSON format for hook manifests
* An exit code contract for hook processes
* A canonical output schema for structured hook responses
* A typed matcher system for tool filtering
* A registry of canonical event names with provider mappings
* A capability model describing optional features with provider support matrices
* A tool vocabulary mapping canonical tool names to provider-native names
* Degradation strategies for handling capability gaps during conversion
* Conformance levels for implementations
***
## 2. Canonical format
### Top-level structure
```json
{
"spec": "hooks/0.1",
"hooks": [
{
"event": "before_tool_execute",
"matcher": "shell",
"handler": {
"type": "command",
"command": "./safety-check.sh",
"timeout": 10
},
"blocking": true
}
]
}
```
| Field | Type | Required | Description |
| ------- | ------ | -------- | ----------------------------------- |
| `spec` | string | Yes | Must be `"hooks/0.1"` |
| `hooks` | array | Yes | Non-empty array of hook definitions |
### Hook definition
| Field | Type | Required | Description |
| --------------- | ------------------------ | -------- | --------------------------------------------------------------------- |
| `event` | string | Yes | Canonical event name (see Event Registry) |
| `matcher` | string, object, or array | No | Tool matcher expression (see Matcher Types) |
| `handler` | object | Yes | Handler definition |
| `blocking` | boolean | No | Whether this hook can prevent the triggering action. Default: `false` |
| `degradation` | object | No | Per-capability fallback strategies |
| `provider_data` | object | No | Opaque provider-specific data, keyed by provider slug |
### Handler definition
| Field | Type | Required | Description |
| ---------------- | ------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| `type` | string | Yes | `"command"` for shell-based handlers. Other types (`"http"`, `"prompt"`, `"agent"`) are defined as capabilities (see Capability Registry) |
| `command` | string | Conditional | Shell command or script path (required when type is `"command"`) |
| `platform` | object | No | Per-OS command overrides. Keys MUST be `"windows"`, `"linux"`, or `"darwin"` |
| `cwd` | string | No | Working directory relative to project root |
| `env` | object | No | Environment variables for the hook process |
| `timeout` | number | No | Max execution time in seconds (recommended default: 30; `0` means no timeout) |
| `timeout_action` | string | No | `"warn"` or `"block"` when timeout exceeded. Default: `"warn"` |
| `async` | boolean | No | Fire-and-forget execution. Default: `false` |
| `status_message` | string | No | Human-readable status text shown while the hook executes |
***
## 3. Exit code contract
| Exit Code | Name | Behavior |
| --------- | ---------- | ------------------------------------------------- |
| 0 | Success | Action proceeds. Stdout parsed as JSON if present |
| 1 | Hook Error | Non-blocking warning. Action proceeds |
| 2 | Block | Action prevented (only when `blocking: true`) |
| Other | Hook Error | Same as exit code 1 |
***
## 4. Canonical output schema
When a hook exits 0 with JSON on stdout:
| Field | Type | Description |
| ---------- | ------- | -------------------------------------------------- |
| `decision` | string | `"allow"`, `"deny"`, or `"ask"` |
| `reason` | string | Human-readable explanation |
| `continue` | boolean | Whether agent continues its loop (default: `true`) |
| `context` | string | Context injected into agent conversation |
Advanced fields (capability-specific):
* `updated_input` — modified tool arguments (requires `input_rewrite` capability)
* `suppress_output` — suppress tool output display (requires `structured_output`)
* `system_message` — inject system prompt message (requires `structured_output`)
***
## 5. Matcher types
### Bare string
Tool vocabulary lookup:
```json
"matcher": "shell"
```
### Pattern object
Regex on tool name:
```json
"matcher": {"pattern": "file_(read|write|edit)"}
```
### MCP object
Target MCP server/tool:
```json
"matcher": {"mcp": {"server": "github", "tool": "create_issue"}}
```
### Array (or)
Match any element:
```json
"matcher": ["shell", "file_write", {"mcp": {"server": "github"}}]
```
***
## 6. Event registry
### Core events
| Event | Description | Blocking Semantic |
| --------------------- | ------------------------------ | --------------------------------- |
| `before_tool_execute` | Before any tool runs | Can prevent tool execution |
| `after_tool_execute` | After tool completes | Observational only |
| `session_start` | Session begins/resumes | Observational; may inject context |
| `session_end` | Session terminates | Observational |
| `before_prompt` | After user input, before agent | Can modify/reject input |
| `agent_stop` | Agent main loop ends | Can trigger retry |
### Extended events
`before_compact`, `notification`, `error_occurred`, `subagent_start`, `subagent_stop`, `permission_request`
### Provider-exclusive events
| Event | Origin Provider |
| ------------------------------------------------------ | --------------- |
| `before_model`, `after_model`, `before_tool_selection` | Gemini CLI |
| `config_change` | Claude Code |
| `file_created`, `file_saved`, `file_deleted` | Kiro |
| `before_task`, `after_task` | Kiro |
### Event name mapping
| Canonical | claude-code | gemini-cli | cursor | copilot-cli | kiro |
| --------------------- | ---------------- | ----------- | -------------------- | ------------------- | ---------------- |
| `before_tool_execute` | PreToolUse | BeforeTool | beforeShellExecution | preToolUse | preToolUse |
| `after_tool_execute` | PostToolUse | AfterTool | afterFileEdit | postToolUse | postToolUse |
| `before_prompt` | UserPromptSubmit | BeforeAgent | beforeSubmitPrompt | userPromptSubmitted | userPromptSubmit |
| `agent_stop` | Stop | AfterAgent | stop | — | stop |
***
## 7. Tool vocabulary
| Canonical | claude-code | gemini-cli | cursor | copilot-cli | kiro |
| ------------ | ----------- | ------------------- | ------------------ | ----------- | ------------- |
| `shell` | Bash | run\_shell\_command | run\_terminal\_cmd | bash | execute\_bash |
| `file_read` | Read | read\_file | read\_file | view | fs\_read |
| `file_write` | Write | write\_file | edit\_file | create | fs\_write |
| `file_edit` | Edit | replace | edit\_file | edit | fs\_write |
| `search` | Grep | grep\_search | grep\_search | grep | grep |
| `find` | Glob | glob | file\_search | glob | glob |
| `web_search` | WebSearch | google\_web\_search | web\_search | — | web\_search |
| `web_fetch` | WebFetch | web\_fetch | — | web\_fetch | web\_fetch |
| `agent` | Agent | — | — | task | use\_subagent |
***
## 8. Capability registry
| Capability | Description | Default Degradation |
| ------------------- | --------------------------------------- | ------------------- |
| `structured_output` | JSON output with rich fields | `warn` |
| `input_rewrite` | Modify tool arguments (safety-critical) | `block` |
| `llm_evaluated` | LLM logic, not deterministic script | `exclude` |
| `http_handler` | HTTP POST handler | `warn` |
| `async_execution` | Fire-and-forget | `warn` |
| `platform_commands` | OS-specific overrides | `warn` |
| `custom_env` | Environment variables | `warn` |
| `configurable_cwd` | Working directory | `warn` |
***
## 9. Degradation strategies
| Strategy | Behavior |
| --------- | ----------------------------------------------------------------------------------- |
| `block` | Converted hook blocks action entirely instead of running with reduced functionality |
| `warn` | Hook runs with reduced functionality; warning emitted |
| `exclude` | Hook excluded from target provider’s configuration |
Authors specify per-capability strategies in the `degradation` field. Absent strategies use safe defaults from the capability registry.
***
## 10. Conversion pipeline
1. **Decode** — Source adapter reads provider-native config → canonical manifest
2. **Validate** — Check capabilities against target provider, apply degradation
3. **Encode** — Target adapter writes canonical → provider-native config
4. **Verify** — Re-decode output to check structural fidelity
***
## 11. Conformance levels
| Level | Requirements |
| ------------ | ---------------------------------------------------------------------------------------------- |
| **Core** | Parse/produce manifests, core events, exit codes, bare string matchers, event+tool translation |
| **Extended** | + All matcher types, output schema, capability inference, degradation, extended events |
| **Full** | + Provider data round-trip, verification, all capabilities, provider-exclusive events |
***
## Appendix: Provider strengths
* **Claude Code** — Richest output contract, four handler types, 25+ events
* **Gemini CLI** — Unique LLM-interaction hooks (`before_model`, `after_model`)
* **Kiro** — File system lifecycle hooks, spec task integration
* **Cursor** — Pre-read file access control
* **Windsurf** — Enterprise deployment infrastructure
* **OpenCode** — Programmatic TypeScript/JavaScript extensibility
* **Copilot CLI** — Conservative safety design, repository-bound hooks
# MCP Comparison
> Cross-provider comparison of MCP Configs support — formats, install methods, discovery paths, and frontmatter fields.
[Source](/reference/mcp-configs-matrix/)
MCP (Model Context Protocol) configs define external tool servers. Every provider supports MCP, but they differ in config file location, format, and supported transports.
## Format and Install Method
How each provider stores and installs mcp configs.
| Provider | Format | Install Method | Symlink |
| -------------------------------------------------------- | ------------------ | -------------- | :-----: |
| [Claude Code](/using-syllago/providers/claude-code.md) | JSON | JSON merge | No |
| [Gemini CLI](/using-syllago/providers/gemini-cli.md) | JSON | JSON merge | No |
| [Cursor](/using-syllago/providers/cursor.md) | JSON | JSON merge | No |
| [Windsurf](/using-syllago/providers/windsurf.md) | JSON | JSON merge | No |
| [Codex](/using-syllago/providers/codex.md) | TOML | JSON merge | No |
| [Copilot CLI](/using-syllago/providers/copilot-cli.md) | JSON | JSON merge | No |
| [Zed](/using-syllago/providers/zed.md) | JSON | JSON merge | No |
| [Cline](/using-syllago/providers/cline.md) | JSON | JSON merge | No |
| [Roo Code](/using-syllago/providers/roo-code.md) | JSON | JSON merge | No |
| [OpenCode](/using-syllago/providers/opencode.md) | JSON with comments | JSON merge | No |
| [Kiro](/using-syllago/providers/kiro.md) | JSON | JSON merge | No |
| [Amp](/using-syllago/providers/amp.md) | JSON | JSON merge | No |
| [Factory Droid](/using-syllago/providers/factory-droid.md) | JSON | JSON merge | No |
| [Crush](/using-syllago/providers/crush.md) | JSON | JSON merge | No |
## Discovery Paths
Where each provider looks for mcp configs files. Paths with `~/` are relative to the user’s home directory; others are relative to the project root.
| Provider | Discovery Paths | Global Install Path |
| -------------------------------------------------------- | ------------------------------------------------------------------------------------------- | ------------------- |
| [Claude Code](/using-syllago/providers/claude-code.md) | `.claude.json`, `.mcp.json` | — |
| [Gemini CLI](/using-syllago/providers/gemini-cli.md) | `.gemini/settings.json` | — |
| [Cursor](/using-syllago/providers/cursor.md) | `.cursor/mcp.json` | — |
| [Windsurf](/using-syllago/providers/windsurf.md) | — | — |
| [Codex](/using-syllago/providers/codex.md) | — | — |
| [Copilot CLI](/using-syllago/providers/copilot-cli.md) | `.copilot/mcp-config.json` | — |
| [Zed](/using-syllago/providers/zed.md) | — | — |
| [Cline](/using-syllago/providers/cline.md) | `~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json` | — |
| [Roo Code](/using-syllago/providers/roo-code.md) | `.roo/mcp.json` | — |
| [OpenCode](/using-syllago/providers/opencode.md) | `opencode.json`, `opencode.jsonc` | — |
| [Kiro](/using-syllago/providers/kiro.md) | `.kiro/settings/mcp.json` | — |
| [Amp](/using-syllago/providers/amp.md) | `.amp/settings.json` | — |
| [Factory Droid](/using-syllago/providers/factory-droid.md) | `.factory/mcp.json` | — |
| [Crush](/using-syllago/providers/crush.md) | `crush.json` | — |
## Config Location
| Provider | Config File |
| -------------------------------------------------------- | ----------------------------- |
| [Claude Code](/using-syllago/providers/claude-code.md) | `.mcp.json` |
| [Gemini CLI](/using-syllago/providers/gemini-cli.md) | `.gemini/settings.json` |
| [Cursor](/using-syllago/providers/cursor.md) | `.cursor/mcp.json` |
| [Windsurf](/using-syllago/providers/windsurf.md) | `.windsurf/mcp_config.json` |
| [Codex](/using-syllago/providers/codex.md) | `.codex/config.toml` |
| [Copilot CLI](/using-syllago/providers/copilot-cli.md) | `.copilot/mcp-config.json` |
| [Zed](/using-syllago/providers/zed.md) | `~/.config/zed/settings.json` |
| [Cline](/using-syllago/providers/cline.md) | `cline_mcp_settings.json` |
| [Roo Code](/using-syllago/providers/roo-code.md) | `.roo/mcp.json` |
| [OpenCode](/using-syllago/providers/opencode.md) | `opencode.json` |
| [Kiro](/using-syllago/providers/kiro.md) | `.kiro/settings/mcp.json` |
| [Amp](/using-syllago/providers/amp.md) | `.amp/settings.json` |
| [Factory Droid](/using-syllago/providers/factory-droid.md) | `.factory/mcp.json` |
| [Crush](/using-syllago/providers/crush.md) | `crush.json` |
## Transport Support
Which MCP transports each provider supports for communicating with tool servers.
| Transport | Claude Code | Gemini CLI | Cursor | Windsurf | Codex | Copilot CLI | Zed | Cline | Roo Code | OpenCode | Kiro | Amp | Factory Droid | Crush |
| ----------------- | :---------: | :--------: | :----: | :------: | :---: | :---------: | :-: | :---: | :------: | :------: | :--: | :-: | :-----------: | :---: |
| `http` | — | — | — | — | — | — | — | — | — | — | — | — | ✓ | ✓ |
| `sse` | ✓ | ✓ | ✓ | ✓ | — | ✓ | — | ✓ | ✓ | — | ✓ | ✓ | — | ✓ |
| `stdio` | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| `streamable-http` | ✓ | — | ✓ | — | — | — | — | ✓ | ✓ | — | — | — | — | — |
**Not supported by:** [Pi](/using-syllago/providers/pi.md).
## See Also
* [MCP Configs Content Type](/using-syllago/content-types/mcp-configs.md)
* [Providers Overview](/using-syllago/providers.md)
* [Compare Providers](/reference/compare-providers.md)
*Generated from syllago 0.13.0 on 2026-05-08.*
# Rules Comparison
> Cross-provider comparison of Rules support — formats, install methods, discovery paths, and frontmatter fields.
[Source](/reference/rules-matrix/)
Rules are the most universal content type — every provider supports them. But the format, frontmatter fields, and file locations vary. This matrix shows how rules work across providers so you know what converts cleanly and what gets adjusted.
## Format and Install Method
How each provider stores and installs rules.
| Provider | Format | Install Method | Symlink |
| -------------------------------------------------------- | ---------------------------- | -------------- | :-----: |
| [Claude Code](/using-syllago/providers/claude-code.md) | Markdown | Symlink | Yes |
| [Gemini CLI](/using-syllago/providers/gemini-cli.md) | Markdown | Symlink | Yes |
| [Cursor](/using-syllago/providers/cursor.md) | MDC (Markdown + frontmatter) | Symlink | Yes |
| [Windsurf](/using-syllago/providers/windsurf.md) | Markdown | Symlink | Yes |
| [Codex](/using-syllago/providers/codex.md) | Markdown | Symlink | Yes |
| [Copilot CLI](/using-syllago/providers/copilot-cli.md) | Markdown | Symlink | Yes |
| [Zed](/using-syllago/providers/zed.md) | Markdown | Project scope | Yes |
| [Cline](/using-syllago/providers/cline.md) | Markdown | Project scope | Yes |
| [Roo Code](/using-syllago/providers/roo-code.md) | Markdown | Project scope | Yes |
| [OpenCode](/using-syllago/providers/opencode.md) | Markdown | Symlink | Yes |
| [Kiro](/using-syllago/providers/kiro.md) | Markdown | Project scope | Yes |
| [Amp](/using-syllago/providers/amp.md) | Markdown | Symlink | Yes |
| [Factory Droid](/using-syllago/providers/factory-droid.md) | Markdown | Project scope | Yes |
| [Pi](/using-syllago/providers/pi.md) | Markdown | Project scope | Yes |
| [Crush](/using-syllago/providers/crush.md) | Markdown | Project scope | Yes |
## Discovery Paths
Where each provider looks for rules files. Paths with `~/` are relative to the user’s home directory; others are relative to the project root.
| Provider | Discovery Paths | Global Install Path |
| -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
| [Claude Code](/using-syllago/providers/claude-code.md) | `CLAUDE.md`, `.claude/rules` | `~/.claude/rules` |
| [Gemini CLI](/using-syllago/providers/gemini-cli.md) | `GEMINI.md` | `~/.gemini` |
| [Cursor](/using-syllago/providers/cursor.md) | `.cursor/rules`, `.cursorrules` | `~/.cursor` |
| [Windsurf](/using-syllago/providers/windsurf.md) | `.windsurfrules`, `.windsurf/rules` | `~/.codeium/windsurf` |
| [Codex](/using-syllago/providers/codex.md) | `AGENTS.md` | `~/.codex` |
| [Copilot CLI](/using-syllago/providers/copilot-cli.md) | `.github/copilot-instructions.md`, `AGENTS.md` | `~/.copilot` |
| [Zed](/using-syllago/providers/zed.md) | `.rules`, `.cursorrules`, `CLAUDE.md` | — |
| [Cline](/using-syllago/providers/cline.md) | `.clinerules`, `~/Documents/Cline/Rules` | — |
| [Roo Code](/using-syllago/providers/roo-code.md) | `.roo/rules`, `.roo/rules-code`, `.roo/rules-architect`, `.roo/rules-ask`, `.roo/rules-debug`, `.roo/rules-orchestrator`, `.roorules`, `~/.roo/rules` | — |
| [OpenCode](/using-syllago/providers/opencode.md) | `AGENTS.md`, `CLAUDE.md` | `~/.config/opencode` |
| [Kiro](/using-syllago/providers/kiro.md) | `.kiro/steering` | — |
| [Amp](/using-syllago/providers/amp.md) | `AGENTS.md`, `AGENT.md`, `CLAUDE.md` | `~/.config/amp` |
| [Factory Droid](/using-syllago/providers/factory-droid.md) | `AGENTS.md` | — |
| [Pi](/using-syllago/providers/pi.md) | `AGENTS.md` | — |
| [Crush](/using-syllago/providers/crush.md) | `AGENTS.md` | — |
## Frontmatter Fields
Which frontmatter fields each provider recognizes in rules files. A checkmark means the provider parses and uses that field during conversion.
| Field | Claude Code | Gemini CLI | Cursor | Windsurf | Codex | Copilot CLI | Zed | Cline | Roo Code | OpenCode | Kiro | Amp | Factory Droid | Pi | Crush |
| ------------------ | :---------: | :--------: | :----: | :------: | :---: | :---------: | :-: | :---: | :------: | :------: | :--: | :-: | :-----------: | :-: | :---: |
| `alwaysApply` | — | — | ✓ | — | — | — | — | — | — | — | — | — | — | — | — |
| `applyTo` | — | — | — | — | — | ✓ | — | — | — | — | — | — | — | — | — |
| `description` | — | — | ✓ | ✓ | — | — | — | — | — | — | ✓ | — | — | — | — |
| `fileMatchPattern` | — | — | — | — | — | — | — | — | — | — | ✓ | — | — | — | — |
| `globs` | — | — | ✓ | ✓ | — | — | — | — | — | — | — | ✓ | — | — | — |
| `inclusion` | — | — | — | — | — | — | — | — | — | — | ✓ | — | — | — | — |
| `name` | — | — | — | — | — | — | — | — | — | — | ✓ | — | — | — | — |
| `paths` | ✓ | — | — | — | — | — | — | ✓ | — | — | — | — | — | — | — |
| `trigger` | — | — | — | ✓ | — | — | — | — | — | — | — | — | — | — | — |
## See Also
* [Rules Content Type](/using-syllago/content-types/rules.md)
* [Providers Overview](/using-syllago/providers.md)
* [Compare Providers](/reference/compare-providers.md)
*Generated from syllago 0.13.0 on 2026-05-08.*
# Skills Comparison
> Cross-provider comparison of Skills support — formats, install methods, discovery paths, and frontmatter fields.
[Source](/reference/skills-matrix/)
Skills are reusable prompt-driven capabilities that can be invoked by name. Not every provider supports them — and those that do vary in what frontmatter fields they recognize.
## Format and Install Method
How each provider stores and installs skills.
| Provider | Format | Install Method | Symlink |
| -------------------------------------------------------- | -------- | -------------- | :-----: |
| [Claude Code](/using-syllago/providers/claude-code.md) | Markdown | Symlink | Yes |
| [Gemini CLI](/using-syllago/providers/gemini-cli.md) | Markdown | Symlink | Yes |
| [Cursor](/using-syllago/providers/cursor.md) | Markdown | Symlink | Yes |
| [Windsurf](/using-syllago/providers/windsurf.md) | Markdown | Symlink | Yes |
| [Codex](/using-syllago/providers/codex.md) | Markdown | Symlink | Yes |
| [Copilot CLI](/using-syllago/providers/copilot-cli.md) | Markdown | Symlink | Yes |
| [Cline](/using-syllago/providers/cline.md) | Markdown | Symlink | Yes |
| [Roo Code](/using-syllago/providers/roo-code.md) | Markdown | Symlink | Yes |
| [OpenCode](/using-syllago/providers/opencode.md) | Markdown | Symlink | Yes |
| [Kiro](/using-syllago/providers/kiro.md) | Markdown | Project scope | Yes |
| [Amp](/using-syllago/providers/amp.md) | Markdown | Symlink | Yes |
| [Factory Droid](/using-syllago/providers/factory-droid.md) | Markdown | Symlink | Yes |
| [Pi](/using-syllago/providers/pi.md) | Markdown | Symlink | Yes |
| [Crush](/using-syllago/providers/crush.md) | Markdown | Symlink | Yes |
## Discovery Paths
Where each provider looks for skills files. Paths with `~/` are relative to the user’s home directory; others are relative to the project root.
| Provider | Discovery Paths | Global Install Path |
| -------------------------------------------------------- | -------------------------------------------------------------------------- | ---------------------------- |
| [Claude Code](/using-syllago/providers/claude-code.md) | `.claude/skills` | `~/.claude/skills` |
| [Gemini CLI](/using-syllago/providers/gemini-cli.md) | `.gemini/skills`, `.agents/skills` | `~/.gemini/skills` |
| [Cursor](/using-syllago/providers/cursor.md) | `.cursor/skills` | `~/.cursor/skills` |
| [Windsurf](/using-syllago/providers/windsurf.md) | `.windsurf/skills`, `.agents/skills` | `~/.codeium/windsurf/skills` |
| [Codex](/using-syllago/providers/codex.md) | `.agents/skills` | `~/.agents/skills` |
| [Copilot CLI](/using-syllago/providers/copilot-cli.md) | `.github/skills` | `~/.github/skills` |
| [Cline](/using-syllago/providers/cline.md) | `.cline/skills`, `.clinerules/skills`, `.claude/skills`, `~/.cline/skills` | `~/.cline/skills` |
| [Roo Code](/using-syllago/providers/roo-code.md) | `.roo/skills`, `.agents/skills` | `~/.roo/skills` |
| [OpenCode](/using-syllago/providers/opencode.md) | `.opencode/skills`, `.agents/skills` | `~/.config/opencode/skills` |
| [Kiro](/using-syllago/providers/kiro.md) | `.kiro/steering` | — |
| [Amp](/using-syllago/providers/amp.md) | `.agents/skills`, `.claude/skills` | `~/.config/agents/skills` |
| [Factory Droid](/using-syllago/providers/factory-droid.md) | `.factory/skills` | `~/.factory/skills` |
| [Pi](/using-syllago/providers/pi.md) | `.pi/skills` | `~/.pi/agent/skills` |
| [Crush](/using-syllago/providers/crush.md) | `.crush/skills` | `~/.config/crush/skills` |
## Frontmatter Fields
Which frontmatter fields each provider recognizes in skills files. A checkmark means the provider parses and uses that field during conversion.
| Field | Claude Code | Gemini CLI | Cursor | Windsurf | Codex | Copilot CLI | Cline | Roo Code | OpenCode | Kiro | Amp | Factory Droid | Pi | Crush |
| -------------------------- | :---------: | :--------: | :----: | :------: | :---: | :---------: | :---: | :------: | :------: | :--: | :-: | :-----------: | :-: | :---: |
| `agent` | ✓ | — | — | — | — | — | — | — | — | — | — | — | — | — |
| `allowed-tools` | ✓ | — | — | — | — | — | — | — | — | — | — | — | — | — |
| `argument-hint` | ✓ | — | — | — | — | ✓ | — | — | — | — | — | — | — | — |
| `compatibility` | ✓ | — | ✓ | — | — | — | — | — | ✓ | ✓ | — | ✓ | ✓ | ✓ |
| `context` | ✓ | — | — | — | — | — | — | — | — | — | — | — | — | — |
| `description` | ✓ | ✓ | ✓ | ✓ | — | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| `disable-model-invocation` | ✓ | — | ✓ | — | — | ✓ | — | — | — | — | — | — | — | — |
| `disallowed-tools` | ✓ | — | — | — | — | — | — | — | — | — | — | — | — | — |
| `effort` | ✓ | — | — | — | — | — | — | — | — | — | — | — | — | — |
| `hooks` | ✓ | — | — | — | — | — | — | — | — | — | — | — | — | — |
| `license` | ✓ | — | ✓ | — | — | ✓ | — | — | ✓ | ✓ | — | ✓ | ✓ | ✓ |
| `metadata` | ✓ | — | ✓ | — | — | — | — | — | ✓ | ✓ | — | ✓ | ✓ | ✓ |
| `model` | ✓ | — | — | — | — | — | — | — | — | — | — | — | — | — |
| `name` | ✓ | ✓ | ✓ | ✓ | — | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| `user-invocable` | ✓ | — | — | — | — | ✓ | — | — | — | — | — | — | — | — |
**Not supported by:** [Zed](/using-syllago/providers/zed.md).
## See Also
* [Skills Content Type](/using-syllago/content-types/skills.md)
* [Providers Overview](/using-syllago/providers.md)
* [Compare Providers](/reference/compare-providers.md)
*Generated from syllago 0.13.0 on 2026-05-08.*
# Telemetry
> What syllago collects, how it works, and what it never collects. Full event catalog with every property documented.
[Source](/reference/telemetry/)
Syllago collects anonymous usage telemetry to understand which commands and features are used. Telemetry is **opt-out** — you can disable it at any time.
## Opting out
Any of these methods will disable telemetry:
```bash
# Via syllago command
syllago telemetry off
# Via environment variable (respects console.do standard)
export DO_NOT_TRACK=1
```
## What we collect
Every event includes these standard properties:
| Property | Type | Description | Example |
| --------- | -------- | --------------------------------- | --------- |
| `version` | `string` | Syllago version | `"0.7.0"` |
| `os` | `string` | Operating system (runtime.GOOS) | `"linux"` |
| `arch` | `string` | CPU architecture (runtime.GOARCH) | `"amd64"` |
## `command_executed`
Fired when a CLI command completes successfully.
**When:** PersistentPostRun (every non-telemetry command)
| Property | Type | Description | Example | Commands |
| --------------------------- | -------- | ------------------------------------------------------------------------------------------------------- | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `command` | `string` | Command name (cobra command path) | `"install"` | all |
| `provider` | `string` | Target provider slug | `"claude-code"` | `install`, `uninstall`, `loadout_apply`, `sandbox_run`, `sync-and-export`, `capmon_validate_spec`, `capmon_validate_format_doc`, `capmon_validate_sources`, `capmon_derive`, `capmon_check`, `capmon_onboard`, `capmon_fetch` |
| `content_type` | `string` | Content type filter or specific type | `"rules"` | `install`, `add`, `convert`, `create`, `uninstall`, `remove`, `list`, `share`, `sync-and-export`, `registry_items`, `capmon_validate_spec` |
| `content_count` | `int` | Number of content items affected | `3` | `install`, `add` |
| `dry_run` | `bool` | Whether —dry-run flag was used | `false` | `install`, `add`, `uninstall`, `remove`, `sync-and-export`, `capmon_fetch` |
| `from` | `string` | Source provider slug when adding cross-provider content | `"cursor"` | `add` |
| `from_provider` | `string` | Source provider for conversion | `"cursor"` | `convert` |
| `to_provider` | `string` | Target provider for conversion | `"claude-code"` | `convert` |
| `source_filter` | `string` | Content source filter (library, shared, or registry) | `"library"` | `list` |
| `filter` | `string` | State-based filter applied to list output (comma-separated states: in-library, not-in-library, project) | `"in-library"` | `list` |
| `install` | `bool` | Whether —install was passed to chain add + install in a single command | `true` | `add` |
| `item_count` | `int` | Number of items in the result set | `12` | `list`, `registry_items` |
| `source_count` | `int` | Total number of provider sources targeted by capmon fetch | `15` | `capmon_fetch` |
| `fetch_errors` | `int` | Number of sources that failed to fetch in capmon fetch | `0` | `capmon_fetch` |
| `mode` | `string` | Operational mode (loadout ‘try’, add ‘monolithic’) | `"try"` | `loadout_apply`, `add` |
| `discovery_candidate_count` | `int` | Number of monolithic rule files considered by add (D18) | `3` | `add` |
| `selected_count` | `int` | Number of monolithic rule files actually imported (D18) | `2` | `add` |
| `split_method` | `string` | Splitter heuristic used for monolithic rule imports (D3) | `"h2"` | `add` |
| `scope` | `string` | Scope label for the imported sources (project, global, mixed) | `"project"` | `add` |
| `action_count` | `int` | Number of actions performed by loadout | `5` | `loadout_apply` |
| `registry_count` | `int` | Number of registries involved | `2` | `registry_sync` |
| `moat_tier` | `string` | Resolved MOAT trust tier for the item (UNSIGNED, SIGNED, DUAL-ATTESTED) | `"SIGNED"` | `install` |
| `moat_gated` | `string` | MOAT install-gate outcome (proceed, hard-block, publisher-warn, private-prompt, tier-below-policy) | `"proceed"` | `install` |
| `verification_state` | `string` | D16 verification state for rule-append installs (fresh, clean, modified) | `"clean"` | `install` |
| `decision_action` | `string` | D17 decision action taken during re-install (proceed, replace, skip, drop\_record, append\_fresh, keep) | `"replace"` | `install` |
## `tui_session_started`
Fired when the TUI exits normally after a session.
**When:** After tea.Program.Run() completes without error (main.go root command)
| Property | Type | Description | Example | Commands |
| --------- | ------ | ------------------------------- | ------- | -------- |
| `success` | `bool` | Whether the TUI exited normally | `true` | `(root)` |
## What we never collect
These categories of data are **never** included in telemetry events, regardless of configuration:
| Category | Examples |
| ----------------------- | ---------------------------------------------------------------- |
| **File contents** | Rule text, skill prompts, hook commands, MCP configs |
| **File paths** | /home/user/.claude/rules/my-secret-rule |
| **User identity** | Usernames, hostnames, IP addresses, email |
| **Registry URLs** | Git clone URLs, registry names |
| **Content names** | Names of rules, skills, agents, hooks, or MCP servers you manage |
| **Interaction details** | Keystrokes, mouse clicks, TUI navigation paths |
## Implementation
* Telemetry is sent to PostHog via their batch API
* A random anonymous ID is generated on first run and stored locally
* No cookies, fingerprinting, or cross-device tracking
* All telemetry code is in [`cli/internal/telemetry/`](https://github.com/OpenScribbler/syllago/tree/main/cli/internal/telemetry)
* The event catalog source of truth is [`catalog.go`](https://github.com/OpenScribbler/syllago/blob/main/cli/internal/telemetry/catalog.go)
*Generated from syllago 0.13.0 on 2026-05-08.*
# CLI Reference
> Complete reference for all syllago commands and flags.
[Source](/using-syllago/cli-reference/)
Auto-generated from syllago 0.13.0 on 2026-05-08.
### Core Commands
| Command | Description |
| -------------------------------------------------------------------- | ------------------------------------------------------------- |
| [`syllago add`](/using-syllago/cli-reference/add.md) | Add content to your library from a provider |
| [`syllago compat`](/using-syllago/cli-reference/compat.md) | Show provider compatibility matrix for a content item |
| [`syllago convert`](/using-syllago/cli-reference/convert.md) | Convert content between provider formats |
| [`syllago doctor`](/using-syllago/cli-reference/doctor.md) | Check your syllago setup for problems |
| [`syllago edit`](/using-syllago/cli-reference/edit.md) | Edit a content item’s display name or description |
| [`syllago explain`](/using-syllago/cli-reference/explain.md) | Show detailed documentation for an error code |
| [`syllago formats`](/using-syllago/cli-reference/formats.md) | List supported file formats |
| [`syllago info`](/using-syllago/cli-reference/info.md) | Show machine-readable capability manifest |
| [`syllago init`](/using-syllago/cli-reference/init.md) | Initialize syllago for this project |
| [`syllago inspect`](/using-syllago/cli-reference/inspect.md) | Show details about a content item |
| [`syllago install`](/using-syllago/cli-reference/install.md) | Activate library content in a provider |
| [`syllago list`](/using-syllago/cli-reference/list.md) | List content items in the library |
| [`syllago providers`](/using-syllago/cli-reference/providers.md) | List providers or show data quality for a specific slug |
| [`syllago refresh`](/using-syllago/cli-reference/refresh.md) | Check for and apply content updates from registries |
| [`syllago remove`](/using-syllago/cli-reference/remove.md) | Remove content from your library and uninstall from providers |
| [`syllago share`](/using-syllago/cli-reference/share.md) | Contribute library content to a team repo or registry |
| [`syllago sync-install`](/using-syllago/cli-reference/sync-install.md) | Sync registries then install content to a provider |
| [`syllago uninstall`](/using-syllago/cli-reference/uninstall.md) | Deactivate content from a provider |
| [`syllago update`](/using-syllago/cli-reference/update.md) | Update syllago to the latest release |
| [`syllago version`](/using-syllago/cli-reference/version.md) | Print syllago version |
### [`syllago capmon`](/using-syllago/cli-reference/capmon.md)
Capability monitor pipeline
| Command | Description |
| ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------- |
| [`syllago capmon backfill`](/using-syllago/cli-reference/capmon-backfill.md) | Populate missing content\_hash values in a provider format doc |
| [`syllago capmon check`](/using-syllago/cli-reference/capmon-check.md) | Check for content drift in provider format docs |
| [`syllago capmon derive`](/using-syllago/cli-reference/capmon-derive.md) | Derive a seeder spec from a provider format doc |
| [`syllago capmon diff`](/using-syllago/cli-reference/capmon-diff.md) | Show field-level changes in provider-capabilities since a git ref |
| [`syllago capmon extract`](/using-syllago/cli-reference/capmon-extract.md) | Run extraction on cached sources |
| [`syllago capmon fetch`](/using-syllago/cli-reference/capmon-fetch.md) | Fetch source URLs and update hash cache |
| [`syllago capmon generate`](/using-syllago/cli-reference/capmon-generate.md) | Regenerate per-content-type views and spec tables from provider-capabilities YAML |
| [`syllago capmon onboard`](/using-syllago/cli-reference/capmon-onboard.md) | Bootstrap a new provider into the capmon pipeline |
| [`syllago capmon run`](/using-syllago/cli-reference/capmon-run.md) | Run the full capability monitor pipeline |
| [`syllago capmon seed`](/using-syllago/cli-reference/capmon-seed.md) | Bootstrap or re-seed provider capability YAML from extracted data |
| [`syllago capmon test-fixtures`](/using-syllago/cli-reference/capmon-test-fixtures.md) | Report fixture staleness or update fixtures for a provider |
| [`syllago capmon validate-format-doc`](/using-syllago/cli-reference/capmon-validate-format-doc.md) | Validate a provider format doc against the canonical keys vocabulary |
| [`syllago capmon validate-sources`](/using-syllago/cli-reference/capmon-validate-sources.md) | Validate a provider’s source manifest has URIs for all supported content types |
| [`syllago capmon verify`](/using-syllago/cli-reference/capmon-verify.md) | Validate provider-capabilities YAML against JSON Schema |
### [`syllago completion`](/using-syllago/cli-reference/completion.md)
Generate the autocompletion script for the specified shell
| Command | Description |
| -------------------------------------------------------------------------------------- | ------------------------------------------------- |
| [`syllago completion bash`](/using-syllago/cli-reference/completion-bash.md) | Generate the autocompletion script for bash |
| [`syllago completion fish`](/using-syllago/cli-reference/completion-fish.md) | Generate the autocompletion script for fish |
| [`syllago completion powershell`](/using-syllago/cli-reference/completion-powershell.md) | Generate the autocompletion script for powershell |
| [`syllago completion zsh`](/using-syllago/cli-reference/completion-zsh.md) | Generate the autocompletion script for zsh |
### [`syllago config`](/using-syllago/cli-reference/config.md)
View and edit syllago configuration
| Command | Description |
| ---------------------------------------------------------------------- | ---------------------------------------- |
| [`syllago config add`](/using-syllago/cli-reference/config-add.md) | Add a provider to the configuration |
| [`syllago config list`](/using-syllago/cli-reference/config-list.md) | List current configuration |
| [`syllago config paths`](/using-syllago/cli-reference/config-paths.md) | Manage custom provider path overrides |
| [`syllago config remove`](/using-syllago/cli-reference/config-remove.md) | Remove a provider from the configuration |
### [`syllago loadout`](/using-syllago/cli-reference/loadout.md)
Apply, create, and manage loadouts
| Command | Description |
| ------------------------------------------------------------------------ | ------------------------------------------------------------------------- |
| [`syllago loadout apply`](/using-syllago/cli-reference/loadout-apply.md) | Preview or apply a loadout (default: preview; use —try or —keep to apply) |
| [`syllago loadout create`](/using-syllago/cli-reference/loadout-create.md) | Interactively create a new loadout |
| [`syllago loadout list`](/using-syllago/cli-reference/loadout-list.md) | List available loadouts |
| [`syllago loadout remove`](/using-syllago/cli-reference/loadout-remove.md) | Remove the active loadout and restore original configuration |
| [`syllago loadout status`](/using-syllago/cli-reference/loadout-status.md) | Show active loadout status |
### [`syllago manifest`](/using-syllago/cli-reference/manifest.md)
Manage registry manifests
| Command | Description |
| ------------------------------------------------------------------------------ | -------------------------------------------- |
| [`syllago manifest generate`](/using-syllago/cli-reference/manifest-generate.md) | Generate a registry.yaml for this repository |
### [`syllago moat`](/using-syllago/cli-reference/moat.md)
Manage MOAT registry trust and verification
| Command | Description |
| ---------------------------------------------------------------- | ----------------------------------------------------------------------- |
| [`syllago moat sign`](/using-syllago/cli-reference/moat-sign.md) | Produce a signature.bundle from a manifest (online or dev-offline mode) |
| [`syllago moat trust`](/using-syllago/cli-reference/moat-trust.md) | Trusted-root lifecycle (status, refresh) |
### [`syllago registry`](/using-syllago/cli-reference/registry.md)
Manage git-based content registries
| Command | Description |
| -------------------------------------------------------------------------- | ---------------------------------------------- |
| [`syllago registry add`](/using-syllago/cli-reference/registry-add.md) | Add a git registry |
| [`syllago registry create`](/using-syllago/cli-reference/registry-create.md) | Create a new registry |
| [`syllago registry items`](/using-syllago/cli-reference/registry-items.md) | Browse content available in registries |
| [`syllago registry list`](/using-syllago/cli-reference/registry-list.md) | List registered registries |
| [`syllago registry remove`](/using-syllago/cli-reference/registry-remove.md) | Remove a registry and delete its local clone |
| [`syllago registry sync`](/using-syllago/cli-reference/registry-sync.md) | Pull latest content from one or all registries |
### [`syllago sandbox`](/using-syllago/cli-reference/sandbox.md)
Run and manage AI CLI tools in bubblewrap sandboxes
| Command | Description |
| ------------------------------------------------------------------------------------ | --------------------------------------------------- |
| [`syllago sandbox allow-domain`](/using-syllago/cli-reference/sandbox-allow-domain.md) | Add a domain to the sandbox allowlist |
| [`syllago sandbox allow-env`](/using-syllago/cli-reference/sandbox-allow-env.md) | Add an env var to the sandbox allowlist |
| [`syllago sandbox allow-port`](/using-syllago/cli-reference/sandbox-allow-port.md) | Add a localhost port to the sandbox allowlist |
| [`syllago sandbox check`](/using-syllago/cli-reference/sandbox-check.md) | Verify bubblewrap, socat, and optionally a provider |
| [`syllago sandbox deny-domain`](/using-syllago/cli-reference/sandbox-deny-domain.md) | Remove a domain from the sandbox allowlist |
| [`syllago sandbox deny-env`](/using-syllago/cli-reference/sandbox-deny-env.md) | Remove an env var from the sandbox allowlist |
| [`syllago sandbox deny-port`](/using-syllago/cli-reference/sandbox-deny-port.md) | Remove a localhost port from the sandbox allowlist |
| [`syllago sandbox domains`](/using-syllago/cli-reference/sandbox-domains.md) | List allowed domains |
| [`syllago sandbox env`](/using-syllago/cli-reference/sandbox-env.md) | List allowed env vars |
| [`syllago sandbox info`](/using-syllago/cli-reference/sandbox-info.md) | Show effective sandbox configuration |
| [`syllago sandbox ports`](/using-syllago/cli-reference/sandbox-ports.md) | List allowed localhost ports |
| [`syllago sandbox run`](/using-syllago/cli-reference/sandbox-run.md) | Run a provider in a sandbox |
### [`syllago telemetry`](/using-syllago/cli-reference/telemetry.md)
Manage usage analytics settings
| Command | Description |
| ---------------------------------------------------------------------------- | ------------------------------------- |
| [`syllago telemetry off`](/using-syllago/cli-reference/telemetry-off.md) | Disable telemetry |
| [`syllago telemetry on`](/using-syllago/cli-reference/telemetry-on.md) | Enable telemetry |
| [`syllago telemetry reset`](/using-syllago/cli-reference/telemetry-reset.md) | Generate a new anonymous ID |
| [`syllago telemetry status`](/using-syllago/cli-reference/telemetry-status.md) | Show telemetry state and anonymous ID |
# syllago add
> Add content to your library from a provider
[Source](/using-syllago/cli-reference/add/)
## Synopsis
```plaintext
syllago add [[/]] --from [flags]
```
## Description
Discovers content from a provider and adds it to your library (\~/.syllago/content/).
Without a positional argument, shows what content is available (discovery mode). Provide a type or type/name to add content.
Syllago handles format conversion automatically. Once added, content can be installed to any supported provider with “syllago install —to \”.
## Options
| Flag | Type | Default | Required | Description |
| --------------------- | ------------- | ------- | -------- | --------------------------------------------------------------------------------------- |
| `--all` | `bool` | — | No | Add all discovered content (cannot combine with positional target) |
| `--base-dir` | `string` | — | No | Override base directory for content discovery |
| `--dry-run` | `bool` | — | No | Show what would be written without actually writing |
| `--exclude` | `stringArray` | — | No | Skip hooks by auto-derived name (hooks and MCP only) |
| `-f`, `--force` | `bool` | — | No | Overwrite existing item without prompting |
| `--from` | `stringArray` | — | Yes | Provider to add from, or path to a monolithic rule file (repeatable for files) |
| `--install` | `bool` | — | No | Install added items immediately after adding (requires —to) |
| `--name` | `string` | — | No | Display name for hooks/MCP (stored in .syllago.yaml metadata) |
| `--no-input` | `bool` | — | No | Disable interactive prompts, use defaults |
| `--scope` | `string` | `all` | No | Settings scope to read from: global, project, or all (hooks and MCP only) |
| `--source-registry` | `string` | — | No | Registry name for taint tracking |
| `--source-visibility` | `string` | — | No | Source registry visibility (public, private, unknown) |
| `--split` | `string` | — | No | Splitter heuristic: h2 |
| `--to` | `string` | — | No | Target provider for —install |
| `--trusted-root` | `string` | — | No | Path to Sigstore trusted\_root.json (overrides registry config and the bundled default) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Discover available content (read-only)
syllago add --from claude-code
# Add all rules from a provider
syllago add rules --from claude-code
# Add a specific rule by name
syllago add rules/security --from claude-code
# Add everything
syllago add --all --from claude-code
# Preview what would be written
syllago add --from claude-code --dry-run
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/add.go)
# syllago capmon
> Capability monitor pipeline
[Source](/using-syllago/cli-reference/capmon/)
Fetch, extract, diff, and report on AI provider capability drift.
## Subcommands
| Command | Description |
| --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| [`backfill`](/using-syllago/cli-reference/capmon-backfill.md) | Populate missing content\_hash values in a provider format doc |
| [`check`](/using-syllago/cli-reference/capmon-check.md) | Check for content drift in provider format docs |
| [`derive`](/using-syllago/cli-reference/capmon-derive.md) | Derive a seeder spec from a provider format doc |
| [`diff`](/using-syllago/cli-reference/capmon-diff.md) | Show field-level changes in provider-capabilities since a git ref |
| [`extract`](/using-syllago/cli-reference/capmon-extract.md) | Run extraction on cached sources |
| [`fetch`](/using-syllago/cli-reference/capmon-fetch.md) | Fetch source URLs and update hash cache |
| [`generate`](/using-syllago/cli-reference/capmon-generate.md) | Regenerate per-content-type views and spec tables from provider-capabilities YAML |
| [`onboard`](/using-syllago/cli-reference/capmon-onboard.md) | Bootstrap a new provider into the capmon pipeline |
| [`run`](/using-syllago/cli-reference/capmon-run.md) | Run the full capability monitor pipeline |
| [`seed`](/using-syllago/cli-reference/capmon-seed.md) | Bootstrap or re-seed provider capability YAML from extracted data |
| [`test-fixtures`](/using-syllago/cli-reference/capmon-test-fixtures.md) | Report fixture staleness or update fixtures for a provider |
| [`validate-format-doc`](/using-syllago/cli-reference/capmon-validate-format-doc.md) | Validate a provider format doc against the canonical keys vocabulary |
| [`validate-sources`](/using-syllago/cli-reference/capmon-validate-sources.md) | Validate a provider’s source manifest has URIs for all supported content types |
| [`verify`](/using-syllago/cli-reference/capmon-verify.md) | Validate provider-capabilities YAML against JSON Schema |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/capmon_cmd.go)
# syllago capmon backfill
> Populate missing content_hash values in a provider format doc
[Source](/using-syllago/cli-reference/capmon-backfill/)
## Synopsis
```plaintext
syllago capmon backfill [flags]
```
## Description
Fetch each source URI in the provider’s FormatDoc and write the SHA-256 hash back into the file, preserving comments and key order. By default only sources whose content\_hash is empty are fetched; use —force to re-baseline every source. Sources with fetch\_method: chromedp are fetched via a headless browser.
## Options
| Flag | Type | Default | Required | Description |
| --------------- | -------- | ----------------------- | -------- | ---------------------------------------------------- |
| `--force` | `bool` | — | No | Re-fetch and overwrite existing content\_hash values |
| `--formats-dir` | `string` | `docs/provider-formats` | No | Directory containing provider format docs |
| `--provider` | `string` | — | No | Provider slug to backfill (required) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago capmon](/using-syllago/cli-reference/capmon.md)
* [syllago capmon check](/using-syllago/cli-reference/capmon-check.md)
* [syllago capmon derive](/using-syllago/cli-reference/capmon-derive.md)
* [syllago capmon diff](/using-syllago/cli-reference/capmon-diff.md)
* [syllago capmon extract](/using-syllago/cli-reference/capmon-extract.md)
* [syllago capmon fetch](/using-syllago/cli-reference/capmon-fetch.md)
* [syllago capmon generate](/using-syllago/cli-reference/capmon-generate.md)
* [syllago capmon onboard](/using-syllago/cli-reference/capmon-onboard.md)
* [syllago capmon run](/using-syllago/cli-reference/capmon-run.md)
* [syllago capmon seed](/using-syllago/cli-reference/capmon-seed.md)
* [syllago capmon test-fixtures](/using-syllago/cli-reference/capmon-test-fixtures.md)
* [syllago capmon validate-format-doc](/using-syllago/cli-reference/capmon-validate-format-doc.md)
* [syllago capmon validate-sources](/using-syllago/cli-reference/capmon-validate-sources.md)
* [syllago capmon verify](/using-syllago/cli-reference/capmon-verify.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/capmon_cmd.go)
# syllago capmon check
> Check for content drift in provider format docs
[Source](/using-syllago/cli-reference/capmon-check/)
## Synopsis
```plaintext
syllago capmon check [flags]
```
## Description
Fetch each source URI in provider format docs, compare content hashes, and create or append GitHub issues when content has changed.
## Options
| Flag | Type | Default | Required | Description |
| ------------------ | -------- | ------------------------------- | -------- | ---------------------------------------------- |
| `--all` | `bool` | — | No | Check all providers |
| `--cache-root` | `string` | `.capmon-cache` | No | Root directory for capmon cache |
| `--canonical-keys` | `string` | `docs/spec/canonical-keys.yaml` | No | Path to canonical-keys.yaml |
| `--dry-run` | `bool` | — | No | Log actions without creating GitHub issues |
| `--formats-dir` | `string` | `docs/provider-formats` | No | Directory containing provider format docs |
| `--provider` | `string` | — | No | Check only this provider slug |
| `--providers-json` | `string` | `providers.json` | No | Path to providers.json |
| `--sources-dir` | `string` | `docs/provider-sources` | No | Directory containing provider source manifests |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago capmon](/using-syllago/cli-reference/capmon.md)
* [syllago capmon backfill](/using-syllago/cli-reference/capmon-backfill.md)
* [syllago capmon derive](/using-syllago/cli-reference/capmon-derive.md)
* [syllago capmon diff](/using-syllago/cli-reference/capmon-diff.md)
* [syllago capmon extract](/using-syllago/cli-reference/capmon-extract.md)
* [syllago capmon fetch](/using-syllago/cli-reference/capmon-fetch.md)
* [syllago capmon generate](/using-syllago/cli-reference/capmon-generate.md)
* [syllago capmon onboard](/using-syllago/cli-reference/capmon-onboard.md)
* [syllago capmon run](/using-syllago/cli-reference/capmon-run.md)
* [syllago capmon seed](/using-syllago/cli-reference/capmon-seed.md)
* [syllago capmon test-fixtures](/using-syllago/cli-reference/capmon-test-fixtures.md)
* [syllago capmon validate-format-doc](/using-syllago/cli-reference/capmon-validate-format-doc.md)
* [syllago capmon validate-sources](/using-syllago/cli-reference/capmon-validate-sources.md)
* [syllago capmon verify](/using-syllago/cli-reference/capmon-verify.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/capmon_cmd.go)
# syllago capmon derive
> Derive a seeder spec from a provider format doc
[Source](/using-syllago/cli-reference/capmon-derive/)
## Synopsis
```plaintext
syllago capmon derive [flags]
```
## Description
Deterministically derive a seeder spec YAML from a provider format doc.
The derived spec is written to —output-dir/\-\.yaml. All canonical\_mappings keys are validated against —canonical-keys. Content types with status=unsupported are omitted from output.
## Options
| Flag | Type | Default | Required | Description |
| ------------------ | -------- | ------------------------------- | -------- | ------------------------------------------- |
| `--canonical-keys` | `string` | `docs/spec/canonical-keys.yaml` | No | Path to canonical-keys.yaml |
| `--formats-dir` | `string` | `docs/provider-formats` | No | Directory containing provider format docs |
| `--output-dir` | `string` | `.develop/seeder-specs` | No | Directory to write the derived seeder spec |
| `--provider` | `string` | — | No | Provider slug to derive spec for (required) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago capmon](/using-syllago/cli-reference/capmon.md)
* [syllago capmon backfill](/using-syllago/cli-reference/capmon-backfill.md)
* [syllago capmon check](/using-syllago/cli-reference/capmon-check.md)
* [syllago capmon diff](/using-syllago/cli-reference/capmon-diff.md)
* [syllago capmon extract](/using-syllago/cli-reference/capmon-extract.md)
* [syllago capmon fetch](/using-syllago/cli-reference/capmon-fetch.md)
* [syllago capmon generate](/using-syllago/cli-reference/capmon-generate.md)
* [syllago capmon onboard](/using-syllago/cli-reference/capmon-onboard.md)
* [syllago capmon run](/using-syllago/cli-reference/capmon-run.md)
* [syllago capmon seed](/using-syllago/cli-reference/capmon-seed.md)
* [syllago capmon test-fixtures](/using-syllago/cli-reference/capmon-test-fixtures.md)
* [syllago capmon validate-format-doc](/using-syllago/cli-reference/capmon-validate-format-doc.md)
* [syllago capmon validate-sources](/using-syllago/cli-reference/capmon-validate-sources.md)
* [syllago capmon verify](/using-syllago/cli-reference/capmon-verify.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/capmon_cmd.go)
# syllago capmon diff
> Show field-level changes in provider-capabilities since a git ref
[Source](/using-syllago/cli-reference/capmon-diff/)
## Synopsis
```plaintext
syllago capmon diff [flags]
```
## Options
| Flag | Type | Default | Required | Description |
| ------------ | -------- | ------- | -------- | ------------------------------------------ |
| `--provider` | `string` | — | No | Limit diff to this provider slug |
| `--since` | `string` | — | No | Git ref to diff against (default: HEAD\~1) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago capmon](/using-syllago/cli-reference/capmon.md)
* [syllago capmon backfill](/using-syllago/cli-reference/capmon-backfill.md)
* [syllago capmon check](/using-syllago/cli-reference/capmon-check.md)
* [syllago capmon derive](/using-syllago/cli-reference/capmon-derive.md)
* [syllago capmon extract](/using-syllago/cli-reference/capmon-extract.md)
* [syllago capmon fetch](/using-syllago/cli-reference/capmon-fetch.md)
* [syllago capmon generate](/using-syllago/cli-reference/capmon-generate.md)
* [syllago capmon onboard](/using-syllago/cli-reference/capmon-onboard.md)
* [syllago capmon run](/using-syllago/cli-reference/capmon-run.md)
* [syllago capmon seed](/using-syllago/cli-reference/capmon-seed.md)
* [syllago capmon test-fixtures](/using-syllago/cli-reference/capmon-test-fixtures.md)
* [syllago capmon validate-format-doc](/using-syllago/cli-reference/capmon-validate-format-doc.md)
* [syllago capmon validate-sources](/using-syllago/cli-reference/capmon-validate-sources.md)
* [syllago capmon verify](/using-syllago/cli-reference/capmon-verify.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/capmon_cmd.go)
# syllago capmon extract
> Run extraction on cached sources
[Source](/using-syllago/cli-reference/capmon-extract/)
## Synopsis
```plaintext
syllago capmon extract [flags]
```
## Options
| Flag | Type | Default | Required | Description |
| ------------ | -------- | ------- | -------- | ------------------------------- |
| `--provider` | `string` | — | No | Extract only this provider slug |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago capmon](/using-syllago/cli-reference/capmon.md)
* [syllago capmon backfill](/using-syllago/cli-reference/capmon-backfill.md)
* [syllago capmon check](/using-syllago/cli-reference/capmon-check.md)
* [syllago capmon derive](/using-syllago/cli-reference/capmon-derive.md)
* [syllago capmon diff](/using-syllago/cli-reference/capmon-diff.md)
* [syllago capmon fetch](/using-syllago/cli-reference/capmon-fetch.md)
* [syllago capmon generate](/using-syllago/cli-reference/capmon-generate.md)
* [syllago capmon onboard](/using-syllago/cli-reference/capmon-onboard.md)
* [syllago capmon run](/using-syllago/cli-reference/capmon-run.md)
* [syllago capmon seed](/using-syllago/cli-reference/capmon-seed.md)
* [syllago capmon test-fixtures](/using-syllago/cli-reference/capmon-test-fixtures.md)
* [syllago capmon validate-format-doc](/using-syllago/cli-reference/capmon-validate-format-doc.md)
* [syllago capmon validate-sources](/using-syllago/cli-reference/capmon-validate-sources.md)
* [syllago capmon verify](/using-syllago/cli-reference/capmon-verify.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/capmon_cmd.go)
# syllago capmon fetch
> Fetch source URLs and update hash cache
[Source](/using-syllago/cli-reference/capmon-fetch/)
## Synopsis
```plaintext
syllago capmon fetch [flags]
```
## Options
| Flag | Type | Default | Required | Description |
| --------------- | -------- | ------- | -------- | ---------------------------------------------------------- |
| `--cache-root` | `string` | — | No | Path to .capmon-cache/ (default: .capmon-cache) |
| `--dry-run` | `bool` | — | No | Report source counts without fetching or writing cache |
| `--provider` | `string` | — | No | Fetch only this provider slug |
| `--sources-dir` | `string` | — | No | Path to provider-sources/ (default: docs/provider-sources) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago capmon](/using-syllago/cli-reference/capmon.md)
* [syllago capmon backfill](/using-syllago/cli-reference/capmon-backfill.md)
* [syllago capmon check](/using-syllago/cli-reference/capmon-check.md)
* [syllago capmon derive](/using-syllago/cli-reference/capmon-derive.md)
* [syllago capmon diff](/using-syllago/cli-reference/capmon-diff.md)
* [syllago capmon extract](/using-syllago/cli-reference/capmon-extract.md)
* [syllago capmon generate](/using-syllago/cli-reference/capmon-generate.md)
* [syllago capmon onboard](/using-syllago/cli-reference/capmon-onboard.md)
* [syllago capmon run](/using-syllago/cli-reference/capmon-run.md)
* [syllago capmon seed](/using-syllago/cli-reference/capmon-seed.md)
* [syllago capmon test-fixtures](/using-syllago/cli-reference/capmon-test-fixtures.md)
* [syllago capmon validate-format-doc](/using-syllago/cli-reference/capmon-validate-format-doc.md)
* [syllago capmon validate-sources](/using-syllago/cli-reference/capmon-validate-sources.md)
* [syllago capmon verify](/using-syllago/cli-reference/capmon-verify.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/capmon_cmd.go)
# syllago capmon generate
> Regenerate per-content-type views and spec tables from provider-capabilities YAML
[Source](/using-syllago/cli-reference/capmon-generate/)
## Synopsis
```plaintext
syllago capmon generate
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago capmon](/using-syllago/cli-reference/capmon.md)
* [syllago capmon backfill](/using-syllago/cli-reference/capmon-backfill.md)
* [syllago capmon check](/using-syllago/cli-reference/capmon-check.md)
* [syllago capmon derive](/using-syllago/cli-reference/capmon-derive.md)
* [syllago capmon diff](/using-syllago/cli-reference/capmon-diff.md)
* [syllago capmon extract](/using-syllago/cli-reference/capmon-extract.md)
* [syllago capmon fetch](/using-syllago/cli-reference/capmon-fetch.md)
* [syllago capmon onboard](/using-syllago/cli-reference/capmon-onboard.md)
* [syllago capmon run](/using-syllago/cli-reference/capmon-run.md)
* [syllago capmon seed](/using-syllago/cli-reference/capmon-seed.md)
* [syllago capmon test-fixtures](/using-syllago/cli-reference/capmon-test-fixtures.md)
* [syllago capmon validate-format-doc](/using-syllago/cli-reference/capmon-validate-format-doc.md)
* [syllago capmon validate-sources](/using-syllago/cli-reference/capmon-validate-sources.md)
* [syllago capmon verify](/using-syllago/cli-reference/capmon-verify.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/capmon_cmd.go)
# syllago capmon onboard
> Bootstrap a new provider into the capmon pipeline
[Source](/using-syllago/cli-reference/capmon-onboard/)
## Synopsis
```plaintext
syllago capmon onboard [flags]
```
## Description
Validates source manifests, fetches all sources, and creates GitHub issues for the new provider. Use this when adding a provider for the first time — there is no prior content\_hash baseline, so all sources are treated as changed.
## Options
| Flag | Type | Default | Required | Description |
| --------------- | -------- | ----------------------- | -------- | ---------------------------------------------- |
| `--cache-root` | `string` | `.capmon-cache` | No | Root directory for capmon cache |
| `--dry-run` | `bool` | — | No | Log actions without creating GitHub issues |
| `--formats-dir` | `string` | `docs/provider-formats` | No | Directory containing provider format docs |
| `--provider` | `string` | — | No | Provider slug to onboard (required) |
| `--sources-dir` | `string` | `docs/provider-sources` | No | Directory containing provider source manifests |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago capmon](/using-syllago/cli-reference/capmon.md)
* [syllago capmon backfill](/using-syllago/cli-reference/capmon-backfill.md)
* [syllago capmon check](/using-syllago/cli-reference/capmon-check.md)
* [syllago capmon derive](/using-syllago/cli-reference/capmon-derive.md)
* [syllago capmon diff](/using-syllago/cli-reference/capmon-diff.md)
* [syllago capmon extract](/using-syllago/cli-reference/capmon-extract.md)
* [syllago capmon fetch](/using-syllago/cli-reference/capmon-fetch.md)
* [syllago capmon generate](/using-syllago/cli-reference/capmon-generate.md)
* [syllago capmon run](/using-syllago/cli-reference/capmon-run.md)
* [syllago capmon seed](/using-syllago/cli-reference/capmon-seed.md)
* [syllago capmon test-fixtures](/using-syllago/cli-reference/capmon-test-fixtures.md)
* [syllago capmon validate-format-doc](/using-syllago/cli-reference/capmon-validate-format-doc.md)
* [syllago capmon validate-sources](/using-syllago/cli-reference/capmon-validate-sources.md)
* [syllago capmon verify](/using-syllago/cli-reference/capmon-verify.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/capmon_cmd.go)
# syllago capmon run
> Run the full capability monitor pipeline
[Source](/using-syllago/cli-reference/capmon-run/)
## Synopsis
```plaintext
syllago capmon run [flags]
```
## Options
| Flag | Type | Default | Required | Description |
| ------------ | -------- | ------- | -------- | ------------------------------------------------------------------------ |
| `--dry-run` | `bool` | — | No | Skip Stage 4 PR/issue creation; write report to stdout |
| `--provider` | `string` | — | No | Limit to this provider slug |
| `--stage` | `string` | — | No | Pipeline stage to run: ‘fetch-extract’ or ‘report’ (default: all stages) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago capmon](/using-syllago/cli-reference/capmon.md)
* [syllago capmon backfill](/using-syllago/cli-reference/capmon-backfill.md)
* [syllago capmon check](/using-syllago/cli-reference/capmon-check.md)
* [syllago capmon derive](/using-syllago/cli-reference/capmon-derive.md)
* [syllago capmon diff](/using-syllago/cli-reference/capmon-diff.md)
* [syllago capmon extract](/using-syllago/cli-reference/capmon-extract.md)
* [syllago capmon fetch](/using-syllago/cli-reference/capmon-fetch.md)
* [syllago capmon generate](/using-syllago/cli-reference/capmon-generate.md)
* [syllago capmon onboard](/using-syllago/cli-reference/capmon-onboard.md)
* [syllago capmon seed](/using-syllago/cli-reference/capmon-seed.md)
* [syllago capmon test-fixtures](/using-syllago/cli-reference/capmon-test-fixtures.md)
* [syllago capmon validate-format-doc](/using-syllago/cli-reference/capmon-validate-format-doc.md)
* [syllago capmon validate-sources](/using-syllago/cli-reference/capmon-validate-sources.md)
* [syllago capmon verify](/using-syllago/cli-reference/capmon-verify.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/capmon_cmd.go)
# syllago capmon seed
> Bootstrap or re-seed provider capability YAML from extracted data
[Source](/using-syllago/cli-reference/capmon-seed/)
## Synopsis
```plaintext
syllago capmon seed [flags]
```
## Options
| Flag | Type | Default | Required | Description |
| ----------------------------- | -------- | ------- | -------- | -------------------------------------------------------------- |
| `--cache-root` | `string` | — | No | Path to .capmon-cache/ (default: .capmon-cache) |
| `--force-overwrite-exclusive` | `bool` | — | No | Allow overwriting provider\_exclusive entries (prints warning) |
| `--provider` | `string` | — | No | Seed only this provider slug |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago capmon](/using-syllago/cli-reference/capmon.md)
* [syllago capmon backfill](/using-syllago/cli-reference/capmon-backfill.md)
* [syllago capmon check](/using-syllago/cli-reference/capmon-check.md)
* [syllago capmon derive](/using-syllago/cli-reference/capmon-derive.md)
* [syllago capmon diff](/using-syllago/cli-reference/capmon-diff.md)
* [syllago capmon extract](/using-syllago/cli-reference/capmon-extract.md)
* [syllago capmon fetch](/using-syllago/cli-reference/capmon-fetch.md)
* [syllago capmon generate](/using-syllago/cli-reference/capmon-generate.md)
* [syllago capmon onboard](/using-syllago/cli-reference/capmon-onboard.md)
* [syllago capmon run](/using-syllago/cli-reference/capmon-run.md)
* [syllago capmon test-fixtures](/using-syllago/cli-reference/capmon-test-fixtures.md)
* [syllago capmon validate-format-doc](/using-syllago/cli-reference/capmon-validate-format-doc.md)
* [syllago capmon validate-sources](/using-syllago/cli-reference/capmon-validate-sources.md)
* [syllago capmon verify](/using-syllago/cli-reference/capmon-verify.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/capmon_cmd.go)
# syllago capmon test-fixtures
> Report fixture staleness or update fixtures for a provider
[Source](/using-syllago/cli-reference/capmon-test-fixtures/)
## Synopsis
```plaintext
syllago capmon test-fixtures [flags]
```
## Options
| Flag | Type | Default | Required | Description |
| ------------ | -------- | ------- | -------- | ------------------------------------------------- |
| `--provider` | `string` | — | No | Provider slug for —update (required with —update) |
| `--update` | `bool` | — | No | Re-fetch live source and update fixture files |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago capmon](/using-syllago/cli-reference/capmon.md)
* [syllago capmon backfill](/using-syllago/cli-reference/capmon-backfill.md)
* [syllago capmon check](/using-syllago/cli-reference/capmon-check.md)
* [syllago capmon derive](/using-syllago/cli-reference/capmon-derive.md)
* [syllago capmon diff](/using-syllago/cli-reference/capmon-diff.md)
* [syllago capmon extract](/using-syllago/cli-reference/capmon-extract.md)
* [syllago capmon fetch](/using-syllago/cli-reference/capmon-fetch.md)
* [syllago capmon generate](/using-syllago/cli-reference/capmon-generate.md)
* [syllago capmon onboard](/using-syllago/cli-reference/capmon-onboard.md)
* [syllago capmon run](/using-syllago/cli-reference/capmon-run.md)
* [syllago capmon seed](/using-syllago/cli-reference/capmon-seed.md)
* [syllago capmon validate-format-doc](/using-syllago/cli-reference/capmon-validate-format-doc.md)
* [syllago capmon validate-sources](/using-syllago/cli-reference/capmon-validate-sources.md)
* [syllago capmon verify](/using-syllago/cli-reference/capmon-verify.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/capmon_cmd.go)
# syllago capmon validate-format-doc
> Validate a provider format doc against the canonical keys vocabulary
[Source](/using-syllago/cli-reference/capmon-validate-format-doc/)
## Synopsis
```plaintext
syllago capmon validate-format-doc [flags]
```
## Description
Validate a provider’s docs/provider-formats/\.yaml file.
Checks:
* Required top-level fields (provider, last\_fetched\_at, content\_types)
* All canonical\_mappings keys exist in canonical-keys.yaml
* All provider\_extensions entries have required fields (id, name, description, source\_ref)
* confidence values are valid (confirmed | inferred | unknown)
Informational fields (generation\_method, notes) are not validated.
## Options
| Flag | Type | Default | Required | Description |
| ------------------ | -------- | ------------------------------- | -------- | ----------------------------------------------------- |
| `--canonical-keys` | `string` | `docs/spec/canonical-keys.yaml` | No | Path to canonical-keys.yaml |
| `--formats-dir` | `string` | `docs/provider-formats` | No | Directory containing provider format docs |
| `--provider` | `string` | — | No | Provider slug whose format doc to validate (required) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago capmon](/using-syllago/cli-reference/capmon.md)
* [syllago capmon backfill](/using-syllago/cli-reference/capmon-backfill.md)
* [syllago capmon check](/using-syllago/cli-reference/capmon-check.md)
* [syllago capmon derive](/using-syllago/cli-reference/capmon-derive.md)
* [syllago capmon diff](/using-syllago/cli-reference/capmon-diff.md)
* [syllago capmon extract](/using-syllago/cli-reference/capmon-extract.md)
* [syllago capmon fetch](/using-syllago/cli-reference/capmon-fetch.md)
* [syllago capmon generate](/using-syllago/cli-reference/capmon-generate.md)
* [syllago capmon onboard](/using-syllago/cli-reference/capmon-onboard.md)
* [syllago capmon run](/using-syllago/cli-reference/capmon-run.md)
* [syllago capmon seed](/using-syllago/cli-reference/capmon-seed.md)
* [syllago capmon test-fixtures](/using-syllago/cli-reference/capmon-test-fixtures.md)
* [syllago capmon validate-sources](/using-syllago/cli-reference/capmon-validate-sources.md)
* [syllago capmon verify](/using-syllago/cli-reference/capmon-verify.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/capmon_cmd.go)
# syllago capmon validate-sources
> Validate a provider's source manifest has URIs for all supported content types
[Source](/using-syllago/cli-reference/capmon-validate-sources/)
## Synopsis
```plaintext
syllago capmon validate-sources [flags]
```
## Options
| Flag | Type | Default | Required | Description |
| --------------- | -------- | ----------------------- | -------- | ---------------------------------------------------------- |
| `--provider` | `string` | — | No | Provider slug whose source manifest to validate (required) |
| `--sources-dir` | `string` | `docs/provider-sources` | No | Directory containing provider source manifests |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago capmon](/using-syllago/cli-reference/capmon.md)
* [syllago capmon backfill](/using-syllago/cli-reference/capmon-backfill.md)
* [syllago capmon check](/using-syllago/cli-reference/capmon-check.md)
* [syllago capmon derive](/using-syllago/cli-reference/capmon-derive.md)
* [syllago capmon diff](/using-syllago/cli-reference/capmon-diff.md)
* [syllago capmon extract](/using-syllago/cli-reference/capmon-extract.md)
* [syllago capmon fetch](/using-syllago/cli-reference/capmon-fetch.md)
* [syllago capmon generate](/using-syllago/cli-reference/capmon-generate.md)
* [syllago capmon onboard](/using-syllago/cli-reference/capmon-onboard.md)
* [syllago capmon run](/using-syllago/cli-reference/capmon-run.md)
* [syllago capmon seed](/using-syllago/cli-reference/capmon-seed.md)
* [syllago capmon test-fixtures](/using-syllago/cli-reference/capmon-test-fixtures.md)
* [syllago capmon validate-format-doc](/using-syllago/cli-reference/capmon-validate-format-doc.md)
* [syllago capmon verify](/using-syllago/cli-reference/capmon-verify.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/capmon_cmd.go)
# syllago capmon verify
> Validate provider-capabilities YAML against JSON Schema
[Source](/using-syllago/cli-reference/capmon-verify/)
## Synopsis
```plaintext
syllago capmon verify [flags]
```
## Options
| Flag | Type | Default | Required | Description |
| -------------------- | -------- | ------- | -------- | ------------------------------------------------------------------- |
| `--cache-root` | `string` | — | No | Path to .capmon-cache/ (default: .capmon-cache) |
| `--migration-window` | `bool` | — | No | Accept current-minus-one schema\_version during schema migrations |
| `--staleness-check` | `bool` | — | No | Check last-run.json age and open issue if stale |
| `--threshold-hours` | `int` | `36` | No | Hours before a run is considered stale (used with —staleness-check) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago capmon](/using-syllago/cli-reference/capmon.md)
* [syllago capmon backfill](/using-syllago/cli-reference/capmon-backfill.md)
* [syllago capmon check](/using-syllago/cli-reference/capmon-check.md)
* [syllago capmon derive](/using-syllago/cli-reference/capmon-derive.md)
* [syllago capmon diff](/using-syllago/cli-reference/capmon-diff.md)
* [syllago capmon extract](/using-syllago/cli-reference/capmon-extract.md)
* [syllago capmon fetch](/using-syllago/cli-reference/capmon-fetch.md)
* [syllago capmon generate](/using-syllago/cli-reference/capmon-generate.md)
* [syllago capmon onboard](/using-syllago/cli-reference/capmon-onboard.md)
* [syllago capmon run](/using-syllago/cli-reference/capmon-run.md)
* [syllago capmon seed](/using-syllago/cli-reference/capmon-seed.md)
* [syllago capmon test-fixtures](/using-syllago/cli-reference/capmon-test-fixtures.md)
* [syllago capmon validate-format-doc](/using-syllago/cli-reference/capmon-validate-format-doc.md)
* [syllago capmon validate-sources](/using-syllago/cli-reference/capmon-validate-sources.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/capmon_cmd.go)
# syllago compat
> Show provider compatibility matrix for a content item
[Source](/using-syllago/cli-reference/compat/)
## Synopsis
```plaintext
syllago compat
```
## Description
Analyzes a library item and shows which providers support it, what warnings arise during conversion, and which providers cannot handle the content type at all.
For each provider, syllago attempts the full canonicalize-then-render pipeline and reports the result.
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Show compatibility for a skill
syllago compat my-skill
# JSON output for scripting
syllago compat my-skill --json
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/compat.go)
# syllago completion
> Generate the autocompletion script for the specified shell
[Source](/using-syllago/cli-reference/completion/)
Generate the autocompletion script for syllago for the specified shell. See each sub-command’s help for details on how to use the generated script.
## Subcommands
| Command | Description |
| ------------------------------------------------------------------- | ------------------------------------------------- |
| [`bash`](/using-syllago/cli-reference/completion-bash.md) | Generate the autocompletion script for bash |
| [`fish`](/using-syllago/cli-reference/completion-fish.md) | Generate the autocompletion script for fish |
| [`powershell`](/using-syllago/cli-reference/completion-powershell.md) | Generate the autocompletion script for powershell |
| [`zsh`](/using-syllago/cli-reference/completion-zsh.md) | Generate the autocompletion script for zsh |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/completion_cmd.go)
# syllago completion bash
> Generate the autocompletion script for bash
[Source](/using-syllago/cli-reference/completion-bash/)
## Synopsis
```plaintext
syllago completion bash
```
## Description
Generate the autocompletion script for the bash shell.
This script depends on the ‘bash-completion’ package. If it is not installed already, you can install it via your OS’s package manager.
To load completions in your current shell session:
```bash
source <(syllago completion bash)
```
To load completions for every new session, execute once:
#### Linux:
```bash
syllago completion bash > /etc/bash_completion.d/syllago
```
#### macOS:
```bash
syllago completion bash > $(brew --prefix)/etc/bash_completion.d/syllago
```
You will need to start a new shell for this setup to take effect.
## Options
| Flag | Type | Default | Required | Description |
| ------------------- | ------ | ------- | -------- | ------------------------------- |
| `--no-descriptions` | `bool` | — | No | disable completion descriptions |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago completion](/using-syllago/cli-reference/completion.md)
* [syllago completion fish](/using-syllago/cli-reference/completion-fish.md)
* [syllago completion powershell](/using-syllago/cli-reference/completion-powershell.md)
* [syllago completion zsh](/using-syllago/cli-reference/completion-zsh.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/completion_cmd.go)
# syllago completion fish
> Generate the autocompletion script for fish
[Source](/using-syllago/cli-reference/completion-fish/)
## Synopsis
```plaintext
syllago completion fish [flags]
```
## Description
Generate the autocompletion script for the fish shell.
To load completions in your current shell session:
```bash
syllago completion fish | source
```
To load completions for every new session, execute once:
```bash
syllago completion fish > ~/.config/fish/completions/syllago.fish
```
You will need to start a new shell for this setup to take effect.
## Options
| Flag | Type | Default | Required | Description |
| ------------------- | ------ | ------- | -------- | ------------------------------- |
| `--no-descriptions` | `bool` | — | No | disable completion descriptions |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago completion](/using-syllago/cli-reference/completion.md)
* [syllago completion bash](/using-syllago/cli-reference/completion-bash.md)
* [syllago completion powershell](/using-syllago/cli-reference/completion-powershell.md)
* [syllago completion zsh](/using-syllago/cli-reference/completion-zsh.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/completion_cmd.go)
# syllago completion powershell
> Generate the autocompletion script for powershell
[Source](/using-syllago/cli-reference/completion-powershell/)
## Synopsis
```plaintext
syllago completion powershell [flags]
```
## Description
Generate the autocompletion script for powershell.
To load completions in your current shell session:
```bash
syllago completion powershell | Out-String | Invoke-Expression
```
To load completions for every new session, add the output of the above command to your powershell profile.
## Options
| Flag | Type | Default | Required | Description |
| ------------------- | ------ | ------- | -------- | ------------------------------- |
| `--no-descriptions` | `bool` | — | No | disable completion descriptions |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago completion](/using-syllago/cli-reference/completion.md)
* [syllago completion bash](/using-syllago/cli-reference/completion-bash.md)
* [syllago completion fish](/using-syllago/cli-reference/completion-fish.md)
* [syllago completion zsh](/using-syllago/cli-reference/completion-zsh.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/completion_cmd.go)
# syllago completion zsh
> Generate the autocompletion script for zsh
[Source](/using-syllago/cli-reference/completion-zsh/)
## Synopsis
```plaintext
syllago completion zsh [flags]
```
## Description
Generate the autocompletion script for the zsh shell.
If shell completion is not already enabled in your environment you will need to enable it. You can execute the following once:
```bash
echo "autoload -U compinit; compinit" >> ~/.zshrc
```
To load completions in your current shell session:
```bash
source <(syllago completion zsh)
```
To load completions for every new session, execute once:
#### Linux:
```bash
syllago completion zsh > "${fpath[1]}/_syllago"
```
#### macOS:
```bash
syllago completion zsh > $(brew --prefix)/share/zsh/site-functions/_syllago
```
You will need to start a new shell for this setup to take effect.
## Options
| Flag | Type | Default | Required | Description |
| ------------------- | ------ | ------- | -------- | ------------------------------- |
| `--no-descriptions` | `bool` | — | No | disable completion descriptions |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago completion](/using-syllago/cli-reference/completion.md)
* [syllago completion bash](/using-syllago/cli-reference/completion-bash.md)
* [syllago completion fish](/using-syllago/cli-reference/completion-fish.md)
* [syllago completion powershell](/using-syllago/cli-reference/completion-powershell.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/completion_cmd.go)
# syllago config
> View and edit syllago configuration
[Source](/using-syllago/cli-reference/config/)
Manage provider selection and preferences in .syllago/config.json.
## Subcommands
| Command | Description |
| ------------------------------------------------------- | ---------------------------------------- |
| [`add`](/using-syllago/cli-reference/config-add.md) | Add a provider to the configuration |
| [`list`](/using-syllago/cli-reference/config-list.md) | List current configuration |
| [`paths`](/using-syllago/cli-reference/config-paths.md) | Manage custom provider path overrides |
| [`remove`](/using-syllago/cli-reference/config-remove.md) | Remove a provider from the configuration |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/config_cmd.go)
# syllago config add
> Add a provider to the configuration
[Source](/using-syllago/cli-reference/config-add/)
## Synopsis
```plaintext
syllago config add
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago config add cursor
```
## See Also
* [syllago config](/using-syllago/cli-reference/config.md)
* [syllago config list](/using-syllago/cli-reference/config-list.md)
* [syllago config paths](/using-syllago/cli-reference/config-paths.md)
* [syllago config remove](/using-syllago/cli-reference/config-remove.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/config_cmd.go)
# syllago config list
> List current configuration
[Source](/using-syllago/cli-reference/config-list/)
## Synopsis
```plaintext
syllago config list
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Show configured providers
syllago config list
# JSON output
syllago config list --json
```
## See Also
* [syllago config](/using-syllago/cli-reference/config.md)
* [syllago config add](/using-syllago/cli-reference/config-add.md)
* [syllago config paths](/using-syllago/cli-reference/config-paths.md)
* [syllago config remove](/using-syllago/cli-reference/config-remove.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/config_cmd.go)
# syllago config paths
> Manage custom provider path overrides
[Source](/using-syllago/cli-reference/config-paths/)
Configure custom base directories or per-type path overrides for providers. Overrides are stored in the global config (\~/.syllago/config.json) since paths are machine-specific.
## Subcommands
| Command | Description |
| ----------------------------------------------------------- | ----------------------------------- |
| [`clear`](/using-syllago/cli-reference/config-paths-clear.md) | Clear path overrides for a provider |
| [`set`](/using-syllago/cli-reference/config-paths-set.md) | Set path overrides for a provider |
| [`show`](/using-syllago/cli-reference/config-paths-show.md) | Show configured path overrides |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/config_cmd.go)
# syllago config paths clear
> Clear path overrides for a provider
[Source](/using-syllago/cli-reference/config-paths-clear/)
## Synopsis
```plaintext
syllago config paths clear [flags]
```
## Options
| Flag | Type | Default | Required | Description |
| -------- | -------- | ------- | -------- | -------------------------------------------------- |
| `--type` | `string` | — | No | specific content type to clear (omit to clear all) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Clear all overrides for a provider
syllago config paths clear claude-code
# Clear only a specific type override
syllago config paths clear cursor --type rules
```
## See Also
* [syllago config paths](/using-syllago/cli-reference/config-paths.md)
* [syllago config paths set](/using-syllago/cli-reference/config-paths-set.md)
* [syllago config paths show](/using-syllago/cli-reference/config-paths-show.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/paths_cmd.go)
# syllago config paths set
> Set path overrides for a provider
[Source](/using-syllago/cli-reference/config-paths-set/)
## Synopsis
```plaintext
syllago config paths set [flags]
```
## Description
Set a base directory or per-type path override for a provider. Paths must be absolute (start with / or \~/).
## Options
| Flag | Type | Default | Required | Description |
| ------------ | -------- | ------- | -------- | ------------------------------------------- |
| `--base-dir` | `string` | — | No | base directory override (replaces home dir) |
| `--path` | `string` | — | No | absolute path for the content type |
| `--type` | `string` | — | No | content type (e.g., skills, hooks) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Set a base directory for a provider
syllago config paths set claude-code --base-dir ~/custom/claude
# Set a per-type path override
syllago config paths set cursor --type rules --path ~/my-rules
```
## See Also
* [syllago config paths](/using-syllago/cli-reference/config-paths.md)
* [syllago config paths clear](/using-syllago/cli-reference/config-paths-clear.md)
* [syllago config paths show](/using-syllago/cli-reference/config-paths-show.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/paths_cmd.go)
# syllago config paths show
> Show configured path overrides
[Source](/using-syllago/cli-reference/config-paths-show/)
## Synopsis
```plaintext
syllago config paths show [flags]
```
## Options
| Flag | Type | Default | Required | Description |
| ------------ | -------- | ------- | -------- | ----------------------- |
| `--provider` | `string` | — | No | filter by provider slug |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Show all path overrides
syllago config paths show
# Show overrides for a specific provider
syllago config paths show --provider claude-code
```
## See Also
* [syllago config paths](/using-syllago/cli-reference/config-paths.md)
* [syllago config paths clear](/using-syllago/cli-reference/config-paths-clear.md)
* [syllago config paths set](/using-syllago/cli-reference/config-paths-set.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/paths_cmd.go)
# syllago config remove
> Remove a provider from the configuration
[Source](/using-syllago/cli-reference/config-remove/)
## Synopsis
```plaintext
syllago config remove
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago config remove windsurf
```
## See Also
* [syllago config](/using-syllago/cli-reference/config.md)
* [syllago config add](/using-syllago/cli-reference/config-add.md)
* [syllago config list](/using-syllago/cli-reference/config-list.md)
* [syllago config paths](/using-syllago/cli-reference/config-paths.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/config_cmd.go)
# syllago convert
> Convert content between provider formats
[Source](/using-syllago/cli-reference/convert/)
## Synopsis
```plaintext
syllago convert [flags]
```
## Description
Transform content between provider formats using syllago’s hub-and-spoke conversion model (source -> canonical -> target).
Accepts either a file path or a library item name:
* File path: reads the file directly (requires —from and —to)
* Library name: looks up the item in your library (—from is optional)
Output goes to stdout by default, or to a file with —output.
## Options
| Flag | Type | Default | Required | Description |
| ---------------- | -------- | ------- | -------- | ------------------------------------------------------------------------- |
| `--diff` | `bool` | — | No | Show unified diff between source and converted output |
| `--from` | `string` | — | No | Source provider (required for file input, optional for library items) |
| `-o`, `--output` | `string` | — | No | Write output to this file path (default: stdout) |
| `--to` | `string` | — | Yes | Target provider (required) |
| `--type` | `string` | `rules` | No | Content type for file input (rules, hooks, skills, agents, commands, mcp) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Convert a Cursor rule to Claude Code format
syllago convert ./my-rule.mdc --from cursor --to claude-code
# Convert a library item to Windsurf format
syllago convert my-rule --to windsurf
# Convert and save to a file
syllago convert my-rule --to cursor --output ./cursor-rule.mdc
# Convert a Copilot instructions file to Cursor
syllago convert ./.github/copilot-instructions.md --from copilot-cli --to cursor --type rules
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/convert.go)
# syllago doctor
> Check your syllago setup for problems
[Source](/using-syllago/cli-reference/doctor/)
## Synopsis
```plaintext
syllago doctor
```
## Description
Validates your syllago installation: library, config, providers, installed content integrity, and registry configuration.
Each check reports \[ok], \[warn], or \[err]. Exit code is 0 if all checks pass, 1 if there are warnings, 2 if there are errors.
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago doctor
syllago doctor --json
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/doctor.go)
# syllago edit
> Edit a content item's display name or description
[Source](/using-syllago/cli-reference/edit/)
## Synopsis
```plaintext
syllago edit [flags]
```
## Description
Updates display name and/or description stored in the item’s .syllago.yaml metadata.
Only the metadata file is changed — the directory name, install paths, and all references remain exactly as they are.
The display name and description appear in the TUI, list output, and anywhere items are presented to users.
## Options
| Flag | Type | Default | Required | Description |
| --------------- | -------- | ------- | -------- | ------------------------------------------------------- |
| `--description` | `string` | — | No | New description for the item |
| `--name` | `string` | — | No | New display name for the item |
| `--type` | `string` | — | No | Content type to disambiguate (skills, hooks, mcp, etc.) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Set a display name for a hook
syllago edit my-hook --name "Pre-commit Linter"
# Set a description
syllago edit my-hook --description "Runs ESLint before every commit"
# Update both at once
syllago edit my-hook --name "Pre-commit Linter" --description "Runs ESLint before every commit"
# Disambiguate by type when name exists in multiple types
syllago edit my-item --name "Better Name" --type hooks
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/edit.go)
# syllago explain
> Show detailed documentation for an error code
[Source](/using-syllago/cli-reference/explain/)
## Synopsis
```plaintext
syllago explain CODE [flags]
```
## Description
Display documentation for a syllago error code.
Each error code has a detailed explanation including what it means, common causes, and how to fix it.
## Options
| Flag | Type | Default | Required | Description |
| -------- | ------ | ------- | -------- | ------------------------------ |
| `--list` | `bool` | — | No | list all available error codes |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago explain CATALOG_001
syllago explain --list
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/explain.go)
# syllago formats
> List supported file formats
[Source](/using-syllago/cli-reference/formats/)
## Synopsis
```plaintext
syllago formats
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago formats
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/formats.go)
# syllago info
> Show machine-readable capability manifest
[Source](/using-syllago/cli-reference/info/)
## Synopsis
```plaintext
syllago info
```
## Description
Outputs a structured summary of syllago’s version, detected providers, registries, and supported content types. Useful for agents and CI scripts discovering syllago’s features.
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Show capabilities summary
syllago info
# JSON output for agent consumption
syllago info --json
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/info.go)
# syllago init
> Initialize syllago for this project
[Source](/using-syllago/cli-reference/init/)
## Synopsis
```plaintext
syllago init [flags]
```
## Description
Detects AI coding tools in use, creates .syllago/config.json with provider selection.
## Options
| Flag | Type | Default | Required | Description |
| ------------- | ------ | ------- | -------- | ----------------------------- |
| `--force` | `bool` | — | No | Overwrite existing config |
| `-y`, `--yes` | `bool` | — | No | Skip interactive confirmation |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Interactive setup
syllago init
# Skip confirmation prompts
syllago init --yes
# Overwrite existing config
syllago init --force
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/init.go)
# syllago inspect
> Show details about a content item
[Source](/using-syllago/cli-reference/inspect/)
## Synopsis
```plaintext
syllago inspect / [flags]
```
## Description
Display full details about a content item for pre-install auditing.
By default, shows metadata and the primary content file. Use —as to preview what the content would look like converted to a specific provider’s format.
Path formats: skills/my-skill Universal content (type/name) rules/claude-code/my-rule Provider-specific (type/provider/name)
## Options
| Flag | Type | Default | Required | Description |
| ----------------- | -------- | ------- | -------- | --------------------------------------------------- |
| `--as` | `string` | — | No | Preview content converted to a provider’s format |
| `--compatibility` | `bool` | — | No | Show per-provider compatibility matrix (hooks only) |
| `--files` | `bool` | — | No | Show file contents |
| `--risk` | `bool` | — | No | Show detailed risk analysis |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Inspect a skill (shows metadata + content)
syllago inspect skills/my-skill
# Preview what a rule looks like in Cursor format
syllago inspect rules/coding-standards --as cursor
# Compare formats side by side
syllago inspect rules/coding-standards --as claude-code
syllago inspect rules/coding-standards --as cursor
# JSON output for scripting
syllago inspect --json skills/my-skill
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/inspect.go)
# syllago install
> Activate library content in a provider
[Source](/using-syllago/cli-reference/install/)
## Synopsis
```plaintext
syllago install [name] [flags]
```
## Description
Install content from your library into a provider’s location.
By default uses a symlink so edits in your library are reflected immediately. Use —method copy to place a standalone copy instead.
Hooks and MCP configs are merged into the provider’s settings file rather than linked.
## Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------------- | --------- | -------- | -------------------------------------------------------------------------- |
| `--all` | `bool` | — | No | Install all library content (cannot combine with a positional name) |
| `--base-dir` | `string` | — | No | Override base directory for content installation |
| `-n`, `--dry-run` | `bool` | — | No | Show what would happen without making changes |
| `--force` | `bool` | — | No | Proceed past high-severity scanner findings |
| `--hook-scanner` | `stringSlice` | — | No | Path to external hook scanner binary (repeatable) |
| `--method` | `string` | `symlink` | No | Install method: symlink (default), copy, or append (monolithic-file rules) |
| `--no-input` | `bool` | — | No | Disable interactive prompts, use defaults |
| `--on-clean` | `string` | — | No | Action when rule is already installed cleanly: replace |
| `--on-modified` | `string` | — | No | Action when install record is stale: drop-record |
| `--to` | `string` | — | No | Provider to install into |
| `--to-all` | `bool` | — | No | Install to all detected providers |
| `--type` | `string` | — | No | Filter to a specific content type |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Install a skill to Claude Code
syllago install my-skill --to claude-code
# Install with a standalone copy instead of symlink
syllago install my-skill --to cursor --method copy
# Install all skills to a provider
syllago install --to claude-code --type skills
# Install to every detected provider at once
syllago install --type skills --to-all
# Install everything from your library
syllago install --all --to claude-code
# Preview what would happen
syllago install my-skill --to claude-code --dry-run
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/install.go)
# syllago list
> List content items in the library
[Source](/using-syllago/cli-reference/list/)
## Synopsis
```plaintext
syllago list [flags]
```
## Description
Show a quick inventory of all content without launching the TUI.
By default, lists all content grouped by type. Use flags to filter.
## Options
| Flag | Type | Default | Required | Description |
| ---------- | ------------- | ------- | -------- | ---------------------------------------------------------------------- |
| `--filter` | `stringSlice` | — | No | Filter by item state (repeatable): in-library, not-in-library, project |
| `--source` | `string` | `all` | No | Filter by source: library, shared, registry, builtin, all |
| `--type` | `string` | — | No | Filter to one content type (e.g., skills, rules) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# List all content grouped by type
syllago list
# Show only library items
syllago list --source library
# Show only skills
syllago list --type skills
# JSON output for scripting
syllago list --json
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/list.go)
# syllago loadout
> Apply, create, and manage loadouts
[Source](/using-syllago/cli-reference/loadout/)
Loadouts bundle a curated set of syllago content — rules, hooks, skills, agents, MCP servers — into a single shareable configuration.
Use “syllago loadout apply” to try or apply a loadout. Use “syllago loadout create” to build a new loadout interactively. Use “syllago loadout remove” to revert an active loadout.
## Subcommands
| Command | Description |
| -------------------------------------------------------- | ------------------------------------------------------------------------- |
| [`apply`](/using-syllago/cli-reference/loadout-apply.md) | Preview or apply a loadout (default: preview; use —try or —keep to apply) |
| [`create`](/using-syllago/cli-reference/loadout-create.md) | Interactively create a new loadout |
| [`list`](/using-syllago/cli-reference/loadout-list.md) | List available loadouts |
| [`remove`](/using-syllago/cli-reference/loadout-remove.md) | Remove the active loadout and restore original configuration |
| [`status`](/using-syllago/cli-reference/loadout-status.md) | Show active loadout status |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/loadout_cmd.go)
# syllago loadout apply
> Preview or apply a loadout (default: preview; use --try or --keep to apply)
[Source](/using-syllago/cli-reference/loadout-apply/)
## Synopsis
```plaintext
syllago loadout apply [name] [flags]
```
## Description
Apply a loadout to configure the current project for one or more providers.
Running with no flags is always safe: it previews planned changes without modifying anything. Use —try or —keep to actually apply the loadout.
—try: apply temporarily; reverts automatically when the session ends. —keep: apply permanently; run “syllago loadout remove” to undo. —to: target a specific provider (overrides the provider declared in the manifest).
## Options
| Flag | Type | Default | Required | Description |
| ------------ | -------- | --------- | -------- | ------------------------------------------------------------------------------- |
| `--base-dir` | `string` | — | No | Override base directory for content installation |
| `--keep` | `bool` | — | No | Apply permanently |
| `--method` | `string` | `symlink` | No | Install method: symlink (default) or copy |
| `--to` | `string` | — | No | Target provider (overrides manifest provider; defaults to claude-code if unset) |
| `--try` | `bool` | — | No | Apply temporarily; auto-revert on session end |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Preview what a loadout would do
syllago loadout apply my-loadout
# Try temporarily (auto-reverts on session end)
syllago loadout apply my-loadout --try
# Apply permanently
syllago loadout apply my-loadout --keep
# Apply to a specific provider
syllago loadout apply my-loadout --keep --to cursor
```
## See Also
* [syllago loadout](/using-syllago/cli-reference/loadout.md)
* [syllago loadout create](/using-syllago/cli-reference/loadout-create.md)
* [syllago loadout list](/using-syllago/cli-reference/loadout-list.md)
* [syllago loadout remove](/using-syllago/cli-reference/loadout-remove.md)
* [syllago loadout status](/using-syllago/cli-reference/loadout-status.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/loadout_apply.go)
# syllago loadout create
> Interactively create a new loadout
[Source](/using-syllago/cli-reference/loadout-create/)
## Synopsis
```plaintext
syllago loadout create
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago loadout create
```
## See Also
* [syllago loadout](/using-syllago/cli-reference/loadout.md)
* [syllago loadout apply](/using-syllago/cli-reference/loadout-apply.md)
* [syllago loadout list](/using-syllago/cli-reference/loadout-list.md)
* [syllago loadout remove](/using-syllago/cli-reference/loadout-remove.md)
* [syllago loadout status](/using-syllago/cli-reference/loadout-status.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/loadout_create.go)
# syllago loadout list
> List available loadouts
[Source](/using-syllago/cli-reference/loadout-list/)
## Synopsis
```plaintext
syllago loadout list
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# List all available loadouts
syllago loadout list
# JSON output
syllago loadout list --json
```
## See Also
* [syllago loadout](/using-syllago/cli-reference/loadout.md)
* [syllago loadout apply](/using-syllago/cli-reference/loadout-apply.md)
* [syllago loadout create](/using-syllago/cli-reference/loadout-create.md)
* [syllago loadout remove](/using-syllago/cli-reference/loadout-remove.md)
* [syllago loadout status](/using-syllago/cli-reference/loadout-status.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/loadout_list.go)
# syllago loadout remove
> Remove the active loadout and restore original configuration
[Source](/using-syllago/cli-reference/loadout-remove/)
## Synopsis
```plaintext
syllago loadout remove [flags]
```
## Options
| Flag | Type | Default | Required | Description |
| -------- | ------ | ------- | -------- | ------------------------------------------- |
| `--auto` | `bool` | — | No | Skip confirmation (used by SessionEnd hook) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago loadout remove
```
## See Also
* [syllago loadout](/using-syllago/cli-reference/loadout.md)
* [syllago loadout apply](/using-syllago/cli-reference/loadout-apply.md)
* [syllago loadout create](/using-syllago/cli-reference/loadout-create.md)
* [syllago loadout list](/using-syllago/cli-reference/loadout-list.md)
* [syllago loadout status](/using-syllago/cli-reference/loadout-status.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/loadout_remove.go)
# syllago loadout status
> Show active loadout status
[Source](/using-syllago/cli-reference/loadout-status/)
## Synopsis
```plaintext
syllago loadout status
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Check if a loadout is active
syllago loadout status
# JSON output
syllago loadout status --json
```
## See Also
* [syllago loadout](/using-syllago/cli-reference/loadout.md)
* [syllago loadout apply](/using-syllago/cli-reference/loadout-apply.md)
* [syllago loadout create](/using-syllago/cli-reference/loadout-create.md)
* [syllago loadout list](/using-syllago/cli-reference/loadout-list.md)
* [syllago loadout remove](/using-syllago/cli-reference/loadout-remove.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/loadout_status.go)
# syllago manifest
> Manage registry manifests
[Source](/using-syllago/cli-reference/manifest/)
## Subcommands
| Command | Description |
| ------------------------------------------------------------- | -------------------------------------------- |
| [`generate`](/using-syllago/cli-reference/manifest-generate.md) | Generate a registry.yaml for this repository |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/manifest_cmd.go)
# syllago manifest generate
> Generate a registry.yaml for this repository
[Source](/using-syllago/cli-reference/manifest-generate/)
## Synopsis
```plaintext
syllago manifest generate [dir] [flags]
```
## Description
Analyze the current repository and generate a registry.yaml manifest. Run with —force to overwrite an existing registry.yaml. When overwriting, a diff of added/removed/changed items is displayed before writing.
## Options
| Flag | Type | Default | Required | Description |
| --------------- | ------------- | ------- | -------- | ------------------------------------------------------------------------------- |
| `--debug-skips` | `bool` | — | No | show per-file skip reasons for content-signal classification |
| `--force` | `bool` | — | No | overwrite existing registry.yaml |
| `--no-config` | `bool` | — | No | suppress .syllago.yaml loading (use with —strict for fully explicit CI control) |
| `--scan-as` | `stringArray` | — | No | scan path as content type: type:path (e.g. skills:Packs/) |
| `--strict` | `bool` | — | No | disable content-signal fallback; fatal on missing scan-as paths |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago manifest](/using-syllago/cli-reference/manifest.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/manifest_cmd.go)
# syllago moat
> Manage MOAT registry trust and verification
[Source](/using-syllago/cli-reference/moat/)
Inspect and manage the MOAT (Model for Origin Attestation and Trust) subsystem.
Slice 1 surface: trusted-root lifecycle via `moat trust status`. Later slices will add manifest verification, tier policy, and revocation.
## Subcommands
| Command | Description |
| --------------------------------------------------- | ----------------------------------------------------------------------- |
| [`sign`](/using-syllago/cli-reference/moat-sign.md) | Produce a signature.bundle from a manifest (online or dev-offline mode) |
| [`trust`](/using-syllago/cli-reference/moat-trust.md) | Trusted-root lifecycle (status, refresh) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/moat_cmd.go)
# syllago moat sign
> Produce a signature.bundle from a manifest (online or dev-offline mode)
[Source](/using-syllago/cli-reference/moat-sign/)
## Synopsis
```plaintext
syllago moat sign [flags]
```
## Description
Assemble a sigstore v0.3 bundle for a manifest.json.
Online mode (—rekor-raw required): Assembles a bundle from a raw Rekor API response captured from a real Publisher Action run. The Rekor entry must have signed sha256(manifest.json). The bundle is verified against the trusted root before being written.
Dev/offline mode (—dev-trusted-root \): Uses an ephemeral offline CA to sign the manifest without any network calls. Writes both signature.bundle (at —out) and trusted\_root.json (in \). The resulting trusted root is development-only — never use it in production.
The —identity flag (online mode only) accepts a JSON file with {“issuer”: ”…”, “subject”: ”…”} matching the expected signing identity. When omitted, the identity is auto-extracted from the Rekor entry cert.
## Options
| Flag | Type | Default | Required | Description |
| -------------------- | -------- | ------- | -------- | ------------------------------------------------------------------------------------------------------------------------ |
| `--dev-trusted-root` | `string` | — | No | Directory for dev-mode: writes trusted\_root.json here and signs with an offline CA (mutually exclusive with —rekor-raw) |
| `--identity` | `string` | — | No | Path to signing identity JSON {“issuer”:”…”,“subject”:”…”} (online mode, auto-extracted when omitted) |
| `--manifest` | `string` | — | Yes | Path to manifest.json (required) |
| `--out` | `string` | — | No | Output path for signature.bundle (default: \.sigstore) |
| `--rekor-raw` | `string` | — | No | Path to raw Rekor API response JSON (online mode) |
| `--trusted-root` | `string` | — | No | Path to trusted-root.json for round-trip verify (online mode, default: bundled root) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Online: sign with a real Rekor raw response
syllago moat sign \
--manifest ./registry/manifest.json \
--rekor-raw ./ci-artifacts/rekor-response.json \
--out ./registry/manifest.json.sigstore
# Dev/offline: generate a smoke fixture bundle + dev trusted root
syllago moat sign \
--manifest ./test-registry/manifest.json \
--dev-trusted-root ./test-registry \
--out ./test-registry/manifest.json.sigstore
```
## See Also
* [syllago moat](/using-syllago/cli-reference/moat.md)
* [syllago moat trust](/using-syllago/cli-reference/moat-trust.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/moat_cmd.go)
# syllago moat trust
> Trusted-root lifecycle (status, refresh)
[Source](/using-syllago/cli-reference/moat-trust/)
Operate on the Sigstore trusted-root bundle used to verify signed registry manifests.
## Subcommands
| Command | Description |
| ----------------------------------------------------------- | ---------------------------------------------------- |
| [`status`](/using-syllago/cli-reference/moat-trust-status.md) | Report the bundled Sigstore trusted root’s freshness |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/moat_cmd.go)
# syllago moat trust status
> Report the bundled Sigstore trusted root's freshness
[Source](/using-syllago/cli-reference/moat-trust-status/)
## Synopsis
```plaintext
syllago moat trust status [flags]
```
## Description
Print the source and calendar age of the bundled Sigstore trusted root, then exit with a stable code CI pipelines can gate on:
0 fresh (age < 90 days) 1 warn (90–179 days) — verification still runs 1 escalated (180–364 days) — verification still runs 2 expired (365+ days) — verification refuses 2 missing (embed is empty — build-time bug) 2 corrupt (issued-at constant malformed — build-time bug)
Use —json to emit a single JSON line for scripts.
## Options
| Flag | Type | Default | Required | Description |
| -------- | ------ | ------- | -------- | -------------------------------------------------- |
| `--json` | `bool` | — | No | Emit a single JSON line instead of key=value lines |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## See Also
* [syllago moat trust](/using-syllago/cli-reference/moat-trust.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/trust_cmd.go)
# syllago providers
> List providers or show data quality for a specific slug
[Source](/using-syllago/cli-reference/providers/)
## Synopsis
```plaintext
syllago providers [slug]
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# List providers and their supported types
syllago providers
# JSON output
syllago providers --json
# Data quality summary for one provider
syllago providers claude-code
syllago providers claude-code --json
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/providers.go)
# syllago refresh
> Check for and apply content updates from registries
[Source](/using-syllago/cli-reference/refresh/)
## Synopsis
```plaintext
syllago refresh [name] [flags]
```
## Description
Compares installed content versions against their source registries and updates items where a newer version is available.
Version comparison uses semver from .syllago.yaml metadata. Items installed from local projects (not registries) are skipped.
## Options
| Flag | Type | Default | Required | Description |
| ------------ | -------- | ------- | -------- | ---------------------------------------------------- |
| `--all` | `bool` | — | No | Refresh all installed items |
| `--dry-run` | `bool` | — | No | Show what would be updated without changing anything |
| `--registry` | `string` | — | No | Only refresh items from this registry |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Refresh a specific item
syllago refresh my-skill
# Check and refresh all installed items
syllago refresh --all
# Dry-run: show what would be updated
syllago refresh --all --dry-run
# Only refresh items from a specific registry
syllago refresh --all --registry team-rules
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/refresh.go)
# syllago registry
> Manage git-based content registries
[Source](/using-syllago/cli-reference/registry/)
Add, remove, list, and sync git repositories as content registries.
Registries are read-only git repos containing shared content (skills, rules, hooks, MCP configs, etc.). Use “registry sync” to pull updates, and “registry items” to browse what’s available.
To use registry content, browse it in the TUI (“syllago”) or install it directly with “syllago install —to \”.
## Subcommands
| Command | Description |
| --------------------------------------------------------- | ---------------------------------------------- |
| [`add`](/using-syllago/cli-reference/registry-add.md) | Add a git registry |
| [`create`](/using-syllago/cli-reference/registry-create.md) | Create a new registry |
| [`items`](/using-syllago/cli-reference/registry-items.md) | Browse content available in registries |
| [`list`](/using-syllago/cli-reference/registry-list.md) | List registered registries |
| [`remove`](/using-syllago/cli-reference/registry-remove.md) | Remove a registry and delete its local clone |
| [`sync`](/using-syllago/cli-reference/registry-sync.md) | Pull latest content from one or all registries |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/registry_cmd.go)
# syllago registry add
> Add a git registry
[Source](/using-syllago/cli-reference/registry-add/)
## Synopsis
```plaintext
syllago registry add [flags]
```
## Options
| Flag | Type | Default | Required | Description |
| ------------------------------- | -------- | ------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| `--moat` | `bool` | — | No | Add as a MOAT-signed registry (required when URL is not in the bundled allowlist and no —signing-identity is passed) |
| `--name` | `string` | — | No | Override the registry name (default: derived from URL) |
| `--ref` | `string` | — | No | Branch, tag, or commit to checkout (default: repo default branch) |
| `--signing-identity` | `string` | — | No | Workflow subject SAN (e.g. ) — implies —moat |
| `--signing-issuer` | `string` | — | No | OIDC issuer URL (default: GitHub Actions issuer) |
| `--signing-repository-id` | `string` | — | No | GitHub numeric repository ID (required for GitHub Actions issuer) |
| `--signing-repository-owner-id` | `string` | — | No | GitHub numeric repository-owner ID (required for GitHub Actions issuer) |
| `--yes` | `bool` | — | No | Auto-accept TOFU during the chained post-add sync (required for MOAT registries that self-declare via registry.yaml without an allowlist match) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Add a registry by URL
syllago registry add https://github.com/team/rules.git
# Add with a custom name
syllago registry add https://github.com/team/rules.git --name team-rules
# Pin to a specific branch
syllago registry add https://github.com/team/rules.git --ref main
```
## See Also
* [syllago registry](/using-syllago/cli-reference/registry.md)
* [syllago registry create](/using-syllago/cli-reference/registry-create.md)
* [syllago registry items](/using-syllago/cli-reference/registry-items.md)
* [syllago registry list](/using-syllago/cli-reference/registry-list.md)
* [syllago registry remove](/using-syllago/cli-reference/registry-remove.md)
* [syllago registry sync](/using-syllago/cli-reference/registry-sync.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/registry_cmd.go)
# syllago registry create
> Create a new registry
[Source](/using-syllago/cli-reference/registry-create/)
## Synopsis
```plaintext
syllago registry create [flags]
```
## Description
Create a new registry in one of two modes:
—new \ Scaffold an empty registry directory structure —from-native Index provider-native content in the current repo
## Options
| Flag | Type | Default | Required | Description |
| --------------- | -------- | ------- | -------- | --------------------------------------------------- |
| `--description` | `string` | — | No | Short description of the registry (used with —new) |
| `--from-native` | `bool` | — | No | Index provider-native content in the current repo |
| `--new` | `string` | — | No | Scaffold an empty registry directory with this name |
| `--no-git` | `bool` | — | No | Skip git init and initial commit (used with —new) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Scaffold an empty registry
syllago registry create --new my-rules
# Scaffold with a description
syllago registry create --new my-rules --description "Team coding standards"
# Index existing provider-native content
syllago registry create --from-native
```
## See Also
* [syllago registry](/using-syllago/cli-reference/registry.md)
* [syllago registry add](/using-syllago/cli-reference/registry-add.md)
* [syllago registry items](/using-syllago/cli-reference/registry-items.md)
* [syllago registry list](/using-syllago/cli-reference/registry-list.md)
* [syllago registry remove](/using-syllago/cli-reference/registry-remove.md)
* [syllago registry sync](/using-syllago/cli-reference/registry-sync.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/registry_cmd.go)
# syllago registry items
> Browse content available in registries
[Source](/using-syllago/cli-reference/registry-items/)
## Synopsis
```plaintext
syllago registry items [name] [flags]
```
## Description
Lists content items from one or all registries.
Use —type to filter by content type. To install registry content, use “syllago install —to \” or browse in the TUI with “syllago”.
## Options
| Flag | Type | Default | Required | Description |
| -------- | -------- | ------- | -------- | --------------------------------------------------- |
| `--type` | `string` | — | No | Filter by content type (skills, rules, hooks, etc.) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# List all items from all registries
syllago registry items
# List items from a specific registry
syllago registry items my-rules
# Filter by content type
syllago registry items --type skills
```
## See Also
* [syllago registry](/using-syllago/cli-reference/registry.md)
* [syllago registry add](/using-syllago/cli-reference/registry-add.md)
* [syllago registry create](/using-syllago/cli-reference/registry-create.md)
* [syllago registry list](/using-syllago/cli-reference/registry-list.md)
* [syllago registry remove](/using-syllago/cli-reference/registry-remove.md)
* [syllago registry sync](/using-syllago/cli-reference/registry-sync.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/registry_cmd.go)
# syllago registry list
> List registered registries
[Source](/using-syllago/cli-reference/registry-list/)
## Synopsis
```plaintext
syllago registry list
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# List all configured registries
syllago registry list
# JSON output
syllago registry list --json
```
## See Also
* [syllago registry](/using-syllago/cli-reference/registry.md)
* [syllago registry add](/using-syllago/cli-reference/registry-add.md)
* [syllago registry create](/using-syllago/cli-reference/registry-create.md)
* [syllago registry items](/using-syllago/cli-reference/registry-items.md)
* [syllago registry remove](/using-syllago/cli-reference/registry-remove.md)
* [syllago registry sync](/using-syllago/cli-reference/registry-sync.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/registry_cmd.go)
# syllago registry remove
> Remove a registry and delete its local clone
[Source](/using-syllago/cli-reference/registry-remove/)
## Synopsis
```plaintext
syllago registry remove
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago registry remove team-rules
```
## See Also
* [syllago registry](/using-syllago/cli-reference/registry.md)
* [syllago registry add](/using-syllago/cli-reference/registry-add.md)
* [syllago registry create](/using-syllago/cli-reference/registry-create.md)
* [syllago registry items](/using-syllago/cli-reference/registry-items.md)
* [syllago registry list](/using-syllago/cli-reference/registry-list.md)
* [syllago registry sync](/using-syllago/cli-reference/registry-sync.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/registry_cmd.go)
# syllago registry sync
> Pull latest content from one or all registries
[Source](/using-syllago/cli-reference/registry-sync/)
## Synopsis
```plaintext
syllago registry sync [name] [flags]
```
## Description
Runs git pull on registry clones to fetch the latest content.
Sync updates the local clone only — it does not modify your library or installed provider content. Use “syllago registry items” to see what changed, and “syllago install” to activate updated content.
## Options
| Flag | Type | Default | Required | Description |
| ------- | ------ | ------- | -------- | ---------------------------------------------------------------------------------------- |
| `--yes` | `bool` | — | No | Auto-accept TOFU (trust-on-first-use) for MOAT registries with no pinned signing profile |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Sync all registries
syllago registry sync
# Sync a specific registry
syllago registry sync my-rules
```
## See Also
* [syllago registry](/using-syllago/cli-reference/registry.md)
* [syllago registry add](/using-syllago/cli-reference/registry-add.md)
* [syllago registry create](/using-syllago/cli-reference/registry-create.md)
* [syllago registry items](/using-syllago/cli-reference/registry-items.md)
* [syllago registry list](/using-syllago/cli-reference/registry-list.md)
* [syllago registry remove](/using-syllago/cli-reference/registry-remove.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/registry_cmd.go)
# syllago remove
> Remove content from your library and uninstall from providers
[Source](/using-syllago/cli-reference/remove/)
## Synopsis
```plaintext
syllago remove [flags]
```
## Description
Removes a content item from your library (\~/.syllago/content/) and uninstalls it from any providers where it is currently installed.
## Options
| Flag | Type | Default | Required | Description |
| ----------------- | -------- | ------- | -------- | ----------------------------------------------- |
| `-n`, `--dry-run` | `bool` | — | No | Show what would happen without making changes |
| `-f`, `--force` | `bool` | — | No | Skip confirmation prompt |
| `--no-input` | `bool` | — | No | Disable interactive prompts, use defaults |
| `--type` | `string` | — | No | Disambiguate when name exists in multiple types |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Remove a skill from library and all providers
syllago remove my-skill
# Disambiguate by type when name exists in multiple types
syllago remove my-rule --type rules
# Skip confirmation prompt
syllago remove my-skill --force
# Preview what would happen
syllago remove my-skill --dry-run
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/remove.go)
# syllago sandbox
> Run and manage AI CLI tools in bubblewrap sandboxes
[Source](/using-syllago/cli-reference/sandbox/)
Sandbox wraps AI CLI tools in bubblewrap to restrict filesystem access, network egress, and environment variables.
Linux only: requires bubblewrap >= 0.4.0 and socat >= 1.7.0.
## Subcommands
| Command | Description |
| -------------------------------------------------------------------- | --------------------------------------------------- |
| [`allow-domain`](/using-syllago/cli-reference/sandbox-allow-domain.md) | Add a domain to the sandbox allowlist |
| [`allow-env`](/using-syllago/cli-reference/sandbox-allow-env.md) | Add an env var to the sandbox allowlist |
| [`allow-port`](/using-syllago/cli-reference/sandbox-allow-port.md) | Add a localhost port to the sandbox allowlist |
| [`check`](/using-syllago/cli-reference/sandbox-check.md) | Verify bubblewrap, socat, and optionally a provider |
| [`deny-domain`](/using-syllago/cli-reference/sandbox-deny-domain.md) | Remove a domain from the sandbox allowlist |
| [`deny-env`](/using-syllago/cli-reference/sandbox-deny-env.md) | Remove an env var from the sandbox allowlist |
| [`deny-port`](/using-syllago/cli-reference/sandbox-deny-port.md) | Remove a localhost port from the sandbox allowlist |
| [`domains`](/using-syllago/cli-reference/sandbox-domains.md) | List allowed domains |
| [`env`](/using-syllago/cli-reference/sandbox-env.md) | Add an env var to the sandbox allowlist |
| [`info`](/using-syllago/cli-reference/sandbox-info.md) | Show effective sandbox configuration |
| [`ports`](/using-syllago/cli-reference/sandbox-ports.md) | List allowed localhost ports |
| [`run`](/using-syllago/cli-reference/sandbox-run.md) | Run a provider in a sandbox |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/sandbox_cmd.go)
# syllago sandbox allow-domain
> Add a domain to the sandbox allowlist
[Source](/using-syllago/cli-reference/sandbox-allow-domain/)
## Synopsis
```plaintext
syllago sandbox allow-domain
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago sandbox allow-domain api.example.com
```
## See Also
* [syllago sandbox](/using-syllago/cli-reference/sandbox.md)
* [syllago sandbox allow-env](/using-syllago/cli-reference/sandbox-allow-env.md)
* [syllago sandbox allow-port](/using-syllago/cli-reference/sandbox-allow-port.md)
* [syllago sandbox check](/using-syllago/cli-reference/sandbox-check.md)
* [syllago sandbox deny-domain](/using-syllago/cli-reference/sandbox-deny-domain.md)
* [syllago sandbox deny-env](/using-syllago/cli-reference/sandbox-deny-env.md)
* [syllago sandbox deny-port](/using-syllago/cli-reference/sandbox-deny-port.md)
* [syllago sandbox domains](/using-syllago/cli-reference/sandbox-domains.md)
* [syllago sandbox env](/using-syllago/cli-reference/sandbox-env.md)
* [syllago sandbox info](/using-syllago/cli-reference/sandbox-info.md)
* [syllago sandbox ports](/using-syllago/cli-reference/sandbox-ports.md)
* [syllago sandbox run](/using-syllago/cli-reference/sandbox-run.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/sandbox_cmd.go)
# syllago sandbox allow-env
> Add an env var to the sandbox allowlist
[Source](/using-syllago/cli-reference/sandbox-allow-env/)
## Synopsis
```plaintext
syllago sandbox allow-env
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago sandbox allow-env OPENAI_API_KEY
```
## See Also
* [syllago sandbox](/using-syllago/cli-reference/sandbox.md)
* [syllago sandbox allow-domain](/using-syllago/cli-reference/sandbox-allow-domain.md)
* [syllago sandbox allow-port](/using-syllago/cli-reference/sandbox-allow-port.md)
* [syllago sandbox check](/using-syllago/cli-reference/sandbox-check.md)
* [syllago sandbox deny-domain](/using-syllago/cli-reference/sandbox-deny-domain.md)
* [syllago sandbox deny-env](/using-syllago/cli-reference/sandbox-deny-env.md)
* [syllago sandbox deny-port](/using-syllago/cli-reference/sandbox-deny-port.md)
* [syllago sandbox domains](/using-syllago/cli-reference/sandbox-domains.md)
* [syllago sandbox env](/using-syllago/cli-reference/sandbox-env.md)
* [syllago sandbox info](/using-syllago/cli-reference/sandbox-info.md)
* [syllago sandbox ports](/using-syllago/cli-reference/sandbox-ports.md)
* [syllago sandbox run](/using-syllago/cli-reference/sandbox-run.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/sandbox_cmd.go)
# syllago sandbox allow-port
> Add a localhost port to the sandbox allowlist
[Source](/using-syllago/cli-reference/sandbox-allow-port/)
## Synopsis
```plaintext
syllago sandbox allow-port
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago sandbox allow-port 8080
```
## See Also
* [syllago sandbox](/using-syllago/cli-reference/sandbox.md)
* [syllago sandbox allow-domain](/using-syllago/cli-reference/sandbox-allow-domain.md)
* [syllago sandbox allow-env](/using-syllago/cli-reference/sandbox-allow-env.md)
* [syllago sandbox check](/using-syllago/cli-reference/sandbox-check.md)
* [syllago sandbox deny-domain](/using-syllago/cli-reference/sandbox-deny-domain.md)
* [syllago sandbox deny-env](/using-syllago/cli-reference/sandbox-deny-env.md)
* [syllago sandbox deny-port](/using-syllago/cli-reference/sandbox-deny-port.md)
* [syllago sandbox domains](/using-syllago/cli-reference/sandbox-domains.md)
* [syllago sandbox env](/using-syllago/cli-reference/sandbox-env.md)
* [syllago sandbox info](/using-syllago/cli-reference/sandbox-info.md)
* [syllago sandbox ports](/using-syllago/cli-reference/sandbox-ports.md)
* [syllago sandbox run](/using-syllago/cli-reference/sandbox-run.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/sandbox_cmd.go)
# syllago sandbox check
> Verify bubblewrap, socat, and optionally a provider
[Source](/using-syllago/cli-reference/sandbox-check/)
## Synopsis
```plaintext
syllago sandbox check [provider]
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Check sandbox prerequisites
syllago sandbox check
# Check prerequisites for a specific provider
syllago sandbox check claude-code
```
## See Also
* [syllago sandbox](/using-syllago/cli-reference/sandbox.md)
* [syllago sandbox allow-domain](/using-syllago/cli-reference/sandbox-allow-domain.md)
* [syllago sandbox allow-env](/using-syllago/cli-reference/sandbox-allow-env.md)
* [syllago sandbox allow-port](/using-syllago/cli-reference/sandbox-allow-port.md)
* [syllago sandbox deny-domain](/using-syllago/cli-reference/sandbox-deny-domain.md)
* [syllago sandbox deny-env](/using-syllago/cli-reference/sandbox-deny-env.md)
* [syllago sandbox deny-port](/using-syllago/cli-reference/sandbox-deny-port.md)
* [syllago sandbox domains](/using-syllago/cli-reference/sandbox-domains.md)
* [syllago sandbox env](/using-syllago/cli-reference/sandbox-env.md)
* [syllago sandbox info](/using-syllago/cli-reference/sandbox-info.md)
* [syllago sandbox ports](/using-syllago/cli-reference/sandbox-ports.md)
* [syllago sandbox run](/using-syllago/cli-reference/sandbox-run.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/sandbox_cmd.go)
# syllago sandbox deny-domain
> Remove a domain from the sandbox allowlist
[Source](/using-syllago/cli-reference/sandbox-deny-domain/)
## Synopsis
```plaintext
syllago sandbox deny-domain
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago sandbox deny-domain api.example.com
```
## See Also
* [syllago sandbox](/using-syllago/cli-reference/sandbox.md)
* [syllago sandbox allow-domain](/using-syllago/cli-reference/sandbox-allow-domain.md)
* [syllago sandbox allow-env](/using-syllago/cli-reference/sandbox-allow-env.md)
* [syllago sandbox allow-port](/using-syllago/cli-reference/sandbox-allow-port.md)
* [syllago sandbox check](/using-syllago/cli-reference/sandbox-check.md)
* [syllago sandbox deny-env](/using-syllago/cli-reference/sandbox-deny-env.md)
* [syllago sandbox deny-port](/using-syllago/cli-reference/sandbox-deny-port.md)
* [syllago sandbox domains](/using-syllago/cli-reference/sandbox-domains.md)
* [syllago sandbox env](/using-syllago/cli-reference/sandbox-env.md)
* [syllago sandbox info](/using-syllago/cli-reference/sandbox-info.md)
* [syllago sandbox ports](/using-syllago/cli-reference/sandbox-ports.md)
* [syllago sandbox run](/using-syllago/cli-reference/sandbox-run.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/sandbox_cmd.go)
# syllago sandbox deny-env
> Remove an env var from the sandbox allowlist
[Source](/using-syllago/cli-reference/sandbox-deny-env/)
## Synopsis
```plaintext
syllago sandbox deny-env
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago sandbox deny-env OPENAI_API_KEY
```
## See Also
* [syllago sandbox](/using-syllago/cli-reference/sandbox.md)
* [syllago sandbox allow-domain](/using-syllago/cli-reference/sandbox-allow-domain.md)
* [syllago sandbox allow-env](/using-syllago/cli-reference/sandbox-allow-env.md)
* [syllago sandbox allow-port](/using-syllago/cli-reference/sandbox-allow-port.md)
* [syllago sandbox check](/using-syllago/cli-reference/sandbox-check.md)
* [syllago sandbox deny-domain](/using-syllago/cli-reference/sandbox-deny-domain.md)
* [syllago sandbox deny-port](/using-syllago/cli-reference/sandbox-deny-port.md)
* [syllago sandbox domains](/using-syllago/cli-reference/sandbox-domains.md)
* [syllago sandbox env](/using-syllago/cli-reference/sandbox-env.md)
* [syllago sandbox info](/using-syllago/cli-reference/sandbox-info.md)
* [syllago sandbox ports](/using-syllago/cli-reference/sandbox-ports.md)
* [syllago sandbox run](/using-syllago/cli-reference/sandbox-run.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/sandbox_cmd.go)
# syllago sandbox deny-port
> Remove a localhost port from the sandbox allowlist
[Source](/using-syllago/cli-reference/sandbox-deny-port/)
## Synopsis
```plaintext
syllago sandbox deny-port
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago sandbox deny-port 8080
```
## See Also
* [syllago sandbox](/using-syllago/cli-reference/sandbox.md)
* [syllago sandbox allow-domain](/using-syllago/cli-reference/sandbox-allow-domain.md)
* [syllago sandbox allow-env](/using-syllago/cli-reference/sandbox-allow-env.md)
* [syllago sandbox allow-port](/using-syllago/cli-reference/sandbox-allow-port.md)
* [syllago sandbox check](/using-syllago/cli-reference/sandbox-check.md)
* [syllago sandbox deny-domain](/using-syllago/cli-reference/sandbox-deny-domain.md)
* [syllago sandbox deny-env](/using-syllago/cli-reference/sandbox-deny-env.md)
* [syllago sandbox domains](/using-syllago/cli-reference/sandbox-domains.md)
* [syllago sandbox env](/using-syllago/cli-reference/sandbox-env.md)
* [syllago sandbox info](/using-syllago/cli-reference/sandbox-info.md)
* [syllago sandbox ports](/using-syllago/cli-reference/sandbox-ports.md)
* [syllago sandbox run](/using-syllago/cli-reference/sandbox-run.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/sandbox_cmd.go)
# syllago sandbox domains
> List allowed domains
[Source](/using-syllago/cli-reference/sandbox-domains/)
## Synopsis
```plaintext
syllago sandbox domains
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago sandbox domains
```
## See Also
* [syllago sandbox](/using-syllago/cli-reference/sandbox.md)
* [syllago sandbox allow-domain](/using-syllago/cli-reference/sandbox-allow-domain.md)
* [syllago sandbox allow-env](/using-syllago/cli-reference/sandbox-allow-env.md)
* [syllago sandbox allow-port](/using-syllago/cli-reference/sandbox-allow-port.md)
* [syllago sandbox check](/using-syllago/cli-reference/sandbox-check.md)
* [syllago sandbox deny-domain](/using-syllago/cli-reference/sandbox-deny-domain.md)
* [syllago sandbox deny-env](/using-syllago/cli-reference/sandbox-deny-env.md)
* [syllago sandbox deny-port](/using-syllago/cli-reference/sandbox-deny-port.md)
* [syllago sandbox env](/using-syllago/cli-reference/sandbox-env.md)
* [syllago sandbox info](/using-syllago/cli-reference/sandbox-info.md)
* [syllago sandbox ports](/using-syllago/cli-reference/sandbox-ports.md)
* [syllago sandbox run](/using-syllago/cli-reference/sandbox-run.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/sandbox_cmd.go)
# syllago sandbox env
> List allowed env vars
[Source](/using-syllago/cli-reference/sandbox-env/)
## Synopsis
```plaintext
syllago sandbox env
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago sandbox env
```
## See Also
* [syllago sandbox](/using-syllago/cli-reference/sandbox.md)
* [syllago sandbox allow-domain](/using-syllago/cli-reference/sandbox-allow-domain.md)
* [syllago sandbox allow-env](/using-syllago/cli-reference/sandbox-allow-env.md)
* [syllago sandbox allow-port](/using-syllago/cli-reference/sandbox-allow-port.md)
* [syllago sandbox check](/using-syllago/cli-reference/sandbox-check.md)
* [syllago sandbox deny-domain](/using-syllago/cli-reference/sandbox-deny-domain.md)
* [syllago sandbox deny-env](/using-syllago/cli-reference/sandbox-deny-env.md)
* [syllago sandbox deny-port](/using-syllago/cli-reference/sandbox-deny-port.md)
* [syllago sandbox domains](/using-syllago/cli-reference/sandbox-domains.md)
* [syllago sandbox info](/using-syllago/cli-reference/sandbox-info.md)
* [syllago sandbox ports](/using-syllago/cli-reference/sandbox-ports.md)
* [syllago sandbox run](/using-syllago/cli-reference/sandbox-run.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/sandbox_cmd.go)
# syllago sandbox info
> Show effective sandbox configuration
[Source](/using-syllago/cli-reference/sandbox-info/)
## Synopsis
```plaintext
syllago sandbox info [provider]
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Show sandbox config
syllago sandbox info
# Show config with provider mount profile
syllago sandbox info claude-code
```
## See Also
* [syllago sandbox](/using-syllago/cli-reference/sandbox.md)
* [syllago sandbox allow-domain](/using-syllago/cli-reference/sandbox-allow-domain.md)
* [syllago sandbox allow-env](/using-syllago/cli-reference/sandbox-allow-env.md)
* [syllago sandbox allow-port](/using-syllago/cli-reference/sandbox-allow-port.md)
* [syllago sandbox check](/using-syllago/cli-reference/sandbox-check.md)
* [syllago sandbox deny-domain](/using-syllago/cli-reference/sandbox-deny-domain.md)
* [syllago sandbox deny-env](/using-syllago/cli-reference/sandbox-deny-env.md)
* [syllago sandbox deny-port](/using-syllago/cli-reference/sandbox-deny-port.md)
* [syllago sandbox domains](/using-syllago/cli-reference/sandbox-domains.md)
* [syllago sandbox env](/using-syllago/cli-reference/sandbox-env.md)
* [syllago sandbox ports](/using-syllago/cli-reference/sandbox-ports.md)
* [syllago sandbox run](/using-syllago/cli-reference/sandbox-run.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/sandbox_cmd.go)
# syllago sandbox ports
> List allowed localhost ports
[Source](/using-syllago/cli-reference/sandbox-ports/)
## Synopsis
```plaintext
syllago sandbox ports
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago sandbox ports
```
## See Also
* [syllago sandbox](/using-syllago/cli-reference/sandbox.md)
* [syllago sandbox allow-domain](/using-syllago/cli-reference/sandbox-allow-domain.md)
* [syllago sandbox allow-env](/using-syllago/cli-reference/sandbox-allow-env.md)
* [syllago sandbox allow-port](/using-syllago/cli-reference/sandbox-allow-port.md)
* [syllago sandbox check](/using-syllago/cli-reference/sandbox-check.md)
* [syllago sandbox deny-domain](/using-syllago/cli-reference/sandbox-deny-domain.md)
* [syllago sandbox deny-env](/using-syllago/cli-reference/sandbox-deny-env.md)
* [syllago sandbox deny-port](/using-syllago/cli-reference/sandbox-deny-port.md)
* [syllago sandbox domains](/using-syllago/cli-reference/sandbox-domains.md)
* [syllago sandbox env](/using-syllago/cli-reference/sandbox-env.md)
* [syllago sandbox info](/using-syllago/cli-reference/sandbox-info.md)
* [syllago sandbox run](/using-syllago/cli-reference/sandbox-run.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/sandbox_cmd.go)
# syllago sandbox run
> Run a provider in a sandbox
[Source](/using-syllago/cli-reference/sandbox-run/)
## Synopsis
```plaintext
syllago sandbox run [flags]
```
## Options
| Flag | Type | Default | Required | Description |
| ---------------- | ------------- | ------- | -------- | ---------------------------------------------- |
| `--allow-domain` | `stringArray` | — | No | Allow an additional domain for this session |
| `--allow-env` | `stringArray` | — | No | Forward an additional env var into the sandbox |
| `--allow-port` | `stringArray` | — | No | Allow a localhost port inside the sandbox |
| `--force-dir` | `bool` | — | No | Skip directory safety checks |
| `--mount-ro` | `stringArray` | — | No | Mount additional path read-only inside sandbox |
| `--no-network` | `bool` | — | No | Block all network egress (no proxy) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Run Claude Code in a sandbox
syllago sandbox run claude-code
# Run with additional domain access
syllago sandbox run claude-code --allow-domain api.example.com
# Run with no network at all
syllago sandbox run gemini-cli --no-network
```
## See Also
* [syllago sandbox](/using-syllago/cli-reference/sandbox.md)
* [syllago sandbox allow-domain](/using-syllago/cli-reference/sandbox-allow-domain.md)
* [syllago sandbox allow-env](/using-syllago/cli-reference/sandbox-allow-env.md)
* [syllago sandbox allow-port](/using-syllago/cli-reference/sandbox-allow-port.md)
* [syllago sandbox check](/using-syllago/cli-reference/sandbox-check.md)
* [syllago sandbox deny-domain](/using-syllago/cli-reference/sandbox-deny-domain.md)
* [syllago sandbox deny-env](/using-syllago/cli-reference/sandbox-deny-env.md)
* [syllago sandbox deny-port](/using-syllago/cli-reference/sandbox-deny-port.md)
* [syllago sandbox domains](/using-syllago/cli-reference/sandbox-domains.md)
* [syllago sandbox env](/using-syllago/cli-reference/sandbox-env.md)
* [syllago sandbox info](/using-syllago/cli-reference/sandbox-info.md)
* [syllago sandbox ports](/using-syllago/cli-reference/sandbox-ports.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/sandbox_cmd.go)
# syllago share
> Contribute library content to a team repo or registry
[Source](/using-syllago/cli-reference/share/)
## Synopsis
```plaintext
syllago share [flags]
```
## Description
Copies a library item to a target repo, stages the change, and optionally creates a branch and PR.
By default, shares to the current team repo (the syllago repo you’re in). Use —to to share to a named registry instead.
## Options
| Flag | Type | Default | Required | Description |
| ------------ | -------- | ------- | -------- | ------------------------------------------------- |
| `--no-input` | `bool` | — | No | Skip interactive git prompts, stage only |
| `--to` | `string` | — | No | Target registry name (omit for current team repo) |
| `--type` | `string` | — | No | Disambiguate when name exists in multiple types |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Share a skill to the current team repo
syllago share my-skill
# Share to a named registry
syllago share my-skill --to my-registry
# Disambiguate by type
syllago share my-rule --type rules
# Non-interactive mode (stage only, no git prompts)
syllago share my-skill --no-input
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/share.go)
# syllago sync-install
> Sync registries then install content to a provider
[Source](/using-syllago/cli-reference/sync-install/)
## Synopsis
```plaintext
syllago sync-install [flags]
```
## Description
Convenience command that syncs all registries then installs content.
Equivalent to running: syllago registry sync && syllago install —to \
This is useful in CI/CD or automation where you want a single command to ensure registries are up-to-date before installing.
## Options
| Flag | Type | Default | Required | Description |
| ----------------- | -------- | ------- | -------- | ------------------------------------------------------------------------------------------------ |
| `-n`, `--dry-run` | `bool` | — | No | Show what would be installed without making changes |
| `--llm-hooks` | `string` | `skip` | No | How to handle LLM-evaluated hooks: skip (drop with warning) or generate (create wrapper scripts) |
| `--name` | `string` | — | No | Filter by item name (substring match) |
| `--source` | `string` | `local` | No | Which items to install: local (default), shared, registry, builtin, all |
| `--to` | `string` | — | Yes | Provider slug to install to, or “all” for every provider (required) |
| `--type` | `string` | — | No | Filter to a specific content type (e.g., skills, rules) |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Sync registries and install to Cursor
syllago sync-install --to cursor
# Install to all providers
syllago sync-install --to all --type skills
# Install only registry content to Kiro
syllago sync-install --to kiro --source registry
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/sync-install.go)
# syllago telemetry
> Manage usage analytics settings
[Source](/using-syllago/cli-reference/telemetry/)
View and control anonymous usage data collection. Run ‘syllago telemetry status’ for details.
## Subcommands
| Command | Description |
| ---------------------------------------------------------- | ------------------------------------- |
| [`off`](/using-syllago/cli-reference/telemetry-off.md) | Disable telemetry |
| [`on`](/using-syllago/cli-reference/telemetry-on.md) | Enable telemetry |
| [`reset`](/using-syllago/cli-reference/telemetry-reset.md) | Generate a new anonymous ID |
| [`status`](/using-syllago/cli-reference/telemetry-status.md) | Show telemetry state and anonymous ID |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/telemetry_cmd.go)
# syllago telemetry off
> Disable telemetry
[Source](/using-syllago/cli-reference/telemetry-off/)
## Synopsis
```plaintext
syllago telemetry off
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago telemetry off
```
## See Also
* [syllago telemetry](/using-syllago/cli-reference/telemetry.md)
* [syllago telemetry on](/using-syllago/cli-reference/telemetry-on.md)
* [syllago telemetry reset](/using-syllago/cli-reference/telemetry-reset.md)
* [syllago telemetry status](/using-syllago/cli-reference/telemetry-status.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/telemetry_cmd.go)
# syllago telemetry on
> Enable telemetry
[Source](/using-syllago/cli-reference/telemetry-on/)
## Synopsis
```plaintext
syllago telemetry on
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago telemetry on
```
## See Also
* [syllago telemetry](/using-syllago/cli-reference/telemetry.md)
* [syllago telemetry off](/using-syllago/cli-reference/telemetry-off.md)
* [syllago telemetry reset](/using-syllago/cli-reference/telemetry-reset.md)
* [syllago telemetry status](/using-syllago/cli-reference/telemetry-status.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/telemetry_cmd.go)
# syllago telemetry reset
> Generate a new anonymous ID
[Source](/using-syllago/cli-reference/telemetry-reset/)
## Synopsis
```plaintext
syllago telemetry reset
```
## Description
Generates a new anonymous ID. Previously collected data under your old ID is not deleted from PostHog. To request deletion, email with your old ID.
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago telemetry reset
```
## See Also
* [syllago telemetry](/using-syllago/cli-reference/telemetry.md)
* [syllago telemetry off](/using-syllago/cli-reference/telemetry-off.md)
* [syllago telemetry on](/using-syllago/cli-reference/telemetry-on.md)
* [syllago telemetry status](/using-syllago/cli-reference/telemetry-status.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/telemetry_cmd.go)
# syllago telemetry status
> Show telemetry state and anonymous ID
[Source](/using-syllago/cli-reference/telemetry-status/)
## Synopsis
```plaintext
syllago telemetry status
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago telemetry status
```
## See Also
* [syllago telemetry](/using-syllago/cli-reference/telemetry.md)
* [syllago telemetry off](/using-syllago/cli-reference/telemetry-off.md)
* [syllago telemetry on](/using-syllago/cli-reference/telemetry-on.md)
* [syllago telemetry reset](/using-syllago/cli-reference/telemetry-reset.md)
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/telemetry_cmd.go)
# syllago uninstall
> Deactivate content from a provider
[Source](/using-syllago/cli-reference/uninstall/)
## Synopsis
```plaintext
syllago uninstall [flags]
```
## Description
Removes installed content from a provider’s location.
For symlinked content: removes the symlink. For copied content: removes the copied file or directory. For hooks/MCP: reverses the JSON merge from the provider’s settings file.
The content remains in your library (\~/.syllago/content/) and can be reinstalled at any time with “syllago install”.
## Options
| Flag | Type | Default | Required | Description |
| ----------------- | -------- | ------- | -------- | ------------------------------------------------------- |
| `-n`, `--dry-run` | `bool` | — | No | Show what would happen without making changes |
| `-f`, `--force` | `bool` | — | No | Skip confirmation prompt |
| `--from` | `string` | — | No | Provider to uninstall from (omit to uninstall from all) |
| `--no-input` | `bool` | — | No | Disable interactive prompts, use defaults |
| `--type` | `string` | — | No | Disambiguate when name exists in multiple types |
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
# Uninstall from a specific provider
syllago uninstall my-skill --from claude-code
# Uninstall from all providers
syllago uninstall my-agent
# Skip confirmation prompt
syllago uninstall my-rule --from cursor --force
# Preview what would happen
syllago uninstall my-skill --dry-run
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/uninstall.go)
# syllago update
> Update syllago to the latest release
[Source](/using-syllago/cli-reference/update/)
## Synopsis
```plaintext
syllago update
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago update
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/update.go)
# syllago version
> Print syllago version
[Source](/using-syllago/cli-reference/version/)
## Synopsis
```plaintext
syllago version
```
## Global Options
| Flag | Type | Default | Required | Description |
| ----------------- | ------ | ------- | -------- | ----------------------------- |
| `--json` | `bool` | — | No | Output in JSON format |
| `--no-color` | `bool` | — | No | Disable color output |
| `-q`, `--quiet` | `bool` | — | No | Suppress non-essential output |
| `-v`, `--verbose` | `bool` | — | No | Verbose output |
## Examples
```bash
syllago version
```
***
[Source](https://github.com/OpenScribbler/syllago/blob/main/cli/cmd/syllago/version.go)
# Collections
> How content is organized in syllago — your library, registries, and loadouts.
[Source](/using-syllago/collections/)
Syllago organizes content into three collection types, each serving a different role in your workflow. Your **library** holds content you own and manage directly. **Registries** connect you to shared content from teams or the community. **Loadouts** bundle content together so you can apply entire configurations at once.
## Quick comparison
| Aspect | Library | Registries | Loadouts |
| ------------ | ------------------------ | ------------------------------- | ----------------------------- |
| Location | `~/.syllago/content/` | Git repos (cloned locally) | Defined in config |
| Access | Read-write | Read locally, contribute via PR | Apply/revert |
| Purpose | Your personal content | Shared team/community content | Bundled configurations |
| Key commands | `add`, `install`, `list` | `registry add/sync/items` | `loadout create/apply/remove` |
## Library
Your personal content store at `~/.syllago/content/`. This is where syllago manages the content you acquire from providers. You have full read-write access — add, edit, or remove content as needed.
```bash
syllago add --from
syllago list
syllago install --to
```
[Library deep-dive](/using-syllago/collections/library.md)
## Registries
Git-based repositories of shared content maintained by teams or the community. You consume registry content locally and can contribute back via pull request using `syllago share --to `.
```bash
syllago registry add
syllago registry sync
syllago registry items
```
[Registries deep-dive](/using-syllago/collections/registries.md)
## Loadouts
Bundled sets of content — rules, skills, agents, hooks, MCP configs — that apply as a unit. Loadouts let you switch between configurations quickly, either temporarily for testing or permanently.
```bash
syllago loadout create
syllago loadout apply --try # temporary
syllago loadout apply --keep # permanent
syllago loadout remove
```
[Loadouts deep-dive](/using-syllago/collections/loadouts.md)
# Library
> Your personal content store — the read-write collection you own and manage directly.
[Source](/using-syllago/collections/library/)
The library is your personal content store at `~/.syllago/content/`. Unlike [registries](/using-syllago/collections/registries.md) (shared, read-only locally) or [loadouts](/using-syllago/collections/loadouts.md) (bundled configurations), the library is fully read-write. You own this content and can add, edit, or remove it freely.
## Directory structure
Content is organized by type. Each item is a directory containing a `.syllago.yaml` metadata file and one or more content files.
```plaintext
~/.syllago/content/
├── rules/
│ ├── typescript/
│ │ ├── .syllago.yaml
│ │ └── typescript.md
│ └── security/
│ ├── .syllago.yaml
│ └── security.md
├── skills/
│ └── develop-docs/
│ ├── .syllago.yaml
│ └── develop-docs.md
├── agents/
├── hooks/
├── commands/
└── loadouts/
```
The `.syllago.yaml` file stores metadata like the item’s name, description, content type, and provider compatibility. The accompanying files hold the actual content that gets exported to providers.
## Adding content
There are three ways to get content into your library.
### Import from a provider
Pull content from an existing provider setup into syllago. This is the most common starting point — bring in what you already have.
```bash
# Discover what a provider has
syllago add --from claude-code
# Add only a specific content type
syllago add skills --from claude-code
# Add a specific item by name
syllago add rules/my-rule --from cursor
# Preview what would be written without actually writing
syllago add --from claude-code --dry-run
# Add everything
syllago add --all --from claude-code
```
Syllago handles format conversion automatically. A Cursor rule becomes a universal syllago item that can later be installed to Claude Code, Kiro, or any other supported provider.
See `syllago add --help` for full options.
## Browsing and inspecting content
### List content
```bash
# Show all content grouped by type
syllago list
# Show only library content
syllago list --source library
# Filter by content type
syllago list --type skills
# JSON output for scripting
syllago list --json
```
The `--source` flag accepts: `library`, `shared`, `registry`, `builtin`, or `all` (default).
See [`syllago list`](/using-syllago/cli-reference/list.md) for full options.
### Inspect an item
View the full metadata and content details for any item.
```bash
# Inspect by type/name
syllago inspect skills/my-skill
# Provider-specific content uses type/provider/name
syllago inspect rules/claude-code/my-rule
```
See [`syllago inspect`](/using-syllago/cli-reference/inspect.md) for full options.
## Exporting to providers
Once content is in your library, install it to any supported provider. Syllago converts between provider formats automatically.
```bash
# Install a specific item to Cursor
syllago install my-rule --to cursor
# Install all skills to Kiro
syllago install --to kiro --type skills
```
For project-scoped providers (Kiro, Cline, Zed), content is written to the current working directory’s provider config.
See `syllago install --help` for full options.
## How it connects
The library sits at the center of the syllago workflow:
* **Providers** are the source and destination. Import from one, export to many.
* **[Registries](/using-syllago/collections/registries.md)** are shared content you consume. Registry items appear alongside library items when you run `syllago list --source all`, but they live in separate cloned repos.
* **[Loadouts](/using-syllago/collections/loadouts.md)** bundle library content into named configurations that can be applied or reverted as a unit.
For an overview of how all three collections work together, see [Collections](/using-syllago/collections.md).
# Loadouts
> Bundle and apply curated sets of AI coding tool content as named configuration profiles.
[Source](/using-syllago/collections/loadouts/)
Loadouts are bundled sets of content — rules, skills, agents, hooks, MCP configs — that apply as a unit. Think of them as named configuration profiles: instead of adding content piece by piece, you define a loadout once and apply everything in a single command.
Loadouts emit Claude Code configuration by default. Use `--to ` on `syllago loadout apply` to target a different provider — the loadout’s constituent items install through that provider’s normal converter.
## How loadouts fit in
Your [library](/using-syllago/collections/library.md) stores individual content items. [Registries](/using-syllago/collections/registries.md) share content across teams. Loadouts sit on top of both — they bundle content from your library into apply-as-a-unit configurations.
```plaintext
Library (individual items) --> Loadouts (bundled profiles) --> Provider config (Claude Code)
```
## Creating a loadout
Use the interactive creator to define a new loadout:
```bash
syllago loadout create
```
This walks you through selecting which content items to include. The result is a named loadout stored in your syllago configuration.
## Applying a loadout
The `apply` command has three modes controlled by flags:
```bash
# Preview what would change (default, no flags)
syllago loadout apply
# Apply temporarily — auto-reverts when the session ends
syllago loadout apply --try
# Apply permanently — persists until you explicitly remove it
syllago loadout apply --keep
```
To target a specific provider:
```bash
syllago loadout apply --keep --to
```
The default (no flags) is a dry run — it shows what files would be created or modified without touching anything. This lets you inspect the effect before committing.
### Temporary vs. permanent
**`--try`** is designed for experimentation. Apply a loadout, test it during your coding session, and it automatically reverts when the session ends. Nothing to clean up.
**`--keep`** writes the configuration to disk permanently. To undo it, use `syllago loadout remove`.
## Managing loadouts
```bash
# List all available loadouts
syllago loadout list
# Check what's currently active
syllago loadout status
# Remove the active loadout and restore original configuration
syllago loadout remove
```
## Use cases
**Per-project configurations.** Define loadouts for different work contexts — a Python backend stack, a frontend stack, a security audit profile — and switch between them as needed.
**Team onboarding.** New team members apply the team’s standard loadout in one command instead of manually configuring rules, skills, and MCP servers.
**Temporary experimentation.** Use `--try` to test a new set of rules or skills without risk. If it doesn’t work out, it reverts automatically.
## Related
* [Collections overview](/using-syllago/collections.md) — how library, registries, and loadouts work together
* [Library](/using-syllago/collections/library.md) — your personal content store
* [Registries](/using-syllago/collections/registries.md) — shared team and community content
* [CLI reference: loadout commands](/using-syllago/cli-reference/loadout-apply.md) — full flag and option details
# Registries
> Share and consume content through git-based registries.
[Source](/using-syllago/collections/registries/)
Registries are git repositories that hold shared syllago content. Teams share content into a registry, and consumers add, sync, and browse it locally. Unlike a read-only package feed, registries support contributing back — `syllago share --to ` opens a pull request against the registry repo.
## How registries work
When you add a registry, syllago clones the git repo locally. Syncing pulls the latest commits. Browsing lists the content available in the clone. Nothing is installed into your [library](/using-syllago/collections/library.md) until you explicitly install an item.
```plaintext
Remote git repo Local clone Your library
┌──────────────┐ add ┌──────────┐ install ┌──────────┐
│ registry.git │──────→ │ .syllago/ │────────→ │ content/ │
└──────────────┘ sync └──────────┘ └──────────┘
↑ │
└──────────────────────┘
publish (PR)
```
## Adding a registry
```bash
syllago registry add https://github.com/your-org/syllago-registry.git
```
Options:
* `--name` — override the registry name (defaults to name derived from the URL)
* `--ref` — pin to a specific branch, tag, or commit (defaults to the repo’s default branch)
```bash
# Pin to a release tag
syllago registry add https://github.com/your-org/syllago-registry.git --ref v2.1
# Custom local name
syllago registry add https://github.com/your-org/syllago-registry.git --name team-rules
```
## Syncing
Pull the latest content from one or all registries:
```bash
# Sync all registries
syllago registry sync
# Sync a specific registry
syllago registry sync team-rules
```
Syncing only updates the local clone. It does not modify your library or any installed content. This keeps your workflow predictable — you choose when to pull updates into your library.
## Browsing content
List what a registry offers:
```bash
# All items across all registries
syllago registry items
# Items from a specific registry
syllago registry items team-rules
# Filter by content type
syllago registry items --type rules
```
## Installing registry content
Install content from a registry into your library using the same `install` command you use for any content:
```bash
syllago install --to
```
Syllago resolves the item from your registered registries. Once installed, the content lives in your library and behaves like any other library content.
## Managing registries
```bash
# List all registered registries
syllago registry list
# Remove a registry (deletes the local clone)
syllago registry remove team-rules
```
## Contributing back
Registries are not read-only. If you have content in your library that belongs in a shared registry, share it:
```bash
syllago share my-skill --to team-rules
```
This opens a pull request against the registry’s git repo. The registry maintainers review and merge through their normal PR workflow — no special tooling required on their end.
`syllago share` works for both registries and arbitrary team repos. Pass `--to ` to target a registered registry; omit it to share into a default team repo.
## Privacy gate
Content from private registries is automatically tainted with source metadata. Syllago blocks publishing tainted content to public registries to prevent accidental leakage. See [Registry Privacy](/advanced/registry-privacy.md) for details.
## Creating your own registry
You can scaffold a new registry with `syllago registry create`:
```bash
# Scaffold an empty registry
syllago registry create --new my-rules --description "Team coding standards"
# Index existing provider-native content in a repo
syllago registry create --from-native
```
Or create one manually — a registry is just a git repo with syllago’s content structure:
1. Create a new git repo
2. Add syllago content following the standard directory layout
3. Push to a git host (GitHub, GitLab, etc.)
4. Share the URL — others add it with `syllago registry add`
## Relationship to other collections
| Collection | Role | Access model |
| ------------------------------------------------ | ----------------------------- | ---------------------------------- |
| [Library](/using-syllago/collections/library.md) | Your personal content | Full read-write |
| **Registries** | Shared team/community content | Consume locally, contribute via PR |
| [Loadouts](/using-syllago/collections/loadouts.md) | Bundled configurations | Apply and revert as a unit |
Registries feed your library. You browse what is available, install what you need, and the installed content becomes part of your library. Loadouts can then bundle library content into switchable configurations.
## Command reference
* [`syllago registry add`](/using-syllago/cli-reference/registry-add.md)
* [`syllago registry sync`](/using-syllago/cli-reference/registry-sync.md)
* [`syllago registry items`](/using-syllago/cli-reference/registry-items.md)
* [`syllago registry list`](/using-syllago/cli-reference/registry-list.md)
* [`syllago registry remove`](/using-syllago/cli-reference/registry-remove.md)
* `syllago registry create`
* `syllago share`
# Content Types
> Overview of syllago content types and provider compatibility.
[Source](/using-syllago/content-types/)
Syllago manages several content types, each stored in a provider-neutral **syllago format**. When installed to a provider, syllago automatically converts to the provider’s native format. See [Format Conversion](/using-syllago/format-conversion.md) for details.
## Provider compatibility matrix
| Content Type | Amp | Claude | Cline | Codex | Copilot | Crush | Cursor | Factory | Gemini | Kiro | OpenCode | Pi | Roo | Windsurf | Zed |
| ------------ | --- | ------ | ----- | ----- | ------- | ----- | ------ | ------- | ------ | ---- | -------- | -- | --- | -------- | --- |
| Rules | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Skills | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | — |
| Agents | — | ✅ | — | ✅ | ✅ | — | ✅ | ✅ | ✅ | ✅ | ✅ | — | ✅ | — | — |
| MCP Configs | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | — | ✅ | ✅ | ✅ |
| Hooks | ✅ | ✅ | ✅ | ✅ | ✅ | — | ✅ | ✅ | ✅ | ✅ | — | ✅ | — | ✅ | — |
| Commands | — | ✅ | ✅ | ✅ | ✅ | — | — | ✅ | ✅ | — | ✅ | ✅ | ✅ | ✅ | — |
## Content type reference
**[Rules](/using-syllago/content-types/rules.md)** — System prompts and custom instructions that guide AI behavior. Supported by every provider.
**[Skills](/using-syllago/content-types/skills.md)** — Multi-file workflow packages that teach the AI specific capabilities.
**[Agents](/using-syllago/content-types/agents.md)** — AI agent definitions and personas with specialized roles.
**[MCP Configs](/using-syllago/content-types/mcp-configs.md)** — MCP server configurations for tool and resource access.
**[Hooks](/using-syllago/content-types/hooks.md)** — Event-driven automation scripts triggered by AI tool lifecycle events.
**[Commands](/using-syllago/content-types/commands.md)** — Custom slash commands that extend the AI tool’s command palette.
**[Loadouts](/using-syllago/collections/loadouts.md)** — Curated content bundles that apply as a unit. Loadouts bundle other content types together so they can be installed and removed in one operation.
# Agents
> How syllago manages AI agent definitions and personas across providers.
[Source](/using-syllago/content-types/agents/)
Agents are named personas with specialized roles. An agent defines a description and a set of instructions that an AI coding tool can assume, letting you switch between focused behaviors — an API design expert, a security reviewer, a documentation writer — without rewriting prompts.
Supported by most providers: Claude Code, Gemini CLI, Cursor, Copilot CLI, Codex, Roo Code, OpenCode, and Kiro.
## Canonical fields
Agents support the following metadata fields:
| Field | Description | Provider Support |
| ---------------- | ----------------------------------------------- | ------------------------------------- |
| `name` | Agent name (required) | All providers |
| `description` | What the agent does (required) | All providers |
| `permissionMode` | Permission level (5 values) | Claude Code (all 5); others as prose |
| `effort` | Time/complexity: `low`, `medium`, `high`, `max` | Claude Code (native); others as prose |
### Permission modes
The `permissionMode` field supports five values:
| Value | Meaning |
| ------------------- | ------------------------------ |
| `default` | Normal permission checking |
| `acceptEdits` | Auto-accept file edits |
| `plan` | Plan-only mode (no execution) |
| `dontAsk` | Skip permission prompts |
| `bypassPermissions` | Full bypass (use with caution) |
Claude Code supports all five modes natively. Other providers embed non-native modes as behavioral prose notes.
See the [Content Types overview](/using-syllago/content-types.md) for the full compatibility matrix.
## Syllago format
Each agent in your library has a `.syllago.yaml` manifest and a Markdown source file.
**Manifest** (`.syllago.yaml`):
```yaml
id: 4369aa21-9660-4511-a9bb-7cea37751529
name: api-agent
type: agents
source_format: md
source_type: provider
added_at: 2026-03-13T00:13:24Z
added_by: syllago
```
**Source file** (`api-agent.md`):
```markdown
---
name: api-agent
description: REST API design agent
---
Design RESTful endpoints with OpenAPI conventions.
Follow resource naming best practices and use proper HTTP methods.
Return consistent error shapes with appropriate status codes.
```
The Markdown body contains the agent’s instructions — what the AI should know and do when assuming this persona. The YAML frontmatter carries metadata (name, description) that providers use for display and selection.
## Provider format differences
Most providers use Markdown with YAML frontmatter, so agents install with minimal transformation. Two providers use different native formats:
### Codex (TOML)
Codex stores agent definitions in TOML. Syllago auto-converts between TOML and Markdown frontmatter on import and install:
```toml
[agent]
name = "api-agent"
description = "REST API design agent"
[agent.instructions]
content = """
Design RESTful endpoints with OpenAPI conventions.
Follow resource naming best practices and use proper HTTP methods.
Return consistent error shapes with appropriate status codes.
"""
```
When you import a Codex agent, syllago parses the TOML and stores it as standard Markdown with frontmatter. When you install to Codex, syllago converts back. No manual format handling needed.
### Kiro (Markdown with rich frontmatter)
Kiro uses Markdown agent files with extensive YAML frontmatter — `name`, `description`, `model`, `tools`, `allowedTools`, `mcpServers`, `hooks`, and more. Syllago maps the canonical agent fields onto Kiro’s frontmatter on install.
## Workflow
```bash
# Add an agent from a provider
syllago add agents/api-agent --from claude-code
# List agents in your library
syllago list --type agents
# Install to a different provider
syllago install api-agent --to codex
# Inspect the stored format
syllago inspect api-agent
```
## Further reading
* [Content Types overview](/using-syllago/content-types.md) — compatibility matrix and all content types
* [Format Conversion](/using-syllago/format-conversion.md) — how syllago converts between provider formats
# Commands
> How syllago manages custom slash commands across providers.
[Source](/using-syllago/content-types/commands/)
Commands are custom slash commands that extend an AI tool’s command palette. They let you define reusable prompts or workflows that users invoke with a slash prefix (e.g., `/fix-typo`).
## Provider support
Commands are supported by the following providers:
| Provider | Format | Notes |
| ----------- | -------- | -------------------------------------- |
| Claude Code | Markdown | Command files in `.claude/commands/` |
| Gemini CLI | Markdown | Command files in `.gemini/commands/` |
| Cursor | Markdown | Command files in `.cursor/commands/` |
| Copilot CLI | Markdown | Command files in `.copilot/commands/` |
| Codex | Markdown | Command files in `.codex/commands/` |
| OpenCode | Markdown | Command files in `.opencode/commands/` |
## Canonical fields
Commands support the following metadata:
| Field | Description | Provider Support |
| -------- | ----------------------------------------------- | ------------------------------------------------ |
| `effort` | Time/complexity: `low`, `medium`, `high`, `max` | Claude Code (native); others as behavioral notes |
## Syllago format
Commands are stored in your library using syllago’s provider-neutral format. The metadata file (`.syllago.yaml`) describes the content, and a separate source file holds the command definition.
### Catalog entry
```yaml
id: 6c0ce509-7960-490f-9100-4d5009d6261c
name: fix_typo
type: commands
source_format: md
source_type: provider
has_source: true
added_at: 2026-03-11T19:23:53Z
added_by: syllago
```
Key fields:
* **type** — always `commands` for this content type
* **source\_format** — the format of the source file (`md` for all supported providers)
* **has\_source** — indicates the item includes a source file with the command definition
### Command source
The source file is a Markdown file with optional YAML frontmatter for metadata. Here is a Claude Code-style example:
```markdown
---
description: Fix a typo in a document.
argument-hint:
---
You are a documentation editor.
1. Read the file at $ARGUMENTS carefully.
2. Find and fix the reported typo.
3. Report back what you changed.
```
All supported providers (Claude Code, Gemini CLI, Cursor, Copilot CLI, Codex, OpenCode, and others) use this Markdown-with-frontmatter convention. Frontmatter fields differ slightly per provider — see the per-provider commands pages under [Providers](/using-syllago/providers.md).
## Format conversion
When you export a command to a provider, syllago converts between formats automatically. See [Format Conversion](/using-syllago/format-conversion.md) for details on how syllago handles cross-format translation.
## Working with commands
```bash
# Add a command from a provider
syllago add commands/fix-typo --from claude-code
# List commands in your library
syllago list --type commands
# Install a command to a different provider
syllago install fix_typo --to gemini-cli
# Inspect a command's metadata and source
syllago inspect fix_typo
```
## See also
* [Content Types Overview](/using-syllago/content-types.md) — compatibility matrix and all content types
* [Format Conversion](/using-syllago/format-conversion.md) — how syllago converts between provider formats
# Hooks
> How syllago manages hooks across providers.
[Source](/using-syllago/content-types/hooks/)
Hooks are event-driven automation scripts triggered by AI tool lifecycle events. They let you run custom logic when specific events occur — before or after a tool call, on session start, on file change, and so on.
Supported by Claude Code, Gemini CLI, Copilot CLI, Cursor, Windsurf, Codex, Cline, and Kiro.
## Canonical format
Syllago uses a provider-neutral canonical format for hooks, defined by the [Hook Interchange Format Specification](/reference/hooks-v1.md).
### Handler types
Hooks support four handler types:
| Type | Description |
| --------- | ---------------------------------------------------- |
| `command` | Shell command executed as a subprocess |
| `http` | HTTP POST to a URL |
| `prompt` | LLM-evaluated logic (not all providers support this) |
| `agent` | Delegated to an agent subprocess |
### Event names (canonical)
Hook events use provider-neutral names in the canonical format. The table below lists events supported by both Claude Code and Gemini CLI; see the [Hook Event Matrix](/reference/hook-events.md) for every canonical event across all providers.
| Canonical Event | Claude Code | Gemini CLI |
| --------------------- | ------------------ | -------------- |
| `after_tool_execute` | `PostToolUse` | `AfterTool` |
| `agent_stop` | `Stop` | `AfterAgent` |
| `before_compact` | `PreCompact` | `PreCompress` |
| `before_prompt` | `UserPromptSubmit` | `BeforeAgent` |
| `before_tool_execute` | `PreToolUse` | `BeforeTool` |
| `notification` | `Notification` | `Notification` |
| `session_end` | `SessionEnd` | `SessionEnd` |
| `session_start` | `SessionStart` | `SessionStart` |
Syllago translates event names automatically when converting between providers.
### Matcher types
Hooks use matchers to target specific tools or events:
* **Bare string**: Tool vocabulary lookup (e.g., `"shell"`, `"file_read"`)
* **Pattern object**: Regex on tool name (`{"pattern": "file_(read|write|edit)"}`)
* **MCP object**: Server+tool targeting (`{"mcp": {"server": "github", "tool": "create_issue"}}`)
* **Array**: OR logic across multiple matchers
### Exit code contract
| Code | Meaning |
| ----- | --------------------------------------- |
| `0` | Success — parse JSON output |
| `1` | Non-blocking warning |
| `2` | Block action (only if `blocking: true`) |
| Other | Treated as warning |
## Provider support
| Provider | Hook Support | Notes |
| ---------------------------- | ------------ | --------------------------------------------------------------------- |
| Claude Code | Full | Richest output contract, all event types |
| Gemini CLI | Full | Unique events: `before_model`, `after_model`, `before_tool_selection` |
| Copilot CLI | Full | Conservative safety design |
| Cursor | Yes | JSON merge into `.cursor/settings.json` |
| Windsurf | Yes | JSON merge |
| Codex | Yes | JSON hooks in `.codex/hooks.json` |
| Cline | Yes | File-based executables in `.clinerules/hooks/` |
| Kiro | Yes | Embedded in agent JSON files |
| Zed, Roo Code, OpenCode, Amp | No | — |
## Hook security
Syllago includes a **hook security scanner** that detects dangerous patterns when converting hooks:
| Risk Level | Patterns Detected |
| ---------- | --------------------------------------------------- |
| **High** | `curl`, `rm -rf`, piped execution, network commands |
| **Medium** | Broad matchers, wildcard patterns |
| **Low** | System paths, environment variable access |
Security warnings appear in `syllago convert` and `syllago install` output.
## Portability warnings
When converting hooks between providers, syllago surfaces warnings for:
* **Unsupported events**: e.g., Gemini’s `before_model` has no Claude Code equivalent
* **Capability mismatches**: e.g., `updated_input` (input rewriting) not supported by target
* **Degradation applied**: hooks that use the `block`, `warn`, or `exclude` degradation strategy
## See also
* [Hook Interchange Format Specification](/reference/hooks-v1.md) — full canonical format specification
* [Content Types Overview](/using-syllago/content-types.md) — full provider compatibility matrix
* [Format Conversion](/using-syllago/format-conversion.md) — how syllago converts between provider formats
# MCP Configs
> How syllago manages MCP server configurations across providers.
[Source](/using-syllago/content-types/mcp-configs/)
MCP (Model Context Protocol) server configurations define external tools and data sources that AI coding tools can connect to — things like database access, API integrations, or custom tool servers. Syllago stores these in a provider-neutral format and converts them to each provider’s native configuration on install.
## Syllago format
MCP configs are stored as JSON with a `mcpServers` key. Each server entry specifies the command to run, its arguments, and any environment variables:
```json
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"],
"env": {
"DATABASE_URL": "postgresql://localhost:5432/mydb"
}
},
"github": {
"command": "node",
"args": ["github-server.js"],
"env": {
"GITHUB_TOKEN": "..."
}
}
}
}
```
Each server entry supports:
* **`command`** — the executable to launch the MCP server
* **`args`** — command-line arguments passed to the server process
* **`env`** — environment variables available to the server at runtime
* **`disabledTools`** — list of tools to disable on this server (supported by Kiro, Windsurf, Roo Code)
### `disabledTools`
The `disabledTools` field lets you selectively disable specific tools from an MCP server:
```json
{
"mcpServers": {
"github": {
"command": "node",
"args": ["github-server.js"],
"disabledTools": ["create_issue", "delete_repo"]
}
}
}
```
This field round-trips through Kiro, Windsurf, and Roo Code. Other providers drop it with a portability warning during conversion.
## Provider support
MCP configs are supported by every provider:
| Provider | Supported | Notes |
| ----------- | --------- | ---------------------------------- |
| Claude Code | Yes | `.claude.json`, `.mcp.json` |
| Gemini CLI | Yes | `.gemini/settings.json` |
| Cursor | Yes | `.cursor/mcp.json` |
| Copilot CLI | Yes | `.copilot/mcp-config.json` |
| Codex | Yes | JSON merge |
| Kiro | Yes | `.kiro/settings/mcp.json` |
| Windsurf | Yes | JSON merge |
| Zed | Yes | Uses `context_servers` key |
| Cline | Yes | VS Code globalStorage |
| Roo Code | Yes | `.roo/mcp.json` |
| OpenCode | Yes | `opencode.json` / `opencode.jsonc` |
| Amp | Yes | `.amp/settings.json` |
## Format differences
Most providers use the same `mcpServers` JSON structure, so conversion is straightforward. The notable exception is Zed.
### Zed: `context_servers` mapping
Zed uses the key `context_servers` instead of `mcpServers` in its configuration. Syllago handles this mapping automatically during install and import — no manual adjustment needed.
Zed native format:
```json
{
"context_servers": {
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"]
}
}
}
```
When you import from Zed, syllago reads `context_servers` and normalizes it to `mcpServers`. When you install to Zed, syllago converts `mcpServers` back to `context_servers`.
## See also
* [Content Types Overview](/using-syllago/content-types.md) — full compatibility matrix and content type listing
* [Format Conversion](/using-syllago/format-conversion.md) — how syllago converts between provider formats
# Rules
> How syllago manages rules — system prompts and custom instructions — across all providers.
[Source](/using-syllago/content-types/rules/)
Rules are system prompts and custom instructions that guide AI behavior. They define coding standards, project conventions, response styles, and any other behavioral guidance for the AI tool. Rules are the most universal content type — every provider supports them.
## What rules do
Rules tell the AI tool *how to behave*. Common uses:
* Coding conventions (language preferences, formatting, patterns)
* Project-specific context (architecture decisions, tech stack)
* Response style (verbosity, tone, explanation depth)
* Workflow instructions (testing requirements, review processes)
## Syllago format
Rules in your library are stored as a directory containing two files: a `.syllago.yaml` metadata file and a Markdown content file.
**Metadata** (`.syllago.yaml`):
```yaml
id: d21d767c-1654-46a5-bc5c-d6aa8d5fbe2c
name: typescript
type: rules
source_format: md
source_type: provider
added_at: 2026-03-11T19:23:53Z
added_by: syllago
```
**Content** (`typescript.md`):
```markdown
---
description: TypeScript coding conventions for this project
globs: "**/*.ts"
---
Use strict TypeScript with explicit return types. Prefer functional
patterns over classes. Write Vitest tests for all new functions.
```
The `source_format` field records the original format the rule was imported from. The `source_type` field indicates whether it came from a provider config or was created directly.
## Provider compatibility
Rules are supported by every provider:
| Provider | Format | Extension | Notes |
| ----------- | ------------------------ | --------- | ------------------------------------------------ |
| Claude Code | Markdown | `.md` | `CLAUDE.md` or `.claude/rules/` |
| Gemini CLI | Markdown | `.md` | `GEMINI.md` |
| Copilot CLI | Markdown | `.md` | `.github/copilot-instructions.md` or `AGENTS.md` |
| Codex | Markdown | `.md` | `AGENTS.md` |
| Cursor | Markdown Component (MDC) | `.mdc` | `.cursor/rules/` or `.cursorrules` |
| Windsurf | Markdown | `.md` | `.windsurfrules` or `.windsurf/rules/` |
| Zed | Markdown | `.md` | `.rules`, `.cursorrules`, or `CLAUDE.md` |
| Cline | Markdown | `.md` | `.clinerules/` |
| Roo Code | Markdown | `.md` | `.roo/rules/` with mode-specific subdirectories |
| OpenCode | Markdown | `.md` | `AGENTS.md` or `CLAUDE.md` |
| Kiro | Markdown | `.md` | `.kiro/steering/` |
| Amp | Markdown | `.md` | `AGENTS.md`, `AGENT.md`, `CLAUDE.md` |
## Format differences
Most providers use plain Markdown, but two require conversion:
### Cursor (MDC format)
Cursor uses MDC format with `.mdc` extension. Syllago maps Markdown frontmatter fields to MDC metadata headers automatically.
**syllago format** (Markdown with frontmatter):
```markdown
---
description: TypeScript coding conventions
globs: "**/*.ts"
alwaysApply: false
---
Use strict TypeScript with explicit return types.
```
**Cursor output** (`.mdc`):
```plaintext
---
description: TypeScript coding conventions
globs: "**/*.ts"
alwaysApply: false
---
Use strict TypeScript with explicit return types.
```
The structure looks similar, but the file extension and how the metadata is parsed differs. Cursor expects `.mdc` and interprets the header block as MDC metadata rather than YAML frontmatter.
### OpenCode (Markdown)
OpenCode reads rules from `AGENTS.md` or `CLAUDE.md` at the project root. Syllago installs the rule body as Markdown into one of those files — frontmatter is folded into the content because OpenCode doesn’t read structured rule metadata.
**syllago format** (Markdown):
```markdown
---
description: TypeScript coding conventions
globs: "**/*.ts"
---
Use strict TypeScript with explicit return types.
```
**OpenCode output** (`AGENTS.md`):
```markdown
## TypeScript coding conventions
Applies to: `**/*.ts`
Use strict TypeScript with explicit return types.
```
## Working with rules
### Creating a rule
```bash
syllago create rules my-rule --provider claude-code
```
This scaffolds a new rule directory under `local/` with template files and `.syllago.yaml` metadata.
### Importing from a provider
```bash
syllago add --from claude-code
```
This scans the provider’s config directory and imports any rules into your syllago library in the provider-neutral format.
### Installing to a provider
Rules install to the target provider’s rules directory, converting format automatically:
```bash
syllago install my-rule --to cursor
```
### Inspecting a rule
```bash
syllago inspect rules/claude-code/my-rule
```
Shows the full metadata and content for pre-install auditing.
## Further reading
* [Content Types Overview](/using-syllago/content-types.md) — provider compatibility matrix and other content types
* [Format Conversion](/using-syllago/format-conversion.md) — how syllago converts between provider formats
# Skills
> How syllago manages skills across providers.
[Source](/using-syllago/content-types/skills/)
Skills are multi-file workflow packages that teach the AI specific capabilities. Unlike [rules](/using-syllago/content-types/rules.md), which provide general behavioral guidance, skills encode structured procedures — they include metadata (name, description, triggers) in frontmatter and detailed step-by-step instructions in the body.
## Syllago format
Each skill in your library has a `.syllago.yaml` manifest and a Markdown content file with YAML frontmatter.
### Manifest (.syllago.yaml)
```yaml
id: a1c7bba3-d8ed-4590-8338-b96895737bf2
name: develop-docs
type: skills
source_format: md
source_type: provider
added_at: 2026-03-16T17:09:06Z
added_by: syllago
```
The `type: skills` field identifies this content as a skill. The `source_format` records the original format so syllago can track provenance.
### Content file
Skill content is a Markdown file with YAML frontmatter containing metadata:
```markdown
---
name: develop-docs
description: Documentation design and planning workflow.
---
# DevelopDocs
Orchestrates the complete documentation development lifecycle.
## Steps
1. Analyze the target audience and scope
2. Create an outline with section headings
3. Draft each section following the style guide
4. Review for technical accuracy
5. Format for the target platform
```
The frontmatter `name` and `description` fields are the skill’s identity — they determine how the AI discovers and activates the skill. The body contains the actual instructions.
## Canonical fields
Skills support the following metadata fields in YAML frontmatter:
| Field | Description | Provider Support |
| --------------- | ----------------------------------------------- | ------------------------------------- |
| `name` | Skill name (required) | All providers |
| `description` | What the skill does (required) | All providers |
| `license` | License identifier (Agent Skills spec) | Claude Code, Cursor |
| `compatibility` | Tool/version constraints | Claude Code, Cursor |
| `metadata` | Arbitrary key-value pairs | Claude Code, Cursor |
| `effort` | Time/complexity: `low`, `medium`, `high`, `max` | Claude Code (native); others as prose |
| `hooks` | Skill-scoped event hooks | Claude Code (native); others warn |
## Provider compatibility
Skills are supported by most providers:
| Provider | Format | Notes |
| ----------- | --------------------------- | ------------------------------------------ |
| Claude Code | Markdown + YAML frontmatter | Full field support including effort, hooks |
| Gemini CLI | Markdown | Metadata embedded in body |
| Cursor | Markdown | Full field support |
| Copilot CLI | Markdown | Skills in `.github/skills/` |
| Codex | Markdown | Skills in `.agents/skills/` |
| Kiro | Markdown steering files | Skills in `.kiro/steering/` |
| Windsurf | Markdown | Skills in `.windsurf/skills/` |
| OpenCode | Markdown | Skills in `.opencode/skills/` |
| Roo Code | Markdown | Skills in `.roo/skills/` |
| Amp | Markdown | Skills in `.agents/skills/` |
Zed and Cline do not support skills.
## Format differences
### Frontmatter handling
The key conversion challenge for skills is frontmatter. Claude Code uses standard YAML frontmatter (`---` delimiters), but other providers handle metadata differently:
* **Claude Code** stores `name` and `description` as YAML frontmatter. The AI reads these fields to understand when and how to apply the skill.
* **Gemini CLI** does not use YAML frontmatter. When converting, syllago either embeds the metadata as a heading/description in the Markdown body or omits it if Gemini can infer the skill’s purpose from context.
* **Kiro** uses Markdown steering files in `.kiro/steering/` with `name`, `description`, and other canonical frontmatter mapped onto Kiro’s steering metadata.
* **OpenCode** uses Markdown-based skills with its own conventions for metadata.
### Conversion example
Converting a skill from Claude Code format to Gemini CLI:
```bash
syllago convert develop-docs --to gemini-cli
```
The Claude Code source with frontmatter:
```markdown
---
name: develop-docs
description: Documentation design and planning workflow.
---
# DevelopDocs
Orchestrates the complete documentation development lifecycle...
```
Becomes a Gemini CLI file without frontmatter, with metadata folded into the body:
```markdown
# DevelopDocs
Documentation design and planning workflow.
Orchestrates the complete documentation development lifecycle...
```
The `description` field is preserved as prose rather than lost, and tool name references in the body are automatically translated to Gemini’s equivalents. See [Format Conversion](/using-syllago/format-conversion.md) for the full conversion model.
## Working with skills
```bash
# Import a skill from your current provider
syllago add --from claude-code
# List all skills in your library
syllago list --type skills
# Install a skill to a specific provider
syllago install develop-docs --to gemini-cli
# Inspect a skill's metadata and content
syllago inspect develop-docs
```
## See also
* [Content Types Overview](/using-syllago/content-types.md) — compatibility matrix and all content types
* [Format Conversion](/using-syllago/format-conversion.md) — how syllago converts between provider formats
# Format Conversion
> How syllago converts content between AI coding tool formats.
[Source](/using-syllago/format-conversion/)
## How conversion works
Syllago uses a hub-and-spoke model. Content in your library is stored in syllago’s canonical format — a provider-neutral representation. Every conversion passes through it:
```plaintext
Source Provider → syllago canonical format → Target Provider
```
When you run `syllago install my-skill --to cursor` or `syllago convert my-rule --to windsurf`, syllago reads the canonical content, then converts it to the target provider’s native format — translating fields, metadata, tool names, and content syntax automatically.
### The three conversion fates
Every field and feature in a provider’s native format has one of three fates during conversion:
**Translated** — The field has a canonical equivalent. Syllago actively maps it to/from the target provider’s equivalent.
| Source | Canonical | Target |
| ------------------------------ | ---------------- | --------------------------------- |
| Claude Code `name` frontmatter | `display_name` | Codex `name` field |
| Claude Code `user-invocable` | `user_invocable` | target equivalent |
| Cline `paths` | `globs` | target equivalent (field renamed) |
| OpenCode `enabled: false` | `disabled: true` | target equivalent (polarity flip) |
**Embedded as prose** — The field has no canonical equivalent. Syllago appends it to the content body in a [conversion notes block](#conversion-notes) so nothing is silently lost.
| Field | Embedded as |
| ------------------------------------------- | -------------------------------------------------- |
| Claude Code `allowed-tools` | ”**Tool restriction:** Use only Read, Grep tools.” |
| Claude Code `context: fork` | ”Run in an isolated context.” |
| Any unsupported metadata or behavioral hint | Natural language description |
**Dropped with warning** — The field can’t be meaningfully preserved. Syllago removes it from the output and emits a [portability warning](#portability-warnings).
| Field | Warning |
| ----------------------------------------- | ---------------------------------------------------- |
| Windsurf `trigger: manual` | ”rule will only activate when explicitly requested” |
| Roo Code mode-based globs | ”Roo Code uses mode-based scoping, not glob scoping” |
| Zed rules with globs | ”Zed does not support glob-scoped rules” |
| MCP `autoApprove` on unsupported provider | ”dropped autoApprove” |
**No silent data loss:** every field either maps to canonical, embeds as prose, or generates a warning. All converters return a result containing `Content`, `Filename`, `Warnings`, and `ExtraFiles` — the `Warnings` array is always populated when something can’t be preserved.
## What gets translated
### Canonical field mapping
Frontmatter fields, metadata keys, and structural properties are mapped through syllago’s canonical schema. Field names may change, data types may adapt, and polarity may flip — but the semantic value is preserved.
See each provider’s conventions pages under [Providers](/using-syllago/providers.md) for the exact field mappings.
### Tool name translation
The canonical format uses provider-neutral tool names. Translation happens automatically during conversion.
| Canonical | Claude Code | Gemini CLI | Cursor |
| ------------ | ----------- | ------------------- | ------------------ |
| `file_read` | Read | read\_file | read\_file |
| `file_write` | Write | write\_file | edit\_file |
| `file_edit` | Edit | replace | edit\_file |
| `shell` | Bash | run\_shell\_command | run\_terminal\_cmd |
| `search` | Grep | grep\_search | grep\_search |
| `find` | Glob | glob | file\_search |
| `web_fetch` | WebFetch | web\_fetch | — |
| `agent` | Agent | — | — |
### Argument substitution
Argument placeholder syntax is actively translated between providers:
| Canonical (Claude Code) | Gemini CLI | VS Code Copilot | Cursor |
| ----------------------- | ---------- | --------------- | ------ |
| `$ARGUMENTS` | `{{args}}` | `${input:args}` | `$1` |
| `$ARGUMENTS[N]` / `$N` | — | — | — |
Lossy translations generate warnings:
* **VS Code Copilot named variables** (`${input:firstName}`) collapse to `$ARGUMENTS` during canonicalization — warning: “named → positional, lossy”
* **Providers without placeholder support** (Windsurf, Cline) receive literal text describing the expected arguments, plus a warning
## What gets preserved
### Conversion notes
When a field has no canonical equivalent, syllago embeds it as prose at the end of the content body:
```markdown
---
**Tool restriction:** Use only Read, Grep tools.
Run in an isolated context.
```
These blocks are:
* Appended after a `---` separator at the end of the content body
* Marked with ``
* Written as natural language descriptions of the original fields
* **Stripped automatically** during re-conversion (`StripConversionNotes()`) to prevent layering — the regex pattern matches `\n---\n\n.*$`
### Preserved but may not work
Some content syntax survives conversion but the target provider may not interpret it. This is different from “translated” (actively mapped) and “dropped” (removed entirely) — the text is present in the output but potentially inert.
**Shell injection syntax** — `` !`command` `` inline syntax and ` ```! ` fenced blocks survive in the content body. The target provider may not execute them. An info-level warning is generated. Gemini CLI template directives (`!{...}`, `@{...}`) are similarly preserved with a warning.
**Provider-specific variables** — `${CLAUDE_SKILL_DIR}`, `${CLAUDE_SESSION_ID}`, and similar tokens remain as literal text. The target provider will not expand them.
## Portability warnings
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)
* Lossy syntax translation (e.g., named variables → positional)
* Preserved-but-inert content syntax (shell injection, provider variables)
```bash
# See warnings in structured format
syllago convert my-skill --to cursor --json
```
## Compatibility matrix
| Content Type | Coverage | Notes |
| ------------ | ------------------------------------ | --------------------------------------------------------------------------------- |
| Rules | Every provider | Format varies by provider but content fully preserved |
| Skills | Most providers | Metadata rendering varies by provider capability |
| Agents | Most providers | Codex uses TOML format, Kiro uses Markdown with YAML frontmatter (auto-converted) |
| MCP configs | Every provider | Zed uses `context_servers` key (handled automatically) |
| Hooks | Many providers | Claude Code, Gemini CLI, Copilot CLI, Cursor, Windsurf, Codex, Cline, Kiro |
| Commands | Many providers | Claude Code, Gemini CLI, Cursor, Copilot CLI, Codex, OpenCode |
| Loadouts | Multi-provider (Claude Code default) | Use `--to ` to target other providers |
## Provider-specific notes
### Cursor
Rules are converted to Markdown Component (MDC) format with `.mdc` extension. Frontmatter fields map to MDC metadata headers.
### Codex
Agent definitions use TOML format. Syllago auto-converts between TOML and Markdown frontmatter.
### Kiro
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.
### Amp
Rules use `AGENTS.md` format with globs array frontmatter. MCP configs use a provider-specific JSON key.
### Zed
MCP server configs use the `context_servers` key instead of `mcpServers`. Syllago handles this mapping automatically.
### OpenCode
Rules use YAML format. Syllago strips Markdown frontmatter and converts to OpenCode’s YAML structure.
## Hook conversion
For hooks specifically, syllago uses the [Hook Interchange Format](/reference/hooks-v1.md) 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)
## Using the convert command
```bash
# 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
```
## See also
* [Content Types](/using-syllago/content-types.md) — what each content type supports
* [Hook Interchange Format](/reference/hooks-v1.md) — full hook conversion specification
* `syllago compat` — check provider compatibility
# Providers
> The AI coding tools syllago integrates with, their supported content types, and how provider detection works.
[Source](/using-syllago/providers/)
A **provider** is an AI coding tool that syllago can read from and write to. Each provider has its own configuration format, file locations, and set of supported content types. syllago handles the differences so you can share configuration between them.
## Checking available providers
To see the full list of providers and what each one supports:
```bash
syllago info providers
```
## Content type support matrix
Not every provider supports every content type. The matrix below shows what each provider can handle.
| Provider | Slug | Rules | Skills | Agents | MCP Configs | Hooks | Commands | Hook Events | MCP Transports |
| -------------------------------------------------------- | --------------- | :---: | :----: | :----: | :---------: | :---: | :------: | :---------: | :-------------------------: |
| [Claude Code](/using-syllago/providers/claude-code.md) | `claude-code` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 24 | stdio, sse, streamable-http |
| [Gemini CLI](/using-syllago/providers/gemini-cli.md) | `gemini-cli` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 11 | stdio, sse |
| [Cursor](/using-syllago/providers/cursor.md) | `cursor` | ✅ | ✅ | ✅ | ✅ | ✅ | — | 14 | stdio, sse, streamable-http |
| [Windsurf](/using-syllago/providers/windsurf.md) | `windsurf` | ✅ | ✅ | — | ✅ | ✅ | ✅ | 6 | stdio, sse |
| [Codex](/using-syllago/providers/codex.md) | `codex` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | — | stdio |
| [Copilot CLI](/using-syllago/providers/copilot-cli.md) | `copilot-cli` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 9 | stdio, sse |
| [Zed](/using-syllago/providers/zed.md) | `zed` | ✅ | — | — | ✅ | — | — | — | stdio |
| [Cline](/using-syllago/providers/cline.md) | `cline` | ✅ | ✅ | — | ✅ | ✅ | ✅ | — | stdio, sse, streamable-http |
| [Roo Code](/using-syllago/providers/roo-code.md) | `roo-code` | ✅ | ✅ | ✅ | ✅ | — | ✅ | — | stdio, sse, streamable-http |
| [OpenCode](/using-syllago/providers/opencode.md) | `opencode` | ✅ | ✅ | ✅ | ✅ | — | ✅ | — | stdio |
| [Kiro](/using-syllago/providers/kiro.md) | `kiro` | ✅ | ✅ | ✅ | ✅ | ✅ | — | 10 | stdio, sse |
| [Amp](/using-syllago/providers/amp.md) | `amp` | ✅ | ✅ | — | ✅ | ✅ | — | — | stdio, sse |
| [Factory Droid](/using-syllago/providers/factory-droid.md) | `factory-droid` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 9 | stdio, http |
| [Pi](/using-syllago/providers/pi.md) | `pi` | ✅ | ✅ | — | — | ✅ | ✅ | 15 | — |
| [Crush](/using-syllago/providers/crush.md) | `crush` | ✅ | ✅ | — | ✅ | — | — | — | stdio, http, sse |
Every provider supports rules. Beyond that, support varies based on what each tool’s configuration format can express.
## Auto-detection
When you run `syllago init`, syllago scans your system for installed providers and configures itself to work with the ones it finds. You don’t need to manually specify which providers you use.
## The `--from` and `--to` flags
When working with content, the `--from` flag tells syllago which provider to read from, and the `--to` flag tells it which provider to write to. Use the provider slug as the value:
```bash
# Add content from Cursor to your library
syllago add --from cursor
# Install a rule to Gemini CLI
syllago install my-rule --to gemini-cli
```
If the source and target providers use different configuration formats, syllago converts automatically. See [Format Conversion](/using-syllago/format-conversion.md) for details.
*Generated from syllago 0.13.0 on 2026-05-08.*
# .syllago.yaml Format
> Reference for the .syllago.yaml metadata file that accompanies every content item in your library.
[Source](/using-syllago/syllago-yaml/)
Every content item in your [library](/using-syllago/collections/library.md) has a `.syllago.yaml` file that tracks the item’s identity, provenance, and [type](/using-syllago/content-types.md) — syllago uses it to manage, inspect, and convert content.
You rarely need to edit `.syllago.yaml` by hand. Syllago generates and maintains it automatically when you [`add`](/using-syllago/cli-reference/add.md) or sync content.
## Field reference
Fields are grouped by purpose. Most fields are optional in YAML (omitted when empty) — the notes above each table call out what’s always present.
### Identity
`format_version`, `id`, `name`, and `type` appear in every saved file. The remaining identity fields are written only when populated.
| Field | Type | Description |
| ---------------- | -------------- | ------------------------------------------------------------------------------------------ |
| `format_version` | int | Schema version. Currently `1`. Bumped when the schema changes incompatibly. |
| `id` | string (UUID) | Unique identifier for this content item. |
| `name` | string | Human-readable name. Used in CLI output and as the directory name. |
| `type` | string | Content type. One of: `rules`, `skills`, `agents`, `hooks`, `commands`, `mcp`, `loadouts`. |
| `description` | string | Short human-readable description. |
| `version` | string | Item version (e.g. `1.0.0`). |
| `author` | string | Author or maintainer. |
| `tags` | list of string | Tags for filtering and search. |
| `hidden` | bool | Hide the item from default listings. Defaults to `false`. |
### Source provenance
These fields record where the content came from. They’re populated when syllago `add`s content from a provider, registry, or filesystem.
| Field | Type | Description |
| ----------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| `source` | string | Discriminator for the source kind. `created` means the item was scaffolded locally via `syllago create`; otherwise unset for imported content. |
| `source_provider` | string | Provider slug content was imported from (e.g. `claude-code`). |
| `source_format` | string | Original file format (e.g. `md`, `mdc`, `json`, `toml`). |
| `source_type` | string | How the content was acquired. One of: `git`, `filesystem`, `registry`, `provider`. |
| `source_url` | string | URL the content was fetched from. Reserved for future `syllago update` capability. |
| `source_hash` | string | SHA-256 of the original content, prefixed with `sha256:`. Used for change detection. |
| `has_source` | bool | Whether the original source file is preserved alongside the converted content (in a `.source/` subdirectory). |
### Registry
Set when content was added from a [registry](/using-syllago/collections/registries.md).
| Field | Type | Description |
| ------------------- | ------ | --------------------------------------------------------------------- |
| `source_registry` | string | Registry name content was imported from (e.g. `acme/internal-rules`). |
| `source_visibility` | string | Visibility at import time. One of: `public`, `private`, `unknown`. |
### Scope
Set on add to track where the content lives.
| Field | Type | Description |
| ---------------- | ------ | ------------------------------------------------------------------ |
| `source_scope` | string | One of: `global`, `project`. |
| `source_project` | string | Project directory name. Set only when `source_scope` is `project`. |
### Lifecycle timestamps
| Field | Type | Description |
| ------------ | ----------------- | ----------------------------------------------------------------------- |
| `created_at` | string (ISO 8601) | When the item was scaffolded via `syllago create`. |
| `added_at` | string (ISO 8601) | When the item was added to the library. |
| `added_by` | string | Who or what added the item — e.g. `syllago v0.9.0`, or a person’s name. |
### Dependencies
| Field | Type | Description |
| -------------- | ---------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| `dependencies` | list of `{type, name}` | Other content items this item depends on. Each entry has a content `type` (e.g. `skills`) and the dependency’s `name`. |
### Bundled scripts (hooks only)
| Field | Type | Description |
| ----------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `bundled_scripts` | list of `{original_path, filename}` | Scripts copied into a hook’s library directory at add time. `original_path` is the absolute path at add time so install can restore the script to its original location; `filename` is its name in the library directory. |
### Detection signals (scanner-computed)
These fields are written by syllago’s content scanner during `add` from filesystem and never read from incoming YAML.
| Field | Type | Description |
| ------------------ | ------ | ---------------------------------------------------------------------------- |
| `confidence` | float | Scanner confidence score (0.0–1.0). |
| `detection_source` | string | Where the scanner detected the content (e.g. `content-signal`, `extension`). |
| `detection_method` | string | One of: `automatic`, `user-directed`. |
## Examples
### Rules (imported from a provider)
```yaml
format_version: 1
id: 671fbd47-ce51-4d2b-8b4c-dc04fa4764d7
name: typescript
type: rules
source_provider: cursor
source_format: mdc
source_type: provider
source_hash: sha256:9fa5fdb87b29dac26eb947717d8a0e0b39d8dc2268393f682f061097c0410206
added_at: 2026-03-16T17:09:06Z
added_by: syllago v0.9.0
```
Standard pattern for content pulled from a provider. The `source_hash` lets syllago detect when the upstream content has changed.
### Hooks (imported with source file preserved)
```yaml
format_version: 1
id: 0e15bb54-3187-4673-9e2e-d1d44e40c951
name: settings
type: hooks
source_provider: claude-code
source_format: json
source_type: provider
has_source: true
added_at: 2026-03-05T22:08:18Z
added_by: syllago v0.9.0
```
When `has_source` is `true`, the original source file is stored in a `.source/` subdirectory inside the item’s directory alongside any converted versions.
### Loadouts (created locally)
```yaml
format_version: 1
id: 3b9656ca-ce37-4146-aed6-5f67244688df
name: testing
type: loadouts
source: created
created_at: 2026-03-12T17:16:18Z
added_at: 2026-03-12T17:16:18Z
added_by: Holden Hewett
```
Content created with [`syllago loadout create`](/using-syllago/cli-reference/loadout-create.md) sets `source: created` to mark it as locally scaffolded. The `added_by` field records the user who created it.
### Imported from a registry
```yaml
format_version: 1
id: aa00cc11-ee22-4433-a55b-66cc77dd88ee
name: secure-api-key-handling
type: rules
source_registry: acme/internal-rules
source_visibility: private
source_format: md
source_type: registry
source_scope: project
source_project: payment-service
added_at: 2026-04-01T09:30:00Z
added_by: syllago v0.9.0
```
Registry-sourced content includes the registry name, visibility at import time, and the project directory the item was scoped to.
## Directory layout
Each content item lives in its own directory within the library. The `.syllago.yaml` file sits alongside the actual content files:
```plaintext
library/
rules/
typescript/
.syllago.yaml
typescript.md
hooks/
settings/
.syllago.yaml
settings.json
loadouts/
testing/
.syllago.yaml
testing.yaml
```
The directory name matches the `name` field in `.syllago.yaml`. Content files use whatever format is appropriate for their [type](/using-syllago/content-types.md).
### Provider-specific metadata files
Some content types — legacy single-file hooks and MCP configs that share a parent directory with sibling files — use a sibling metadata file named `.syllago..yaml` instead of a directory-level `.syllago.yaml`. Syllago reads and writes both forms transparently.
# The TUI
> How to navigate the syllago terminal user interface.
[Source](/using-syllago/tui/)
Running `syllago` with no arguments launches the interactive terminal user interface (TUI). It gives you a visual way to browse and manage your library, registries, and providers without memorizing CLI commands.
```sh
syllago
# or use the alias
syl
```
## What you can do
* Browse your library, registries, and providers in one place
* Install and uninstall content to/from providers
* Add content from providers
* Search and filter content with live results
* Inspect content details
## Keyboard shortcuts
### Navigation
| Key | Action |
| -------------- | ---------------------------------------- |
| Up/Down or j/k | Navigate lists and scroll |
| PgUp/PgDn | Jump a full viewport |
| Home/End | Jump to first/last item |
| Enter | Open item / confirm action |
| Esc | Go back one level |
| Tab/Shift+Tab | Switch focus between sidebar and content |
### Actions
| Key | Action |
| --- | ---------------------------------------- |
| / | Search (live filtering with match count) |
| ? | Toggle keyboard shortcut help |
| i | Install selected item |
| x | Uninstall selected item |
| a | Add content (context-specific) |
| d | Remove item |
## Mouse support
Click to select cards, items, tabs, breadcrumbs, and modal buttons. The scroll wheel works in all scrollable areas.
## TUI vs CLI
The TUI and CLI are equivalent — anything you can do in the TUI, you can do with [CLI commands](/using-syllago/cli-reference.md). The TUI is for interactive exploration; the CLI is for scripting and automation (`--json` output on all commands).
## Accessibility
For screen reader users, CLI commands with `--json` output are recommended. Colors can be disabled with `NO_COLOR=1` or `--no-color`.