Skill: Connect to Live Snowflake
SkillDatabases & dataQuery the live/remote Snowflake warehouse instead of the local practice copy. Use when the user says "connect to snowflake", "use the live data", "go remote", "query the warehouse", or asks "is this hitting snowflake or duckdb?". Assumes credentials already exist (first-time setup is /setup-snowflake); opts into remote via ConnectionManager and verifies the connection type before any query runs.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Skill: Connect to Live Snowflake skill
What this skill tells your AI
The instructions your AI receives, as published by ai-analyst-lab/ai-analyst in .claude/skills/connect-snowflake/SKILL.md and read by ahel’s review.
Purpose
Run queries against the live Snowflake warehouse — not the local DuckDB practice copy. This is the runbook for "actually go remote." Credentials and config already exist; this skill is about opting into remote and verifying you landed there.
This is distinct from /setup-snowflake (the first-time wizard that collects the
connection fields, writes the password to .env, and verifies the native
ConnectionManager session). Use this skill when the
warehouse is already configured and you just want to query the live data through
ConnectionManager.
When to Use
Trigger on any request to use the live/remote Snowflake data, e.g.:
- "connect to snowflake", "query snowflake", "use the live data / live warehouse"
- "run this against snowflake / the real data / production", "go remote"
- "is this hitting snowflake or duckdb?", "query the live tables"
- Any analysis where the user explicitly wants live warehouse numbers rather than the local DuckDB practice snapshot
How the repo decides local vs. remote
detect_active_source() (in helpers/data/data_helpers.py) defaults to the local
DuckDB copy even though the active dataset declares
connection_type: snowflake. It only goes remote when you opt in, via either:
- Env flag (per-shell):
AAP_USE_REMOTE=1(also acceptstrue/yes), OR - Persisted flag:
use_remote: truein.knowledge/active.yaml
Set use_remote: true in .knowledge/active.yaml for a persistent opt-in, and set
AAP_USE_REMOTE=1 in the same shell command as python3 as a belt-and-suspenders guard.
To confirm you actually landed on the warehouse (not the local fallback), call
ConnectionManager.verify_remote(): it returns {"remote": bool, "identity": {account, warehouse, database, schema, version}, "reason": ...} from Snowflake's own session context functions. Treat
remote: False as "you are NOT on Snowflake" and fix the reason before querying.
Instructions
Step 1 — Run through ConnectionManager with remote opted in
ConnectionManager auto-loads .env, expands the $SNOWFLAKE_* placeholders
from the manifest, and lazy-connects. The export must be in the same Bash
call as the python3 — shell env does not persist between separate tool calls.
export AAP_USE_REMOTE=1 && python3 -W ignore -c "
import warnings; warnings.filterwarnings('ignore')
from helpers.data.connection_manager import ConnectionManager
mgr = ConnectionManager()
print('backend:', mgr.connection_type) # MUST print 'snowflake'
df = mgr.query('SELECT event_type, COUNT(*) n FROM events GROUP BY event_type ORDER BY n DESC')
print(df.to_string(index=False))
mgr.close()
"
Tables are unqualified in your configured schema (e.g. events, orders,
sessions, users, promotions, products). Use Snowflake dialect:
DATE_TRUNC('month', col), etc. — or get_dialect("snowflake") from
helpers/data/sql_dialect.py.
Step 2 — Verify you're actually on Snowflake (not the DuckDB fallback)
Before trusting any number, confirm:
mgr.connection_typereturnssnowflake(if it printsduckdb, the opt-in didn't take — re-check thatexport AAP_USE_REMOTE=1ran in the same command).- A
SELECT CURRENT_ACCOUNT(), CURRENT_WAREHOUSE(), CURRENT_DATABASE(), CURRENT_SCHEMA()returns the account, warehouse, database, and schema from your own connection config (.env/connection_templates/) — compare against what you expect, never assume.
Always tell the user which source is live.
Step 3 — Log every query
ConnectionManager.query() auto-logs at execution by default — that covers
the requirement. If you query some other way (raw connector, MCP), log manually:
python3 scripts/log_query.py --dataset {active} --agent ad-hoc \
--purpose "..." --sql "..." --result "..."
Gotchas
export AAP_USE_REMOTE=1and thepython3call must share one Bash command (&&), or the flag is lost and you silently get DuckDB.- Read
.knowledge/datasets/{active}/quirks.mdbefore trusting edge columns. - Ignore the LibreSSL / urllib3 / NotOpenSSL warnings — harmless. Suppress with
-W ignore+warnings.filterwarnings('ignore')as shown. - Requires
snowflake-connector-python(pip install -e ".[warehouses]"; see the /setup-snowflake prerequisite). - The password lives in
.envasSNOWFLAKE_PASSWORD; account, user, warehouse, database, schema, and role live in the dataset manifest. Never echo or cat.env.
To go back to local DuckDB
Unset the opt-in: unset AAP_USE_REMOTE for the shell, and/or set
use_remote: false in .knowledge/active.yaml. connection_type will then
report duckdb.
Signals
- GitHub stars
- 297
- Forks
- 137
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
connect-snowflake- Source
- github.com/ai-analyst-lab/ai-analyst