DEV Community: Takuya Shoji

Near-Zero-Maintenance Open Data Sharing with Snowflake Managed Iceberg Open Data Sharing

Takuya Shoji — Fri, 21 Aug 2026 01:08:04 +0000

Introduction

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

Note: (August 2026) Open Data Sharing is in Public Preview as of this writing. The feature may change before it reaches general availability.

With the release of Open Data Sharing, Snowflake's Iceberg Table offering now covers three dimensions: catalog, storage, and how you share the data. This gives you the flexibility to pick the combination that best fits your use case.

For a great overview of the catalog and storage options, see this article (Japanese):
https://zenn.dev/snowflakejp/articles/fdf4ec46570d86

In this article I focus on the near-zero-maintenance combination: Snowflake Managed Storage + Open Data Sharing, implemented with TPC-H sample data. Here's what we'll cover:

Create Snowflake Managed Iceberg Tables
Load TPC-H sample data
Publish via Open Data Sharing as an Iceberg REST API (both SQL and Snowsight UI walkthrough)
Query from an external engine (DuckDB) — no Snowflake account on the consumer side

Implementation uses an Azure Japan East account.

tl;dr

Catalog options

Snowflake as catalog — Snowflake manages table metadata (CATALOG = 'SNOWFLAKE'). Supports full DML, Time Travel, clustering, replication, and most Snowflake features. Best when you want the full Snowflake experience.
External catalog — Metadata is managed by an external system (AWS Glue, Databricks Unity Catalog, etc.) and accessed through a catalog integration or catalog-linked database. Use this when you need to connect to an existing Iceberg catalog or work with Delta format. Note: cloning, clustering, replication, and standard streams are not available.

Storage options

Snowflake Managed Storage — Snowflake stores and manages the table files. No cloud storage setup or IAM configuration needed. Just specify EXTERNAL_VOLUME = SNOWFLAKE_MANAGED in CREATE ICEBERG TABLE.
External volume — Table files are stored in your own S3, GCS, or Azure Blob. Use when you want to keep data in your existing cloud storage or need to work with an external catalog.

Sharing options

Secure Data Sharing — Snowflake's established data sharing mechanism for sharing tables, views, Semantic Views, AI products (Cortex Search, Cortex Agents), and Native Apps between Snowflake accounts. Best for secure sharing within the Snowflake ecosystem.
Open Data Sharing — Provides read-only access to Iceberg tables via an Iceberg REST API using a PAT (Programmatic Access Token) issued for an External Consumer object. No Snowflake account required on the consumer side. Best for sharing with external partners outside the Snowflake ecosystem.
IRC API through Horizon Catalog — Provides read/write access from external engines like Spark and Trino through Snowflake's existing auth mechanisms (PAT, key pair, External OAuth, WIF). Supports masking/row-access policies and vended credentials. Best for trusted internal consumers that need write access.

Storage comparison

	Snowflake Managed	External Volume
Setup	Just specify `EXTERNAL_VOLUME = SNOWFLAKE_MANAGED`	Requires creating cloud storage, IAM configuration, and an external volume object
Table file location	Snowflake-provided storage	Your own cloud storage (S3, GCS, Azure, S3-compatible)
Fail-safe	Available for Permanent tables (7 days)	None (manage via cloud storage versioning)
Time Travel	Available (up to 90 days)	None
Bucket & IAM management	Handled automatically by Snowflake	You configure buckets and IAM policies
Data compaction	Free and automatic when Snowflake writes	Charged separately
Supported clouds	AWS and Azure only	AWS, Azure, GCP
Best for	Minimizing operational overhead on new or existing workloads	Reusing existing cloud storage or working with external Iceberg catalogs

Sharing comparison

Both Open Data Sharing and Horizon Catalog use the Iceberg REST Catalog API. Here's how they compare alongside traditional Secure Data Sharing:

	Secure Data Sharing	Open Data Sharing	IRC API through Horizon Catalog
Consumer Snowflake account	Required	Not required	Not required
Authentication	Snowflake credentials (account-to-account)	External consumer PAT (other methods coming)	Snowflake user PAT / key pair / External OAuth / WIF
Access level	Read-only	Read-only	Read + write
Vended credentials	Not supported	Not supported	Supported
Data protection policies	Supported (masking, row access)	Not supported	Masking and row access policies supported
Shareable objects	Tables, views, Semantic Views, AI products, and more	Only tables included in the EXTERNAL LISTING	All Iceberg tables in the account*¹
Status	GA	Public Preview	GA
Best for	Secure sharing within and outside the organization with Snowflake accounts	Read-only sharing with external partners who don't have a Snowflake account	Read/write access for internal external engines

Note: *¹ Access to External Iceberg tables via catalog-linked database is in Public Preview as of August 2026. See the documentation for details.

Architecture Overview

Prerequisites

Item	Requirement
Snowflake account	AWS or Azure region (`SNOWFLAKE_MANAGED` is not available on GCP — see note below)
Role	`ACCOUNTADMIN` (or a custom role with the necessary privileges)
Warehouse	An active warehouse is required when creating Iceberg tables
TPC-H sample data	`SNOWFLAKE_SAMPLE_DATA` database (available in all accounts)
Open Data Sharing	Public Preview. Data is served from the provider account's region (no cross-region replication)

Note: If you're using a Google Cloud Platform account, SNOWFLAKE_MANAGED is not available. Create an external volume pointing to Google Cloud Storage and specify EXTERNAL_VOLUME = '<your_gcs_volume>' instead. See the official documentation.

Step 1: Set Up the Database, Schema, and Warehouse

USE ROLE ACCOUNTADMIN;

-- Create warehouse (skip if you already have one)
CREATE WAREHOUSE IF NOT EXISTS iceberg_demo_wh
  WAREHOUSE_SIZE = 'XSMALL'
  AUTO_SUSPEND   = 60
  AUTO_RESUME    = TRUE;

-- Create database and schema
CREATE DATABASE IF NOT EXISTS iceberg_demo_db;
CREATE SCHEMA IF NOT EXISTS iceberg_demo_db.tpch;

USE DATABASE iceberg_demo_db;
USE SCHEMA tpch;
USE WAREHOUSE iceberg_demo_wh;

Step 2: Create Managed Iceberg Tables

'SNOWFLAKE_MANAGED' is a reserved keyword, not the name of an external volume you create. Specifying it means Snowflake manages the underlying storage for you — no S3 bucket, Azure Blob, or IAM setup required.

We'll demonstrate two creation patterns:

CUSTOMER: define columns explicitly, load data in Step 3
ORDERS: use CTAS to create and load in one shot

First, create the CUSTOMER table with an explicit column definition:

CREATE OR REPLACE ICEBERG TABLE customer (
  c_custkey    INTEGER,
  c_name       STRING,
  c_address    STRING,
  c_nationkey  INTEGER,
  c_phone      STRING,
  c_acctbal    NUMBER(12, 2),
  c_mktsegment STRING,
  c_comment    STRING
)
EXTERNAL_VOLUME = 'SNOWFLAKE_MANAGED'
CATALOG         = 'SNOWFLAKE';

Then create ORDERS using CTAS — this creates and loads the table in one statement:

CREATE OR REPLACE ICEBERG TABLE orders
  EXTERNAL_VOLUME = 'SNOWFLAKE_MANAGED'
  CATALOG         = 'SNOWFLAKE'
AS
  SELECT * FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS;

After creation, run SHOW ICEBERG TABLES to verify the storage type:

SHOW ICEBERG TABLES IN SCHEMA iceberg_demo_db.tpch;

If the external_volume_name column shows SNOWFLAKE_MANAGED and iceberg_table_type shows MANAGED, the tables were created correctly.

Step 3: Load TPC-H Data

SNOWFLAKE_SAMPLE_DATA is read-only, so we use INSERT INTO ... SELECT to pull the data into our Iceberg tables.

-- Load CUSTOMER (TPC-H SF1: ~150,000 rows)
INSERT INTO iceberg_demo_db.tpch.customer
SELECT
  c_custkey,
  c_name,
  c_address,
  c_nationkey,
  c_phone,
  c_acctbal,
  c_mktsegment,
  c_comment
FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.CUSTOMER;

-- Verify row count
SELECT COUNT(*) FROM iceberg_demo_db.tpch.customer;
-- → 150,000

Iceberg tables support full DML just like regular Snowflake tables:

-- Check customer distribution by market segment
SELECT c_mktsegment, COUNT(*) AS cnt
FROM iceberg_demo_db.tpch.customer
GROUP BY c_mktsegment
ORDER BY cnt DESC;

Step 4: Set Up Open Data Sharing

With the data loaded, we can now set up external sharing. Open Data Sharing can be configured via SQL or the Snowsight UI — the underlying operations are identical.

⚠️ Warning: The PAT secret is shown only once at creation time. Copy it immediately — there's no way to retrieve it later. If you lose it, drop the PAT and create a new one.

Note: If your account has a network policy, you need to add an entry for each external consumer. See the Open Data Sharing documentation for details.

Option A: SQL Setup

Step 4-SQL-1: Create a Share and Grant Privileges

-- Create the share
CREATE OR REPLACE SHARE iceberg_open_share;

-- Grant access to the database, schema, and tables
GRANT USAGE  ON DATABASE iceberg_demo_db                 TO SHARE iceberg_open_share;
GRANT USAGE  ON SCHEMA   iceberg_demo_db.tpch            TO SHARE iceberg_open_share;
GRANT SELECT ON TABLE    iceberg_demo_db.tpch.customer   TO SHARE iceberg_open_share;
GRANT SELECT ON TABLE    iceberg_demo_db.tpch.orders     TO SHARE iceberg_open_share;

Step 4-SQL-2: Create the External Listing

CREATE EXTERNAL LISTING IF NOT EXISTS iceberg_open_listing
  SHARE iceberg_open_share AS
$$
title: "TPC-H Iceberg Demo"
description: "Snowflake Managed Iceberg Table demo using TPC-H SF1 dataset"
open_sharing:
  catalog_identifier: "iceberg-demo-db"
listing_terms:
  type: "OFFLINE"  # Term acceptance happens outside the Snowflake platform
external_targets:
  access:
    - external_consumers: [ICEBERG_CONSUMER]
$$;

catalog_identifier is the catalog name that consumers will use to reference the data (corresponds to the "Catalog Identifier" field in the Snowsight UI).

Step 4-SQL-3: Verify the Listing and Get the Connection Info

-- Check listing status
SHOW LISTINGS LIKE 'ICEBERG_OPEN_LISTING';
DESC LISTING iceberg_open_listing;

-- Get the catalog_uri to give to consumers
CALL SYSTEM$GET_LISTING_URL_FOR_EXTERNAL_CONSUMER('ICEBERG_OPEN_LISTING');

Sample result:

{
  "catalog": "iceberg-demo-db",
  "catalog_uri": "https://<account-identifier>.snowflakecomputing.com/polaris/open-sharing/api/catalog",
  "scope": "session:role:external"
}

The URL contains /polaris/open-sharing/api/catalog — this is Open Data Sharing's dedicated endpoint, distinct from the Horizon Catalog endpoint (/polaris/api/catalog).

Give consumers four pieces of information: catalog_uri, catalog (catalog name), scope, and the PAT secret.

Step 4-SQL-4: Create the External Consumer and Issue a PAT

USE ROLE ACCOUNTADMIN;

-- Create the External Consumer object
CREATE OR REPLACE EXTERNAL CONSUMER iceberg_consumer
  COMMENT = 'Test consumer';

-- Issue a PAT (copy the secret from the result and save it securely)
ALTER EXTERNAL CONSUMER iceberg_consumer ADD PAT demo_pat;

Sample result:

+----------+-------------------------------------------------+
| pat_name | secret                                          |
+----------+-------------------------------------------------+
| DEMO_PAT | <copy this secret and store it safely>          |
+----------+-------------------------------------------------+

Option B: Snowsight UI Setup

The UI walkthrough covers the same operations as the SQL approach. Follow along with the screenshots.

Step 4-UI-1: Open the "Open Sharing" wizard

In Snowsight, go to Data sharing → External sharing. Click the Share dropdown in the top right and select Open share.

Step 4-UI-2: Select the tables to share

From the Select Data dropdown, expand ICEBERG_DEMO_DB > TPCH and check both CUSTOMER and ORDERS. Click Done. Only Iceberg tables appear as selectable in the UI.

Step 4-UI-3: Configure the listing and add an External Consumer

On the next screen, configure the listing:

Catalog Identifier: the name consumers use to reference the catalog (set to iceberg-open-listing here)
Open Sharing Identifier / SQL Listing Name: auto-generated, but editable

Click + Add under "Add external consumers".

Step 4-UI-4: Create a new External Consumer

In the consumer search dropdown, select + New external consumer. Fill in the name and comment in the dialog. The region (Azure - Japan East) and authentication method (PAT Token) are set automatically. Click Create external consumer.

Step 4-UI-5: Confirm and create the open sharing

Verify that the new consumer appears in the "Add External Consumer" field, then click Create open share.

Step 4-UI-6: Check the endpoint on the detail page

After creation, you land on the listing detail page. The Share Endpoint section shows the catalog name, catalog URI, and OAuth URI. You can also download all connection details as a .txt file using Download config (.txt).

This information corresponds to the JSON returned by CALL SYSTEM$GET_LISTING_URL_FOR_EXTERNAL_CONSUMER in the SQL path.

Step 4-UI-7: Issue the PAT from the External Consumer detail page

Click ICEBERG_CONSUMER in the "External consumers" section, then click Generate token in the "Programmatic access tokens" section.

Set a name and expiry in the dialog, then click Create PAT.

Click Copy to clipboard and close. Give consumers the catalog URI from Step 4-UI-6 and this PAT secret.

⚠️ Warning: Once the PAT is generated, copy or download the secret immediately. Closing this screen makes it permanently inaccessible.

After setup, your open sharing listing appears under Data Sharing → Share with your account as type "Open Sharing".

Step 5: Query from DuckDB

We'll use DuckDB 1.2+ with the iceberg extension as our external client.

pip install duckdb

import json, duckdb

# Connection info from Step 4-UI-6 or Step 4-SQL-3
# (result of CALL SYSTEM$GET_LISTING_URL_FOR_EXTERNAL_CONSUMER('ICEBERG_OPEN_LISTING'))
OPEN_SHARING_JSON = '{"catalog_uri": "https://<account-identifier>.snowflakecomputing.com/polaris/open-sharing/api/catalog", "catalog": "<catalog_name>", "scope": "session:role:external"}'
open_sharing = json.loads(OPEN_SHARING_JSON)

CATALOG_URI  = open_sharing["catalog_uri"]  # /polaris/open-sharing/api/catalog
CATALOG_NAME = open_sharing["catalog"]       # value of the catalog field
SCOPE        = open_sharing["scope"]         # session:role:external (fixed for Open Sharing)
TOKEN_URI    = f"{CATALOG_URI.rstrip('/')}/v1/oauth/tokens"

PAT_SECRET   = "<PAT secret saved at issuance time>"

con = duckdb.connect()
con.execute("INSTALL iceberg; LOAD iceberg;")
con.execute("INSTALL httpfs;  LOAD httpfs;")

# Register the PAT as an OAuth2 credential
# DuckDB automatically runs the client_credentials flow against TOKEN_URI
con.execute(f"""
    CREATE OR REPLACE SECRET open_sharing_secret (
        TYPE              ICEBERG,
        CLIENT_ID         '',
        CLIENT_SECRET     '{PAT_SECRET}',
        OAUTH2_SERVER_URI '{TOKEN_URI}',
        OAUTH2_GRANT_TYPE 'client_credentials',
        OAUTH2_SCOPE      '{SCOPE}'
    )
""")

# Attach the Iceberg REST Catalog
con.execute(f"""
    ATTACH '{CATALOG_NAME}' AS open_catalog (
        TYPE                   ICEBERG,
        ENDPOINT               '{CATALOG_URI}',
        SECRET                 open_sharing_secret,
        ACCESS_DELEGATION_MODE 'vended_credentials'
    )
""")

# List all tables (schema column gives the query path)
print(con.execute("SHOW ALL TABLES").fetchdf())

Sample SHOW ALL TABLES output:

       database schema      name
0  open_catalog   TPCH  CUSTOMER
1  open_catalog   TPCH    ORDERS

Tables are referenced as open_catalog."<schema>"."<table>". Always check SHOW ALL TABLES to get the exact schema name before querying.

Check the CUSTOMER table schema and fetch the first rows:

# Describe schema
print(con.execute('DESCRIBE open_catalog."TPCH"."CUSTOMER"').fetchdf())

# Fetch first 10 rows
print(con.execute('''
    SELECT c_custkey, c_name, c_mktsegment, c_acctbal
    FROM open_catalog."TPCH"."CUSTOMER"
    LIMIT 10
''').fetchdf())

   C_CUSTKEY              C_NAME C_MKTSEGMENT  C_ACCTBAL
0          1  Customer#000000001     BUILDING     711.56
1          2  Customer#000000002   AUTOMOBILE     121.65
2          3  Customer#000000003   AUTOMOBILE    7498.12
3          4  Customer#000000004    MACHINERY    2866.83
4          5  Customer#000000005    HOUSEHOLD     794.47
...

Row count and market segment breakdown (TPC-H SF1: 150,000 total):

print(con.execute('''
    SELECT c_mktsegment, COUNT(*) AS cnt
    FROM open_catalog."TPCH"."CUSTOMER"
    GROUP BY c_mktsegment ORDER BY cnt DESC
''').fetchdf())

  C_MKTSEGMENT    cnt
0    HOUSEHOLD  30189
1     BUILDING  30142
2    FURNITURE  29968
3    MACHINERY  29949
4   AUTOMOBILE  29752

Join CUSTOMER and ORDERS for a revenue summary by segment:

print(con.execute('''
    SELECT
        c.c_mktsegment,
        COUNT(o.o_orderkey)             AS order_count,
        ROUND(SUM(o.o_totalprice), 2)   AS total_revenue,
        ROUND(AVG(o.o_totalprice), 2)   AS avg_order_price
    FROM open_catalog."TPCH"."ORDERS"   o
    JOIN open_catalog."TPCH"."CUSTOMER" c ON o.o_custkey = c.c_custkey
    GROUP BY c.c_mktsegment
    ORDER BY total_revenue DESC
''').fetchdf())

  C_MKTSEGMENT  order_count   total_revenue  avg_order_price
0     BUILDING       303959  45906759082.38        151029.44
1    HOUSEHOLD       300147  45393200282.40        151236.57
2    FURNITURE       299461  45312940516.95        151314.99
3    MACHINERY       298980  45201073855.83        151184.26
4   AUTOMOBILE       297453  45015339723.27        151335.97

Registering the PAT as an OAuth2 credential via CREATE SECRET is all it takes — DuckDB handles the token exchange automatically. From a machine with no Snowflake account at all, you can query TPC-H data with plain SQL.

Conclusion

Step	What we did
Create Iceberg tables	Delegated storage management to Snowflake with `EXTERNAL_VOLUME = 'SNOWFLAKE_MANAGED'` — no external storage or IAM setup
Load data	Loaded TPC-H sample data with `INSERT INTO ... SELECT` (CUSTOMER) and CTAS (ORDERS)
Set up Open Data Sharing (SQL)	`EXTERNAL CONSUMER` → PAT → `SHARE` → `EXTERNAL LISTING`
Set up Open Data Sharing (UI)	External Sharing → Open Sharing wizard — table selection and consumer creation in a few clicks
External access	Iceberg REST API + PAT enables data access with no Snowflake account on the consumer side

Snowflake Managed Storage dramatically simplifies setup compared to a custom external volume. No external storage, no IAM to configure. You still get Time Travel, Fail-safe, clustering, and other Snowflake operational capabilities — and because data is stored in Iceberg format, you don't lose interoperability with external engines.

Open Data Sharing differs from Horizon Catalog IRC access in one key way: it doesn't require consumers to have a Snowflake account, and read access is strictly enforced. A single PAT hands off Iceberg REST API access, making it well-suited for sharing data with external partners or systems outside the Snowflake ecosystem. Use the UI for a quick setup; use SQL when you need IaC or automation.

One current limitation: per-table data protection policies (masking, row access) are not yet supported in Open Data Sharing, so you may need to prepare consumer-specific views or tables per share. More capabilities are coming.

Change Log

(20260820) Initial post

Original Japanese Article

Snowflake Managed Iceberg × Open Data Sharing によるニアゼロメンテナンスなオープン共有

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

Takuya Shoji — Tue, 04 Aug 2026 05:34:29 +0000

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.

References

Promotion

Snowflake What's New Updates on X

I share Snowflake What's New updates on X. Follow for the latest insights:

English Version

Snowflake What's New Bot (English Version)

Japanese Version

Snowflake's What's New Bot (Japanese Version)

Change Log

(20260804) Initial post

Original Japanese Article

Snowflake CoCo (Cortex Code) の Skill・Plugin の違いと使い分け、共有方法