一键导入
lookml-view
Use this skill to create or modify LookML Views. Covers basic view definitions, sql_table_name, file organization, and patterns.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use this skill to create or modify LookML Views. Covers basic view definitions, sql_table_name, file organization, and patterns.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Looker Developer Onboarding: Step 3. Authenticates the Looker CLI using OAuth. Only execute this after Step 2 (CLI Verification using `installing-looker-cli`).
Looker Developer Onboarding: Step 4. Creates a database connection in Looker to Google BigQuery. Only execute this after Step 3 (CLI Authentication using `authenticating-looker-cli`).
Looker Developer Onboarding: Step 7 (Final Step). Creates a LookML dashboard in the project, imports it as a user-defined dashboard (UDD) in Looker, and iteratively refines it based on user feedback by syncing changes. Only execute this after Step 6 (Model Setup using `creating-lookml-model`).
Looker Developer Onboarding: Step 6. Creates LookML views and models based on the user's goals, maps model connections, validates LookML, and runs verification queries. Only execute this after Step 5 (Project Setup using `setting-up-looker-project`).
Looker Developer Onboarding: Step 1. Guides the agent to explore BigQuery data and define the onboarding goal. This is the first active step, to be executed immediately after reading the parent orchestrator `looker-developer-onboarding`.
Looker Developer Onboarding: Step 2. Verifies that the Looker CLI is available in the PATH, or installs it from GitHub Releases if missing. Only execute this after Step 1 (Data Discovery using `exploring-data-for-looker`).
| name | lookml-view |
| description | Use this skill to create or modify LookML Views. Covers basic view definitions, sql_table_name, file organization, and patterns. |
| license | Apache-2.0 |
| metadata | {"publisher":"google","version":"v1"} |
views/[datasource_name]/[view_name].view.lkmlviews/[datasource_name]/[view_name]_ext.view.lkmlviews/[datasource_name]/[view_name]_rfn.view.lkmlviews/[datasource_name]/[view_name]_ndt.view.lkmlviews/[datasource_name]/[view_name]_sdt.view.lkmlprimary_key: yes — Why: essential for symmetric aggregates, which Looker uses to handle JOIN row duplication correctly (prevents fanout in multi-join queries).+ before the view name (e.g., view: +users) to refine existing views without modifying the original file.extends to reuse logic from other views.explore_source) over SQL Derived Tables (sql) where possible. When creating entity rollups or summary facts (e.g., user_order_facts), assess whether an existing Explore can source the data. NDTs are recommended because they minimize code drift and automatically inherit underlying LookML descriptions, formatting, and Row-Level Security (RLS). If an NDT is too complex, or if specific SQL features are required, an SDT is fully acceptable.snake_case for view names and filenames.include, refinements (+), and Hub & Spoke patterns.view: users {
sql_table_name: `project.dataset.users` ;;
dimension: user_id {
primary_key: yes
type: number
sql: ${TABLE}.id ;;
group_label: "IDs"
description: "Unique internal user ID."
}
dimension: email {
type: string
sql: ${TABLE}.email ;;
description: "User's email address."
}
}
include: "/views/base/users.view"
view: users_extended {
extends: [users]
dimension: lifetime_value {
type: number
sql: ${TABLE}.ltv ;;
description: "Total lifetime value of the user."
}
}
include: "/views/users.view"
view: +users {
label: "All Users (Refined)"
dimension: email {
# Adding a description to an existing field
description: "Primary contact email."
}
}