skills/building-a-dashboard/SKILL.md
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.
npx skillsauth add posthog/ai-plugin building-a-dashboardInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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 the
user is clearly describing something that already exists, they probably want an update.dashboard-get to see its current tiles before you change anything.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 and
how 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 and
actually 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 of
tiles — insights you omit are removed, so include the ones you want to keep.dashboard-reorder-tiles) when the user explicitly
asks to rearrange, reorder, or move tiles.dashboard-insights-run to confirm the tiles return data, then summarize what you built and invite the
user to refine it.dashboard-widget-catalog-list,
dashboard-widgets-batch-add) instead.data-ai
Signals scout for PostHog Tasks, the agent work items a project runs. Two lenses: delivery health (runs failing, clustered by repository and error class, and retry storms) every run, and on a slower rotation demand (recurring asks across human-authored tasks that point at a product gap). Skips the scout fleet's own run rows.
devops
Signals scout for the PostHog Conversations (support inbox) product. Watches the `$conversation_*` ticket-lifecycle events for support-delivery regressions — SLA breach-rate steps, first-response latency blowouts, backlog inflow-vs-resolution imbalance, and channel / assignment concentration — and files each dated regression as a report. Complements the per-ticket product-feedback signals the emission pipeline already fires; does not re-surface individual ticket content.
development
Populates and maintains a project's data catalog (semantic layer): canonical metrics, trust marks (certifications) on warehouse tables/views, and reviewed table relationships. Use when asked to set up / seed / bootstrap the data catalog or semantic layer, to catalog a project's metrics, to certify or deprecate data sources, to propose or review table joins, or to work through the proposal review queue. To *use* an existing catalog to answer a business-number question, see querying-posthog-data instead. Trigger terms: data catalog, semantic layer, canonical metric, certify table, deprecate source, relationship proposal, metric drift, review queue.
tools
Investigate logs in a PostHog project: verify a service or deployment is healthy, explain an error spike, triage an incident, or understand what a log stream is saying. Use when the user asks to "check the logs", asks whether a service, deploy, release, or change is working or broke anything, asks why errors are up or what changed, or wants the root cause of failures visible in logs. Routes the logs MCP tools (services overview, pattern mining, before/after pattern diffing, bucketed counts, facets, raw rows) so investigations start from summaries instead of raw rows or hand-written SQL over the logs table.