tower-ontology

Profiles Iceberg lakehouse tables with SQL and records a verified entity model as catalog knowledge.

2|Updated Jul 11, 2026
One-click install
npx skills add https://github.com/tower/agent-skills --skill tower-ontology-tower
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tower-ontology
Source: https://github.com/tower/agent-skills/tree/main/skills/tower-ontology
Command: npx skills add https://github.com/tower/agent-skills --skill tower-ontology-tower

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Undocumented data catalogs force every agent and analyst to guess table meanings, grain, and join keys from column names, producing confidently wrong analysis. This Skill builds a verified ontology for a Tower-managed Apache Iceberg lakehouse by proving every claim with SQL before recording it. ## Core Features & Use Cases - SQL-Verified Profiling: Proves table grain, primary key uniqueness, null rates, and data freshness with aggregate queries instead of inferring from column names. - Relationship Validation: Tests candidate joins for cardinality and orphan rates, recording only relationships that actually hold in the data. - Persistent Catalog Knowledge: Writes entity, column, metric, and overview entries via tower catalogs knowledge with confidence levels (confirmed, heuristic, inferred) so future sessions start with the semantics. - Use Case: A new catalog lands with 19 undocumented tables. Run this Skill to inventory the catalog, profile each table, prove the joins, and produce an entity map plus a list of open questions for the data owner. ## Quick Start Ask the agent to profile the default Tower catalog and build a verified ontology of its tables and relationships, recording the results as catalog knowledge.

Frequently Asked Questions about tower-ontology

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I document and profile tables in a data lakehouse?▼

Use this Skill to inventory the catalog with tower catalogs show, then run one profiling query per table to verify grain, nullability, and freshness. Each verified entity is recorded immediately via tower catalogs knowledge so future agents start with the semantics.

How to verify join keys and table relationships with SQL?▼

Run a LEFT JOIN aggregate query counting child rows, matched rows, and distinct keys on both sides. Equal match counts confirm a clean join, the ratio of distinct keys reveals N:1 or 1:1 cardinality, and zero matches means the supposed foreign key does not exist.

Does this skill modify or write data to my tables?▼

No. It is strictly read-only: it queries tables with short-lived read-only credentials and writes only knowledge entries describing schemas, grain, keys, and definitions. It never passes --write to tower catalogs query and never alters data.

Why do date functions fail on Iceberg timestamp columns in DuckDB?▼

The sandboxed DuckDB cannot load the icu extension, so date_trunc, year(), and similar functions fail on TIMESTAMP WITH TIME ZONE columns, which all Iceberg timestamps are. Cast the column first with CAST(ts AS TIMESTAMP); values are UTC.

What happens if the ontology profiling pass is interrupted?▼

Nothing is lost. Knowledge entries are written per table as profiling completes, and set upserts by name, so re-running skips tables that already have an entity entry and resumes cleanly.

When should I not use the tower-ontology skill?▼

Do not use it to answer business questions (that is tower-data), to ingest data (that is tower-integration), or to fix data quality problems. It reports issues like stale tables and orphan rates but never rewrites data.