Agent skill

Modeler

by sidequery in sidequery/sidemantic

Build, validate, and manage semantic models using Sidemantic.

Apache-2.0Auto-check passedDatabases

Install Modeler

skills CLI
$ npx skills add sidequery/sidemantic --skill modeler -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install sidequery/sidemantic modeler --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/sidequery/sidemantic.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/sidemantic/skills/modeler .claude/skills/modeler && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
modeler
GitHub stars
129
Token cost
~4.2k tokens
SKILL.md length
1,269 words
Files
6 (incl. references)
Skills in repo
3
Repo updated
First seen
Licence
Apache-2.0

At a glance

Build, validate, and manage semantic models using Sidemantic.

  • Works in 7 steps: Analyze the database schema → Create Model definitions → Define Dimensions → …
  • Asked to create a semantic layer
  • SKILL.md covers Quick Start, Generate Models from SQL Queries, Core Workflow and Segments, plus 7 more sections
  • Calls uv

What it does

Modeler is an agent skill from sidequery/sidemantic. Build, validate, and manage semantic models using Sidemantic. Use when asked to create a semantic layer, define metrics/dimensions, model a database schema, generate models from SQL queries, import from Cube/dbt/LookML, or set up analytics definitions. Prioritizes CLI-first workflows, with YAML and optional Python API usage for advanced automation.

Its SKILL.md is about 4.2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 6 other files, including reference files (for example `references/generation.md`, `references/migration.md` and `references/patterns.md`).

It sits in Databases, covering SQL, Data pipelines and ETL and Database schema design. It works with SQL, Python, dbt and DuckDB. The repository describes itself as: The universal metrics layer. Compatible with 15+ formats: Cube, MetricFlow, LookML, Omni, BSL, LDM, Cortex, Malloy, OSI, SML, TML, Hex, Rill, Superset. The licence is Apache-2.0.

When your agent uses it

  • Asked to create a semantic layer
  • Define metrics/dimensions
  • Model a database schema
  • Generate models from SQL queries

Example prompts

  • “/modeler”

Requirements

  • Python 3

Workflow steps

7 steps, taken from the step headings in SKILL.md.

  1. Analyze the database schema
  2. Create Model definitions
  3. Define Dimensions
  4. Define Metrics
  5. Define Relationships
  6. Validate and inspect
  7. Test with queries

What it can do on your machine

Read from SKILL.md and the folder at commit db203eb. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • uv

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use uv, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Modeler loads about 4.2k tokens when it runs, and up to ~21k if it reads all its reference files. Until then it costs about 90 tokens; SKILL.md has 1,269 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~90
When it runs · the whole SKILL.md, loaded when a task matches
~4.2k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~21k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from sidequery/sidemantic at commit db203eb, republished under its Apache-2.0 licence (© sidequery). 1,269 words, ~4,230 tokens.

Download SKILL.mdSave it as .claude/skills/modeler/SKILL.md (or your agent's skills folder). This skill also uses 5 other files; get the full folder from GitHub.
name
modeler
description
Build, validate, and manage semantic models using Sidemantic. Use when asked to create a semantic layer, define metrics/dimensions, model a database schema, generate models from SQL queries, import from Cube/dbt/LookML, or set up analytics definitions. Prioritizes CLI-first workflows, with YAML and optional Python API usage for advanced automation.
license
Apache-2.0
metadata.author
sidemantic
metadata.version
1.0

Sidemantic Modeler

Build semantic layers that map physical database tables to business-friendly dimensions and metrics. Sidemantic generates SQL from these definitions, handling joins, aggregations, granularity, and dialect differences automatically.

Quick Start

2-Minute First Success (CLI-first onboarding path)
bash
uv add sidemantic duckdb

mkdir -p models

cat > models/orders.yml <<'YAML'
models:
  - name: orders
    table: orders
    primary_key: order_id
    dimensions:
      - name: status
        type: categorical
    metrics:
      - name: revenue
        agg: sum
        sql: order_amount
      - name: order_count
        agg: count
YAML

uv run sidemantic validate models/ --verbose
uv run sidemantic info models/
uv run sidemantic query \
  "SELECT revenue, status FROM orders ORDER BY revenue DESC LIMIT 5" \
  --models models/ --connection duckdb:///data.duckdb --format json

Assumes an orders table already exists in data.duckdb with status and order_amount columns. Use --format json or --format jsonl when consuming CLI results in automation; use --plain for stable tab-separated text. Primary data is stdout and status is stderr, so do not merge the streams before parsing.

YAML (preferred for file-based models)
yaml
models:
  - name: orders
    table: orders
    primary_key: order_id
    dimensions:
      - name: status
        type: categorical
      - name: order_date
        type: time
        sql: created_at
        granularity: day
    metrics:
      - name: revenue
        agg: sum
        sql: order_amount
      - name: order_count
        agg: count

Load and query:

python
from sidemantic import SemanticLayer

layer = SemanticLayer.from_yaml("models.yml", connection="duckdb:///data.duckdb")
result = layer.sql("SELECT revenue, status FROM orders")
Python API (advanced, optional)
python
from sidemantic import Model, Dimension, Metric, SemanticLayer

layer = SemanticLayer(connection="duckdb:///data.duckdb")
Model(
    name="orders",
    table="orders",
    primary_key="order_id",
    dimensions=[
        Dimension(name="status", type="categorical"),
        Dimension(name="order_date", type="time", sql="created_at", granularity="day"),
    ],
    metrics=[
        Metric(name="revenue", agg="sum", sql="order_amount"),
        Metric(name="order_count", agg="count"),
    ],
)
result = layer.sql("SELECT revenue, status FROM orders")

Generate Models from SQL Queries

The fastest path when existing queries are available. The Migrator reverse-engineers semantic models by analyzing SQL: it extracts tables, columns, aggregations, joins, time dimensions, derived metrics, and window functions automatically.

CLI (bootstrap from a folder of .sql files)
bash
# Generate model YAML + rewritten queries from raw SQL
sidemantic migrate generate queries/ --output output/

# Check coverage: how well do existing models handle these queries?
sidemantic migrate check queries/ --models models/ --verbose
Python API (advanced/automation only)
python
from sidemantic import SemanticLayer
from sidemantic.core.migrator import Migrator

# Connect to your database (optional but improves inference via information_schema)
layer = SemanticLayer(connection="duckdb:///data.duckdb", auto_register=False)
migrator = Migrator(layer, connection=layer.conn)

# Feed it SQL queries (strings, not files)
queries = [
    "SELECT status, SUM(amount) AS revenue, COUNT(*) AS orders FROM orders GROUP BY status",
    "SELECT DATE_TRUNC('month', created_at), SUM(amount) FROM orders GROUP BY 1",
    "SELECT c.region, SUM(o.amount) / COUNT(DISTINCT c.id) AS rev_per_customer "
    "FROM orders o JOIN customers c ON o.customer_id = c.id GROUP BY 1",
]

report = migrator.analyze_queries(queries)
models = migrator.generate_models(report)          # YAML-ready model dicts
graph_metrics = migrator.generate_graph_metrics(report, models)  # cross-model metrics
rewritten = migrator.generate_rewritten_queries(report)          # semantic SQL

# Write to disk
migrator.write_model_files(models, "output/models/")
migrator.write_rewritten_queries(rewritten, "output/rewritten_queries/")

# Print coverage report
migrator.print_report(report, verbose=True)
What the Migrator auto-detects
Pattern in SQLWhat it generates
SUM(amount) / COUNT(*) / AVG(price)Metric with matching agg
COUNT(DISTINCT user_id)Metric with agg: count_distinct
SUM(amount) AS revenueMetric named revenue (preserves aliases)
GROUP BY statusDimension type: categorical
DATE_TRUNC('month', created_at)Dimension type: time, granularity extracted from SQL (here: month)
JOIN customers ON o.customer_id = c.idRelationship many_to_one, foreign_key: customer_id
SUM(a) / NULLIF(COUNT(b), 0)Derived metric with formula
SUM(x) OVER (ORDER BY date ROWS ...)Cumulative metric with window
SUM(x) OVER (PARTITION BY DATE_TRUNC(...))Cumulative metric with grain_to_date
Cross-model expressionsGraph-level derived metrics
Workflow: queries first, then refine
  1. Collect existing SQL queries (dashboards, reports, ad-hoc analyses)
  2. Run migrator.analyze_queries(queries) to generate a first pass
  3. Review generated models: rename metrics, add descriptions, fix types
  4. Run coverage check to verify queries can be rewritten through the semantic layer
  5. Iterate until coverage is high

For the full Migrator API (all methods, outputs, edge cases), load references/generation.md.

Core Workflow

Follow these steps when building a semantic model from a database schema.

Step 1: Analyze the database schema

Inspect tables, columns, data types, and foreign key relationships. Identify which tables hold transactional/event data (fact tables) and which hold descriptive attributes (dimension tables).

Step 2: Create Model definitions

For each table, create a Model with:

  • name: a short, snake_case identifier
  • table: schema-qualified table name (e.g., public.orders)
  • primary_key: the table's primary key column (default: id)

Use sql instead of table for derived/virtual tables built from a SQL expression.

Step 3: Define Dimensions

Add dimensions for columns used in GROUP BY or WHERE clauses. Choose the correct type:

TypeWhen to useExample
categoricalStrings, enums, IDs for groupingstatus, region
timeDates/timestamps (enables granularity)created_at, order_date
booleanComputed true/false from SQL expressionsql: "amount > 100"
numericNumbers used for grouping, not aggregationquantity_bucket

Time dimensions require granularity (one of: second, minute, hour, day, week, month, quarter, year). Queries use double-underscore syntax: orders.order_date__month.

Use sql when the dimension maps to a different column name or a computed expression. If omitted, defaults to a column matching name.

Set parent on dimensions to create drill-down hierarchies (e.g., country > state > city).

Step 4: Define Metrics

Add metrics for columns that should be aggregated.

Simple aggregations (model-level):

aggSQL generatedNotes
sumSUM(col)Revenue, quantities
countCOUNT(*)Row counts (no sql needed)
count_distinctCOUNT(DISTINCT col)Unique values
avgAVG(col)Averages
min / maxMIN(col) / MAX(col)Extremes
medianMEDIAN(col)Median

Model-level simple metrics currently validate against: sum, count, count_distinct, avg, min, max, median.

Use filters on a metric to create filtered aggregations (e.g., filters: ["status = 'completed'"]). These become CASE WHEN expressions, not WHERE clauses.

Complex metrics (usually graph-level, in top-level metrics: section):

typePurposeRequired fields
ratioDivision of two measuresnumerator, denominator
derivedArbitrary SQL formulasql (references other metrics)
cumulativeRolling/running totalssql, optional window or grain_to_date
time_comparisonPeriod-over-periodbase_metric, comparison_type (yoy/mom/wow/dod/qoq)
conversionFunnel analysisentity, base_event, conversion_event

Graph-level metrics sit in the top-level metrics: section (outside models:). They reference model-level measures using model.metric syntax.

Step 5: Define Relationships

Connect models with relationships so Sidemantic can auto-generate JOINs.

TypeDirectionExample
many_to_oneThis model has FK to otherorders -> customers
one_to_oneUnique FKuser -> user_profile
one_to_manyOther model has FK to thiscustomer -> orders
many_to_manyThrough junction tablestudents <-> courses

Declare relationships on the model that owns the foreign key. For many_to_one, foreign_key defaults to {related_model}_id.

For many_to_many, specify through (junction model), through_foreign_key, and related_foreign_key.

Step 6: Validate and inspect
bash
# Validate definitions (checks for errors and warnings)
sidemantic validate models/ --verbose

# Quick summary of what's defined
sidemantic info models/
Step 7: Test with queries
bash
# Validate and inspect without writing code
uv run sidemantic validate models/ --verbose
uv run sidemantic info models/

# Execute semantic SQL through CLI
uv run sidemantic query \
  "SELECT revenue, status FROM orders WHERE status = 'completed'" \
  --models models/ --connection duckdb:///data.duckdb

Python API (optional):

python
# Structured query API
result = layer.query(
    metrics=["orders.revenue"],
    dimensions=["orders.status", "orders.order_date__month"],
    filters=["orders.status = 'completed'"],
    order_by=["orders.revenue DESC"],
    limit=10,
)

# SQL interface (auto-rewrites through semantic layer)
result = layer.sql("SELECT revenue, status FROM orders WHERE status = 'completed'")

# Compile to SQL without executing
sql = layer.compile(metrics=["orders.revenue"], dimensions=["customers.region"])

Segments

Reusable named WHERE filters applied at query time. Unlike metric filters, segments affect all metrics in the query.

yaml
models:
  - name: orders
    table: orders
    segments:
      - name: completed_orders
        sql: "status = 'completed'"
      - name: us_only
        sql: "{model}.region = 'US'"

Segments are model-scoped and used as model.segment references at query time:

bash
uv run sidemantic query \
  "SELECT revenue, status FROM orders WHERE completed_orders" \
  --models models/ --connection duckdb:///data.duckdb

Python API (optional):

python
result = layer.query(
    metrics=["orders.revenue"],
    dimensions=["orders.status"],
    segments=["orders.completed_orders"],
)
Show full SKILL.md (518 more words)Show less

Loading from Other Formats

CLI-first:

bash
uv run sidemantic info path/to/models/
uv run sidemantic validate path/to/models/ --verbose

Python API (optional):

python
from sidemantic import SemanticLayer, load_from_directory

layer = SemanticLayer(connection="duckdb:///data.duckdb")
load_from_directory(layer, "path/to/models/")

Auto-detects: Cube (.yml with cubes:), dbt MetricFlow (.yml with semantic_models:), LookML (.lkml), Malloy (.malloy), Rill, Hex, Snowflake Cortex, and more.

For detailed field mappings from each format, load references/migration.md.

Auto-Registration

When SemanticLayer() is created with auto_register=True (the default), it sets itself as the "current layer." Any Model() or Metric() constructed while a layer is active auto-registers with it. This is why the Quick Start examples don't call layer.add_model().

If you create Models before creating a SemanticLayer, they won't be registered. Either create the layer first, or use layer.add_model(model) explicitly.

Jinja2 Parameters

SQL expressions in models support Jinja2 templating:

yaml
models:
  - name: orders
    sql: "SELECT * FROM orders WHERE region = '{{ region }}'"

Pass values at query time:

python
result = layer.query(metrics=["orders.revenue"], parameters={"region": "US"})

CLI Reference

All commands are run as sidemantic <command>. Use --config path/to/sidemantic.yaml to load a config file with connection and model path settings.

CommandPurpose
validate [DIR] --verboseValidate definitions, show errors and warnings
info [DIR]Summary of models, dimensions, metrics, relationships
query [DIR] -c CONNECTION SQLExecute SQL through the semantic layer (--format table/json/csv, --limit N)
migrator [DIR] --queries PATHCoverage analysis: check how well models handle SQL queries
migrator --queries PATH --generate-models OUTBootstrap: generate model YAML from SQL queries
preagg recommend [DIR]Recommend pre-aggregation tables from query patterns
preagg apply [DIR]Apply pre-aggregation recommendations
serve [DIR] -c CONNECTIONStart PostgreSQL wire-protocol server
mcp-serve [DIR] -c CONNECTIONStart MCP server for AI tool integration
workbench [DIR] -c CONNECTIONInteractive TUI with SQL editor and charting
lspStart LSP server for Sidemantic SQL files

Connection Strings

duckdb:///:memory:                             # In-memory DuckDB
duckdb:///path/to/db.duckdb                    # File-based DuckDB
duckdb://md:database_name                      # MotherDuck
postgres://user:pass@host:port/dbname          # PostgreSQL
bigquery://project_id/dataset_id               # BigQuery
snowflake://user:pass@account/database/schema  # Snowflake
clickhouse://user:pass@host:port/database      # ClickHouse
databricks://token@server-hostname/http-path   # Databricks
spark://host:port/database                     # Spark SQL
adbc://driver/uri                              # ADBC

Reference Files

Load these when you need deeper detail:

  • references/yaml-schema.md: Field-level YAML schema with every field, type, default, and constraint
  • references/patterns.md: Complete YAML templates for e-commerce, SaaS, marketing, IoT, and star schema patterns
  • references/validation.md: All validation rules, error messages, and fixes
  • references/migration.md: Field-by-field mappings from Cube, dbt, LookML, and other formats
  • references/generation.md: Migrator API, schema introspection, auto-model generation, pre-aggregation recommendations

Common Mistakes

  1. Missing granularity on time dimensions. Every type: time dimension needs granularity: day (or similar).
  2. Simple metric without agg. Metrics that are not complex types need an agg field (sum, count, avg, etc.) or a full SQL expression like sql: "SUM(amount)".
  3. Unqualified fields in multi-model queries. Single-model SQL can use unqualified names (SELECT revenue FROM orders), but cross-model queries should use explicit model.field.
  4. No relationship path between models. Cross-model queries require a chain of relationships connecting all involved models.
  5. Using type: string or type: number for dimensions. The valid types are categorical, time, boolean, numeric.
  6. Confusing model-level vs graph-level metrics. Model-level metrics use agg. Graph-level metrics (ratio, derived, etc.) go in the top-level metrics: section.
  7. Missing required fields on complex metrics. ratio needs numerator + denominator. derived needs sql. time_comparison needs base_metric. conversion needs entity, base_event, conversion_event.
  8. Plural relationship names create wrong FK defaults. Relationship named customers defaults FK to customers_id, not customer_id. Always set foreign_key explicitly.
  9. SQL expressions with YAML special characters. Quote SQL containing :, #, {, or >.
  10. Duplicate model or metric names. Names must be unique across the entire semantic layer.
  11. Creating Models before SemanticLayer. With auto-registration (default), Models must be created after the SemanticLayer, or they won't register.

© sidequery, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 5 other files (references) in plugins/sidemantic/skills/modeler of sidequery/sidemantic.

  • SKILL.md
  • references/generation.md
  • references/migration.md
  • references/patterns.md
  • references/validation.md
  • references/yaml-schema.md

Open the folder on GitHubat commit db203eb

Compare with similar skills

Modeler next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Modeler compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Modeler this skillsidequery/sidemantic129—~4.2kAutomated safety check: PassApache-2.0
Snowflake Developmentsickn33/agentic-awesome-skills47k2 repos~2.1kAutomated safety check: PassMIT
Snowflake Developmentalirezarezvani/claude-skills28k—~3.2kAutomated safety check: PassMIT
Analytics Engineerborghei/Claude-Skills874—~3.4kAutomated safety check: PassMIT
Chdb SQLvemetric/vemetric3941 repos~1.2kAutomated safety check: PassApache-2.0
Pytorch Clickhousepytorch/test-infra113—~2.8kAutomated safety check: PassCustom licence

Similar skills

  • Snowflake Development

    sickn33/agentic-awesome-skills

    Comprehensive Snowflake development assistant covering SQL best practices, data pipeline design (Dynamic Tables, Streams, Tasks, Snowpipe), Cortex AI functions, Cortex Agents, Snowpark Python, dbt…

    47k GitHub starsUsed in 2 repos~2.1k tokens
    DatabasesAuto-check passed
  • Snowflake Development

    alirezarezvani/claude-skills

    A skill your agent uses when writing Snowflake SQL, building data pipelines with Dynamic Tables or Streams/Tasks, using Cortex AI functions, creating Cortex Agents, writing Snowpark Python…

    28k GitHub stars~3.2k tokensUpdated 1 mo ago
    DatabasesAuto-check passed
  • Analytics Engineer

    borghei/Claude-Skills

    Analytics engineering across data modeling, dbt, transformation, and semantic layers.

    874 GitHub stars~3.4k tokensUpdated today
    Data & AnalyticsAuto-check passed
  • Chdb SQL

    vemetric/vemetric

    A skill your agent uses when the user wants to run SQL — especially analytical SQL — on local files (parquet/csv/json), URLs, S3 paths, or remote databases (Postgres, MySQL, MongoDB, ClickHouse…

    394 GitHub starsUsed in 1 repo~1.2k tokens
    DatabasesAuto-check passed
  • Pytorch Clickhouse

    pytorch/test-infra

    Load this FIRST whenever working with PyTorch CI data (any pytorch/ org repo), the torchci/HUD codebase, or the PyTorch HUD ClickHouse database.

    113 GitHub stars~2.8k tokensUpdated today
    DatabasesAuto-check passed
  • Data Warehouse Experimentation

    rampstackco/claude-skills

    Running experiments out of the data warehouse instead of via dedicated experiment platforms.

    935 GitHub stars~7.3k tokensUpdated today
    DatabasesAuto-check passed

More from sidequery/sidemantic

  • Webapp Builder

    sidequery/sidemantic

    Build interactive analytics webapps, demos, dashboards, or embedded app surfaces from Sidemantic semantic models using copyable component primitives and deterministic query inspection.

    129 GitHub stars~5.5k tokensUpdated today
    Auto-check passed
  • Semantic Analyst

    sidequery/sidemantic

    Answer analytical, KPI, metric, trend, cohort, and business-performance questions through a Sidemantic semantic layer.

    129 GitHub stars~982 tokensUpdated today
    Auto-check passed

Categories

Questions about Modeler

What does Modeler do?

Build, validate, and manage semantic models using Sidemantic. Modeler is an agent skill from sidequery/sidemantic. Build, validate, and manage semantic models using Sidemantic.

When should I use Modeler?

Modeler fits situations like: asked to create a semantic layer; define metrics/dimensions; model a database schema; generate models from SQL queries.

How do I install Modeler in Claude Code?

Run `npx skills add sidequery/sidemantic --skill modeler -a claude-code`. Or copy the skill folder (plugins/sidemantic/skills/modeler in sidequery/sidemantic) into .claude/skills/modeler in your project. Claude Code loads it when a task matches its description.

How do I install Modeler in Codex?

Run `npx skills add sidequery/sidemantic --skill modeler -a codex`. Or copy the skill folder (plugins/sidemantic/skills/modeler in sidequery/sidemantic) into .agents/skills/modeler in your project. Codex loads it when a task matches its description.

Can I use Modeler in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add sidequery/sidemantic --skill modeler -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/modeler, .gemini/skills/modeler, .github/skills/modeler and .opencode/skills/modeler in your project.

What does Modeler need to run?

Going by SKILL.md and its folder, Modeler needs the command-line tools its instructions call (uv). Our summary lists: Python 3.

Does Modeler access the network?

SKILL.md contains no URLs. Its commands use uv, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Modeler safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Modeler use?

Modeler is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Modeler use?

About 4.2k tokens (SKILL.md is roughly 17k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 17k tokens, read only when the agent opens those files.

What are the alternatives to Modeler?

Skills that share tags, products or a category with Modeler: Snowflake Development (sickn33/agentic-awesome-skills, 47k stars), Snowflake Development (alirezarezvani/claude-skills, 28k stars), Analytics Engineer (borghei/Claude-Skills, 874 stars) and Chdb SQL (vemetric/vemetric, 394 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Modeler?

sidequery (a GitHub organization) maintains it in sidequery/sidemantic, which has 129 GitHub stars. The repository holds 3 skills in this directory. The repository was last updated on October 7, 2026.

Source: sidequery/sidemantic on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.