skills/formatting-insight-axes/SKILL.md
Pick the right y-axis unit when creating or updating a TrendsQuery insight via `posthog:insight-create` or `posthog:insight-update`. Use when the agent is about to add a `formula` purely to convert units (e.g. dividing seconds by 60 to display minutes), when a `math_property` is a duration, currency, ratio, or large count, or whenever the user mentions "format the y-axis", "duration", "seconds", "minutes", "hours", "milliseconds", "ms", "percentage", "currency", "decimals", "axis label", or "axis unit" in the context of a graph insight.
npx skillsauth add posthog/ai-plugin formatting-insight-axesInstall 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.
PostHog renders TrendsQuery insights with a built-in axis formatter. Use it
instead of contorting formula or aggregationAxisPostfix to fake units.
If you are reaching for any of these, stop and pick a format below first:
formula: "A / 60" with aggregationAxisPostfix: " mins" — manual seconds -> minutesformula: "A / 1000" with aggregationAxisPostfix: " s" — manual ms -> secondsformula: "A * 100" with aggregationAxisPostfix: "%" — manual ratio -> percentaggregationAxisPostfix: "ms" / "s" / "min" / "hr" on raw valuesThese freeze the unit at one scale. The built-in formatter picks a friendly unit per value (1.5s, 2m 12s, 1h 4m) and keeps the underlying series numerically correct for further math, breakdowns, and alerts.
Set trendsFilter.aggregationAxisFormat on the TrendsQuery:
| Value | Use when the series is... | Renders as |
| ------------------- | ---------------------------------------- | --------------------------- |
| numeric (default) | a plain count | 1,234 |
| duration | seconds (any scale) | 45s, 2m 12s, 1h 4m |
| duration_ms | milliseconds | 850ms, 1.5s, 1m 4s |
| percentage | already 0-100 | 47.3% |
| percentage_scaled | a ratio 0-1 | 47.3% |
| currency | money in the project's base currency | $1,234.56 (or local code) |
| short | large counts you want compacted | 1.2K, 3.4M |
Companion fields on trendsFilter:
aggregationAxisPrefix — literal prefix (e.g. "$") when you need a symbol
pinned to a specific currency or unit, regardless of project settingsaggregationAxisPostfix — literal suffix; reserve for genuine units the
format can't express (e.g. " req", " events"), never for "mins" /
"s" / "%" — the percentage formats already append the % sign, so a
"%" postfix renders 50%%decimalPlaces — cap decimals (1 or 2 is usually right for currency / ratios)format or prefix carefullyaggregationAxisFormat: "currency" renders with the project's base currency
(set in project settings, defaults to USD). Use it when the underlying values
are in that same currency — e.g. revenue events that PostHog auto-converts to
the project's base currency.
If the values are pinned to a specific currency regardless of project (e.g.
$ai_total_cost_usd is always USD, even on a EUR-base project), use
aggregationAxisPrefix: "$" + decimalPlaces: 2 so the symbol matches the
data. Using format: "currency" here would render USD values with € on a
EUR project.
If the series is in seconds (latency, session length, time-to-first-event,
processing time, page load, etc.), silently default to
aggregationAxisFormat: "duration". Do not stop to ask — the formatter is
non-destructive (the underlying values stay in seconds either way, only the
labels change), so picking it is always at least as good as raw seconds.
Only confirm with the user when they have explicitly named a fixed unit they want pinned ("show this in minutes", "graph the average in hours"):
"I can pin the y-axis to minutes by dividing the series by 60, or use PostHog's
durationformatter which auto-picks seconds / minutes / hours per value —90srenders as1m 30sand5400sas1h 30m. Which would you prefer?"
In one-shot MCP contexts where no user is in the loop, just pick duration
and move on.
{
"kind": "TrendsQuery",
"series": [
{
"kind": "EventsNode",
"event": "$pageview",
"math": "p95",
"math_property": "$performance_page_loaded"
}
],
"trendsFilter": {
"aggregationAxisFormat": "duration_ms"
}
}
{
"kind": "TrendsQuery",
"series": [
{
"kind": "EventsNode",
"event": "$pageleave",
"math": "avg",
"math_property": "$session_duration"
}
],
"trendsFilter": {
"aggregationAxisFormat": "duration"
}
}
{
"trendsFilter": {
"aggregationAxisFormat": "currency",
"decimalPlaces": 2
}
}
{
"trendsFilter": {
"aggregationAxisPrefix": "$",
"decimalPlaces": 2
}
}
{
"kind": "TrendsQuery",
"series": [
{
"kind": "EventsNode",
"event": "checkout_completed",
"math": "dau"
},
{
"kind": "EventsNode",
"event": "checkout_started",
"math": "dau"
}
],
"trendsFilter": {
"formula": "A / B",
"aggregationAxisFormat": "percentage_scaled",
"decimalPlaces": 1
}
}
If you are updating an insight and notice it already uses the
formula/postfix anti-pattern, fix it in the same posthog:insight-update
call — drop the divide-by-N, drop the aggregationAxisPostfix, and set the
matching aggregationAxisFormat. The series values stay the same, only the
labels change. Do not go scanning unrelated insights for this pattern —
fix only the ones you are already touching.
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.