metabase_ingest

Convert Metabase questions, models, and metrics into ktx Semantic Layer source definitions.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Metabase instances accumulate hundreds of questions, models, and metrics whose business logic stays locked inside the BI tool. This Skill migrates that logic into ktx Semantic Layer (KSL) source definitions so data agents can query the warehouse using approved, reusable metric definitions instead of re-deriving SQL from scratch.

Core Features & Use Cases

  • SQL translation and cleanup: Inlines cross-card {{#N}} references, drops dummy-substituted template placeholders and optional [[ ]] clauses, and validates the result as a standalone subquery.
  • Type and join mapping: Maps Metabase result_metadata base types to KSL column types, detects PK/FK grain and join candidates, and enforces key-only join rules to prevent broken joins.
  • Deduplication and decomposition: Collapses near-duplicate cards into one generalized source and decomposes pre-aggregated GROUP BY queries into row-level columns plus KSL measures.
  • Use Case: Given a WorkUnit of staged cards/<id>.json files from a Metabase collection, produce overlay or standalone semantic-layer sources with measures, joins, provenance tags, and skip/fallback records for trivial or untranslatable cards.

Quick Start

Load this Skill when a WorkUnit contains Metabase card JSON files and ask the agent to ingest the staged cards into ktx semantic layer sources.

Frequently Asked Questions about metabase_ingest

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

FAQPage Schema
How do I migrate Metabase questions into a semantic layer?

Stage each Metabase card as JSON with resolvedSql and resultMetadata, then map base types to KSL column types, decompose GROUP BY aggregations into measures, and write sources via sl_write_source or sl_edit_source. Near-duplicate cards are collapsed into one generalized source.

How are Metabase field types mapped to semantic layer column types?

Integer, Float, Decimal, and BigInteger base types map to number; Text and TextLike map to string; DateTime, Date, and DateTimeWithTZ map to time; Boolean maps to boolean. Semantic types like CreationTimestamp mark time-role columns, while PK and FK types identify grain and join candidates.

What happens to Metabase template variables and card references during ingestion?

Resolved cards already have {{#N}} references inlined and optional clauses dropped. Fallback cards require manual inlining of referenced card SQL and removal of {{ var }} placeholders and [[ ]] brackets. Dummy-substituted filter clauses from required placeholders must be dropped before writing the source.

Can this handle cards that join multiple warehouse tables?

Yes, but joins are only declared when the card output exposes a local key column matching the target source grain. Joining on display values like names is rejected by the validator; the key column must be projected in the SQL first, using many_to_one for FK-to-dimension relationships.

What happens when a Metabase card cannot be translated?

Trivial queries and duplicates are skipped automatically. Cards whose fallback SQL cannot be confidently translated are skipped and recorded via emit_unmapped_fallback with reason parse_error, while unresolvable table references produce an unmapped-table wiki entry documenting the gap.