Reading Data Dictionary

Use this before writing SQL for documented metrics, so that business and product terms map to the right models, columns, and definitions instead of guesses.

When invoked from the elicitation flow to resolve specific LOOK UP terms, scope the work to those terms: resolve their definitions and surface any options/candidates back to the user. Do not perform a full data exploration unless the user explicitly asked for one or no curated model is obvious.

Where the definitions live

This skill is generic. A project may document its data in one or more of:

• a dbt project (model .sql, models/**/*.yml, target/manifest.json, generated docs)
• a dedicated data dictionary directory (for example data_dictionary/**)
• metric or semantic-model YAML files
• a BI tool's metric layer, a wiki, or a README

If your team has a canonical source (for example a dbt repository), treat it as the source of truth and point this skill at it. Prefer reading it over the remote gh API or a fresh checkout rather than relying on a possibly-stale local clone.

Useful artifacts to inspect first, when present: