Generated banner for Investigate Metric
Generated logo for Investigate Metric

Investigate Metric

PostHogOfficialPublished by PostHog

  • Skill
  • Workflow
  • Data and AI
  • MIT
  • Low risk
  • Has scripts

From the author

Diagnose why a product metric changed (dropped, spiked, or plateaued) by orchestrating breakdowns, actors, paths, lifecycle, retention, and annotations queries. Use when the user reports an anomaly, asks "why did X change?", asks to explain or walk them through a chart, or needs root-cause analysis for a trend, funnel, retention, stickiness, or lifecycle metric.
— the description by PostHog

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The investigate-metric skill provides a structured, step-by-step procedure for root-cause analysis of product metric anomalies. It guides the user through classifying the metric, confirming the anomaly, checking for variance, identifying known changes, and running specific playbooks based on the query type. The skill leverages various PostHog tools to isolate segments, compare periods, and generate clear explanations for stakeholders.

What it does

  • Classifies metric anomalies based on query type (Trends, Funnels, Retention, etc.).
  • Performs variance checks to distinguish between real anomalies and expected seasonality.
  • Correlates anomalies with recent feature flags, experiments, and annotations.
  • Executes specialized playbooks for deep-dive analysis into specific metric behaviors.
  • Generates interactive chart explanations to walk users through findings.
  • Produces structured written reports when chart explanations are not applicable.

When to use it

  • When a user asks why a specific product metric has dropped, spiked, or plateaued.
  • When investigating anomalies in dashboards, saved insights, or custom queries.
  • When a user requests an explanation or a walkthrough of a specific chart.
  • When performing root-cause analysis for trends, funnels, retention, or lifecycle metrics.

Advantages

  • Standardizes the investigation process to ensure consistent and thorough analysis.
  • Reduces manual effort by automating comparisons to prior periods and breakdown attribution.
  • Provides a clear taxonomy of common causes to speed up hypothesis generation.
  • Integrates directly with PostHog tools for seamless data retrieval and visualization.

Usage examples

“Why did our signup conversion rate drop last Tuesday?”
The agent will classify the metric, run a funnel analysis, compare the date range to prior periods, and identify if the drop correlates with a specific release or traffic source.
“Can you walk me through this retention chart?”
The agent will analyze the retention cohort data, identify key trends or shifts, and generate an interactive chart explanation highlighting the most significant moments.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/posthog/investigate-metric/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip investigate-metric.zip -d .agents/skills

Documentation by PostHog

Investigating a metric change

For "why did X change?" questions about a saved insight, dashboard tile, or pasted query, and for "explain this chart" or "walk me through this" when the user names no change. Don't load this skill for plain "what is X?" questions — only when there's a chart or an observed change to explain.

Tools

Targets PostHog MCP v2. Typed query tools accept the query body directly — pass kind, series, dateRange as top-level fields, do not wrap in InsightVizNode.

ToolPurpose
posthog:query-trendsTrends (count over time)
posthog:query-funnelFunnels (multi-step conversion)
posthog:query-retentionRetention (cohort return rates)
posthog:query-stickinessStickiness (active days per user)
posthog:query-lifecycleLifecycle (new/returning/resurrecting/dormant)
posthog:query-pathsPaths (navigation flow)
posthog:query-trends-actorsUsers behind a trend bucket (trends source only)
posthog:execute-sqlExisting SQL insights and custom analysis
posthog:read-data-schemaDiscover events, properties, sample values
posthog:insight-get / -queryFetch a saved insight's metadata / data
posthog:explain-chartWalk the user through a trends chart (Step 5)

Plus the standard PostHog tools the playbooks reference by name (feature-flag-get-all, experiment-list, annotations-list, query-error-tracking-issues-list, query-logs, query-session-recordings-list, cohorts-list/-create, annotation-create, insight-create).

Helper scripts

  • compare_to_prior_periods.py — auto-detects interval and compares recent values to the natural cycle (day-of-week, hour-of-week, or sequential). Use to resolve step 2.2 cheaply.

  • breakdown_attribution.py — ranks breakdown segments by absolute delta and flags offsetting moves.

python3 scripts/compare_to_prior_periods.py < query_result.json
WINDOW=7 python3 scripts/breakdown_attribution.py < breakdown_result.json

Step 1 — Classify the metric

Read query.kind from the source the user pointed at:

  • Saved insight (URL, short_id): posthog:insight-get → query.kind. Use posthog:insight-query if you also need the numbers.

  • A query you already ran or the user pasted: read kind directly.

  • A metric the user only names, such as "signups", or shows in a screenshot: find its event with posthog:read-data-schema and run it as one series over time with posthog:query-trends. That query is your TrendsQuery. When query-trends cannot express the metric, such as a warehouse-only metric or a custom SQL join, run it with posthog:execute-sql and treat it as a HogQLQuery.

  • Nothing pointed at, or several events could be the metric: ask which one. Don't guess.

kindPlaybook
TrendsQuerytrend-playbook.md
FunnelsQueryfunnel-playbook.md
RetentionQueryretention-playbook.md
StickinessQuerystickiness-playbook.md
LifecycleQuerylifecycle-playbook.md
PathsQuerypaths-playbook.md
HogQLQueryroute by what the SQL aggregates (see below)

If kind === "TrendsQuery" and trendsFilter.display === "BoxPlot", use box-plot-playbook.md — distribution metric, no breakdowns.

For HogQLQuery insights, classify by the SQL's shape: count over time → trend playbook, multi-step conversion → funnel playbook, cohort return → retention playbook. Run the SQL through posthog:execute-sql to get the data, then follow the closest playbook's steps. See HogQL insights in shared-patterns.md.

If the user's question spans multiple kinds, run the playbooks in sequence.

Choose how you will show the findings

Decide this now, before the investigation, because it changes which queries you keep.

When the user gave you a saved insight or a query that is a TrendsQuery over time (not a box plot, 2D heatmap or scatter plot), or named a metric you ran as one, the investigation ends with a chart explanation from posthog:explain-chart. posthog:explain-chart exists only where chart explanations are enabled, so check for it now and read its schema. Where PostHog tools run through exec, it is not in your own tool list: run info explain-chart before you decide it is missing. When it does not exist, the findings go in a written report. The chart explanation is the answer, in place of a notebook or a long reply. Write a notebook as well only when the user asks for one. For anything else, such as a metric that only SQL can express, the findings go in a written report.

When it is a chart explanation:

  • Add "Show the chart explanation (Step 5)" as the last item of your plan or to-do list.

  • Keep the query behind each finding. The chart explanation runs it again and draws the result beside the finding. Prefer an insight query, such as a TrendsQuery with a breakdown or a property filter, and use SQL only for what an insight query cannot express.

Step 2 — Common opening moves

2.1 Confirm the anomaly

Run the primary tool. Record baseline, current, delta (absolute and %), and the start of the anomaly window.

When the user asked you to explain a trends chart over time and named no change, find what stands out first with what-stands-out.md. Each moment it finds becomes its own anomaly to run through the rest of the steps, most striking first. For funnels, retention, paths and other kinds, use that kind's playbook to choose what to look into.

2.2 Variance check

Widen to 3–4× the user's interval (or use compareFilter: {"compare": true} on TrendsQuery / StickinessQuery; for other kinds run two date ranges). Pipe the widened result through compare_to_prior_periods.py — it flags seasonality, partial right-edge buckets, and real anomalies. If the movement is normal variance, report that and stop.

2.3 Known changes in the window

In rough order of signal:

  • posthog:feature-flag-get-all → flags with updated_at near the anomaly start.

  • posthog:experiment-list → start_date / end_date near the start.

  • posthog:annotations-list → date_marker near the start.

  • git log for the window if the repo is reachable (highest signal when available).

Any match is a hypothesis to confirm in the playbook (usually via breakdown on $feature/<flag_key>, app_version, or utm_source).

Step 3 — Run the playbook

Open the playbook for the kind from Step 1 and follow its numbered steps. Carry the record from 2.1 and any candidates from 2.3 into it.

Step 4 — Cross-check

Pick a segment the suspected cause should not have affected and rerun there. Stable in the control = strong hypothesis; moved too = expand the investigation. Skip when 2.2 already explained the movement.

Step 5 — Write findings

Before you write your answer, call posthog:explain-chart when the investigation has a TrendsQuery over time. Do this after a long investigation too, and when most of your evidence is SQL. For anything else, use the written report.

The chart explanation

It draws the chart with each moment highlighted and lets the user step through them. Map the investigation onto it:

  • Anomaly → one chapter per moment, with start and end copied exactly from the chart's days. The app works out each chapter's numbers from the chart, so leave them out of summary.

  • Likely cause and Confidence → cause, confidence and confidence_reason.

  • Evidence → evidence, each finding with the query that produced it, the insightShortId of a saved insight, or a url to a GitHub pull request or commit. No other links are accepted. The chart explanation runs each query and draws it: an insight query with its insight chart, and a HogQLQuery from its rows. Shape the SQL for the chart, with the x-axis column first, then optionally one text column to break down by, then the numbers. Prefer a series over time to a before-and-after comparison, so the user sees when the change happened.

  • Zoomed-in evidence → when the metric moved suddenly, add one finding that zooms in on the change. Use the insight's own query with a dateRange around the change, at the interval that shows it best, from minute to day. Filter it to the segment the cause points at, such as the affected browser or region.

  • A headline of one sentence with no numbers sums up the whole chart. Wrap each name behind a moment, such as the referrer of a spike or the country behind a rise, in **double asterisks** so the chart explanation highlights it. Do the same in each cause.

Call posthog:explain-chart first. It reports any chapter whose dates match no point on the chart, so fix those dates and call it again. When its response says the user already sees the result, the chart explanation is on screen, and you are done. Otherwise call posthog:render-ui with tool_name explain-chart and the same input as tool_input. When render-ui does not exist, call posthog:explain-chart-save with the same arguments and give the user the link it returns, which opens the chart explanation in PostHog. When the call fails because the tool does not exist, or neither render-ui nor a link is available, the user sees nothing, so write the written report instead.

Then reply briefly. Say which chapter to look at first, then add only what the chart explanation cannot hold, such as a caveat about the data, a linked fix or a decision that is still open. End with one offer from below. The chart explanation already holds the chart, the chapters, their causes and their evidence, so do not describe the chart or list the moments again.

The written report

Without the chart explanation, use the format below. Offer to save key charts via posthog:insight-create. If a cause is found and no annotation marks it, offer posthog:annotation-create. See common-causes.md for the cause taxonomy.

# Investigation: <metric>

**Anomaly**: <baseline> → <current> (<delta>) starting <date>

## Likely cause

<one sentence>

**Confidence**: low | medium | high — <one-line reason>

**Evidence**

- <query result>
- <flag / experiment / annotation / commit if applicable>

## Possible causes (ruled out)

- <hypothesis>: <why>

## Affected segment

- <shared properties of affected users/events>

## Data gaps

- <checks skipped and why>

## Suggested follow-ups

- <concrete next action>
- <offer to save chart / create annotation>

Confidence rule of thumb:

  • high — multiple independent signals corroborate (e.g. a segment isolates the delta and a flag/version aligns and an error or annotation matches).

  • medium — one corroborating signal, or strong pattern-match without a cross-check.

  • low — pattern matches a known cause but no corroboration, or the data only rules things out.

Link insights and dashboards inline: [Name](/insights/short_id).

Reference files

Files

scripts/compare_to_prior_periods.py

#!/usr/bin/env python3
"""Compare a recent series to comparable prior periods, accounting for cycles.

Reads the JSON output of a `posthog:query-trends` (or similar) call on stdin or
as a file path. Auto-detects interval and picks the right cycle:

    minute → no cycle, rolling (last N vs preceding N)
    hour   → weekly cycle (168 buckets, weekday × hour-of-day)
    day    → weekly cycle (7 buckets, weekday)
    week   → no cycle, sequential
    month  → no cycle, sequential

Use after step 2.1 of SKILL.md to resolve the variance question (step 2.2).

Usage:
    python3 scripts/compare_to_prior_periods.py < query_result.json
    python3 scripts/compare_to_prior_periods.py query_result.json

Optional env:
    TOLERANCE=N.NN  Fraction outside prior min/max counted as still "in range"
                    (default 0.10 — i.e. 10% wiggle on each side of the band).
    TOP=N           For hourly output, how many most-deviated points to show
                    (default 10).
    RECENT=N        How many recent intervals to evaluate (default: one cycle).
"""

from __future__ import annotations

import json
import os
import sys
from datetime import datetime
from statistics import median


WEEKDAYS = ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"]


def load_input() -> dict:
    if len(sys.argv) > 1:
        with open(sys.argv[1]) as f:
            raw = f.read()
    else:
        raw = sys.stdin.read()
    parsed = json.loads(raw)
    if isinstance(parsed, list) and parsed and parsed[0].get("type") == "text":
        parsed = json.loads(parsed[0]["text"])
    return parsed


def extract_series(payload: dict) -> tuple[list[str], list[float], str, str]:
    """Return (days, data, label, interval)."""
    results = payload.get("results") or payload.get("result") or []
    if not results:
        raise SystemExit("No results in payload — is this a trends query response?")
    series = results[0]
    days = series.get("days") or []
    data = series.get("data") or []
    label = series.get("label") or series.get("custom_name") or "metric"

    interval = (payload.get("query") or {}).get("interval")
    if not interval:
        interval = infer_interval_from_days(days)

    if len(days) != len(data):
        raise SystemExit(f"days ({len(days)}) and data ({len(data)}) length mismatch")
    return days, data, label, interval


def infer_interval_from_days(days: list[str]) -> str:
    """Best-effort interval detection from the gap between days[0] and days[1]."""
    if len(days) < 2:
        return "day"
    a = parse_dt(days[0])
    b = parse_dt(days[1])
    if a is None or b is None:
        return "day"
    delta = abs((b - a).total_seconds())
    if delta < 120:
        return "minute"
    if delta < 7200:
        return "hour"
    if delta < 60 * 60 * 30:  # < ~30 hours = day
        return "day"
    if delta < 60 * 60 * 24 * 10:
        return "week"
    return "month"


def parse_dt(s: str) -> datetime | None:
    s = s.replace("Z", "+00:00")
    for fmt in (None, "%Y-%m-%dT%H:%M:%S", "%Y-%m-%d %H:%M:%S", "%Y-%m-%d"):
        try:
            return datetime.fromisoformat(s) if fmt is None else datetime.strptime(s, fmt)
        except ValueError:
            continue
    return None


def fmt(v: float) -> str:
    a = abs(v)
    sign = "-" if v < 0 else ""
    if a >= 1_000_000:
        return f"{sign}{a / 1_000_000:.2f}M"
    if a >= 1_000:
        return f"{sign}{a / 1_000:.1f}K"
    return f"{sign}{a:,.0f}"


def classify(value: float, prior: list[float], tolerance: float) -> tuple[str, float]:
    """Return (verdict, deviation_pct).

    deviation_pct is signed; 0 means inside the prior min/max band.
    """
    if not prior:
        return "no priors", 0.0
    lo, hi = min(prior), max(prior)
    lo_band = lo * (1 - tolerance)
    hi_band = hi * (1 + tolerance)
    if lo_band <= value <= hi_band:
        return "in range", 0.0
    if value < lo_band:
        pct = (value - lo) / lo * 100 if lo else 0
        return f"BELOW ({pct:+.0f}% vs min)", pct
    pct = (value - hi) / hi * 100 if hi else 0
    return f"ABOVE ({pct:+.0f}% vs max)", pct


def compare_cycle_keyed(
    points: list[tuple[datetime, float]],
    cycle_len: int,
    key_fn,
    tolerance: float,
) -> tuple[list[dict], int, int]:
    """Group prior points by cycle key, compare recent points to their bucket.

    Returns (results, in_range_count, out_of_range_count).
    """
    if len(points) < cycle_len * 2:
        return [], 0, 0
    recent = points[-cycle_len:]
    priors = points[:-cycle_len]

    grouped: dict = {}
    for dt, v in priors:
        grouped.setdefault(key_fn(dt), []).append(v)

    last_dt = recent[-1][0]
    out: list[dict] = []
    in_range = out_of_range = partial = 0
    for dt, v in recent:
        key = key_fn(dt)
        prior_vals = grouped.get(key, [])
        verdict, dev = classify(v, prior_vals, tolerance)
        # Soften: if this is the very last bucket and it's >=50% below prior min,
        # it's almost certainly a partial period (incomplete day / hour).
        is_last = dt == last_dt
        if (
            is_last
            and prior_vals
            and "BELOW" in verdict
            and v < min(prior_vals) * 0.5
        ):
            verdict = f"PARTIAL? ({(v - min(prior_vals)) / min(prior_vals) * 100:+.0f}% vs min)"
            partial += 1
        elif "in range" in verdict:
            in_range += 1
        elif prior_vals:
            out_of_range += 1
        out.append({
            "dt": dt,
            "key": key,
            "value": v,
            "prior_min": min(prior_vals) if prior_vals else None,
            "prior_max": max(prior_vals) if prior_vals else None,
            "prior_median": median(prior_vals) if prior_vals else None,
            "n_prior": len(prior_vals),
            "verdict": verdict,
            "deviation": abs(dev),
            "partial": "PARTIAL?" in verdict,
        })
    return out, in_range, out_of_range


def report_day_cycle(label: str, days: list[str], data: list[float], tolerance: float) -> None:
    points: list[tuple[datetime, float]] = [
        (dt, v) for d, v in zip(days, data) if (dt := parse_dt(d)) is not None
    ]

    results, in_range, out_of_range = compare_cycle_keyed(
        points, cycle_len=7, key_fn=lambda dt: dt.weekday(), tolerance=tolerance
    )

    print(f"# Same-day-of-week comparison — {label}")
    print()
    print(f"Window: {days[0]} → {days[-1]}  ({len(days)} days)")
    print(f"Cycle: weekly  (each weekday compared to prior {(len(days) // 7) - 1} same-weekdays)")
    print()
    if not results:
        print("Not enough history — need at least 2 full weeks. Widen the dateRange.")
        return

    print("| Day | Most recent | Prior median | Prior range | Verdict |")
    print("| --- | ---: | ---: | --- | --- |")
    for r in results:
        prior_range = (
            f"{fmt(r['prior_min'])} – {fmt(r['prior_max'])}" if r["prior_min"] is not None else "—"
        )
        print(
            f"| {WEEKDAYS[r['key']]} {r['dt'].date()} "
            f"| {fmt(r['value'])} "
            f"| {fmt(r['prior_median']) if r['prior_median'] is not None else '—'} "
            f"| {prior_range} "
            f"| {r['verdict']} |"
        )

    print()
    has_partial = any(r.get("partial") for r in results)
    if out_of_range == 0 and in_range > 0:
        msg = (
            f"**Verdict: every completed weekday is within ±{tolerance:.0%} of the "
            "prior weeks' range — likely normal seasonality.**"
        )
        if has_partial:
            msg += " The last day looks partial; ignore it for now and re-check after it completes."
        print(msg)
    elif out_of_range > 0:
        print(
            f"**Verdict: {out_of_range} completed weekday(s) outside the prior weeks' "
            f"range (±{tolerance:.0%} tolerance) — proceed with the playbook.**"
        )
        if has_partial:
            print("(The last day appears partial and was excluded from the count.)")


def report_hour_cycle(
    label: str, days: list[str], data: list[float], tolerance: float, top: int
) -> None:
    points: list[tuple[datetime, float]] = [
        (dt, v) for d, v in zip(days, data) if (dt := parse_dt(d)) is not None
    ]

    results, in_range, out_of_range = compare_cycle_keyed(
        points,
        cycle_len=168,
        key_fn=lambda dt: (dt.weekday(), dt.hour),
        tolerance=tolerance,
    )

    print(f"# Same-hour-of-week comparison — {label}")
    print()
    print(f"Window: {days[0]} → {days[-1]}  ({len(days)} hours, "
          f"~{len(days) / 168:.1f} weeks)")
    print(f"Cycle: weekly × hourly (168 buckets, each hour vs prior weeks' same weekday-hour)")
    print()
    if not results:
        print("Not enough history — need at least 2 full weeks of hourly data. Widen the dateRange.")
        return

    print(f"Last 168 hours: **{in_range} in range, {out_of_range} outside ±{tolerance:.0%}**")
    print()

    flagged = [
        r for r in results
        if "in range" not in r["verdict"] and not r.get("partial")
    ]
    flagged.sort(key=lambda r: r["deviation"], reverse=True)

    if flagged:
        print(f"## Top {min(top, len(flagged))} most deviated hours")
        print()
        print("| Time | Value | Prior median | Prior range | Verdict |")
        print("| --- | ---: | ---: | --- | --- |")
        for r in flagged[:top]:
            wd, hr = r["key"]
            prior_range = (
                f"{fmt(r['prior_min'])} – {fmt(r['prior_max'])}" if r["prior_min"] is not None else "—"
            )
            print(
                f"| {WEEKDAYS[wd]} {hr:02d}:00 ({r['dt'].strftime('%Y-%m-%d')}) "
                f"| {fmt(r['value'])} "
                f"| {fmt(r['prior_median']) if r['prior_median'] is not None else '—'} "
                f"| {prior_range} "
                f"| {r['verdict']} |"
            )
        print()

        # Aggregate where the flags concentrate
        by_weekday: dict[int, int] = {}
        by_hour: dict[int, int] = {}
        for r in flagged:
            wd, hr = r["key"]
            by_weekday[wd] = by_weekday.get(wd, 0) + 1
            by_hour[hr] = by_hour.get(hr, 0) + 1

        if by_weekday:
            print("## Flags by weekday")
            print()
            for wd in sorted(by_weekday, key=lambda k: -by_weekday[k]):
                print(f"- {WEEKDAYS[wd]}: {by_weekday[wd]}")
            print()
        if by_hour:
            print("## Flags by hour-of-day")
            print()
            for hr in sorted(by_hour, key=lambda k: -by_hour[k])[:10]:
                print(f"- {hr:02d}:00 — {by_hour[hr]}")
            print()

    print()
    if out_of_range == 0 and in_range > 0:
        print(
            f"**Verdict: every hour in the last week is within ±{tolerance:.0%} of "
            "prior weeks — likely normal seasonality.**"
        )
    elif out_of_range > 0:
        if out_of_range / max(1, in_range + out_of_range) > 0.5:
            print(
                f"**Verdict: >50% of hours are out of range — likely a sustained shift, "
                "not a localized incident. Proceed with the playbook.**"
            )
        else:
            print(
                f"**Verdict: {out_of_range} flagged hours concentrated in the table above. "
                "Check whether they cluster around a deploy time / incident — "
                "see SKILL.md step 2.3.**"
            )


def report_sequential(
    label: str,
    days: list[str],
    data: list[float],
    interval: str,
    recent_n: int,
    tolerance: float,
) -> None:
    """Sequential comparison for week / month / minute — no natural cycle."""
    if len(data) < recent_n + 3:
        print(f"# Sequential comparison — {label}", flush=True)
        print()
        print(
            f"Not enough history for {interval} interval — need at least "
            f"{recent_n + 3} points; have {len(data)}. Widen the dateRange."
        )
        return

    recent = list(zip(days[-recent_n:], data[-recent_n:]))
    priors = data[:-recent_n]
    prior_med = median(priors)
    lo, hi = min(priors), max(priors)

    print(f"# Sequential comparison — {label}")
    print()
    print(
        f"Window: {days[0]} → {days[-1]}  ({len(days)} {interval} intervals). "
        f"No natural cycle for {interval} — comparing last {recent_n} to "
        f"prior {len(priors)} values."
    )
    print()
    print(f"Prior median: {fmt(prior_med)}  |  range: {fmt(lo)} – {fmt(hi)}")
    print()
    print(f"| {interval.title()} | Value | Verdict |")
    print("| --- | ---: | --- |")
    out_of_range = 0
    in_range = 0
    for d, v in recent:
        verdict, _ = classify(v, priors, tolerance)
        if "in range" in verdict:
            in_range += 1
        else:
            out_of_range += 1
        print(f"| {d} | {fmt(v)} | {verdict} |")
    print()
    if out_of_range == 0:
        print(
            f"**Verdict: all recent {interval}s within ±{tolerance:.0%} of the prior "
            "range — within normal variance.**"
        )
    else:
        print(f"**Verdict: {out_of_range} of {recent_n} recent {interval}s outside the "
              f"prior range — proceed with the playbook.**")


def main() -> int:
    tolerance = float(os.environ.get("TOLERANCE", "0.10"))
    top = int(os.environ.get("TOP", "10"))
    recent_override = os.environ.get("RECENT")

    payload = load_input()
    days, data, label, interval = extract_series(payload)

    if not days:
        print("Empty series — nothing to compare.", file=sys.stderr)
        return 1

    if interval == "day":
        report_day_cycle(label, days, data, tolerance)
    elif interval == "hour":
        report_hour_cycle(label, days, data, tolerance, top)
    elif interval in {"minute", "second"}:
        recent_n = int(recent_override) if recent_override else 60
        report_sequential(label, days, data, interval, recent_n, tolerance)
    elif interval == "week":
        recent_n = int(recent_override) if recent_override else 4
        report_sequential(label, days, data, interval, recent_n, tolerance)
    elif interval == "month":
        recent_n = int(recent_override) if recent_override else 3
        report_sequential(label, days, data, interval, recent_n, tolerance)
    else:
        print(f"Unsupported interval '{interval}'. Treating as sequential.", file=sys.stderr)
        recent_n = int(recent_override) if recent_override else 7
        report_sequential(label, days, data, interval, recent_n, tolerance)

    return 0


if __name__ == "__main__":
    sys.exit(main())

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Python

Security

What our scanner noticed· Low risk

  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
PostHog
Publisher
PostHog (Official)
Source
PostHog/skills · skills/omnibus/investigate-metric · commit a5d30e7
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by PostHog or PostHog.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download investigate-metric.zip