snowflake-cli_skill

This skill helps you run SQL, deploy apps, and automate Snowflake operations with the snow CLI across environments and stages.
  • Python

26

GitHub Stars

2

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill sfc-gh-dflippo/snowflake-dbt-demo --skill snowflake-cli

  • SKILL.md13.0 KB
  • STAGE_OPERATIONS.md8.8 KB

Overview

This skill wraps the Snowflake CLI (snow) to execute SQL, manage Snowflake objects, deploy Streamlit and Snowpark apps, and orchestrate data pipeline tasks from the command line. It focuses on reliable connection handling, variable templating, stage operations, and CI/CD automation patterns. Use it to run scripts, deploy apps, manage stages, and embed Snowflake operations into automation workflows.

How this skill works

The skill issues snow commands using a named connection profile (default from ~/.snowflake/connections.toml unless overridden with -c). It supports three variable systems: bash (${VAR}), standard CLI templates (<% var %>) and Jinja ({{ var }}), with stage execution defaulting to Jinja. Typical flows include snow sql for inline or heredoc SQL, snow stage for file operations and staged execution, snow streamlit for app deployments, and snow snowpark for building/deploying UDFs and procedures.

When to use it

  • Run ad hoc or scripted SQL from CI/CD or local shells
  • Deploy Streamlit apps or Snowpark objects to Snowflake
  • Upload, list, download, or execute files from Snowflake stages
  • Manage warehouses, tables, roles, and other Snowflake objects via CLI
  • Automate multi-environment deployments using bash variables and templating

Best practices

  • Keep connection profiles in ~/.snowflake/connections.toml and use -c to select environment
  • Use bash variables for environment and file paths, <% %> for inline SQL, and {{ }} for staged SQL files
  • Prefer heredoc (snow sql -i <<EOF) for multi-statement scripts to avoid quoting issues
  • Quote string variable values with -D name="'value'" to preserve literal strings
  • Test commands locally before placing them into CI/CD pipelines and handle permission grants explicitly

Example use cases

  • Run a multi-statement migration with heredoc and environment-specific DB/schema values
  • Deploy a Streamlit app: snow streamlit deploy --replace -c default and retrieve URL with snow streamlit get-url
  • Upload ETL scripts to a stage and execute them with snow stage execute @my_stage/script.sql -D db=PROD_DB
  • Build and deploy Snowpark procedures from a project: snow snowpark build && snow snowpark deploy --replace -c default
  • List or describe objects during audits: snow object list table -c default or snow object describe table my_table -c default

FAQ

Use bash (${VAR}) for environment and shell-level values, <% var %> for inline snow sql commands, and {{ var }} for SQL files executed from stages. Enable Jinja explicitly with --enable-templating JINJA when needed.

Why does a variable appear literally in my SQL?

Check that you used the template syntax that matches the command (snow sql uses <% %> by default, stage execute uses Jinja). Ensure -D flags are provided and templating isn’t disabled.

How do I run multi-statement scripts without escaping quotes?

Use heredoc with snow sql -i <<EOF so the shell expands bash variables before sending SQL; use <% %> or {{ }} inside as appropriate for CLI templating.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational