Takuya Shoji

Posted on Aug 4

Snowflake CoCo Skills, Plugins, and Profiles: When to Use Each and How to Share Them

#snowflake #ai #llm #productivity

Introduction

Snowflake CoCo (Cortex Code was renamed CoCo at Snowflake Summit 2026) is Snowflake's AI coding agent for SQL authoring, data analysis, and app development and more. It's available in several interfaces: CoCo in Snowsight, CoCo CLI, CoCo Desktop, VS Code Extension, and Claude Code Plugin.

Across all of these, you can extend agent behavior using Skills and Plugins. The names are similar enough to cause confusion, but each plays a distinct role. Additionally, Profile is the highest-level extension package — its spec may change before GA.

This article explains what each one is, when to use it, and how to share Skills and Plugins with your team using the recently added Skills and Plugins Sharing feature.

Note: This article reflects my personal views and does not represent Snowflake's official position.

Note: (July 2026) Skills and Plugins Sharing is in Public Preview (available in all accounts). Profile behavior may change in future updates.

tl;dr

Aspect	Skill	Plugin	Profile
Main purpose	Inject domain knowledge and procedures	Package extensions	Switch configuration sets
What it is	Single `.md` file	Directory (multiple components)	JSON config object
Contains	Instructions and workflows	Skills + Hooks + MCP servers + Agents	Skills + MCP + Hooks + Plugins + System Prompt + settings + permissions
Management commands	`/skill` / `$<skill-name>`	`/plugin`	`/profile` / `cortex profile`
How to share	Catalog / Stage / Git	GitHub / local / catalog	Stage / GitHub

The containment hierarchy looks like this:

Skills and Plugins Sharing lets you distribute Skills and Plugins within your organization with native Snowflake versioning.

What is a Skill?

Overview

A Skill is the smallest unit for injecting domain knowledge and procedures into the AI agent. It's a single SKILL.md Markdown file that contains workflows and instructions.

my-skill/
  SKILL.md         ← required
  reference.md     ← optional (supplementary info the agent can reference)
  scripts/         ← optional (helper scripts called from the skill)

A basic SKILL.md looks like this:

---
name: data-onboarding
description: Guide the process of adding a new data source to the team's data platform
---

# When to use this skill

- When the user asks to add a new table or data source
- When they say "I want to ingest data" or "add a new source"

# Steps

1. Confirm the data source type (S3 / API / DB)
2. Create the schema definition and a landing table in the `RAW` database
3. Build the transformation layer using a Dynamic Table
4. Set up data quality checks (NOT NULL, unique constraints)
5. Notify the team's Slack channel when complete

How to invoke

Type / in chat and pick from the skill list
Explicitly invoke with $<skill-name>
The agent auto-invokes when user input semantically matches the description field

Auto-invocation fires when the agent matches the trigger conditions in description against what the user typed. For explicit invocation, use /skill or $<skill-name>.

Management

CoCo Desktop: Agent Settings panel → Skills.

CoCo CLI:

cortex skill list              # list available skills
cortex skill add <path>        # add from local path / GitHub URL / Stage path
cortex skill publish ./my-skill --to-stage @MY_DB.MY_SCHEMA.MY_STAGE/skills/

# After logging in to CoCo
/skill              # list available skills
/skill-development  # invoke the skill for building new skills

Where skills live and their priority

Location	Path	Scope
Project	`.cortex/skills/`	Workspace only
User	`~/.snowflake/cortex/skills/`	Shared across all workspaces
Bundled	Built into the app	Read-only
GitHub	Under cache directory	Fetched from remote
Catalog	Snowflake-managed	Shared within the account

When to use

You want a specific business procedure to run the same way every time
You want to share know-how with teammates in a reproducible form

What is a Plugin?

Overview

A Plugin is an "extension unit" that bundles Skills, Hooks, MCP servers, and subagents into a single directory. Install it once and all related components become active.

A couple of terms worth knowing:

Hook: a script that runs automatically at specific events (e.g., before or after a tool call)
MCP server: an external tool integration server following the Model Context Protocol (used for GitHub, Jira, etc.)

my-plugin/
  .cortex-plugin/
    plugin.json   ← manifest (required)
  skills/
    my-skill/
      SKILL.md
  agents/
    my-agent.md
  .hooks.json     ← optional
  .mcp.json       ← optional

The manifest looks like this:

{
  "name": "my-plugin",
  "version": "1.0.0",
  "description": "Plugin for custom workflows",
  "skills": ["skills"],
  "hooks": {},
  "mcpServers": {}
}

The skills field takes the name of the directory where Skills are stored (default: skills/).

Management

CoCo Desktop:

Agent Settings panel → Plugins. You can add plugins via:

Local folder: specify a directory that has .cortex-plugin/plugin.json
GitHub: use owner/repo format (SSH, GitLab, and Bitbucket also work)
Catalog: import using a snow://skill_catalog/... URI

CoCo CLI:

cortex plugin list             # list installed plugins
cortex plugin add owner/repo   # install from GitHub
cortex plugin add ./my-plugin  # install from local folder

When to use

You want to distribute a set of Skills, Hooks, and MCP servers together as a package
You want to bundle the full extension environment for a customer demo or a specific engagement

What is a Profile?

Overview

A Profile is the top-level configuration package. It combines Skills, MCP servers, Hooks, Plugins, a system prompt, environment variables, settings overrides, and permission rules into one unit. Profiles can be distributed remotely from a Snowflake Stage or GitHub and applied in bulk per team or role.

Field	Description
`skillRepos`	Skills (distributed from Stage / GitHub)
`mcpServers`	MCP server configuration
`systemPromptRepo`	Custom system prompt (`AGENTS.md`, etc.)
`hooks`	Lifecycle hooks
`plugins`	Plugin references (plugins distributed via Profile appear as `origin: profile`)
`envVars`	Environment variables
`settingsOverrides`	CoCo settings overrides (second in priority after Managed Settings)
`permissions`	Permission rules (`deny` / `onlyAllow`)

Security model

Profile sits second in CoCo's settings priority hierarchy, right after Managed Settings (org-level policy):

Managed Settings (restrictions) > Profile overrides > Project Settings > Managed defaults > User Settings > defaults

Without going into Managed Settings in detail, the key constraints on Profile permission rules are:

A Profile cannot grant access that Managed Settings has explicitly denied
A Profile cannot expand the Managed Settings allowlist
A Profile can only restrict access further — not expand it

In other words, admins set the security boundary in Managed Settings, and Profiles layer role-specific restrictions within that boundary.

Management

CoCo Desktop: Agent Settings panel → Profiles.

CoCo CLI:

# Publish a Profile to Stage (--skill-stage specifies the Stage for Skills distribution)
cortex profile publish data-analyst --skill-stage @MY_DB.MY_SCHEMA.MY_STAGE/skills/

# Switch Profile
# Use the /profile command to switch interactively

Setting an org-wide default:

In the org's Managed Settings (managed-settings.json), set defaults.profileName to configure a default Profile for all users. Individual users can still override this.

{
  "version": "1.0",
  "defaults": {
    "profileName": "data-analyst"
  }
}

Note: As of July 2026, Profile is available in both CoCo CLI and CoCo Desktop, but there is no dedicated documentation page yet. The behavior described here may change significantly at general release — avoid using Profile in production for now.

When to use

You want to distribute a complete set of Skills + MCP + Prompt + permission restrictions per role (sales, engineering, analytics)
You want to switch connections, models, and settings per engagement
You're an admin applying role-specific feature restrictions within a security boundary

Skills and Plugins Sharing

The problem with previous sharing methods

Before this feature, sharing Skills and Plugins with a team meant using Git repos or Snowflake Stages. Git worked but required managing repo access permissions, and distributing to team members unfamiliar with Git was cumbersome. Stage-based sharing could use Snowflake roles for access control, but had no version management or catalog browsing.

Skills and Plugins Sharing, added in 2026, addresses these problems. Skills and Plugins are managed natively in Snowflake, available as a Preview Feature in all accounts.

From Snowsight's Horizon Catalog → Skills & Plugins page, you can search and manage all shared Skills and Plugins in your account.

How it works

Skills and Plugins registered in the catalog are stored in your Snowflake account as CORTEX EXTENSION objects. Like TABLE or FUNCTION, CORTEX EXTENSION is a DDL object in Snowflake, and access is managed with GRANT — no Git permission setup required.

CORTEX EXTENSION (TYPE=SKILL or TYPE=PLUGIN)
  └── versioned storage
  └── access control via Snowflake roles
  └── referenced via snow://skill_catalog/... URI

Note: Cortex Extension objects are stored by default in the SKILL_SHARING schema of your personal DB (auto-created by Snowflake).

Sharing options: access and discoverability

Two concepts control sharing, and they're independent:

Concept	What it controls
Access (RBAC)	Which roles can install and use the Skill or Plugin
Discoverability	Whether it appears in catalog search

Combining these gives two sharing styles:

Private sharing: turn discoverability off and share the catalog link with specific roles only. It won't appear in search, but anyone with the link can access it (think "unlisted video").
Role / PUBLIC sharing: grant access to a role + enable discoverability, so the Skill or Plugin is findable in the catalog.

Publishing to the catalog

From CoCo Desktop

For a Skill:

Agent Settings → Skills, select the skill
Click "Publish to Skills Catalog" (the cloud upload icon)
The workflow runs automatically and returns a snow://skill_catalog/... URI

For a Plugin:

Agent Settings → Plugins, select the plugin
Click "Publish to Plugins Catalog"
Same flow — returns a snow://skill_catalog/... URI

From CoCo in Snowsight

Just type Share skill <skill-name> in chat to start sharing.

Note: As of July 2026, sharing Plugins from CoCo in Snowsight is not yet supported.

From CoCo CLI

In CoCo CLI, invoke the /share-skill-and-plugin skill to publish to the catalog:

> /share-skill-and-plugin my-skill

CoCo will confirm the target role (default: PUBLIC) and discoverability (default: enabled), then return the snow://skill_catalog/... URI on completion. You can also use the /skill command and select the share option for a specific skill.

Only Skills and Plugins you created locally can be published. Items already imported from the catalog cannot be re-published.

Note: cortex skill publish --to-stage distributes files to a Snowflake Stage. This is separate from registering to the catalog (CORTEX EXTENSION) — don't confuse the two.

Importing from the catalog

CoCo Desktop:

Search for the target in Snowsight's Horizon Catalog → Skills & Plugins
Copy the snow://skill_catalog/... URI
Agent Settings → Skills (or Plugins) → + → "Add from Skills Catalog"
Paste the URI and import

CoCo CLI:

cortex skill add snow://skill_catalog/MY_DB.MY_SCHEMA.MY_SKILL/versions/version$1

URI format is snow://skill_catalog/DB.SCHEMA.EXTENSION_NAME (dot-separated, not slashes)
version$1 refers to the first published version
If you omit the version, the latest certified version is used when one exists, otherwise the latest version
Imported Skills and Plugins get a CATALOG badge and can be updated with the Sync button or these commands:

Updating via CoCo CLI:

# Update a specific Skill (provide the snow:// URI)
cortex skill update snow://skill_catalog/MY_DB.MY_SCHEMA.MY_SKILL

# Update a specific Plugin
cortex plugin update my-plugin

# Update all installed Plugins at once
cortex plugin update

Catalog vs. Stage: which to use

	Skills Catalog	Stage-based
Version management	Yes (CORTEX EXTENSION)	No (file overwrite)
Catalog browsing	Searchable in Snowsight	Direct path only
Access control	Snowflake roles	Snowflake roles
Git required	No	No
Fine-grained file control	No	Yes

The catalog is the right choice when your team needs version management and catalog browsing. Stage-based distribution suits teams already running a Stage workflow or needing fine-grained file-level control.

Governance

Users with ACCOUNTADMIN can manage all Skills and Plugins in the account from the Snowsight Horizon Catalog → Skills & Plugins page.

Note: As of July 30, 2026, only Skills can be previewed in the catalog. Plugin contents are not visible from the catalog UI.

Action	Description
Certify	Certify a version and add a Certified badge. Users see the latest certified version first.
Change access	Change which roles can install and use it.
Change discoverability	Toggle visibility in catalog search.
Change owner	Reassign ownership of the Cortex Extension object.
Delete	Remove the Skill or Plugin from the catalog.
View telemetry	View 28-day install and usage counts.

When you perform a governance action for the first time, you'll be prompted to select a database where governed objects will be stored. After that, all governed objects are centrally managed in that database (separate from the owner's personal DB).

Limitations

Cross-account sharing is not supported — same Snowflake account only
Security scanning for Skills and Plugins is not yet available
Locally created Skills and Plugins don't appear in catalog search until you explicitly publish them
Export outside of Snowflake is not supported

Use Case Scenarios

Scenario 1: Setting Up a Customer Demo Environment

1. Switch to customer A's Snowflake connection with a Profile
   → /profile switch customer-a

2. Install the full set of Skills and Hooks for customer A via a Plugin
   → Agent Settings → Plugins → Add from GitHub
   or: cortex plugin add owner/customer-a-plugin

3. Invoke a Skill to run specific procedures
   → /semantic-view (example: semantic view creation skill)

The division of labor: Profile switches the connection, Plugin assembles the tools, Skill executes the specific procedures.

Scenario 2: Distributing a Skill to Your Team

When you only need to share a specific workflow (e.g., a semantic view creation procedure), publishing a single Skill to the catalog or a Stage is the simplest path.

# Publish to catalog (via CoCo Desktop GUI)
# → share the snow://skill_catalog/... URI and distribution is done

# Via Stage (CoCo CLI)
cortex skill publish ./my-skill --to-stage @SHARED.SKILLS.TEAM_LIBRARY/my-skill/

Scenario 3: Standardizing Environments Across Teams

For distributing different environments to multiple roles (sales, engineering, data analytics), use a Profile. It applies Skills, MCP servers, a system prompt, and connection settings all at once.

# Publish role-specific Profiles (CoCo CLI)
cortex profile publish sales-engineer --skill-stage @SHARED.PROFILES.STAGE/se/
cortex profile publish data-analyst    --skill-stage @SHARED.PROFILES.STAGE/analyst/

Conclusion

Skill is the smallest unit — it defines how to do something
Plugin is a functional module bundling Skills, MCP servers, Hooks, and Agents
Profile is the top-level distribution package — it covers everything a Plugin provides, plus a system prompt, settings overrides, and permission restrictions tailored to a user persona

Three axes for choosing a sharing method:

Scope	Recommended approach
Personal (workspace)	Project skills (`.cortex/skills/`)
Small team (Git-based)	Install via GitHub
Organization-wide (Snowflake role management)	Skills and Plugins Sharing
Role-based environment distribution	Profile + Stage

CoCo's extension system has three layers at different levels of granularity. Choosing the right level for your use case keeps configuration simple while maximizing reusability.