Menu
Media & entertainment domain knowledge: content catalogs, participation tables, ranking determinism.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Load when working with Xata Postgres branches: forking a branch, building or testing dbt models on a branch, wiring dbt to a branch's credentials, diffing two branches, or the pre-merge impact report. Covers create_xata_branch, delete_xata_branch, get_dbt_profile, xata_branch_diff, schema_diff_branches, and pgroll migrations.
Load at Step 1 before exploring the project. Covers output shape inference, incremental model handling, and what to trust in YML.
Use this skill before writing any SQL query. Covers: output shape inference (cardinality clues from the question), efficient schema exploration, iterative CTE-based query building, structured verification loop (row count, NULL audit, fan-out check, sample inspection), error recovery protocol, saving output to result.sql and result.csv, turn budget management, and common benchmark traps.
Populate the knowledge base from dbt project research. Proposes entries across all 6 categories at org, project, and connection scopes.
Load FIRST before any dbt project work. Covers the full 8-step dbt workflow: project scanning, skill loading, validation, macro discovery, research, technical spec, SQL writing, and verification. Also covers output shape inference, incremental model handling, and what to trust in YML.
Loaded at Step 2 for the full workflow. Covers column naming, type preservation, JOIN defaults, lookup joins, sibling models, materialization, packages, and filtering rules.
| name | domain-media |
| description | Media & entertainment domain knowledge: content catalogs, participation tables, ranking determinism. |
BEFORE writing any JOIN, check: does the project have BOTH a broad table (all content types) AND narrow tables (one content type only)?
IF YES - ALWAYS join to the broad table. Joining to a narrow table silently drops all rows for other content types. A model called podcast_engagement does NOT mean you join only to a podcasts table when a broader all_content table exists - the model name describes what the output represents, not which source rows to include.
IF NO - there is only one content table. Use it.
To verify: run SELECT COUNT(DISTINCT <key>) FROM <broad_table> and compare to SELECT COUNT(DISTINCT <key>) FROM <narrow_table>. If the broad table has MORE distinct entities, you MUST use it.
Tables that record WHO participated in WHAT (credits, casts, rosters, lineups, contributors) contain ALL participant types - actors, directors, producers, writers, coaches, players.
Do NOT filter by participant type based on the model name or task description. The participation table defines the population. Include all rows unless the YML description contains an explicit filter condition.
When aggregating content metrics, drive FROM the participation/event table (credits, views, ratings, matches), not the content table (movies, players, tournaments). The participation table has one row per event - that is the correct grain.
When ranking entities (top-N, best-rated, most-X), use ROW_NUMBER() with a deterministic tiebreaker - the entity's primary key as the final ORDER BY term. Ordering by a non-unique column (rating, count) alone produces different rankings on each run.
NEVER use DENSE_RANK() for top-N selection - DENSE_RANK() can return more than N rows when ties exist at the boundary.
