메뉴
Media & entertainment domain knowledge: content catalogs, participation tables, ranking determinism.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
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.
