/feature-usage-feed

name: feature-usage-feed
description: >
  Set up an LLM-judge evaluation that extracts canonical use cases for a
  PostHog feature at scale and streams the results to a Slack channel as a
  live feed. Use when someone wants to understand how users are actually
  using a specific AI/LLM-powered feature in production — what they're
  investigating, what questions they're trying to answer, and what
  patterns surface — without manually reading hundreds of traces. Assumes
  the feature emits `$ai_generation` and `$ai_evaluation` events with
  `$session_id` linkage to the trigger user's recording (the standard
  setup post the session-summary linkage PRs).

Building a feature usage feed via LLM evals

Some PostHog features (group session summaries, single session summaries, replay AI search, error tracking AI debug, etc.) generate hundreds or thousands of LLM traces per week. Reading them by hand is not feasible. This skill covers the end-to-end pattern for turning that trace volume into a live Slack feed of canonical use cases — what users are actually doing with the feature.

The workflow is **mixed, and leans UI**. Trace inspection and filter discovery (steps 1-2) are MCP-driven. Eval creation, dry-running, and enabling (steps 4-5) are MCP-driven _when_ `posthog:llma-evaluation-*` tools are exposed to your agent — but they often aren't, in which case fall back to the UI (Data pipeline → destinations for the alert is always UI). Each step flags its UI fallback. Expect to finish in the UI even when you start from chat.

When to use

• "How are people actually using [feature X] in production?"
• "Can we identify the canonical use cases for [feature X] so we can write better docs / prioritize improvements?"
• "I want a Slack feed of representative usage examples without manually skimming traces."
• "Set up a feed of use cases for [feature X] in #team-[area]-usage."

If the user just wants to debug a single trace or tune an existing eval, redirect to `exploring-llm-traces` or `exploring-llm-evaluations` instead.

Two filter patterns

This skill supports two different ways to scope an eval to "the feature you care about":

**Pattern A — Feature-native trace_id prefix.** For standalone features that emit their own `$ai_trace_id` pattern (e.g. `session-summary:group:`, `replay-search:`, error-tracking-specific flows). Filter on the prefix.

**Pattern B — PostHog AI agent mode.** For features the user interacts with _via_ PostHog AI in a specific agent mode (error tracking, product analytics, session replay, SQL, flags, surveys, AI observability). Filter on `ai_product = 'posthog_ai' AND agent_mode = '<mode>'`. This requires PR #55160 (merged April 2026) to be deployed, which threads `agent_mode` and `supermode` onto every `$ai_generation` emitted by the chat agent loop. A useful ergonomic side-effect: `agent_mode IS NOT NULL` is a reliable "user-facing chat turn" filter — batch jobs and tool-internal LLM calls go through different code paths and have `agent_mode=null`, so they're excluded for free.

If the user asks "what are users trying to DO in [ET / replay / SQL / flags / surveys] mode of PostHog AI", that's Pattern B. If they ask "what use cases does [standalone feature] cover", that's Pattern A. Pick the pattern first — the prompt, filter, and Slack channel naming all follow from it.

Prerequisites

| Requirement | How to verify | | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | (Pattern A) Feature emits `$ai_generation` events with a stable `$ai_trace_id` pattern | `posthog:execute-sql` for distinct `$ai_trace_id` prefixes | | (Pattern B) `agent_mode` property is present on recent `$ai_generation` events | `posthog:execute-sql` group-by `properties.agent_mode` on recent `ai_product='posthog_ai'` events. Null bucket is normal (batch jobs + tool-internal calls) — you want non-null coverage across the modes you care about. | | `$session_id` is attached to the `$ai_generation` events (links trace to trigger session) | `posthog:execute-sql` for `countIf($session_id IS NOT NULL) / count()` | | `$session_id` is also attached to the `$ai_evaluation` events (lets the Slack alert link to the session) | Same query but on `$ai_evaluation` events after the eval has run once | | User has organisation-level AI data processing approval | Required for `llm_judge` evaluations |

If `$session_id` is missing on either event type, file a backend fix before continuing — there is no UI workaround. The session-summary feature has a worked example of the threading pattern in PR #54952. For Pattern B, the agent-mode threading pattern is in PR #55160.

Tools

| Tool