lookml_ingest

Convert LookML views, models, and explores into ktx semantic layer sources.

1.6k|101|Updated May 10, 2026
One-click install
npx skills add https://github.com/Kaelio/ktx --skill lookml-ingest
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: lookml_ingest
Source: https://github.com/Kaelio/ktx/tree/main/packages/cli/src/skills/lookml_ingest
Command: npx skills add https://github.com/Kaelio/ktx --skill lookml-ingest

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Translating LookML definitions into a semantic layer by hand is error-prone: dimension_group timeframes get mistaken for physical columns, derived tables lose their grain, and enforced filters like sql_always_where get dropped. This Skill provides a deterministic mapping from LookML constructs to ktx semantic layer sources with verification steps that prevent hallucinated column names.

Core Features & Use Cases

  • LookML-to-ktx mapping table: Maps views to overlays or standalone sources, measures to measures, explore joins to the join graph, and filters to segments, with a LookML-to-ktx type map.
  • Three capture shapes with worked examples: Overlay for thin wrappers over manifest tables, standalone from derived_table, and standalone with sql_always_where folded into the sql clause.
  • Identifier verification protocol: Requires sl_discover, entity_details, and sql_execution probes before any write, plus sl_validate after every sl_write_source to catch invented columns via warehouse errors.
  • Use Case: While ingesting a Looker project, the agent encounters a view with a derived_table computing biomarker deltas; it writes a standalone ktx source with explicit grain and columns, then validates it against the warehouse before continuing.

Quick Start

Load this skill whenever the turn contains .lkml content and ask the agent to map the LookML views and explores into ktx semantic layer sources with provenance tags.

Frequently Asked Questions about lookml_ingest

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

FAQPage Schema
How do I convert LookML views into a semantic layer?

Map each LookML view to either an overlay (when sql_table_name matches a manifest table) or a standalone source (when it uses derived_table or sql_always_where). Measures become measures, explore joins become join entries, and always_filter or conditionally_filter become named segments.

How do LookML dimension_group timeframes map to semantic layer columns?

A dimension_group expands at Looker render time into fields like date_raw or date_week, but these are not physical warehouse columns. Map each dimension_group to a single column entry using the physical column from its sql clause, with type time and role time.

When should a LookML view become an overlay versus a standalone source?

Use an overlay when the view is a thin wrapper over a manifest-backed table via sql_table_name, inheriting grain and base columns. Use a standalone source with explicit sql, grain, and columns when the view defines a derived_table or sql_always_where.

Why do semantic layer queries fail with Unrecognized name errors after LookML ingestion?

These errors occur when invented column names, such as timeframe expansions like date_date, are written into sql, columns, or grain. Prevent this by calling sl_discover or a sql_execution probe before writing, and sl_validate after every sl_write_source.

What happens when the Looker connection does not match the warehouse connection?

A hard gate marked [LOOKML SL WRITES DISALLOWED] blocks sl_write_source and sl_edit_source for that WorkUnit when the declared Looker connection mismatches the expected connection name. Continue wiki extraction and preserve the mismatch reason in any emit_unmapped_fallback.

How should sql_always_where be modeled in the semantic layer?

Fold sql_always_where directly into the standalone source's sql clause as a WHERE condition, since it is enforced rather than opt-in. Do not model it as a segment or duplicate it as per-measure filters.