Help us improve
Share bugs, ideas, or general feedback.
From honeycomb
Designs and creates Honeycomb boards (dashboards) with SLO panels, queries, and context from code/docs for service health, feature usage, or incidents.
npx claudepluginhub honeycombio/agent-skill --plugin honeycombHow this skill is triggered — by the user, by Claude, or both
Slash command
/honeycomb:create-honeycomb-boardThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Build a board (dashboard) in Honeycomb using the `create_board` MCP tool.
Builds operational monitoring dashboards for Grafana, SigNoz, and similar platforms, focusing on health, latency, throughput, and action-oriented panels from metrics.
Builds production-ready Grafana dashboards with panels, template variables, annotations, and provisioning for Prometheus/Loki metrics. Use for SRE operational views, SLO reporting, or version-controlled deployments.
Generates APM dashboards for Grafana, Datadog, and New Relic with golden signals, request metrics, resource utilization, and more. Use when creating performance monitoring visualizations.
Share bugs, ideas, or general feedback.
Build a board (dashboard) in Honeycomb using the create_board MCP tool.
There is no update tool — define it well before creating.
When building a board, think about the purpose and time frame involved. Some examples:
Use get_slos to list SLOs in the environment. Relevant SLOs will go on the board as slo panels.
Look at the code and docs (using Read/Grep/Glob) to understand the service or feature. Use this to write a text panel. Link to GitHub or documentation if you can.
This will vary greatly depending on the purpose of the board.
Description of the application and link to the code - great for a service board.
What is the feature, and what business impact does it have? - great for a feature board.
What is the problem, and what is the impact? What patterns do we see? - great for a problem board.
Get Honeycomb context: Call get_workspace_context for available environments. Use get_environment to find datasets — each dataset corresponds to an OTEL_SERVICE_NAME.
Code context: Look at the language and any custom attributes (often prefixed app.). Custom fields are prime candidates for breakdowns and business metrics.
Discover columns: Use find_columns or get_dataset_columns. Pay special attention to non-standard columns — those are specific to the application.
Find queries: Use find_queries to see what people have already queried. Check get_triggers for what they alert on — those indicate what matters.
Time range: Default to 2 hours. Use 8–24 hours for lower-volume services. Use 7 days for feature usage boards. Keep it consistent across all panels.
Aim for 6–12 graphs. Stat panels are bonus — they don't count against this limit.
List your candidate queries for the user with reasons before running them. See ${CLAUDE_PLUGIN_ROOT}/skills/create-honeycomb-board/references/board-queries.md for what to include and how to write each kind.
Use run_query for each candidate query. Each result returns a query run PK (like QR-abc123) — you'll use this as the panel id when building the board.
Fix errors. Eliminate queries that return no interesting results.
Think about visual flow and how to make the board expressive. The board uses a 12-column grid — stat panels can sit side-by-side, a heatmap deserves full width, breakdowns benefit from extra height. See ${CLAUDE_PLUGIN_ROOT}/skills/create-honeycomb-board/references/board-layout.md for sizing examples.
Consider preset_filters if viewers will want to slice the board interactively (by route, region, account tier, etc.).
For each panel, display:
query_url from the run_query result metadata). Briefly describe what the results showed.End with: "Here's the board I'd create. Shall I go ahead?"
This step is non-negotiable. If the user says "just create it", "I trust you", or "skip the preview" — show the plan anyway. The user cannot meaningfully confirm something they haven't seen. There is no way to update a board after creation; the only fix is to delete it and start over. Showing the plan first protects them even when they think they don't need it.
The one exception: if the user has already reviewed and approved a specific plan in this conversation, you may proceed.
Call create_board with a panels array. Every panel requires a type field — "query", "slo", or "text" — that determines what other fields apply. See ${CLAUDE_PLUGIN_ROOT}/skills/create-honeycomb-board/references/board-layout.md for the full field reference.
{
"environment_slug": "production",
"name": "Checkout Service",
"description": "...",
"panels": [
{
"type": "text",
"content": "## Checkout Service\nOwned by Platform team. [Source](https://github.com/...)"
},
{
"type": "slo",
"id": "SLO-abc123",
"size": { "width": 4 }
},
{
"type": "query",
"id": "QR-abc123",
"name": "Request Rate",
"chart_type": "stat",
"display_style": "chart",
"size": { "width": 4 }
},
{
"type": "query",
"id": "QR-def456",
"name": "Error Rate",
"chart_type": "stat",
"display_style": "chart",
"size": { "width": 4 }
},
{
"type": "query",
"id": "QR-ghi789",
"name": "Latency Distribution",
"description": "Overall request latency as a heatmap",
"chart_type": "default",
"display_style": "chart",
"size": { "width": 12, "height": 3 }
}
],
"preset_filters": [{ "column": "http.route", "alias": "Route" }],
"tags": ["team:platform", "tier:critical"]
}
Link the user to the board.