Manage Honeycomb boards: create, update panels, configure visualizations, and review in Chrome. Activated by explicit mention of Honeycomb boards or /board invocation.
Manages Honeycomb boards by creating, updating panels, configuring visualizations, and reviewing them in Chrome.
npx claudepluginhub bendrucker/honeycomb-cliThis skill inherits all available tools. When active, it can use any tool Claude has access to.
references/api-types.mdManage Honeycomb boards using the CLI. Covers the full lifecycle: creating boards, adding query/text/SLO panels, configuring visualization settings, and reviewing boards visually in Chrome.
For query design guidance (calculations, filters, breakdowns, visualization selection, granularity tuning, anti-patterns), load the /query skill.
Verify auth before any board operation:
honeycomb auth status
A config key is required. If not configured, run honeycomb auth login.
honeycomb board create --name "Service Health" --description "Key metrics for the API gateway"
Save the returned board ID for subsequent operations.
honeycomb board get <board-id> --format json
Always fetch the current board state before updating. The update command merges JSON fields, but panels are replaced as a whole array.
Pipe JSON to update. Non-specified top-level fields are preserved (name, description, tags, preset_filters, layout_generation). Panels are replaced entirely when included.
jq -n '{panels: [...]}' | honeycomb board update <board-id> --file -
To replace the board completely (discarding all existing fields):
honeycomb board update <board-id> --file board.json --replace
Adding a query panel requires three steps: create a query, create a query annotation, then add the panel to the board.
Use the Honeycomb MCP server to create and test queries when available. This works on all plans and doesn't require Enterprise API permissions.
honeycomb mcp call run_query -f dataset=<dataset> -f query_json='<json>'
To save a query via the API (requires appropriate key permissions):
honeycomb api -X POST /1/queries/<dataset> --input <query-file>.json
Note: piping JSON via stdin can fail if string values contain special characters (e.g., != in filter operators). Use --input with a file instead.
Extract the query id from the response.
jq -n '{name: "Panel Title", query_id: "<query-id>"}' | honeycomb query annotation create --dataset <dataset> --file -
Extract the annotation id from the response.
Fetch the current board, append the new panel to the panels array, and update:
honeycomb board get <board-id> --format json | \
jq '.panels += [{"type": "query", "query_panel": {"query_id": "<qid>", "query_annotation_id": "<aid>", "query_style": "graph", "visualization_settings": {"charts": [{"chart_type": "tsbar"}]}}}]' | \
honeycomb board update <board-id> --file - --replace
When adding panels to an existing board, fetch the board JSON first, modify the panels array, and send the full board back with --replace. The merge behavior without --replace replaces the panels array wholesale if the panels key is present.
Important: The dataset field appears in board get output on query panels but is rejected by the update API. Strip it before sending: jq 'walk(if type == "object" and has("dataset") and has("query_id") then del(.dataset) else . end)'
{
"type": "query",
"query_panel": {
"query_id": "<id>",
"query_annotation_id": "<id>",
"query_style": "graph",
"visualization_settings": { ... }
},
"position": {"x_coordinate": 0, "y_coordinate": 0, "width": 6, "height": 4}
}
query_style: "graph" (default), "table", "combo" (graph + table).
Use for section headers, documentation, and context. Supports Markdown (max 10,000 chars).
{
"type": "text",
"text_panel": {"content": "## Request Performance\nKey latency and throughput metrics."},
"position": {"x_coordinate": 0, "y_coordinate": 0, "width": 12, "height": 1}
}
{
"type": "slo",
"slo_panel": {"slo_id": "<id>"},
"position": {"x_coordinate": 0, "y_coordinate": 0, "width": 6, "height": 4}
}
Boards are launchpads, not wallboards -- each panel should answer a question or launch a deeper inquiry. A panel that shows what but not a path to why is a dead end. Every query panel is clickable in Honeycomb, so design panels as starting points for investigation, not final answers.
Organize panels top-to-bottom by importance:
Use text panels as section dividers to organize large boards:
{"type": "text", "text_panel": {"content": "## Downstream Dependencies"}}
Add context where metrics need interpretation:
{"type": "text", "text_panel": {"content": "**Note**: Latency spikes >500ms typically correlate with database connection pool exhaustion. Check the connection pool metrics below."}}
Add up to 5 preset filters for cross-board filtering. These create dropdown filters at the top of the board.
{
"preset_filters": [
{"column": "service.name", "alias": "Service"},
{"column": "environment", "alias": "Environment"},
{"column": "http.route", "alias": "Route"}
]
}
alias is the display label (max 50 chars)service.name, environment, k8s.namespace.name, http.routeCategorize boards with up to 10 key:value tags (lowercase only):
{
"tags": [
{"key": "team", "value": "platform"},
{"key": "service", "value": "api-gateway"}
]
}
Set layout_generation: "auto" and omit position fields. Honeycomb arranges panels automatically.
The board uses a 12-column grid. Specify position on each panel:
{"x_coordinate": 0, "y_coordinate": 0, "width": 6, "height": 4}
width: 12width: 6, second panel at x_coordinate: 6width: 4Common layouts:
width: 6 panelswidth: 12, height: 1) followed by stat cards (width: 3, height: 3)width: 12, height: 5) for deep-dive queriesWhen adding panels to an existing board with manual positioning, fetch the current board to understand the y_coordinate of the last panel, then place new panels below.
Board views are saved filter configurations that provide different perspectives on the same board.
honeycomb board view create --board <board-id> --name "Production" --filter "environment:=:production"
Multiple filters:
honeycomb board view create --board <board-id> --name "API Errors" \
--filter "service.name:=:api-gateway" \
--filter "http.status_code:>=:500"
Filter format: column:operation:value (value optional for exists/does-not-exist).
honeycomb board view list --board <board-id>
After creating or updating a board, open it in Chrome for visual assessment.
Get the board URL:
honeycomb board get <board-id> --format json | jq -r '.links.board_url'
Open the board in Chrome using mcp__claude-in-chrome__navigate
Ask the user to confirm they are logged into Honeycomb and can see the board
Use mcp__claude-in-chrome__read_page to capture the board state
Assess the board for:
Report findings and suggest specific changes using the update workflow above
When reviewing automatically, check:
When the user is reviewing:
Fetch the board, filter out the panel by index or query_annotation_id, and update:
honeycomb board get <board-id> --format json | \
jq 'del(.panels[2])' | \
honeycomb board update <board-id> --file - --replace
Fetch the board and rearrange the panels array or update position coordinates:
honeycomb board get <board-id> --format json | \
jq '.panels |= [.[2], .[0], .[1]] + .[3:]' | \
honeycomb board update <board-id> --file - --replace
Expert guidance for Next.js Cache Components and Partial Prerendering (PPR). **PROACTIVE ACTIVATION**: Use this skill automatically when working in Next.js projects that have `cacheComponents: true` in their next.config.ts/next.config.js. When this config is detected, proactively apply Cache Components patterns and best practices to all React Server Component implementations. **DETECTION**: At the start of a session in a Next.js project, check for `cacheComponents: true` in next.config. If enabled, this skill's patterns should guide all component authoring, data fetching, and caching decisions. **USE CASES**: Implementing 'use cache' directive, configuring cache lifetimes with cacheLife(), tagging cached data with cacheTag(), invalidating caches with updateTag()/revalidateTag(), optimizing static vs dynamic content boundaries, debugging cache issues, and reviewing Cache Component implementations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.