posthog/building-a-dashboard
> Build a new dashboard, or update an existing one, from a set of insights — the same job the in-app assistant does with its upsert-dashboard tool, but over MCP. Use when a user asks to create a dashboard, put several metrics/charts together on one page, assemble a dashboard for a topic (product analytics, retention, revenue, activation, etc.), or add/remove/replace insights on a dashboard they already have. Covers deciding create vs update, reusing existing insights vs creating new ones, and using PostHog's vetted dashboard templates as reference for what a strong dashboard on a topic looks like.
This is a copy. The original lives at posthog/ai-plugin-building-a-dashboard.
npx skills add https://github.com/PostHog/posthog --skill building-a-dashboard
A dashboard is a collection of insight tiles on one page. Your job is to figure out which insights belong on it,
reuse what already exists, create what's missing, and lay them out sensibly — not to blindly generate charts.
First work out whether you're creating a new dashboard or changing an existing one.
dashboards-get-all (its search param does fuzzy name/description matching). If theuser is clearly describing something that already exists, they probably want an update.
dashboard-get to see its current tiles before you change anything.ask a short clarifying question rather than guessing.
PostHog ships vetted dashboard templates for common topics, and orgs can share their own. Consult them before you
build — they're a strong signal of which insights pair well on a topic.
dashboard-templates-list — browse templates (use search for a topic, scope to narrow to global / team /organization). This returns names, descriptions, and tags only.
dashboard-templates-retrieve — open the closest template to see its tiles: which insights it groups together andhow each is queried.
Treat templates as examples, not a spec. Take inspiration from the insights and their groupings, but tailor every
insight to the user's own events, properties, and intent. Don't copy a template verbatim, and don't force a template
onto a request it doesn't fit — a good bespoke dashboard beats a mismatched template every time.
Prefer reusing existing insights over recreating them.
insights-list and read promising ones with insight-get to check they match the user's intent andactually have data. Full-text search misses things named differently, so list broadly before concluding an insight
doesn't exist.
insight-create (see the product-analytics insight skills for query shape).dashboard-create with a short (3–7 word) name and a concise description, then add the insight tiles.dashboard-update. Adding, replacing, or removing insights means sending the full intended set oftiles — insights you omit are removed, so include the ones you want to keep.
dashboard-reorder-tiles) when the user explicitlyasks to rearrange, reorder, or move tiles.
dashboard-insights-run to confirm the tiles return data, then summarize what you built and invite theuser to refine it.
dashboard-widget-catalog-list,dashboard-widgets-batch-add) instead.
Take posthog/building-a-dashboard from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.