一键导入
lookml-sets
Guide to using LookML sets for grouping fields, controlling visibility, and managing drill paths.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Guide to using LookML sets for grouping fields, controlling visibility, and managing drill paths.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
This skill enables agents to assist users in programmatically creating, updating, and managing Looker themes using the Looker API. Use this when you need to automate visual styling, implement brand-specific themes, or manage instance-wide default themes.
Detailed guidelines and mandatory workflows for localizing LookML models, views, explores, and dashboards, including string catalog creation and deployment via lkr-dev-cli.
Parent orchestrator skill for coordinating full-stack internationalization and localization across LookML models/dashboards and the React frontend application.
Comprehensive standards, UI design principles, tabbed report architecture, and automation patterns for creating and managing modern LookML dashboards using local LookML files and Looker MCP/CLI tools.
Analyzes a specific LookML dashboard (e.g., brand_lookup.dashboard.lookml), extracts all query elements and merge results, verifies them via run_inline_query(result="sql"), and self-heals missing LookML fields by iteratively adding best-guess calculations to local LookML views.
Standards, workflow rules, and helper patterns for managing LookML files in the Looker project using the `lkr-dev-cli` CLI tool, including full project and single-file push/pull synchronization and production deployment.
| name | lookml-sets |
| description | Guide to using LookML sets for grouping fields, controlling visibility, and managing drill paths. |
Sets are reusable lists of fields (dimensions, measures, and filters) defined within a view or a model. They are primarily used to group fields together for various purposes such as drill-down paths, explore field visibility, and more.
set: set_name {
fields: [field_name1, field_name2, view_name.field_name3, ...]
}
[set_name*] includes all fields from another set.[-field_name] excludes a specific field.view_name.set_name* refers to a set in another view (ensure views are joined).Sets are the standard way to define what happens when a user clicks on a measure value. Instead of listing fields repeatedly, define a set and reference it.
view: orders {
# ... dimensions ...
set: order_details {
fields: [id, created_date, status, user.email]
}
measure: count {
type: count
drill_fields: [order_details*]
}
}
You can use sets at the Explore level to explicitly define which fields are visible to users. This is best practice for curating Explores.
explore: orders {
fields: [ALL_FIELDS*] # Start with everything (default)
# OR
fields: [orders.order_details*, users.user_info*] # Allowlist specific sets
}
Use sets to exclude specific fields from an Explore without hiding them at the view level (which hides them globally).
explore: orders {
fields: [ALL_FIELDS*, -users.password_hash]
}
detail SetEvery view should ideally have a default set (commonly named detail or drill_set) that includes the most relevant fields for drilling into a record from that view.
view: users {
dimension: id { primary_key: yes ... }
dimension: name { ... }
dimension: email { ... }
# Standard set for drilling
set: detail {
fields: [id, name, email]
}
}
snake_case for set names.user_info, financial_metrics, drill_detail.While you can reference other_view.field in a view's set, this creates a dependency. Ensure that other_view is always joined whenever the set is used.
fields: [orders.detail*, users.detail*]).You can build sets on top of other sets.
set: basic_info {
fields: [id, name]
}
set: extended_info {
fields: [basic_info*, email, created_date]
}