Plugins Reference
Plugins extend Syntic Code with new slash commands, tools, hooks, and bundled context. A plugin is a directory containing a manifest and the assets it registers. This page documents the manifest schema and how Syntic Code discovers and loads plugins. Once installed, a plugin’s commands and tools appear alongside the built-ins.
Manifest schema
Every plugin has a syntic-plugin.json manifest at its root:
{
"name": "release-helper",
"version": "1.2.0",
"description": "Commands for cutting and verifying releases.",
"commands": [
{ "name": "cut-release", "path": "commands/cut-release.md" }
],
"tools": [
{ "name": "changelog", "path": "tools/changelog.js" }
],
"hooks": {
"PostToolUse": [{ "matcher": "write", "command": "./hooks/lint.sh" }]
}
}| Field | Type | Description |
|---|---|---|
name | string | Unique plugin identifier. Required. |
version | string | Semantic version of the plugin. Required. |
description | string | Short summary shown in /plugins. |
commands | array | Slash commands the plugin registers. |
tools | array | Tools the plugin adds, each with a permission default. |
hooks | object | Lifecycle hooks, using the hooks schema. |
Installing and loading
Plugins load from the project’s .syntic/plugins/ directory and from your global ~/.syntic/plugins/. Syntic Code scans both on startup, validates each manifest, and registers what it finds. Use /plugins inside a session to list installed plugins, see their status, and disable any you do not want active. A plugin that fails validation is skipped with a diagnostic rather than blocking the session.
Distribution
A plugin is just a directory, so it can be shared as a git repository, a tarball, or a folder in a monorepo. Keep the manifest at the root and reference assets by relative path so the plugin is portable. Because plugins can register tools and hooks that run commands, only install plugins from sources you trust — Syntic Code applies your normal permission rules to plugin-added tools, but hooks run with your shell’s privileges.