query-debugging — Claude Code skill: what it does, how to install
Inspects past Honeydew query executions, extracts compiled SQL, and troubleshoots execution failures.
npx skills add honeydew-ai/honeydew-ai-coding-agents-plugins --skill query-debugging -a claude-codeWhat query-debugging does
This skill wraps the list_query_history tool from the honeydew MCP server. Rather than launching fresh queries, it inspects runs that already executed across BI tools like Tableau or Power BI, MCP calls, and deep analysis steps. You can pull the original query string, the compiled warehouse SQL, or the resolved YAML semantic definition.
History queries remain scoped to the active workspace session. Standard users view only their personal activity, while administrators inspect all runs and filter using user_in.
When diagnosing failures, the workflow filters by status_in="FAILED", pulls YAML attributes, and halves the field list with get_data_from_fields to isolate the offending metric. A connected honeydew MCP server is required.
What it helps with
- inspect failed Honeydew runs filtered by status_in="FAILED"
- compare client SQL from Tableau or Power BI with compiled warehouse SQL
- isolate internal query crashes through field bisecting
- trace semantic queries generated during deep analysis steps
Example prompts for the agent
- Show failed queries in the current workspace today along with their compiled SQL.
- Inspect the query Tableau sent to Honeydew on the last run.
- Bisect the failing query fields to find which metric causes the crash.
How to install query-debugging
1Skills CLI (Vercel)
npx skills add honeydew-ai/honeydew-ai-coding-agents-plugins --skill query-debugging -a claude-code2Manually: put the files in place
~/.claude/skills/query-debugging/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/query-debugging/
1Skills CLI (Vercel)
npx skills add honeydew-ai/honeydew-ai-coding-agents-plugins --skill query-debugging -a codex2Manually: put the files in place
.agents/skills/query-debugging/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add honeydew-ai/honeydew-ai-coding-agents-plugins --skill query-debugging -a cursor2Manually: put the files in place
.cursor/skills/query-debugging/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install honeydew-ai/honeydew-ai-coding-agents-plugins query-debugging2Manually: put the files in place
.github/skills/query-debugging/SKILL.md1Skills CLI (Vercel)
npx skills add honeydew-ai/honeydew-ai-coding-agents-plugins --skill query-debugging -a gemini-cli2Platform CLI
gemini skills install https://github.com/honeydew-ai/honeydew-ai-coding-agents-plugins --path skills/query-debuggingManually: put the files in place
.devin/skills/query-debugging/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add honeydew-ai/honeydew-ai-coding-agents-plugins --skill query-debugging -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about query-debugging
How do I install query-debugging in Claude Code?
Run npx skills add honeydew-ai/honeydew-ai-coding-agents-plugins --skill query-debugging -a claude-code.
What does query-debugging do?
It inspects historical semantic layer runs in Honeydew, showing client origins, compiled SQL, and YAML definitions to troubleshoot execution errors.
How does this differ from the query skill?
The query-debugging skill strictly inspects past query history. To execute new queries or analyses, use the query skill instead.
Source text
SKILL.md · Apache-2.0
---
name: query-debugging
description: Use when the user wants to review or inspect past query executions in Honeydew — what ran, from which client (BI tools, SQL interface, MCP, deep analysis), the semantic definition or compiled SQL behind a run, who ran it and when — and to debug failures. Uses the list_query_history MCP tool. For running new queries or analysis use the query skill.
---
## Overview
Honeydew records every query executed through the semantic layer — MCP tools, BI tools over the SQL/XMLA interfaces (Tableau, Power BI, …), scheduled jobs, and deep analysis. Use `list_query_history` (from the `honeydew` MCP server) to see **what ran, who ran it, from which client, and how**, and to drill into any run's semantic definition or compiled SQL. Debugging failures is one use, not the only one.
Reach for this skill on questions like:
- "What ran against this domain today, and from which clients?"
- "Which BI tool queried this model, and what did it send?"
- "Show me the queries my last deep analysis generated."
- "Why did my query fail? Show me its SQL."
For running a *new* query, use the **query** skill. This skill inspects queries that already ran.
The tool's description and parameter schema cover the exact arguments and response fields; this skill covers what they can't — **when to reach for it, how to read the results, and the workflows.**
---
## Prerequisites
Query history is scoped to the session's workspace — check with `get_session_workspace_and_branch`, and set one via the **workspace-branch** skill if needed. Non-admin callers see only their own queries; admins see all and can filter by `user_in`.
---
## Reading the Results
- **client** — where the query came from (`Tableau`, `Power BI`, `MCP`, …); how you tell a dashboard's query from an MCP or deep-analysis run.
- **original SQL vs. compiled SQL** — SQL-interface clients (Tableau, Power BI) carry the *original* SQL the client sent, before compilation; the *compiled* warehouse SQL comes from `include_sql`. Clients that submit a semantic field list (MCP, deep analysis) have no original SQL.
- **semantic definition** — `include_yaml` returns the attributes/metrics/filters the run resolved to — what you reproduce or alter a query from.
- **app link** — always **show it** so the user can open the query in Honeydew.
Keep `include_yaml` / `include_sql` off for the initial scan; enable them only on the run you're drilling into. **Deep analysis lands here too** — each `initiate_analysis` step runs semantic-layer queries, so this is where you inspect what an analysis actually computed per step.
---
## Workflows
**Review / audit:** list the relevant slice (by domain, client, user, or time window) and read `client`, `owner`, status, and timestamps. Add `include_yaml` / `include_sql` on a specific run to reproduce or explain it.
**Debug a failure:** list with `status_in="FAILED"`, read the error message, then re-list that query with `include_yaml=true` to see the fields that failed (add `include_sql=true` for warehouse-side errors — permissions, missing table). Reproduce with `get_data_from_fields` from the YAML and fix (see the **query** and **filtering** skills), then report what failed, the app link, and the fix.
**Isolate an internal error (minimal reproduction):** when the error is generic ("internal error"/compilation crash) and names no field, bisect:
1. Pull the failed query's YAML (`include_yaml=true`) and rebuild it verbatim as an ad-hoc `get_data_from_fields` call. Confirm it still errors — if not, the cause is environmental (branch, data, transient), not the query.
2. Drop attributes/metrics/filters and re-run, halving the field set each round; keep whichever half still errors.
3. Converge to the smallest failing query. The field whose removal clears the error — or the minimal combination that only fails together — is the culprit.
4. Report that minimal field list plus its compiled SQL — far more actionable than the original wide query.
Use `get_sql_from_fields` between rounds to watch the offending SQL fragment appear or disappear with the culprit field.
© honeydew-ai · Apache-2.0 · honeydew-ai/honeydew-ai-coding-agents-plugins