
Snowflake Semanticview
Author, alter, and CLI-validate Snowflake semantic views on a star schema so analysts and agents query a governed semantic layer.
Overview
Snowflake Semantic View is an agent skill most often used in Build (also Operate) that creates, alters, and CLI-validates Snowflake semantic views on star-schema models.
Install
npx skills add https://github.com/github/awesome-copilot --skill snowflake-semanticviewWhat is this skill?
- One-time setup: verify `snow --help`, install Snowflake CLI if missing, add connection via `snow connection add`
- Per-request workflow: confirm database, schema, role, warehouse, view name, and star-schema shape
- Drafts CREATE/ALTER SEMANTIC VIEW DDL aligned to official Snowflake syntax docs
- Populates synonyms and comments on dimensions, facts, and metrics—preferring Snowflake object comments as source
- Validates semantic-view DDL through the CLI against the configured connection
- 5-step per-request workflow from target confirmation through DDL validation
Adoption & trust: 8.8k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need a governed semantic layer in Snowflake but semantic view DDL, synonyms, and CLI validation steps are easy to get wrong solo.
Who is it for?
Indie builders wiring Snowflake analytics who already use or can install Snowflake CLI and model data as facts plus conformed dimensions.
Skip if: Teams without Snowflake access, non-star-schema dumps, or workflows that only need generic SQL views with no semantic layer.
When should I use this skill?
Create, alter, and validate Snowflake semantic views using Snowflake CLI (snow); build or troubleshoot semantic layer definitions with CREATE/ALTER SEMANTIC VIEW; validate DDL via CLI; guide CLI install and connection se
What do I get? / Deliverables
You leave with connection-ready semantic view DDL, enriched metadata on metrics and dimensions, and CLI-validated definitions ready to deploy.
- CREATE or ALTER SEMANTIC VIEW DDL with dimensions, facts, and metrics
- Synonyms and comments populated for semantic objects
- CLI-validated semantic view definition against the target account
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build → integrations because the workflow centers on Snowflake CLI DDL against warehouse objects, not day-two incident response. Semantic views connect facts and conformed dimensions—integration work between raw tables and a consumable metrics layer.
Where it fits
You add a semantic view over orders and customers so your in-app analytics agent queries named metrics, not ad-hoc joins.
Backend exposes consistent revenue metrics—you ALTER SEMANTIC VIEW after new fact columns ship.
Production metrics look wrong—you re-validate semantic view DDL and synonyms against Snowflake via CLI.
How it compares
Skill-guided Snowflake semantic layer DDL and CLI validation—not a hosted BI product or dbt-only modeling workflow.
Common Questions / FAQ
Who is snowflake-semanticview for?
Solo builders and small teams exposing metrics through Snowflake semantic views who want agent help with DDL, metadata, and CLI checks.
When should I use snowflake-semanticview?
In Build integrations when standing up or changing semantic views; in Operate infra when troubleshooting semantic layer DDL against a live Snowflake connection.
Is snowflake-semanticview safe to install?
The skill drives CLI commands against your Snowflake account—use least-privilege roles, rotate credentials carefully, and review the Security Audits panel on this page.
SKILL.md
READMESKILL.md - Snowflake Semanticview
# Snowflake Semantic Views ## One-Time Setup - Verify Snowflake CLI installation by opening a new terminal and running `snow --help`. - If Snowflake CLI is missing or the user cannot install it, direct them to https://docs.snowflake.com/en/developer-guide/snowflake-cli/installation/installation. - Configure a Snowflake connection with `snow connection add` per https://docs.snowflake.com/en/developer-guide/snowflake-cli/connecting/configure-connections#add-a-connection. - Use the configured connection for all validation and execution steps. ## Workflow For Each Semantic View Request 1. Confirm the target database, schema, role, warehouse, and final semantic view name. 2. Confirm the model follows a star schema (facts with conformed dimensions). 3. Draft the semantic view DDL using the official syntax: - https://docs.snowflake.com/en/sql-reference/sql/create-semantic-view 4. Populate synonyms and comments for each dimension, fact, and metric: - Read Snowflake table/view/column comments first (preferred source): - https://docs.snowflake.com/en/sql-reference/sql/comment - If comments or synonyms are missing, ask whether you can create them, whether the user wants to provide text, or whether you should draft suggestions for approval. 5. Use SELECT statements with DISTINCT and LIMIT (maximum 1000 rows) to discover relationships between fact and dimension tables, identify column data types, and create more meaningful comments and synonyms for columns. 6. Create a temporary validation name (for example, append `__tmp_validate`) while keeping the same database and schema. 7. Always validate by sending the DDL to Snowflake via Snowflake CLI before finalizing: - Use `snow sql` to execute the statement with the configured connection. - If flags differ by version, check `snow sql --help` and use the connection option shown there. 8. If validation fails, iterate on the DDL and re-run the validation step until it succeeds. 9. Apply the final DDL (create or alter) using the real semantic view name. 10. Run a sample query against the final semantic view to confirm it works as expected. It has a different SQL syntax as can be seen here: https://docs.snowflake.com/en/user-guide/views-semantic/querying#querying-a-semantic-view Example: ```SQL SELECT * FROM SEMANTIC_VIEW( my_semview_name DIMENSIONS customer.customer_market_segment METRICS orders.order_average_value ) ORDER BY customer_market_segment; ``` 11. Clean up any temporary semantic view created during validation. ## Synonyms And Comments (Required) - Use the semantic view syntax for synonyms and comments: ``` WITH SYNONYMS [ = ] ( 'synonym' [ , ... ] ) COMMENT = 'comment_about_dim_fact_or_metric' ``` - Treat synonyms as informational only; do not use them to reference dimensions, facts, or metrics elsewhere. - Use Snowflake comments as the preferred and first source for synonyms and comments: - https://docs.snowflake.com/en/sql-reference/sql/comment - If Snowflake comments are missing, ask whether you can create them, whether the user wants to provide text, or whether you should draft suggestions for approval. - Do not invent synonyms or comments without user approval. ## Validation Pattern (Required) - Never skip validation. Always execute the DDL against Snowflake with Snowflake CLI before presenting it as final. - Prefer a temporary name for validation to avoid clobbering the real view. ## Example CLI Validation (Template) ```bash # Replace placeholders with real values. snow sql -q "<CREATE OR ALTER SEMANTIC VIEW ...>" --connection <connection_name> ``` If the CLI uses a differen