MCPInstall

looker-studio-bigquery

Route BigQuery-backed Looker Studio work into one stakeholder-reporting packet: dashboard-spec, slow-dashboard triage, refresh-shape choice, audience split, or exec-handoff. Use when the user needs KPI boards, PM/ops reviews, marketing / GTM reporting, product funnel summaries, or game/live-ops telemetry dashboards on top of curated BigQuery data. Route KPI explanation to data-analysis, repeated anomaly hunting to pattern-detection, telemetry/alerting coverage to monitoring-observability, and semantic-platform choice to survey.

Installs
389
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/akillness/jeo-skills --skill looker-studio-bigquery
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads looker-studio-bigquery automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

Looker Studio + BigQuery

Use this skill when the real deliverable is one trustworthy stakeholder-reporting packet on top of BigQuery.

looker-studio-bigquery owns the reporting layer for:

  • PM / ops KPI review boards
  • product funnel, retention, and rollout dashboards already modeled in BigQuery
  • marketing / GTM channel and revenue reporting
  • game / live-ops / business telemetry review boards
  • refresh, cost, audience, and export-handoff decisions for Looker Studio on curated data

Read these support docs first when needed:

  • references/intake-packets-and-route-outs.md
  • references/modeling-refresh-and-cost.md
  • references/dashboard-delivery-checklist.md
  • references/modes-and-routing.md

When to use this skill

  • The user explicitly wants Looker Studio / Data Studio + BigQuery help.
  • The data already lives in BigQuery, or the dashboard clearly sits on curated BigQuery tables/views.
  • The main job is dashboard structure, refresh/cost shape, audience-specific delivery, or export-ready reporting.
  • The request is about KPI boards, PM/ops reviews, marketing/GTM reporting, product summary dashboards, or game/business telemetry dashboards.
  • The real risk is dashboard trust, refresh design, or mixed-audience sprawl rather than raw SQL interpretation alone.

When not to use this skill

  • The main job is explaining why a KPI moved or what the dataset means → use data-analysis
  • The main job is repeated anomaly hunting or reusable rule scans across metrics/events → use pattern-detection
  • The main job is telemetry reliability, alerting, or instrumentation coverage → use monitoring-observability
  • The main job is choosing a full BI / semantic platform → use survey
  • The main job is broad GCP/bootstrap/deploy work → route to the relevant infrastructure skill first

Instructions

Step 1: Pick one primary packet before talking about charts

Normalize the request into one packet.

looker_studio_bigquery_packet:
  primary_packet: dashboard-spec | slow-dashboard | refresh-shape | audience-split | exec-handoff
  audience: executive | pm-ops | product-analytics | marketing-gtm | game-liveops | mixed | unknown
  source_shape: curated-table | view | scheduled-query-output | materialized-view | mixed | unknown
  freshness_need: near-real-time | hourly | daily | weekly | unknown
  trust_risk: low | medium | high

Pick exactly one primary_packet:

  • dashboard-spec — build or redesign a stakeholder dashboard
  • slow-dashboard — fix a dashboard that is slow, expensive, or brittle
  • refresh-shape — decide live vs scheduled vs snapshot vs BI Engine
  • audience-split — separate one overloaded report into audience-specific artifacts
  • exec-handoff — produce a thin dashboard plus export/sheet/deck handoff for commentary and approvals

If two packets seem plausible, choose the one that removes the biggest delivery risk first.

Step 2: Keep the dashboard thin on purpose

Before designing sections, answer these:

  1. What review ritual or decision does this dashboard support?
  2. What table/view is the source of truth?
  3. Which metrics belong in BigQuery instead of report-level formulas?
  4. Who owns freshness, trust checks, and caveats?

If the request still depends on raw fact tables, unstable joins, or fuzzy metric definitions, say so and push modeling work upstream before polishing the dashboard.

Step 3: Shape the packet, not a generic BI essay

Use the packet guidance in references/intake-packets-and-route-outs.md.

Minimum packet expectations:

  • dashboard-spec → page structure, KPI set, chart-to-question mapping, and BigQuery contract
  • slow-dashboard → bottleneck order, upstream precompute options, and one shortest-path fix
  • refresh-shape → live vs scheduled vs snapshot choice tied to the real review cadence
  • audience-split → artifact split by stakeholder ritual, trust need, and detail depth
  • exec-handoff → thin dashboard plus Connected Sheets / export / slide handoff plan

Do not answer with a generic chart buffet.

Step 4: Return a delivery brief

Use this structure:

# Looker Studio Delivery Brief

## Primary packet
- Packet: ...
- Audience: ...
- Confidence: high | medium | low

## Review ritual and question
- Ritual: ...
- Decisions supported: ...

## BigQuery contract
- Source table/view: ...
- Grain: ...
- Core dimensions: ...
- Core metrics: ...
- Freshness / owner / caveats: ...

## Recommended dashboard shape
- Pages or sections: ...
- KPI and chart-to-question mapping: ...
- Filters / drilldowns / export needs: ...

## Refresh, cost, and trust plan
- Preferred refresh shape: ...
- Heavy logic to move upstream: ...
- Trust or caveat notes: ...

## Recommended next artifact
- Choose one: dashboard spec | SQL handoff list | refresh decision memo | audience split brief | export / Connected Sheets handoff

## Route-outs
- Upstream modeling / KPI interpretation / anomaly hunting / observability / platform comparison as needed

Step 5: Route out honestly

  • If the user needs dataset reasoning or KPI explanation, route to data-analysis.
  • If the user needs repeated anomaly detection or reusable metric rules, route to pattern-detection.
  • If the user needs telemetry coverage, alerting, or instrumentation trust, route to monitoring-observability.
  • If the user needs a heavier BI or semantic-platform decision, route to survey.

Examples

Example 1: PM / ops dashboard build

Input

Build a leadership-ready PM review dashboard in Looker Studio on top of BigQuery weekly KPIs.

Output sketch

  • Packet: dashboard-spec
  • Dashboard shape: KPI scorecards + main trend + one drilldown + owner/freshness notes
  • Next artifact: dashboard spec

Example 2: Slow marketing board

Input

Our marketing funnel dashboard is too slow and expensive whenever people touch filters.

Output sketch

  • Packet: slow-dashboard or refresh-shape
  • Primary recommendation: precompute the repeated funnel logic in BigQuery before styling changes
  • Next artifact: refresh decision memo or SQL handoff list

Example 3: Mixed audience dashboard

Input

One board is trying to serve executives, PMs, growth, and live-ops. Should we keep patching it?

Output sketch

  • Packet: audience-split
  • Recommendation: split the artifact by decision ritual and trust needs
  • Next artifact: audience split brief

Example 4: Commentary-friendly handoff

Input

Leadership wants a weekly board, but they still annotate numbers in Sheets before the review.

Output sketch

  • Packet: exec-handoff
  • Recommendation: keep the dashboard thin and define the export / Connected Sheets handoff explicitly
  • Next artifact: export / Connected Sheets handoff

Best practices

  1. Start from the current packet, not from chart types.
  2. Keep heavy logic in BigQuery whenever possible.
  3. Tie freshness to the real review ritual instead of pretending everything must be live.
  4. Split dashboards by audience when one artifact keeps absorbing incompatible needs.
  5. Name the owner, caveats, and trust contract in every serious dashboard handoff.
  6. Prefer route-outs over stuffing analysis, anomaly hunting, or observability into this skill.

References

FAQ

What does the looker-studio-bigquery skill do?

Route BigQuery-backed Looker Studio work into one stakeholder-reporting packet: dashboard-spec, slow-dashboard triage, refresh-shape choice, audience split, or exec-handoff. Use when the user needs KPI boards, PM/ops reviews, marketing / GTM reporting, product funnel summaries, or game/live-ops telemetry dashboards on top of curated BigQuery data. Route KPI explanation to data-analysis, repeated anomaly hunting to pattern-detection, telemetry/alerting coverage to monitoring-observability, and semantic-platform choice to survey.

How do I install looker-studio-bigquery?

Run npx skills add https://github.com/akillness/jeo-skills --skill looker-studio-bigquery in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/looker-studio-bigquery/ (personal) or .claude/skills/looker-studio-bigquery/ (project).

Which AI agents can use looker-studio-bigquery?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is looker-studio-bigquery safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains looker-studio-bigquery?

It is published by akillness in akillness/jeo-skills. It has 389 recorded installs.

More from akillness/jeo-skills

View all →

rtk

akillness/jeo-skills

Install, initialize, verify, and troubleshoot RTK (Rust Token Killer) for AI coding agents. Use when you need to reduce shell-command token output, confirm that the correct rtk binary is installed, choose between Homebrew, install.sh, or Cargo installation, wire rtk init for Claude Code, Codex, Gemini CLI, Cursor, Copilot, Windsurf, Cline, or OpenCode, or use compact wrappers such as rtk git status, rtk read, rtk grep, rtk test, rtk lint, and rtk gain. Triggers on: rtk, rust token killer, token saver cli, rtk init, rtk gain, codex rtk, gemini rtk, opencode rtk, claude hook token reduction.

Backend & APIs672 installs

graphify

akillness/jeo-skills

Drive Graphify from its CLI to build, refresh, query, export, and serve a durable code/corpus knowledge graph. Use when the user wants .graphify/GRAPHREPORT.md, graph.json, graph.html, graphify update/summary/query/path/explain/tree, change-aware review context, git-hook or watch-based refresh, a stdio MCP graph server, or an install into jeo, jeopi, gjc, opencode, Claude, Codex, or Gemini. Also covers the honest structural fallback when native extraction is empty or misleading. Route simple locate/reference work to codebase-search, narrative knowledge-base work to llm-wiki, and project-memory handoff to opencontext. Triggers on: graphify, graphify update, graphify query, knowledge graph CLI, GRAPHREPORT.md, graph.json, codebase graph, graph refresh, graphify install, graphify serve, review context, affected flows.

data-analysis

akillness/jeo-skills

Analyze datasets to extract insights, identify patterns, and generate reports.

598 installs

code-refactoring

akillness/jeo-skills

Turn a cleanup packet into one behavior-preserving refactor brief. Use when simplifying a messy function/component/service, freezing behavior before touching fragile legacy code, splitting a cleanup-heavy diff into reviewable slices, or planning a repeated migration / codemod without changing intended behavior. Route diagnosis to debugging, review judgment to code-review, validation-program design to testing-strategies, bottleneck-led tuning to performance-optimization, and pure symbol inventory to codebase-search.

technical-writing

akillness/jeo-skills

Write internal technical documentation for engineers and operators: technical specs, architecture docs, ADRs, runbooks, migration plans, and developer-facing implementation guides. Use when the main job is capturing a technical decision, system boundary, operating procedure, or rollout path for builders and maintainers. Triggers on: tech spec, design doc, architecture doc, ADR, runbook, migration guide, implementation guide, rollout doc, operational guide, and internal technical writing. End-user onboarding guides, tutorials, FAQs, and help-center flows belong here too. Route API portals to api-documentation, release notes to changelog-maintenance, decks to presentation-builder, and GTM messaging to marketing-automation.

Docs & Writing544 installs

web-accessibility

akillness/jeo-skills

Routing-first skill for web accessibility remediation and verification. Use when the main job is classifying which accessibility surface is failing — semantics, keyboard/focus, labels/announcements, visual perception/reflow, media alternatives, or routed-app navigation feedback — and turning vague audit, WCAG, axe/Lighthouse, or "make this accessible" requests into one concrete remediation packet. Broad UI critique for hierarchy, polish, and launch readiness belongs here too. Route component API architecture and system governance to design-system, and responsive layout strategy to responsive-design.

Frontend & Design531 installs

Popular data & databases skills

View category →

Postgres best practices maintained by Supabase, for Postgres running anywhere. Load this skill BEFORE writing or changing anything that lives in a Postgres database: creating or altering tables and columns (including choosing column types), schema design, migrations and declarative schema files, RLS policies and the tests that verify them, indexes, triggers, database functions, queues and scheduled jobs (pgcron, pgmq), vector/semantic search (pgvector), and restoring dumps (pgrestore) or importing data. Also load it when diagnosing slow queries, high CPU, timeouts, EXPLAIN plans, connection exhaustion, locking, bloat, or rows visible to the wrong user or tenant. This is not just a performance guide — schema, migration, security, and SQL authoring tasks need these rules too, even for a one-column change or a single query.

OfficialData & Databases462.2K installs

prisma-client-api

prisma/skills

Prisma Client API reference covering model queries, filters, operators, and client methods. Use when writing database queries, using CRUD operations, filtering data, or configuring Prisma Client. Triggers on "prisma query", "findMany", "create", "update", "delete", "$transaction".

OfficialData & Databases393.5K installs

Deprecated compatibility name for prisma-orm-setup. Use only when a user or existing integration explicitly invokes prisma-database-setup; otherwise select prisma-orm-setup.

OfficialData & Databases392.3K installs

prisma-cli

prisma/skills

Prisma ORM 7 CLI reference for existing Prisma 7 applications or explicitly selected Prisma 7 workflows. Covers prisma init, generate, migrate, db, dev, studio, and mcp. For setup, connection repair, or Prisma 8, use prisma-orm-setup; not the Prisma Platform CLI.

OfficialData & Databases390.8K installs

prisma-postgres

prisma/skills

Deprecated compatibility name for prisma-postgres-setup. Use only when a user or existing integration explicitly invokes prisma-postgres; otherwise select prisma-postgres-setup.

OfficialData & Databases384.4K installs

Required reference for Prisma ORM 7 SQL driver adapter work. Use when implementing or modifying adapters, adding database drivers, or touching SqlDriverAdapter, Transaction, savepoint, result mapping, or DriverAdapterError behavior. Covers current transaction lifecycle, optional savepoint hooks, original database-error preservation, and verification.

OfficialData & Databases378.9K installs