DEV Community: Snowflake

I built a remote control for Cortex Code in Slack so I can step away from my laptop

Dash — Mon, 13 Apr 2026 14:00:00 +0000

Snowflake Cortex Code CLI Meets Slack

Cortex Code CLI is Snowflake's AI coding agent that runs in your terminal. It can write code, execute SQL and DDL scripts, create and deploy data pipelines, generate dashboards, reads & write files, manages git repos and more.

Cortex Code CLI also has a hook system and skill framework that make it extensible so you can build sidecar apps that plug into its lifecycle. I wanted to explore this extensibility by building a Slack bridge: get DM notifications about what the agent is doing, and reply with instructions to steer it, all from your phone. The whole conversation happens in Slack while the agent keeps working in the terminal. No servers, no databases, no cloud infra. Just a Slack bot, some JSON files, and a shell wrapper.

What It Actually Does

It supports two interaction patterns:

Free-text conversations: You type a message in the Slack DM. It lands in a session-specific inbox file. The agent's cron job picks it up on the next cycle and treats it as user input. This is the core of the bridge — you can ask questions (“what's the row count on that table?”), give instructions (“skip that step and move to the next one”), make decisions (“use approach #2”), or redirect the work entirely (“actually, focus on the API layer first”). The agent responds back via Slack.
Notifications: The agent sends you status updates as Slack DMs. “Feature engineering done, 5 tables created.” “Model training complete, 3 models evaluated.” “Blog post committed and pushed.” You see them on your phone and know what's happening without being at the terminal.

Note: This bridge works best with “bypass safeguards” enabled in Cortex Code CLI, which lets the agent execute tools without pausing for terminal confirmations. That's what makes the remote workflow possible; if the agent stopped to ask for permission at the terminal, you'd have to be sitting there anyway.

But understand the tradeoff: bypass safeguards means the agent can execute bash commands, write files, run SQL, and push to git without asking first. You're trusting the agent to do the right thing. The Slack bridge gives you visibility (notifications) and steering (free-text replies), but it doesn't replace the confirmation gate — it replaces the terminal. Use it on repos and environments where you're comfortable with that level of autonomy.

Key Design Decisions

Socket Mode: No public URLs needed. The bot connects outbound to Slack's WebSocket API. Works behind firewalls, no ngrok required.
File-based inbox: Each Cortex Code CLI session gets its own inbox_{session_id}.json. The bridge bot writes to it; the CLI polls it via cron. Dead simple, zero dependencies.
Metadata routing: Every outbound Slack message includes session metadata. When you reply, Slack sends that metadata back. The bridge uses it to write to the correct session's inbox. Multiple sessions, no crosstalk.
Sidecar process: The bridge bot runs as a background process, started automatically by a SessionStart hook. It's not embedded in Cortex Code CLI ; it's a separate Python process that communicates via the filesystem.

The Code

The project has four main files.

1) config.py: Configuration and Session Management

It handles paths, tokens, and multi-session routing.

BRIDGE_DIR = Path.home() / ".cortex-slack-bridge"
INBOX_FILE = BRIDGE_DIR / "inbox.json"
PID_FILE = BRIDGE_DIR / "bridge.pid"

Token lookup follows a priority chain: environment variable > macOS Keychain > config file. Env vars (SLACK_BRIDGE_APP_TOKEN, SLACK_BRIDGE_BOT_TOKEN) are checked first, then Keychain via the security CLI, then ~/.cortex-slack-bridge/config.json as a fallback. The Keychain path means tokens never sit in plain text on disk:

KEYCHAIN_SERVICE = "coco-slack-bridge"

def keychain_get(key: str) -> str | None:
    try:
        result = subprocess.run(
            ["security", "find-generic-password", "-s", KEYCHAIN_SERVICE, "-a", key, "-w"],
            capture_output=True, text=True, timeout=5,
        )
        if result.returncode == 0:
            return result.stdout.strip()
    except (FileNotFoundError, subprocess.TimeoutExpired):
        pass
    return None

Zero new dependencies; just the security CLI that ships with macOS. Session management is minimal: get_session_inbox() returns the inbox path for a session ID, and set_active_session() / get_active_session() track which session the bridge should route messages to when there's no metadata to go on.

2) bridge.py: The Socket Mode Bot

This is the long-running process. It connects to Slack via Socket Mode so when you type in the Slack DM, it captures the text and writes it to the active session's inbox:

@app.event("message")
def handle_dm(event, say):
    user = event.get("user")
    if subtype or user != target_user:
        return

    _append_inbox({
        "type": "reply",
        "text": event.get("text", ""),
        # ...
    })

    say("Message sent to CoCo CLI. Awaiting response…")

Both bridge.py and notify.py append every message to ~/.cortex-slack-bridge/history.jsonl which acts as a permanent audit trail. Inbound DMs, outbound notifications, consumed confirmations — everything gets logged with direction and timestamp.

def _log_history(entry: dict, direction: str):
    try:
        record = {**entry, "direction": direction, "logged_at": time.time()}
        with open(HISTORY_FILE, "a") as f:
            f.write(json.dumps(record) + "\n")
    except Exception:
        pass # history logging done not break core functionality

Three direction values: inbound (user DMs and button clicks), outbound (agent notifications and confirmation requests), consumed (confirmation responses popped from the inbox).

3) notify.py: Sending Messages

This is the outbound side. The main function is send_message() — it sends a plain DM or a color-coded message (blue for status, green for success, yellow for warnings, red for errors). Every message includes session metadata so replies route back correctly:

metadata = {
    "event_type": "cortex_bridge",
    "event_payload": {"session_id": sid},
}

There's also a send_confirmation() function that sends Approve/Deny buttons and polls the inbox for a response. It's used by coco-bridge confirm for scripted gate checks.

4) bin/coco-bridge: The Shell Wrapper

A bash script that makes everything easy to use from Cortex Code CLI's skill system:

coco-bridge start          # Start the bridge bot
coco-bridge stop           # Stop it
coco-bridge status         # Check if running
coco-bridge send "message" # Send a DM
coco-bridge send "msg" - type success # Color-coded
coco-bridge confirm "question" # Approve/Deny buttons
coco-bridge inbox          # Read inbox contents
coco-bridge history        # Last 20 messages (audit log)
coco-bridge history 50     # Last N messages
coco-bridge setup-keychain # Store tokens in macOS Keychain
coco-bridge clear-keychain # Remove tokens from Keychain
coco-bridge logs           # Tail the log file

It auto-detects the project's virtualenv, manages the PID file, and dispatches to the Python modules.

Why This Works

Most AI coding agents don't expose lifecycle hooks as in programmatic entry points where your own code runs at specific moments in the agent's execution. Cortex Code CLI does! It has a hook system that fires shell commands at session start, after every tool call, on user input, and at session end. Combined with a skill framework that lets you teach the agent new behaviors via markdown files, you get a real extensibility contract. This Slack bridge exists entirely because of that, and it's worth understanding the two mechanisms that make it work.

The Hook System

Cortex Code CLI has a lifecycle hook system defined in ~/.snowflake/cortex/hooks.json. You can register shell commands that fire at specific points:

SessionStart: runs when a new session begins (before the agent does anything)
PostToolUse: fires after every tool call (bash, file write, SQL execution, etc.)
UserPromptSubmit: fires when the user sends a message
Stop: fires when the session ends
SubagentStop: fires when a background agent completes

Each hook is a shell command with a configurable timeout. The stdout from SessionStart hooks gets passed to the agent as context, which is how the bridge tells Cortex Code CLI “hey, I'm running, ask the user if they want Slack enabled.”

This is a big deal. It means you can build sidecar applications that plug into Cortex Code CLI's lifecycle without modifying the CLI itself.

The Slack bridge uses SessionStart to auto-launch. But you could just as easily build:

A PostToolUse hook that logs every tool call to a database (audit trail)
A UserPromptSubmit hook that captures conversation history (flight recorder)
A Stop hook that sends a session summary to Slack or email

Setting It Up

Prerequisites

Python 3.10+
A Slack workspace where you can install apps
Cortex Code CLI

Create the Slack App

Go to api.slack.com/apps and create a new app
Under Socket Mode, enable it and create an App-Level Token with connections:write scope. Copy the xapp-… token.
Under OAuth & Permissions, add these Bot Token Scopes: chat:write to send DMs, im:history to read DM history, im:read to view DM channels, im:write to open DM channels
Under Event Subscriptions, enable events and subscribe to the message.im bot event
Under Interactivity & Shortcuts, enable interactivity (no URL needed for Socket Mode)
Install the app to your workspace. Copy the Bot User OAuth Token (xoxb-…).
Find your Slack User ID: click your profile picture in Slack, click the three dots, “Copy member ID”

NOTE: the app-level token, bot user oauth token and your Slack member ID will be used later under Configure Tokens section.

Install the Bridge

git clone https://github.com/iamontheinet/cortex-code-cli-slack-bridge.git \
  ~/Apps/cortex-code-cli-slack-bridge
cd ~/Apps/cortex-code-cli-slack-bridge
python3 -m venv .venv
.venv/bin/pip install -e .

Install Cortex Code CLI Skill

Cortex Code CLI has a skill system that lets you teach the agent new behaviors via markdown files. The repo includes the Cortex Code CLI skill file that teaches the agent how to manage the bridge. For example, when to poll, how to format messages, how to activate and deactivate.

Copy it to your skills directory:

mkdir -p ~/.snowflake/cortex/skills/slack-bridge
cp skill/SKILL.md ~/.snowflake/cortex/skills/slack-bridge/SKILL.md

The Slack bridge skill defines:

Trigger phrases: “slack on”, “enable slack”, “/slack”, etc.
Activation flow: what to do when the user opts in
Message routing: how to handle inbox entries, when to send notifications
Deactivation: how “slack off” tears down the polling

When you say “slack on”, the skill instructs the agent to:

Create a session-scoped cron job that polls the inbox every minute
Send an activation message to Slack
Start routing questions and status updates through Slack instead of the terminal

The cron pattern here is worth calling out. Cortex Code CLI's cron_create tool lets you schedule prompts that fire on a schedule — and they're session-scoped, meaning they die when the session ends. The bridge uses this as a heartbeat: every minute, a “Slack inbox check” prompt fires. The skill tells the agent to read the inbox file, and if it's empty, sleep 30 seconds and check again. Two checks per cron fire gives you ~30-second worst-case latency without doubling the cron frequency or adding a file watcher. It's a cheap way to give an agent a polling loop — just a cron job and a JSON file. The skill also handles “slack off” to disable the bridge mid-session.

Configure Tokens

The recommended approach stores tokens in macOS Keychain:

coco-bridge setup-keychain
# Prompts for app token, bot token, and user ID
# Stores them in Keychain under the "coco-slack-bridge" service

If you already have a config.json, setup-keychain reads from it, migrates to Keychain, and offers to delete the file.

Alternatively, use a config file or env vars:

# Config file approach
mkdir -p ~/.cortex-slack-bridge
cp config.json.example ~/.cortex-slack-bridge/config.json
# Edit with your actual tokens

# Or env vars
export SLACK_BRIDGE_APP_TOKEN="xapp-1-A0…"
export SLACK_BRIDGE_BOT_TOKEN="xoxb-…"
export SLACK_BRIDGE_USER_ID="U02M…"

Start and Test

# Start the bridge
bin/coco-bridge start

# Send a test message
bin/coco-bridge send "Hello from the bridge!"

# Test a reply - type something back in the Slack DM, then check:
bin/coco-bridge inbox

Wire Up the SessionStart Hook

Add this to ~/.snowflake/cortex/hooks.json so the bridge auto-starts with every Cortex Code CLI session:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "/Users/YOUR_USERNAME/.cortex-slack-bridge/start-hook.sh",
            "timeout": 10,
            "enabled": true
          }
        ]
      }
    ]
  }
}

Copy the start hook script:

cp demo-start-hook.sh ~/.cortex-slack-bridge/start-hook.sh
chmod +x ~/.cortex-slack-bridge/start-hook.sh

The Beauty of Extensibility

The whole project is ~300 lines of Python plus a shell wrapper. No servers, no databases, no cloud infra. It extends Cortex Code CLI with a mobile-friendly communication layer so you can kick off a task, walk away, get updates, reply with instructions, all from Slack.

But the bigger takeaway isn't the Slack bridge itself, it's that Cortex Code CLI is built to be extended this way. Hooks give you lifecycle access. Skills give you behavioral control. The filesystem gives you a dead-simple IPC layer. This bridge is one example; the pattern works for any sidecar you can imagine: audit loggers, custom approval gates, integration bridges to other tools.

Stay Connected

Thank you for your time. I hope you found this blog both educational and inspiring. The code can be found here.

Clone it, plug in your Slack tokens, and build something on top of it. The Cortex Code CLI is waiting for your hooks. If you're experimenting with this workflow or planning to, I'd love to hear what you're building.

Connect with me on LinkedIn for more demos as well as AI product & feature updates.

Hot off the press -- Snowflake Cortex Code in Snowsight is now GA!

Dash — Thu, 26 Mar 2026 18:40:50 +0000

Building and scaling AI apps natively on your data just got a massive upgrade.

Here is what is included in this release:

⚡ Rapid prototyping to production: execute large, multi-step projects directly in Snowsight.
🔒 Enterprise-grade governance: built-in controls and observability for regulated environments.
💸 Cost-aware automation: specialized skills for cost optimization and agentic ML workflows.
🪟 Cross-platform CLI: native Windows support removes friction for engineering teams.

🙌 My absolute new favorite in CLI: Agent Teams!

Here's what I tried: "Build a Streamlit chat app in a new folder that streams responses from the Cortex Agent. Use a team of 3 agents (client, UI, config) with a shared event contract defined upfront to avoid integration mismatches."

🤯 I'm still blown away by how well the Agent Teams handled that shared event contract. If you had a team of agents to automate your workflow today, what's the first project you'd assign them? Let's discuss in comments👇

🔗 Get started in mins: https://www.snowflake.com/en/developers/guides/getting-started-with-cortex-code-cli/

Let's learn together!

The data engineer's Cortex Code cheat sheet

Daniel Myers — Thu, 26 Mar 2026 18:06:57 +0000

A practical guide to the commands, prompts, patterns, and habits that make Cortex Code useful in real data work.

Cortex Code is a data-native coding agent that works directly against your data environment. It sees schemas, roles, grants, tags, lineage, query history, semantic models, and the live shape of the data you are trying not to break.

Your SQL lives in a repo. Your dbt models live in a repo. Your DAGs live in a repo. But the work usually fails or succeeds somewhere else: in the data itself, in the state of the platform, and in the operational rules wrapped around it.

That is where Cortex Code is useful. It can work against the same environment your code depends on instead of treating the repo as the whole system.

This post is a field guide for data engineers who want to use Cortex Code every day. It focuses on the commands, prompts, dbt workflows, Airflow patterns, AGENTS.md, and Skills that are worth keeping close at hand.

Start with the right mental model

The point of Cortex Code is not "SQL autocomplete, but fancier."

The point is that it can work against your Snowflake environment, not just the files on disk.

That changes what is possible:

You can ask for tables by business concept instead of object name.
You can ask why a role cannot read an object instead of manually spelunking grants.
You can edit a dbt model, run the smallest safe build, compare dev and prod, and leave behind a validation query.
You can ask for cost and governance answers using account context.
You can package a good workflow as a reusable Skill instead of repeating the same ten-step ritual forever.

If the job depends on Snowflake account state, Cortex Code should be in the loop.

Why Cortex Code is unusually good at data work

There are a few reasons it fits data engineering better than generic coding agents:

It understands Snowflake objects, roles, schemas, and SQL semantics.
It can search Snowflake objects and documentation directly.
It has direct SQL execution instead of forcing you to copy SQL into another tool.
It can work in Snowsight for discovery, admin, and workspace tasks.
It can work in the CLI for local repo work, dbt, git, shell commands, Airflow, Skills, and automation.
It works within Snowflake RBAC and the CLI's approval modes. That matters when your day job includes production data and access boundaries.

The repo-only agents are still valuable. I use them. But for data engineering, repo context is only half the picture.

Get your setup right once

The daily experience gets much better if you spend ten minutes on setup instead of winging it.

Before you start, install the Snowflake CLI (snow). Cortex Code CLI shares the same Snowflake connection setup and ~/.snowflake/connections.toml file. Also make sure you are on a supported platform for Cortex Code CLI per the official docs.

Install the CLI

curl -LsS https://ai.snowflake.com/static/cc-scripts/install.sh | sh

If you are on Windows, use the PowerShell installer from the official docs:

irm https://ai.snowflake.com/static/cc-scripts/install.ps1 | iex

Start it with a specific connection and working directory:

cortex -c dev -w ~/src/analytics

Resume the last session:

cortex --continue

Run a one-off prompt from the shell:

Use -p for quick one-off prompts if your account supports print mode. Subscription and trial accounts block -p / --print, so in those environments you should start cortex -c dev and run the same request interactively.

cortex -c dev -p "List every table tagged PII = TRUE in ANALYTICS_DB"

Enable the right roles and model access

The exact role setup depends on which surface you use:

Cortex Code CLI: start with SNOWFLAKE.CORTEX_USER.
Cortex Code in Snowsight: grant SNOWFLAKE.COPILOT_USER plus SNOWFLAKE.CORTEX_USER or SNOWFLAKE.CORTEX_AGENT_USER.

If you use both, the simplest baseline is COPILOT_USER plus CORTEX_USER.

ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'AWS_US';

GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE DATA_ENGINEER;

-- If you use Cortex Code in Snowsight:
GRANT DATABASE ROLE SNOWFLAKE.COPILOT_USER TO ROLE DATA_ENGINEER;

-- Optional, depending on your org's access model for agentic workflows:
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_AGENT_USER TO ROLE DATA_ENGINEER;

The ALTER ACCOUNT statement must be run by ACCOUNTADMIN. Replace AWS_US with the region setting your account needs. If your organization restricts model access, make sure the required models are allowed and cross-region inference is enabled for the region you actually need.

One extra nuance: some accounts inherit SNOWFLAKE.CORTEX_USER through PUBLIC unless it has been revoked, so do not assume a missing explicit grant always means a missing effective permission.

Create separate connections for dev and prod-readonly

Do this once. Future you will thank you.

~/.snowflake/connections.toml

[dev]
account = "myorg-myaccount"
user = "you@example.com"
authenticator = "externalbrowser"
warehouse = "DEV_WH"
role = "DATA_ENGINEER"
database = "ANALYTICS"
schema = "PUBLIC"

[prod_readonly]
account = "myorg-myaccount"
user = "you@example.com"
authenticator = "externalbrowser"
warehouse = "PROD_WH"
role = "ANALYST"
database = "ANALYTICS"
schema = "PUBLIC"

Now you can be explicit:

cortex -c dev -w ~/src/analytics
cortex -c prod_readonly -w ~/src/analytics

That one habit prevents a surprising amount of nonsense.

Commands worth memorizing

These are the ones I would actually keep handy.

Startup patterns

cortex
cortex -c dev
cortex -c dev -w ~/src/analytics
cortex --continue
cortex --plan
cortex -p "Explain why this query is slow and optimize it"

CLI slash commands that matter for data engineers

These are Cortex Code CLI commands. In Snowsight, / is mainly for built-in and personal skills, not the full CLI slash-command surface.

/plan
/status
/sql
/sh
/conn
/diff
/fdbt
/lineage
/worktree
/skill
/mcp

Airflow commands worth knowing

cortex airflow health
cortex airflow dags list
cortex airflow dags get my_pipeline
cortex airflow dags source my_pipeline
cortex airflow runs trigger my_pipeline
cortex airflow runs list my_pipeline
cortex airflow tasks list my_pipeline <run_id>

Make the CLI fit your team

You do not need a huge amount of local configuration, but a little goes a long way.

~/.snowflake/cortex/settings.json

{
  "defaultViewMode": "compact",
  "autoUpdate": true,
  "theme": "dark"
}

~/.snowflake/cortex/settings.json

{
  "permissions": {
    "defaultMode": "ask",
    "dangerouslyAllowAll": false
  }
}

That keeps the CLI terse and keeps permission prompts on by default. permissions.json is better thought of as the remembered approval cache, not the main place to set those defaults.

If your team wants shared repo behavior, use AGENTS.md for project rules and Skills for repeatable workflows. If your organization wants harder controls, use managed settings instead of relying on everybody to configure the CLI the same way.

Snowsight versus CLI

Use both. They are not competing surfaces.

Surface	Best for
`Cortex Code in Snowsight`	SQL authoring, quick catalog discovery, dbt Projects on Snowflake, permissions questions, governance, FinOps, quick query fixes, `@`-based object context, diff review in Workspaces
`Cortex Code CLI`	local `dbt` repos, local files, `git`, shell commands, validation workflows, Airflow, Skills, `AGENTS.md`, repeatable engineering work

The easy rule is this:

Start in Snowsight when you are exploring.
Switch to the CLI when you need local files, source control, or repeatable workflows.

Daily workflow 1: find the right data faster

This is where Cortex Code immediately feels different from generic coding agents.

You are not asking it to write SQL from a blank prompt. You are asking it to navigate the warehouse with you.

Start with plain English:

Find all tables related to customers that I have write access to.

Then narrow:

List every table tagged PII = TRUE in ANALYTICS_DB and show the owning roles.

Then ask for lineage:

Show the lineage from RAW_DB.ORDERS to downstream dashboards.

In Snowsight, use @ mentions to attach objects directly to the chat context before asking follow-up questions.

Example:

@RAW_DB.ORDERS @ANALYTICS_DB.CUSTOMERS
Explain the likely join path between these objects and tell me which columns you would trust for churn analysis.

If you are in the CLI and want a quick fallback query, use /sql. In the interactive CLI, use Ctrl+J for multi-line SQL.

/sql
SELECT table_catalog, table_schema, table_name
FROM SNOWFLAKE.ACCOUNT_USAGE.TABLES
WHERE deleted IS NULL
  AND (
    table_name ILIKE '%CUSTOMER%'
    OR table_schema ILIKE '%CUSTOMER%'
  )
ORDER BY created DESC;

Generic agents are decent once you hand them the schema. Cortex Code is better when finding the schema is the job.

One caveat: SNOWFLAKE.ACCOUNT_USAGE.TABLES is a convenience fallback, not a universal or real-time discovery surface. It depends on your account visibility into ACCOUNT_USAGE, and those views can lag.

Daily workflow 2: stop guessing about permissions

Permissions bugs waste a ridiculous amount of time because they usually look like code bugs at first.

Useful prompts:

What privileges does my role have on this database?

Why am I getting a permissions error on ANALYTICS_DB.CORE.CUSTOMERS?

Show the grants my current role can see for ANALYTICS_DB.CORE.CUSTOMERS, and tell me what extra visibility I would need for a full access audit.

Find all tables that have PII in them.

This is a good example of where generic coding agents usually stall out. They can explain the idea of RBAC. Cortex Code can help investigate your real Snowflake objects and whatever grants your current role can actually see.

Daily workflow 3: use it as a SQL mechanic, not just a generator

One of the best ways to use Cortex Code is to hand it real SQL that already exists and ask it to make that SQL better.

Explain and optimize a query

What does this SQL script do?

Explain why this query is slow and optimize it without changing semantics.

WITH daily_revenue AS (
  SELECT
    customer_id,
    CAST(order_date AS DATE) AS order_day,
    SUM(amount) AS daily_revenue
  FROM ANALYTICS_DB.MART.ORDERS
  WHERE order_date >= DATEADD(day, -90, CURRENT_DATE())
  GROUP BY 1, 2
)
SELECT
  a.customer_id,
  a.order_day,
  a.daily_revenue,
  (
    SELECT SUM(b.daily_revenue)
    FROM daily_revenue b
    WHERE b.customer_id = a.customer_id
      AND b.order_day BETWEEN DATEADD(day, -6, a.order_day) AND a.order_day
  ) AS rolling_7d_revenue
FROM daily_revenue a
ORDER BY a.customer_id, a.order_day;

Then push further:

Show me the tradeoffs in your rewrite.
If there are multiple good versions, rank them by readability, cost, and likely performance.

In Snowsight, you can also use the built-in fix flow on failed SQL and then ask follow-up questions in the same context.

That matters. Good data work is almost never "write one query." It is "write, inspect, fix, rerun, compare."

Daily workflow 4: work a dbt project end to end

This is where Cortex Code starts earning permanent terminal space.

The strongest pattern is:

Open the repo with Cortex Code in the right working directory.
Ask for a plan.
Make the model change.
Run the narrowest possible dbt selector.
Generate proof, not just code.

Start the session:

cortex -c dev -w ~/src/analytics

Then turn on planning mode:

/plan

Then give it a concrete task:

Update models/marts/fct_customer_revenue.sql to include refunded_amount.
Run the smallest safe dbt build for the affected graph.
If tests fail, fix the model or tests.
Then write a validation query comparing dev and prod totals for the last 30 days.
Save the validation SQL in analysis/refunded_amount_check.sql.

That is a better prompt than "add refunded amount" because it asks for the full workflow, including proof.

Give Cortex Code repo rules with AGENTS.md

This is one of the highest leverage things you can do for dbt.

AGENTS.md

# analytics repo rules

- Always use fully qualified object names in generated SQL unless the model style already abstracts them.
- For changes to marts, metrics, or business logic, generate a validation query in `analysis/`.
- Prefer `TRY_TO_*` functions for raw ingestion cleanup.
- For model changes, start with `dbt build -s "<changed_model>+"` to validate the changed model and downstream dependents. Use `dbt ls -s "+<changed_model>"` when you want to inspect upstream ancestors first.
- Add or update schema tests for every new key, enum, or non-null business field.
- Never use production roles for write operations.
- When a change touches finance metrics, compare dev and prod for at least the last 30 days.

Now Cortex Code has your rules before it starts making changes.

Ask it to reason across model, graph, and warehouse

Good dbt prompts:

Create a new staging model for RAW.CUSTOMERS that handles duplicates, mixed-case email, malformed dates, and empty-string fields.

Analyze this dbt project and identify the smallest set of models I need to run after changing fct_customer_revenue.

Show me the upstream and downstream graph for this model and tell me where a breaking change would hurt the most.

Review the failing dbt tests and tell me whether the bug is in the model, test assumptions, or source data.

Keep shell access in the loop

Sometimes the best pattern is conversational reasoning plus direct shell execution:

/sh dbt build -s "fct_customer_revenue+"

/sh dbt ls -s "+fct_customer_revenue"

/sh dbt docs generate

The first command validates the changed model plus downstream dependents. The second shows upstream ancestry so you can inspect dependencies before you widen the blast radius.

If you want to stay in shell mode for a while, run /sh with no arguments. The CLI switches into terminal mode and treats subsequent input as shell commands until you exit that mode.

If you want lineage help, call it out:

/lineage fct_customer_revenue

Then ask:

Based on the lineage, which models should I validate manually before merging this change?

Daily workflow 5: use Cortex Code to tune slow dbt models

The internal Snowflake examples here are especially strong.

The useful prompt pattern is:

Analyze our dbt project, identify the slowest-running models, suggest specific optimizations, and flag any models that are not used downstream that we could drop.

That can surface things people usually do not revisit once the pipeline "works":

bad materialization choices
unnecessary joins
stale models with no downstream value
incremental models that should not be full-refreshing
models that should probably be split

The best move after a good optimization pass is to turn it into a Skill.

Daily workflow 6: convert one-off work into Skills

This is one of the differentiators that gets overlooked.

If you do the same debugging or optimization dance every week, package it.

For a local repo or CLI workflow, project skills live under .cortex/skills/. In Snowsight Workspaces, personal skills live under .snowflake/cortex/skills in that workspace and are only available there.

Create the directory:

mkdir -p .cortex/skills/dbt-slow-model-audit

Then add SKILL.md:

---
name: dbt-slow-model-audit
description: Find slow dbt models and propose safe optimizations
---

# When to use

- The user wants to reduce runtime or credits in a dbt project.
- The user suspects one or more models are bottlenecks.

# Instructions

1. Identify the slowest models using available dbt artifacts or warehouse history.
2. Inspect materialization strategy, joins, filters, and incremental logic.
3. Flag unused downstream models that may be removable.
4. Propose the smallest set of changes that will improve runtime safely.
5. Generate a validation plan and save findings in `analysis/dbt_slow_model_audit.md`.

This example keeps the frontmatter minimal on purpose. tools: is optional. If you want to lock a Skill to a specific tool set, use the exact tool identifiers from the current Cortex Code docs or a known working Skill repo. Also note that the CLI's custom-skill model is the most fully documented path today. In Snowsight, stick to documented personal skills.

List available Skills:

cortex skill list

Inside a session:

/skill

This is how you turn "that smart thing the agent did once" into a team workflow.

Daily workflow 7: use the built-in Airflow support

If your world includes Airflow, Cortex Code gets more interesting than a generic Python helper.

This assumes you have already configured an Airflow instance for Cortex Code and installed uv, as Snowflake's Using Apache Airflow with Cortex Code CLI docs require.

One implementation detail worth knowing: cortex airflow is a passthrough wrapper around the Airflow helper Snowflake ships with Cortex Code. Treat the examples below as practical command patterns, not as a separately documented native command grammar owned entirely by the main CLI.

Useful commands:

cortex airflow health
cortex airflow dags list
cortex airflow dags get daily_etl
cortex airflow dags source daily_etl
cortex airflow runs trigger daily_etl
cortex airflow runs list daily_etl

Useful prompts:

Why did my_pipeline fail last night?

Create a DAG that extracts from Snowflake and loads to S3 daily.

Set up my dbt project to run in Airflow using Cosmos.

Migrate my DAGs from Airflow 2 to Airflow 3.

This is a good example of Cortex Code's advantage. A generic coding agent can write DAG code. Cortex Code can reason about the DAG, the Airflow instance, and the Snowflake side of the workflow in one place.

Daily workflow 8: use Snowsight when you want fewer tabs

Do not force everything through the CLI.

Snowsight is excellent for the stuff people usually break flow for:

quick SQL authoring
finding the right table or column
fixing failed SQL
checking user and role access
cost and usage questions
iterating on code in Workspaces with diff review

Example prompts that work well in Snowsight:

What databases do I have access to?

Write a query for top 10 customers by revenue and a 7-day moving average.

Which 5 service types are using the most credits? Show me a visualization and how to reduce costs.

Find all tables that have PII in them.

The strongest Snowsight feature for day-to-day engineering work might be the simple one: you stay inside the same environment where you are already writing and running the query.

Where Cortex Code is differentiated for Snowflake-heavy work

This is the part people care about, so here is the blunt version. These are practical workflow comparisons, not vendor benchmarks. What a generic coding agent can do depends heavily on how you have integrated it with shells, databases, MCP servers, and other tools.

When Cortex Code wins

Task	Generic coding agent	Cortex Code advantage
Find the right table when you only know the business concept	Without Snowflake-aware integration, often needs schema pasted in or separate metadata queries	Can search Snowflake objects and docs directly, with tags and lineage surfaced when available
Debug a role or grant problem	Can explain RBAC patterns, but usually needs live Snowflake access to inspect real grants	Can help investigate grants and access questions using your current Snowflake visibility
Tune a query that is slow in your warehouse	Can reason from SQL text, but usually needs Snowflake access wired in for warehouse-specific answers	Can work from Snowflake context, docs, and account-aware patterns
Edit a `dbt` model and prove the change is safe	Good at code edits, but may be blind to live Snowflake state unless you wire queries and tools into the workflow	Can help with SQL, `dbt`, validation queries, and Snowflake-side proof in one workflow
Decide between model patterns on Snowflake	General advice unless it can inspect Snowflake objects and docs	Snowflake-aware guidance for semantic objects, platform behavior, and role-aware execution
Build a data workflow that touches SQL, files, shell, and account state	Works if you integrate shell, DB, and metadata tools; less native out of the box	Native fit for mixed data-engineering workflows
Airflow plus Snowflake debugging	Strong on Python, depends on Airflow and Snowflake integrations for live instance context	Built-in Airflow support plus Snowflake-aware reasoning

The simplest summary still holds:

If the answer depends on your Snowflake account, reach for Cortex Code.
If the answer depends on a large non-Snowflake codebase or frontend stack, a generic coding agent may be a better first tool.

When generic agents still win

Be honest about this. Cortex Code is not the best tool for everything.

Use Cursor, Claude Code, or Codex first when you are doing:

frontend work
framework-heavy app scaffolding
polyglot refactors across large non-Snowflake services
local codebase reasoning where warehouse context does not matter

The happy path for most teams is not replacement. It is pairing.

Use your favorite generic coding agent for repo-wide engineering. Use Cortex Code when the work turns into data engineering instead of pure software engineering.

Safety habits

If you want to use Cortex Code seriously, a few habits go a long way.

Use planning mode on anything non-trivial

/plan

This is especially useful before schema changes, broad dbt runs, and anything that touches production objects.

Keep a readonly prod connection

Do not make the agent safe through vibes. Make it safe through connections and roles.

Review diffs and proposed writes

This sounds obvious, but it is the line between "useful accelerator" and "expensive story."

Put repo rules in `AGENTS.md`

Do not rely on the model to guess your team's validation and rollout standards.

Package sensitive workflows as Skills

That gives you repeatability and makes the steps inspectable.

Avoid routine `ACCOUNTADMIN` use

If you need elevated setup, do it deliberately. Do not turn that into the default development posture.

A prompt pack worth stealing

These are the prompts I would actually keep around.

Discovery and governance

Find all tables related to customers that I have write access to.

List every table tagged PII = TRUE in ANALYTICS_DB and show the owning roles.

Show the lineage from RAW_DB.ORDERS to downstream dashboards.

Why am I getting a permissions error on ANALYTICS_DB.CORE.CUSTOMERS?

SQL and performance

What does this SQL script do?

Explain why this query is slow and optimize it without changing semantics.

Write a query for top 10 customers by revenue and add a 7-day moving average.

dbt

Create a staging model for RAW.CUSTOMERS that handles duplicates, malformed dates, empty strings, and mixed-case emails.

Update models/marts/fct_customer_revenue.sql to include refunded_amount, run the smallest safe dbt selector, and generate a dev-versus-prod validation query.

Analyze this dbt project, identify the slowest-running models, and suggest the smallest safe changes to reduce runtime and credits.

Airflow

Why did my_pipeline fail last night?

Create a DAG that extracts from Snowflake and loads to S3 daily.

Set up my dbt project to run in Airflow using Cosmos.

Skills and repeatability

In a local repo, turn this repeated optimization workflow into a Skill and save it in .cortex/skills/dbt-slow-model-audit.

The real differentiator

The best way to think about Cortex Code is is better workflow compression for data work.

That is what shows up again and again in the strong use cases:

dbt changes plus tests plus validation
schema discovery plus lineage plus governance
query tuning plus account context
Airflow plus Snowflake debugging
repeated workflows converted into Skills

That is why it feels different from a repo-only agent. It is not just helping you write the step you are on. It is helping you get through the whole chain without losing context.

If you are a data engineer, that is the part worth caring about.

[DYK with Dash] Want a policy enforcement layer over your AI coding assistant?

Dash — Thu, 26 Mar 2026 00:51:02 +0000

🙌 Snowflake Cortex Code CLI has a programmable hooks system that fires on 11 lifecycle events -- PreToolUse, PostToolUse, SessionStart, Stop, and more. You write a shell script, and if it returns exit code 2, the operation is HARD BLOCKED.

↳ Validate every bash command before it runs
↳ Block writes to protected files
↳ Log every tool call for audit
↳ Inject context at session start

This is guardrails-as-code for AI-assisted development.

Share this with your platform team -- they need to see this 👇

📖 Get started: https://www.snowflake.com/en/developers/guides/getting-started-with-cortex-code-cli/

Let's learn together!

[DYK with Dash] Build your own AI sub-agents with... Markdown?!

Dash — Tue, 24 Mar 2026 14:23:17 +0000

🙌 Drop a Markdown file with YAML frontmatter into .cortex/agents/ and Snowflake Cortex Code turns it into a fully functional specialized sub-agent with scoped tool access.

↳ Define a code-reviewer agent that only has Read access
↳ Create a migration-checker with Bash + SQL
↳ Share them with your team through version control

That's it. Your team's best practices, encoded as agents.

What custom agent would you build? 👇

📖 Get started: https://docs.snowflake.com/en/user-guide/cortex-code/cortex-code-cli

Let's learn together!

CortexCode #Snowflake #AI #Developers #DataEngineering #DevTools

Data governance just became a conversation, not a workflow.

Dash — Fri, 20 Mar 2026 14:22:04 +0000

🤔 If you've ever tried to get a full picture of your governance posture, you know the drill -- run classification in one place, write masking policies
somewhere else, dig through access history six months ago, and still not really know what's covered.

🙌 We built something to fix that. Data Governance Skills for Snowflake Cortex Code let you govern your data by just... asking.

"What's my governance maturity score?" gives you a 0-5 score across classification, protection, and access monitoring. Per database. With the actual gaps called out.

🤯 The thing I like most -- these aren't generic AI prompts hoping the SQL is right. There are 100+ verified query patterns under the hood, built
specifically for governance views.

Classification, masking, row access policies, data quality via DMFs, lineage with impact analysis -- all in natural language, all native to Snowflake Horizon Catalog. No external catalog to sync. No metadata that's hours behind.

A data steward can now do in one conversation what used to be a sprint across multiple teams!

Available now in Cortex Code CLI. Check it out and let me know what you think: https://docs.snowflake.com/en/user-guide/cortex-code/cortex-code-cli

[DYK with Dash] Git branching... but for AI conversations?!

Dash — Thu, 19 Mar 2026 14:13:18 +0000

🤯 Type '/fork' mid-conversation in Snowflake Cortex Code and it creates a branch of your session at any point you choose. Try a risky refactor, explore a wild idea -- and if it goes sideways, your original session is still right there waiting for you.

↳ '/fork' -- branch from any message
↳ '/fork my-experiment' -- name it for easy recall
↳ '/rewind 3' -- or just roll back 3 messages

This is git-branch thinking applied to your AI workflow. Experiment fearlessly!

Try it: '/fork' your next risky experiment and tell me what you explored 👇

Get started: https://docs.snowflake.com/en/user-guide/cortex-code/cortex-code-cli

Let's learn together!

CortexCode #Snowflake #AI #Developers #DataEngineering #Productivity

[DYK with Dash] Cortex Code has a secret weapon most people walk right past!

Dash — Thu, 19 Mar 2026 00:34:54 +0000

❄️ Type #DB.SCHEMA.TABLE directly in your Snowflake Cortex Code prompt and BOOM -- it auto-injects the full column metadata, primary keys, row count, and sample rows into context. No more copy-pasting DESCRIBE output. No more guessing column names.

👉 Just prefix any fully-qualified table name with # and the agent instantly knows your schema
👉 Autocomplete kicks in after you type #
👉 Works with any table in your Snowflake account

Stop manually feeding context. Let the CLI do it for you!

Try this right now: type # and pick a table -- then drop your result in the comments 👇

📖 Docs: https://docs.snowflake.com/en/user-guide/cortex-code/cortex-code-cli

DEV Community: Snowflake

I built a remote control for Cortex Code in Slack so I can step away from my laptop

Snowflake Cortex Code CLI Meets Slack

What It Actually Does

Key Design Decisions

The Code

1) config.py: Configuration and Session Management

2) bridge.py: The Socket Mode Bot

3) notify.py: Sending Messages

4) bin/coco-bridge: The Shell Wrapper

Why This Works

The Hook System

Setting It Up

Prerequisites

Create the Slack App

Install the Bridge

Install Cortex Code CLI Skill

Configure Tokens

Start and Test

Wire Up the SessionStart Hook

The Beauty of Extensibility

Stay Connected

Hot off the press -- Snowflake Cortex Code in Snowsight is now GA!

The data engineer's Cortex Code cheat sheet

Start with the right mental model

Why Cortex Code is unusually good at data work

Get your setup right once

Install the CLI

Enable the right roles and model access

Create separate connections for dev and prod-readonly

Commands worth memorizing

Startup patterns

CLI slash commands that matter for data engineers

Airflow commands worth knowing

Make the CLI fit your team

Snowsight versus CLI

Daily workflow 1: find the right data faster

Daily workflow 2: stop guessing about permissions

Daily workflow 3: use it as a SQL mechanic, not just a generator

Explain and optimize a query

Daily workflow 4: work a dbt project end to end

Give Cortex Code repo rules with AGENTS.md

Ask it to reason across model, graph, and warehouse

Keep shell access in the loop

Daily workflow 5: use Cortex Code to tune slow dbt models

Daily workflow 6: convert one-off work into Skills

Daily workflow 7: use the built-in Airflow support

Daily workflow 8: use Snowsight when you want fewer tabs

Where Cortex Code is differentiated for Snowflake-heavy work

When Cortex Code wins

When generic agents still win

Safety habits

Use planning mode on anything non-trivial

Keep a readonly prod connection

Review diffs and proposed writes

Put repo rules in AGENTS.md

Package sensitive workflows as Skills

Avoid routine ACCOUNTADMIN use

A prompt pack worth stealing

Discovery and governance

SQL and performance

dbt

Airflow

Skills and repeatability

The real differentiator

Further reading

[DYK with Dash] Want a policy enforcement layer over your AI coding assistant?

[DYK with Dash] Build your own AI sub-agents with... Markdown?!

CortexCode #Snowflake #AI #Developers #DataEngineering #DevTools

Data governance just became a conversation, not a workflow.

[DYK with Dash] Git branching... but for AI conversations?!

CortexCode #Snowflake #AI #Developers #DataEngineering #Productivity

[DYK with Dash] Cortex Code has a secret weapon most people walk right past!

Put repo rules in `AGENTS.md`

Avoid routine `ACCOUNTADMIN` use