skills/choosing-trend-or-slope-view/SKILL.md
Clarify how to visualize change over a time range before building a trend. Use whenever the user asks how much something changed, grew, dropped, improved, or regressed between two points or periods — "how much did X change from A to B", "before vs after", "start vs end", "week over week", "compare this month to last", "change over time" — or mentions a "slope chart" / "slopegraph". Two readings of "change" need different charts: the whole trend (a line, every interval) versus just the two endpoints (a slope, start vs end). Ask which they want, then render it. Not for choosing a saved insight ChartDisplayType in the insight editor.
npx skillsauth add posthog/ai-plugin choosing-trend-or-slope-viewInstall 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.
"How did X change between A and B?" is ambiguous. Two charts answer two different questions, so clarify before you build unless the user already named one:
When the request could be either, ask a short either/or, e.g.:
Do you want to see how it moved across the whole period (a line chart), or just the change from the start to the end (a slope chart)?
If the user clearly wants one — "just tell me how much it grew start to end" → slope; "show me the trend / when did it spike" → line — skip the question and build it.
Both come from the same TrendsQuery over the same date range — the slope is
that series collapsed to its first and last point, not a different query.
Default trends behavior. Create or run a TrendsQuery and leave
trendsFilter.display as ActionsLineGraph (the default, "change over time"):
{
"kind": "TrendsQuery",
"series": [{ "kind": "EventsNode", "event": "$pageview", "math": "total" }],
"dateRange": { "date_from": "2025-01-01", "date_to": "2025-03-31" },
"trendsFilter": { "display": "ActionsLineGraph" }
}
Run the trend with posthog:query-trends. The result card Max renders has a
Line / Bar / Slope view toggle — switch it to Slope to show each series as
a single line from its first to its last point, with the per-series change in the
legend. Tell the user they can flip to the Slope view on the result.
The slope view is best for a clean before→after comparison, especially with several series/categories whose relative movement matters. Pick a date range whose two ends are the points you want compared (the slope uses the first and last interval).
query-trends
result card) and the saved-insight slope (ChartDisplayType.SlopeGraph, behind the
slope-graph-insight feature flag) show the same thing: the first interval's value
vs the last interval's value, at the chosen group-by interval. The grouping defines
the slope — group by month to compare the first vs last month, by day for the first
vs last day. Use the inline view for a quick before→after on a result you're already
looking at; reach for the saved display to persist it on a dashboard where the flag
is enabled. A still-accumulating final period is shown as-is with a dashed connector,
the same affordance the line chart uses for an incomplete tail.compareFilter: { "compare": true } overlays the two periods; a slope is the
better fit when comparing the endpoints of many series at once.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.