Menu
Capture semantic-layer and knowledge updates from a live database schema snapshot.
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/Kaelio/ktx --skill ordersThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Showing SKILL.md
Extract durable ktx wiki knowledge from staged Sigma data model specs and workbook summaries. Load for WorkUnits with unitKey sigma-data-models or sigma-workbooks.
Use when answering a question that needs data from a ktx-connected database - investigating, analyzing, "how many", "show me", "what's the breakdown of", finding records by value, exploring tables, comparing periods, explaining metrics, or any data-analysis request. Triggers even when the user does not say "analytics"; if the answer requires querying a configured ktx connection, this skill applies.
ktx's knowledge base - wiki pages for durable, reusable business knowledge. Covers capture workflow for user preferences, metric definitions, organizational conventions, and cross-references between wiki pages and semantic-layer sources. Loaded by the post-turn memory-agent only. The research agent reads wiki via `wiki_read`/`wiki_search` but does not write it.
Based on SOC occupation classification
| name | live_database_ingest |
| description | Capture semantic-layer and knowledge updates from a live database schema snapshot. |
| callers | ["memory_agent"] |
Use this skill when the ingest work unit contains raw files under
raw-sources/<connectionId>/live-database/<syncId>/.
connection.json to understand the snapshot metadata.foreign-keys.json when the table has a foreign key or when joins are
needed for the semantic-layer source.sl_write_source.table field.descriptions.db on tables and columns.sl_validate for the table source before the work unit completes.Sample values come from the scan record; do not invent values not present in relationship-profile.json.
Before writing a wiki page or SL source on any topic:
discover_data({query: "<topic>"}) - see what wikis, SL sources, and raw
tables already exist. Prefer updating existing pages over creating new ones.Before emitting any schema.table or schema.table.column into a wiki body,
SL source, tables: frontmatter, sl_refs, or emit_unmapped_fallback:
entity_details({connectionId, targets: [{display: "<identifier>"}]}) -
confirm the identifier resolves; inspect native types, FK/PK, and
sampleValues.entity_details sampleValues for the relevant
column. If sampleValues is short or the sample may have missed real values,
run a sql_execution probe with the same warehouse connection id:
sql_execution({connectionId, sql: "SELECT DISTINCT <col> FROM <ref> LIMIT 50"}).sql_execution({connectionId, sql: "SELECT 1 FROM <ref> LIMIT 0"}).
If it errors, the identifier is fictional.[unverified - from <rawPath>] in the wiki body,
citing the exact raw path that mentioned it.emit_unmapped_fallback with no_physical_table, include
the failing probe error in clarification.<schema>.<table> placeholder strings from these instructions
into output.For a raw table with this shape:
{
"name": "orders",
"db": "public",
"columns": [
{ "name": "id", "type": "integer", "nullable": false, "primaryKey": true }
]
}
Write a semantic-layer source with this shape:
name: orders
table: public.orders
grain: id
columns:
- name: id
type: number
Use string, number, time, or boolean for column types. When a database
type is ambiguous, use string.
The raw snapshot is structural evidence. Do not invent measures, segments, business definitions, or joins that are not present in the snapshot files.