Design and then create a board (dashboard) in Honeycomb with queries and SLOs. Trigger phrases: "create a board", "make a board", "build a dashboard", "create a Honeycomb board", "make a dashboard in Honeycomb", "set up a board", "dashboard for my service", "visualize service health", "golden signals dashboard", "set up monitoring board", or any request to design and create or build a Honeycomb board or dashboard.
From honeycombnpx claudepluginhub honeycombio/agent-skill --plugin honeycombThis skill is limited to using the following tools:
references/board-layout.mdreferences/board-queries.mdDispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Executes pre-written implementation plans: critically reviews, follows bite-sized steps exactly, runs verifications, tracks progress with checkpoints, uses git worktrees, stops on blockers.
Guides idea refinement into designs: explores context, asks questions one-by-one, proposes approaches, presents sections for approval, writes/review specs before coding.
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.