Plugins
1. Plugins
Picture this. You've just built the perfect skill for CoCo. It knows your project, your conventions, your team's guardrails. It's exactly what you needed. Now your teammate asks, Can I use that in my project too? And suddenly you're copy-pasting folders, maintaining duplicates, hoping nobody edits the wrong version. Then your security lead wants a safety hook added. Now you've got three separate things. None of them versioned together, none of them easy to share, and all of them slowly drifting out of sync. There has to be a better way. There is. It's called a plugin. In this module, you'll learn how plugins solve exactly this problem, bundling everything your agent needs into a single, versioned, installable unit. Skills, hooks, subagents, MCP servers, all shipping together, all governed by one manifest. And you'll get hands-on experience building a custom plugin and publishing it to the catalog for others to use. By the end, you'll know how to build one, distribute it, and install it anywhere your team works. Let's get into it. Now that you have a working custom skill, let's talk about plugins before we build one. Understanding plugins and why they exist will help you with your projects. In addition, we will talk about a few of the extensibility features for AI coding agents, hooks, subagents, and MCP servers. Then we will show you how to build a custom plugin and distribute it. Let's get started. What is a plugin? Skills alone have limitations. The project skill you just built works great for you in your workspace. But what if you want to use this skill in a different project or repository? You'd have to create a copy of it in the other project, and then you'd have multiple copies to maintain. Plug-ins were designed to package and distribute agent capabilities, which include skills. And there are other important extensibility features for AI coding agents in addition to skills. For example, what if you want to add a production safety hook alongside it? For example, detect when the agent is about to execute a command that targets a production environment, and deny execution unless explicit human override conditions are met. Or a subagent for a GitHub pull request review? Now you're managing three separate things, none of them versioned together or installable as a unit. And what if your hook or subagent needs to be shared across multiple repositories, not just one? That's where plugins come in. A plugin is a single installable unit that bundles everything together, skills, hooks, subagents, and MCP servers, with a version number, a formal validation step, and a one-command install. Plug-ins were designed to be the right packaging unit for distributing agent capabilities, both within a team and across an organization. Here's why a plugin is a far better packaging unit than a raw skill folder. First, it's a single installable unit. One action in your agent settings panel registers everything, whereas raw skills require tedious, separate registration. Second, plugins enable true bundling, carrying skills, hooks, subagents, and MCP servers as a coherent capability. And third, they are formally validatable. The manifest is parsed and checked on install, stopping broken configs before they enter your workspace. Beyond setup, plugins give you total lifecycle control. They are versioned right in the manifest. They are updatable via GitHub-sourced plugins or Snowflake repository via a single sync button to instantly pull the latest release. And finally, you get full registry tracking, recording the exact source, install time, and active state, so you always know precisely what's deployed. Here you can see that a plugin is a self-contained directory with a manifest file at a well-known path. Note that CoCo uses the .cortex-plugin directory name. If you use .claude-plugin, that works too for Claude-compatible tooling, but .cortex-plugin is the standard for CoCo. The plugin.json file is the heart of the plugin. Written in JSON, it declares everything the plugin contains, who made it, and how it behaves. This is a minimal example showing what makes up the manifest file on a macOS or Linux developer's desktop system. Now, let's take a look under the hood, what actually goes inside a plugin. A complete plugin can bundle five key elements into one version package. First, skills. These are the skill folders you're already familiar with. Only now, they're versioned together and declared directly inside your manifest skills array. Second, subagents. These are markdown files structured with YAML frontmatter, defining properties like name, tools, and model, followed by instruction prompts in the body. The key difference between a skill and a subagent? A skill guides an interactive, back-and-forth session, while a subagent runs autonomously to completion on a dedicated task. Third, hooks. Hooks are shell scripts triggered by key lifecycle events defined in a hooks.json file. One of the most important for data engineers is PreToolUse, which fires before CoCo executes a tool like a bash command. This is how you enforce strict safety guardrails, for instance, blocking direct deployments to production. Fourth, MCP servers. Powered by the model context protocol, these servers expose external tools and systems, like GitHub or your internal issue tracker, allowing CoCo to pull context from beyond your local code base. We won't cover MCP servers in depth in this course, but full details are available in the CoCo documentation. And finally, activation.md. This optional markdown file displays automatically when a user activates the plugin, giving them immediate guidance on what the plugin does and how to start using it. Five distinct components working in harmony inside one single plugin. You can add a local plugin by selecting a folder on your file system that contains a plugin.json manifest file. The plugin is registered by reference, and it stays where it is on disk, and no files are copied. Note that local plugins update automatically. File watchers detect changes to skill files, hooks, and MCP configurations, so your edits take effect immediately without needing to sync or refresh. You can also add from GitHub. Just provide a GitHub repository in the format owner/repo. The repository is cloned into the Snowflake Cortex Plugins directory and registered as a GitHub-sourced plugin. Plugins imported from GitHub can be synced to pull the latest version from the remote repository. Click the Sync icon on the Plugin Detail page to start a sync. The Plugins Catalog is Snowflake's built-in registry for sharing and discovering plugins across your organization. Plugins in the catalog are stored as versioned Cortex Extension objects, so access is governed by Snowflake roles and grants, no Git credentials or file sharing required. When you import a plugin from the catalog, CoCo Desktop downloads the plugin files from Snowflake, parses the manifest, and registers the plugin. Catalog plugins can be updated to the latest published version without removing and reinstalling them. Just open the Plugins Detail page and click the Sync button. CoCo Desktop queries Snowflake for the latest published version, downloads it, and overwrites the local cache. You can publish any local or project plugin to the Plugins Catalog so others in your organization can import it. First, open the Agent Settings panel and select the Plugins category. Then, select the plugin you want to publish. Next, click the Publish to Plugins Catalog (cloud upload) icon. Let's wrap up. We've seen how plugins simplify sharing agent capabilities by bundling skills, hooks, subagents, and MCP servers into one clean, validatable package. We looked at the manifest file that defines them, the components that go inside them, and how easily you can manage and distribute them. Whether you are iterating locally, pulling from GitHub, or sharing securely across your organization using the Snowflake Plugins Catalog, now in the hands-on exercise that follows you will take the custom skill you built in the earlier module, create a hook plus a dbt-review subagent, and create a custom plugin. Then you will publish it to the Snowflake repository.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.