← ClaudeAtlas

bq-cost-auditorlisted

Audit BigQuery SQL or a whole project for cost, then return a rewritten query and a projected byte reduction. Use when the user asks why a query is slow or expensive, mentions a BigQuery bill or slot contention, asks to optimize or tune SQL, asks about partitioning or clustering choices, or pastes a query and asks what is wrong with it. Also use before shipping any model that will run on a schedule.
rk-chavali/gcp-de-skills · ★ 0 · AI & Automation · score 70
Install: claude install-skill rk-chavali/gcp-de-skills
# BigQuery cost auditor Read `references/bigquery-cost-heuristics.md` and `references/execution-model.md` before the first audit in a session. ## Run the audit, do not narrate it If the BigQuery MCP server or an authenticated `bq` CLI is available, gather the evidence yourself. A cost audit built on real bytes is a different artifact from one built on reading the SQL. **With the MCP server** (`execute_sql_readonly` only, never `execute_sql`): 1. `get_table_info` on every table the query touches. This gives you the partition column, the clustering columns, and the size. Do not ask the user for a schema you can read. 2. Run the three `INFORMATION_SCHEMA` queries from the heuristics reference through `execute_sql_readonly`. Real bytes, real run counts, real users. 3. Aggregate in SQL. Results are capped at 3,000 rows, so never `SELECT` raw job rows and count them yourself. **With the `bq` CLI**, add the one thing MCP cannot do, a dry run of the rewrite: ```bash bq query --use_legacy_sql=false --dry_run < rewritten.sql ``` That is the only way to get a before-and-after on a query that has never run. Without it, project from the historical bytes of the original and say that is what you did. **With neither**, emit the commands and label every number as unverified. State which of the three you used in your first line. "Read 14 days of job history through the MCP server" and "estimated from the SQL text" are different claims and the user deserves to know which o