Duration: 5

Anyone can get an AI agent to produce a result. Professionals ensure the right result, every time.

AI coding agents are completely reshaping the data engineering landscape — and if you're not already using them regularly, I'd encourage you to start today. But here's the thing: the fact that an AI agent can generate code isn't actually that interesting anymore. What is interesting is how professional data engineers should be thinking about and leveraging these tools to create repeatable, high-quality outcomes.

That's exactly what this Quickstart is about. We're going to use Snowflake's AI coding agent — Cortex Code (or "CoCo") — to build a real data engineering project. But more importantly, we're going to do it the right way, by encoding our standards and conventions into reusable Skills and Plugins so that every member of your team gets consistent, professional results from the agent — not just you, and not just today.

Duration: 10

Before we start building, let's get CoCo and the starter dbt project connected to your Snowflake account.

In order to connect to your Snowflake account from CoCo Desktop and GitHub Actions, we will use a Snowflake Personal Access Token (or PAT). Please follow the steps in Generating a programmatic access token to create a Snowflake PAT for your user. Use these values when creating the PAT, in the "New programmatic access token" dialog:

Make sure to save the PAT before leaving the page, as you won't be able to view it again. We will use the PAT in the next section to configure dbt as well as in the final CI/CD section to connect to Snowflake from GitHub Actions.

Finally, run the following command in a SQL script in Workspaces. This will allow you to bypass the active network policy rule temporarily, for 60 minutes, in order to test out the CI/CD pipeline. For long-term access you need to create a network policy allowing access from the GitHub Actions environment. For more details check out our Controlling network traffic with network policies page.

This Quickstart uses a starter repository that includes a pre-built dbt project. The two existing models (customers and orders_summary) are there as a starting point — you'll add the third model yourself using a custom skill you create later on.

Start by forking the starter repository to your own GitHub account. Visit the Data Engineering with CoCo Quickstart Repository and click the Fork button near the top right. Complete any required fields and click Create Fork.

Then clone your fork to your local machine:

Take a moment to look at what's in the starter:

If you haven't already installed CoCo Desktop, follow the installation instructions for your operating system.

Once installed, open CoCo Desktop and configure your Snowflake connection. CoCo supports several authentication methods, for this Guide use Password authentication with your Snowflake PAT as the password. See the CoCo authentication documentation for all options.

Finally, use File → Open Folder to open the sfguide-data-engineering-with-coco directory you cloned above. The first time you open the folder CoCo Desktop will ask you if you Trust the files, go ahead and Trust them. CoCo is context-aware: opening the project folder means the agent can see your files, read your code, and run commands in the right place.

The dbt project is pointed at SNOWFLAKE_SAMPLE_DATA.TPCH_SF1, which is available in every Snowflake account. There's nothing to load — the data is already there.

But we need to create the demo environment in Snowflake so that dbt can write to it. The scripts/setup.sql script contains all the code needed to create the role, warehouse, database and schema for the demo environment.

And the good part is you can run SQL scripts directly from CoCo Desktop by following these steps:

dbt looks for profiles.yml in ~/.dbt/ by default. If you don't have one yet, copy the example file:

If you already have a ~/.dbt/profiles.yml, open it and add the coco_de_guide profile block from dbt/profiles.yml.example alongside your existing profiles — each top-level key is a separate profile and they won't conflict.

Open ~/.dbt/profiles.yml (CMD/CTRL+p) and replace the placeholders in the coco_de_guide block with your values:

Make sure dbt can connect to your Snowflake account. Open a terminal in CoCo Desktop and run the following command:

You should see All checks passed! at the end of the output. If you run into any connection issues, double-check your profiles.yml values and make sure your Snowflake account identifier is in the correct format (e.g., xy12345.us-east-1).

Duration: 5

Cortex Code (CoCo) is Snowflake's AI coding agent — an autonomous, context-aware agent optimized for data engineering, analytics, and machine learning tasks. Unlike generic coding assistants, CoCo has deep native knowledge of Snowflake: it understands your schemas, respects your RBAC configuration, and knows Snowflake best practices without being told. Critically for enterprises, the model and the data it touches never leave Snowflake's security perimeter.

CoCo is available in three form factors, and the right choice depends on how you work:

This Quickstart uses CoCo Desktop throughout. Local file access and full extensibility support — skills, plugins, hooks, and subagents — are central to what we're building, and Desktop is the right tool for all of it.

Duration: 10

Before you write a single prompt, there's one thing that will improve every single interaction you have with CoCo in this project: an AGENTS.md file.

AGENTS.md is a Markdown file at the root of your project that contains conventions, context, and commands that you want the agent to know about — every single session, automatically. Without it, you'd have to re-explain your database names, your naming conventions, and your preferred commands every time you start a new chat. With it, that context is always there.

Think of it as the onboarding document you'd write for a new team member — except this team member reads it perfectly every time, never forgets it, and follows it consistently. Here's the key guidance I follow when writing AGENTS.md:

Let's create an AGENTS.md for this project. In the CoCo chat panel, enter the following prompt:

CoCo will generate an AGENTS.md file. Review it and accept/save the changes by clicking on the "Keep" button. Your AGENTS.md may be slightly different, and that's OK, but it should look something like this:

Now let's put AGENTS.md to immediate use. The starter project was built before these conventions were established — which is exactly the situation you'll often face when inheriting a codebase. Let's have CoCo audit the existing models and bring them into compliance.

In the CoCo chat panel, enter:

CoCo will read AGENTS.md, then inspect each model SQL file. It should find that orders_summary.sql references source tables directly by their fully-qualified Snowflake path instead of going through _sources.yml:

CoCo will rewrite the model to use the correct {{ source() }} references:

Click on "Keep" to accept that changes. Once the fix is applied, run dbt build to confirm nothing broke:

This is AGENTS.md doing its job. CoCo didn't need to be told what the violation was or what the fix should look like — it read the conventions, read the code, and connected the two. That's the value: not any single dramatic prompt, but every prompt in the session being grounded in your actual standards rather than the model's best guess.

Duration: 10

We've seen AGENTS.md handle project context and enforce existing conventions. But what about when you're creating something new? When the task is "build a new dbt model," AGENTS.md tells CoCo the database name and the build command — but it doesn't tell it the specific workflow your team follows or the standards that must hold for every new model. That's what Skills are for.

Let's take a few minutes to understand what Skills actually are — because this concept is central to everything that follows in this Quickstart.

Agent Skills are used for implementing repeatable, multi-step workflows. They're made up of instructions that tell the agent how to perform a specific type of task. Skills are supported by most AI coding agents, and the emerging open standard is documented at agentskills.io.

Here's the key insight: Skills encode what the model can't infer on its own. This is worth repeating because it's the most common mistake I see when teams start writing skills. The frontier LLM models are incredibly capable and already know how to do most data engineering tasks. You don't need to write a Skill teaching CoCo what dbt is or how to write a SQL transformation — it already knows. What you do need to capture in a Skill is any repeatable process that is specific to your team: your naming conventions, your testing standards, your deployment workflow, the exact steps you want followed in a particular order.

At its core, a Skill is a folder containing a single required file: SKILL.md. This file has two parts:

1. YAML Frontmatter — metadata about the skill, including its name and description
2. Markdown body — the actual instructions the agent will follow

The description field is especially important: CoCo uses it to decide when to automatically invoke the Skill. Write it as a clear, one-sentence trigger — think of it as answering the question "when should CoCo use this skill?"

Here's the minimum structure of a SKILL.md file:

A Skill lives in a folder, and that folder can contain more than just SKILL.md. You can bundle scripts, templates, and reference materials alongside your instructions:

For many Skills, the SKILL.md file alone is enough. The scripts folder becomes useful when your workflow requires running a specific piece of code consistently.

CoCo ships with a set of bundled Skills for Snowflake-specific workflows that require specialized knowledge the base model doesn't have on its own — things like deploying dbt projects as Snowflake-native objects via the snow dbt CLI, managing Dynamic Tables, working with Iceberg catalogs, and more. These are maintained by Snowflake and are automatically available without any setup.

For common tasks that are well-represented in the model's training data — standard SQL, Python, dbt syntax, general software engineering practices — you typically don't need a skill at all. CoCo's base knowledge handles those.

Custom Skills are ones you write yourself, for your specific team and project. They don't teach CoCo how to use a tool — it already knows. They encode the choices your team has made: which conventions to follow, which steps to run in which order, which guardrails to apply.

A useful rule of thumb: if you find yourself starting a prompt with "remember, we always..." — that's a custom skill waiting to be written.

Duration: 10

Before writing your first custom Skill, it's worth understanding what you don't need to encode. The frontier model behind CoCo has broad, deep knowledge of the software and data engineering ecosystem — and that means for a lot of common tasks, you can just ask.

Our starter project has two models — customers and orders_summary — but neither has schema tests defined in _schema.yml. Schema tests validate your data against expectations (like not_null and unique) every time you run dbt build, catching data quality issues before they reach downstream consumers.

Let's ask CoCo to add them. No skill invocation, no special instructions — just a direct prompt:

CoCo will read the model SQL files, identify the primary key columns, and generate dbt/models/_schema.yml with appropriate tests for customer_key in customers and order_key in orders_summary, along with additional column-level tests where they make sense. Review the changes and click on "Keep" to accept/save them. Run dbt build to confirm everything passes:

CoCo just added a complete set of schema tests without being told what the primary keys were, how _schema.yml is structured, or what test types are available in dbt. It already knew all of that.

Notice, though, that we had to specify the filename _schema.yml explicitly — without it, CoCo defaults to schema.yml. Both are valid dbt, but your project uses the underscore prefix by convention. This is a small but telling example of the broader point: the model knows the tool, not your team's choices. It doesn't know that you always use dbt build rather than dbt run, that primary key tests are required on every new model, or that source references must go through _sources.yml. Those are your team's specific conventions, and without being told, the model will handle them inconsistently from one session to the next. That's exactly what a custom Skill addresses.

Duration: 15

CoCo's base knowledge is great for standard dbt tasks. But for the conventions that are specific to this project — the ones that need to hold consistently across every new model your team builds — that's where a custom Skill comes in.

CoCo knew the dbt test syntax, the _schema.yml structure, and the right test types — all general knowledge. What it doesn't know is the three conventions your team has agreed on for this project: always use dbt build (not dbt run), every primary key must have not_null and unique tests, and raw tables must always go through _sources.yml. Those choices aren't right or wrong in any absolute sense — they're just the standards your team has decided to follow. A custom Skill is how you encode them so CoCo applies them consistently, without being reminded.

Skills need to live somewhere CoCo can find them. CoCo auto-discovers project skills from a .snowflake/cortex/skills/ folder inside the open workspace — no registration or install step required. As soon as the folder exists and contains a SKILL.md, the skill is live. Let's create it:

Now let's write the Skill. In the CoCo chat panel, enter:

Review the generated SKILL.md and click on "Keep" to accept/save the changes. It should have a clean YAML frontmatter block with name and description, followed by the four workflow steps and the three conventions. The description should read something like: "Create a new dbt model in this project. Use when adding a model for a new source table or analytical use case."

If anything looks off — a missing convention, a step out of order — correct it now. Your SKILL.md may be slightly different, and that's OK, but it should look something like this:

Now for the payoff: let's use the skill we just wrote to build the third model in our project. In the CoCo chat panel, enter:

Watch what happens. CoCo auto-discovers the skill from .snowflake/cortex/skills/, matches the prompt against its description, and invokes it automatically. It will follow the workflow steps in order and apply all three conventions — without you having to repeat any of them:

1. Identify the supplier and lineitem source tables from _sources.yml
2. Write dbt/models/supplier_performance.sql using {{ source() }} references
3. Add the model entry to _schema.yml with primary key tests
4. Run dbt build --select supplier_performance --project-dir dbt/ and report the result

That's the difference between a one-off prompt and a Skill. The conventions are encoded once. The team benefits every time. Accept the changes by clicking "Keep" on each new/modified file.

Duration: 10

We now have a working custom Skill. Let's talk about Plugins before we build one — because understanding why Plugins exist makes it much easier to understand what we're about to put together.

The project skill you just built works great — for you, in this workspace. But what if you want to use this skill in a different project/repository? You'd have to create a copy of it in the other project, and then you'd have multiple copies to maintain. And there are other important extensibility features for AI coding agents besides skills. For example, what if you want to add a production safety hook alongside it? Or a subagent for PR 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 this 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. Plugins were designed to be the right packaging unit for distributing agent capabilities, both within a team and across an organization.

Here's a short list of why a Plugin is a better packaging unit than a raw Skill folder:

A Plugin is a self-contained directory with a manifest file at a well-known path:

The plugin.json file is the heart of the Plugin. It declares everything the Plugin contains, who made it, and how it behaves. Here's a minimal example:

Let's briefly cover each element a Plugin can contain:

Skills — the Skill folders we already know about, now bundled and versioned together. Pointed to via the "skills" array in the manifest.

Agents (Subagents) — Markdown files that define autonomous, specialized agents. Like Skills, they have YAML frontmatter with name, description, and optionally tools and model. The body contains instructions the agent follows when invoked. The key difference from a Skill: a subagent is designed to run autonomously to completion on a specific task, whereas a Skill guides an interactive session.

Hooks — shell commands that run on lifecycle events. The most useful for data engineers is PreToolUse, which fires before CoCo executes a tool (like running a Bash command). This is how you add guardrails — for example, blocking direct production deployments. Hooks are defined in a hooks.json file and reference shell scripts.

MCP Servers — Model Context Protocol servers that expose external tools to the agent. For example, you could wire up a connection to your internal issue tracker or GitHub so CoCo can pull context from outside the codebase. We won't cover MCP Servers in depth in this Quickstart, but you can find full details in the CoCo documentation.

activation.md — an optional Markdown file displayed to the user when the Plugin is activated. Use it to explain what the Plugin does and how to enable it.

Duration: 20

We have all the pieces — a custom Skill, a clear understanding of what Plugins are, and a project that's ready to be hardened. Now let's bundle everything into a proper Plugin. The first thing we'll do is migrate the skill from its project-local home into the plugin folder, then add a production safety hook and a dbt review subagent alongside it.

The skill currently lives at .snowflake/cortex/skills/new-dbt-model/ — scoped to this workspace. We're going to move it into .cortex/plugins/coco-de-guide/ — the project-scoped plugin directory that CoCo auto-discovers. Run these commands in the terminal:

The skill is now in .cortex/plugins/coco-de-guide/skills/new-dbt-model/SKILL.md. CoCo auto-discovers plugins in .cortex/plugins/, so once the manifest is in place, the plugin will be live — no separate install step needed.

Let's create the .cortex-plugin/ directory and write the manifest. In the CoCo chat panel, enter:

CoCo will create both plugin.json and activation.md. Accept the changes by clicking "Keep" on each new/modified file. Your plugin.json manifest may be slightly different, and that's OK, but it should look something like this:

One of the most valuable things a Plugin can do is protect your environment from mistakes. A common problem with AI coding agents is that they'll happily run whatever command you ask — including commands that write directly to production. We can prevent that with a PreToolUse hook.

Let's add a hook that blocks any dbt command that targets production:

CoCo will create both files. The shell script reads the tool input from stdin (as JSON), extracts the command, and checks it against the pattern. The hooks.json wires it up. Accept the changes by clicking the 'Keep' button. Your hooks.json may be slightly different, and that's OK, but it should look something like this:

We'll test the hook in the next step.

The final piece of our Plugin is a subagent for reviewing dbt model changes. Unlike a Skill — which guides an interactive session — this subagent is designed to run autonomously to completion. We'll use it both locally (before opening a PR) and in CI/CD (on every PR automatically). That "same agent, two contexts" pattern is one of the most powerful things you can build with CoCo.

Review the generated dbt-review.md and click on "Keep" to accept/save the changes. It should have YAML frontmatter with name, description, tools, and model fields, followed by the review steps and output format.

Because the plugin lives in .cortex/plugins/coco-de-guide/, CoCo Desktop will discover it automatically when the workspace is opened. To verify it is active:

1. Click the Settings tab (gear icon) in the bottom of the left sidebar
2. Open the Plugins section
3. Look for coco-de-guide in the Plugins grid

If the plugin appears but is toggled off, click the toggle to enable it. If it doesn't appear at all, click the ↻ (refresh) button in the Plugins toolbar to force a reload of the plugin registry.

Click the plugin card to open its detail view and verify that all three components — the skill, the hook, and the subagent — are listed.

Now that the plugin is active, the hook is live. Try to get CoCo to run a production deployment by entering this prompt in the chat panel (not in the terminal):

You should see the hook fire and block the command with a clear explanation before CoCo can execute it. This is a small but important example of the broader principle: agents should not make changes directly in production. Even with clear instructions, agents generate content dynamically — and that non-determinism is not something you want in a production pipeline. Hooks give you hard guardrails that enforce that boundary regardless of what the agent decides.

Before wiring this subagent into CI/CD, try it from the chat panel first. Type:

The subagent will run to completion autonomously — finding changed model files, running dbt build for each, checking conventions, and producing a PASS/FAIL report. If you've made any changes that violate the new-dbt-model skill conventions, you'll see specific remediation steps in the output.

Duration: 7

So far, your plugin lives at .cortex/plugins/coco-de-guide/ inside this repository. Teammates can install it by cloning the repo or using Add from GitHub in CoCo Desktop. That works — but Snowflake has a better option for teams that want centralized discovery and access control: the Plugins Catalog.

The Plugins Catalog is Snowflake's built-in registry for sharing and discovering plugins across your organization. Publishing to it gives you:

When you publish a plugin, CoCo creates a CORTEX EXTENSION object in your Snowflake account. A Cortex Extension is a schema-level object (TYPE = PLUGIN) that stores your plugin's files as a live, versioned stage and holds the READ grants that control who can use it.

The naming follows a convention: the plugin's name field is uppercased and hyphens are replaced with underscores. The object is created in a SKILL_SHARING schema inside your personal database:

Once published, the plugin has a share URI — a snow:// link that uniquely identifies this version:

This is what you share with your team. It's stable, access-controlled, and works regardless of whether the recipient has access to your Git repository.

1. Click the Settings tab (gear icon) in the bottom of the left sidebar
2. Open the Plugins section
3. Click the coco-de-guide plugin card to open its detail view
4. Click the Publish to Plugins Catalog button (cloud-upload icon)

A chat session opens and the share-skill-and-plugin skill runs automatically. It will:

1. Prompt you to confirm the plugin name and description
2. Create the SKILL_SHARING schema in your personal database (if it doesn't exist) and grant USAGE to PUBLIC
3. Create the COCO_DE_GUIDE Cortex Extension object
4. Upload all plugin files to the extension's versioned stage
5. Commit the version and apply your chosen access settings

At the end, CoCo reports the share URI:

This Quickstart doesn't walk through the consumer-side flow, but here's how a teammate would install your published plugin:

1. Click the Settings tab (gear icon) in the bottom of the left sidebar
2. Open the Plugins section
3. Click + and choose Add from Plugins Catalog
4. Paste the snow://skill_catalog/... URI and click Import

CoCo downloads the plugin files from Snowflake, validates the manifest, and registers it. The plugin appears in the grid with a CATALOG badge. They can sync to newer versions at any time from the plugin's detail view.

Duration: 15

Everything we've built so far — the AGENTS.md, the Skill, the Plugin, the hook, the subagent — was designed with this moment in mind. We're going to take the exact same dbt-review subagent we've been running locally and wire it into a GitHub Actions workflow so it runs automatically on every pull request that touches a dbt model. Same agent. Same conventions. Now running in CI.

This is the payoff of building a Plugin instead of a loose collection of Skill files. But there's one important note about what's different here: while this Quickstart uses CoCo Desktop for the interactive development sections, the CI/CD pipeline uses the CoCo CLI — the terminal-native form of the same agent. The CLI is the right tool for automation: it runs headlessly, connects via a credentials file, and is installable in any CI environment. The plugin you built in .cortex/plugins/ is auto-discovered by the CLI just as it is by Desktop — no separate install step needed.

From your forked repository on GitHub, click Settings → Secrets and variables → Actions. Add the following repository secrets:

Let's have CoCo write the workflow file. In the CoCo chat panel, enter:

Review the generated workflow and click "Keep" to accept/save the changes. Your workflow may be slightly different, and that's OK, but it should look something like this:

A few things worth noting. fetch-depth: 0 is essential — the dbt-review agent uses git diff origin/main...HEAD to find changed files, which requires full history. The Snowflake connection is configured as a connections.toml file rather than environment variables — this is how the CoCo CLI picks up credentials. The plugin in .cortex/plugins/ is auto-discovered by the CLI the same way it is by Desktop, so no install step is needed. And the intelligence lives entirely in the subagent definition, not in this workflow — the workflow is just infrastructure.

By default, GitHub Actions workflows are disabled in forked repositories. Enable them by going to the Actions tab in your forked repository and clicking I understand my workflows, go ahead and enable them.

Commit all the files you've created in this Quickstart to a new feature branch and push to GitHub using CoCo Desktop's built-in Source Control panel.

Create a new branch

Click the branch name in the bottom status bar (it will show main or whatever branch you're on). Select Create new branch... and enter feature/add-coco-plugin.

Stage and commit your changes

Open the Source Control panel by clicking the Source Control icon in the Activity Bar on the left, or press Cmd+Shift+G (macOS) / Ctrl+Shift+G (Windows/Linux). You'll see all the files you've created listed under Changes.

Click the + icon next to Changes to stage everything, then type a commit message in the input box at the top of the panel:

Click the Commit button, or press Cmd+Enter / Ctrl+Enter.

Push and open a pull request

Click Publish Branch in the Source Control panel (or the sync icon in the status bar) to push feature/add-coco-plugin to your fork on GitHub.

Then switch to GitHub in your browser and open a pull request from feature/add-coco-plugin to main in your forked repository. When creating the pull request, make sure the base repository is your fork, not the upstream Snowflake-Labs repository. GitHub defaults to comparing against the upstream, which you'll need to change.

Navigate to the Actions tab to watch the workflow run. Once it completes, you'll see the dbt-review agent's PASS/FAIL report as output in the workflow logs. You will also see the agent's output in the PR itself as a comment.

Duration: 2

Congratulations! You've built a complete, professional-grade data engineering workflow with Cortex Code. Let's take a moment to look back at what you actually built — and more importantly, why each piece matters.

You started with an empty project and an AI coding agent. The first thing you did wasn't write a prompt — it was write an AGENTS.md. That single file changed the quality of every subsequent interaction. From there, you used the agent to add test coverage to existing models, then created a custom Skill that encoded your team's specific conventions. You immediately proved that Skill worked by using it to build a new model. Then you packaged that Skill — along with a production safety hook and a dbt review subagent — into a Plugin: a versioned, validatable, single-installable unit that can be shared across your entire team. And finally, you took that same subagent and wired it into GitHub Actions, so code review by your AI agent now happens automatically on every pull request.

That last part is the real payoff. The dbt-review subagent didn't get smarter when you moved it to CI/CD — it just became consistent. And consistency, at scale, is what separates a professional data engineering practice from a collection of one-off prompts.