Create a plugin

Authoring a plugin packages your team’s conventions, rules, skills, commands, MCP servers, and hooks, into one installable bundle. This page covers the plugin layout and how to include each kind of component so others can install your setup with a single command.

Plugin layout

A plugin is a directory with a manifest at its root and subfolders for each component type. The manifest, syntic-plugin.json, declares the plugin’s name, version, and description.

my-plugin/
  syntic-plugin.json
  rules/conventions.md
  skills/release-notes/SKILL.md
  commands/changelog.md
  hooks/hooks.json
  mcp.json

{
  "name": "acme-conventions",
  "version": "1.0.0",
  "description": "Acme's coding rules, skills, and review commands."
}

Adding components

Each component type lives in its own place and reuses the same formats you already use in a project. Put behavior guidance in rules/, and package repeatable procedures as skill directories under skills/, each with a SKILL.md. Define new slash commands as markdown files in commands/, where the filename becomes the command name. Declare external connections in mcp.json using the standard mcpServers schema, and register lifecycle hooks in hooks/hooks.json.

// hooks/hooks.json
{
  "hooks": {
    "PostToolUse": [
      { "matcher": "Write", "command": "npm run lint --silent" }
    ]
  }
}

Testing and publishing

Install your plugin locally from its directory to try it before sharing.

syntic plugin install ./my-plugin

Run a session and exercise each component: confirm the rules take effect, the skills trigger, the commands appear, the MCP servers connect, and the hooks fire. Once it works, publish by pushing the directory to a repository so others can install with github:owner/repo, or add it to a marketplace catalog for wider discovery. Bump the version in the manifest on every change so installs and updates stay predictable.