finding-experiments

Resolves a PostHog experiment reference from natural language to a concrete experiment ID by browsing `experiment-list` (not feature-flag tools), with disambiguation when multiple experiments match. Use when the user names or quotes an experiment ("split test demo", "the File engagement boost experiment", "onboarding retention test", "landing page hero experiment", "pricing experiment"), describes it loosely ("the signup experiment", "my pricing test", "the one with the new checkout"), uses a relative reference ("latest", "most recent", "the one I created yesterday"), filters by status (running, draft, paused, exposure frozen, stopped, archived), or otherwise refers to an experiment by anything other than its concrete ID.

Jump to install Review files

Repository: PostHog/ai-plugin
Last source activity: October 16, 2026 at 08:22
Detected SKILL.md language: English
Stars: 95
Forks: 20

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with an AI assistant

Copy this prompt into the AI assistant you're using.

Follow https://skillsmp.com/skill-install/prompt.md to install only the Agent Skill at https://github.com/PostHog/ai-plugin/tree/main/skills/finding-experiments.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/PostHog/ai-plugin --skill finding-experiments

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

SKILL.md

Source instructions · Read-only preview

name: finding-experiments
description: Resolves a PostHog experiment reference from natural language to a concrete experiment ID by browsing `experiment-list` (not feature-flag tools), with disambiguation when multiple experiments match. Use when the user names or quotes an experiment ("split test demo", "the File engagement boost experiment", "onboarding retention test", "landing page hero experiment", "pricing experiment"), describes it loosely ("the signup experiment", "my pricing test", "the one with the new checkout"), uses a relative reference ("latest", "most recent", "the one I created yesterday"), filters by status (running, draft, paused, exposure frozen, stopped, archived), or otherwise refers to an experiment by anything other than its concrete ID.

# Finding experiments Users refer to experiments by name, description, or relative references — not by ID. This skill resolves natural language references to concrete experiment IDs. ## How to find an experiment Use the **experiment-list** tool from the Posthog-local MCP server. IMPORTANT: Do NOT use `feature-flag-get-all` or any feature flag tool to find experiments. Use the dedicated experiment list tool: `experiment-list`. This tool returns experiments with their id, name, status, feature_flag_key, start_date, end_date, and created_at. Browse the returned list to find the experiment matching the user's reference: - **By name**: scan the `name` field for matches - **By recency**: results are ordered newest first by default - **By status**: match the `status` field (draft, running, paused, exposure_frozen, stopped) - **By flag key**: skip the list and call `experiment-get-by-flag-key` with the key. It returns the full experiment, or `found: false` with a `reason`. `no_flag` and `no_experiment` mean the key is free, so this is also the existence check to run before `experiment-create`. `ambiguous` means several experiments share the flag and none is the single live one: show the `candidates` and pick one with `experiment-get` rather than creating another. - **By partial flag key**: call `experiment-list` with `search` set to the fragment. `search` matches substrings of the experiment name and the flag key, ignoring case. ## After finding matches - **Exactly one match**: Use it. Confirm with the user by name before destructive actions (delete, ship, end). - **Multiple matches**: List them with name, status, and creation date. Ask the user to pick. - **No matches**: Tell the user. Suggest checking archived experiments or different terms. ## Get full details if needed After resolving to an ID, call `experiment-get` for the full object (metrics, flag details, parameters). ## Examples ```text User: "pause my signup experiment" Agent: 1. Calls experiment-list 2. Scans results, finds "New signup process" (ID: 1371, status: running) 3. Proceeds to pause experiment 1371 ``` ## When NOT to search - You already have the experiment ID from earlier in the conversation - The user just created the experiment — you have the ID from the create response - The user provided the ID directly ## Related skills - **`managing-experiment-lifecycle`** — act on the experiment once you've resolved its ID - **`diagnosing-experiment-health`** — investigate the experiment you found

View on GitHub

Back to search Back to installation

creating-online-evaluations

Author continuously-running online evaluations in PostHog AI observability, grounded in real failure modes you've identified. Use when the user wants evaluations that automatically score new generations or whole traces going forward — "create an eval to catch X", "continuously check that responses do Y", "turn these failures into evals". Covers letting the explored data decide how many evals to create, proposing that set for the user to pick, choosing the target and eval type (hog / llm_judge / sentiment), configuring a provider and model for an llm_judge eval (a provider key gates enabling, not creation), scoping which generations trigger it via conditions, creating disabled, verifying scope, enabling, and backfilling past data. Proposes a sentiment eval when no failure mode is worth catching. Finding and ranking the failure modes worth evaluating is its own job — use exploring-ai-failures first. To debug or manage evaluations that already exist, use exploring-llm-evaluations.

2026-10-23

querying-posthog-data

Explains how to query PostHog data, defaulting to typed runners for supported product analytics. Read it before you write HogQL/SQL. Also read it before you call execute-sql against PostHog. Use it to find or aggregate PostHog entities. These entities include insights, dashboards, cohorts, feature flags, experiments, surveys, hog flows, warehouse data, and persons. Use it for trends, funnels, retention, lifecycle, paths, stickiness, web analytics, error tracking, logs, sessions, and LLM traces. Before you calculate a governed business or telemetry measure, check system.information_schema.metrics for an approved definition. Examples include MRR, activation, billable usage, active organizations, and failure rates. Use the approved definition before you derive a measure from raw events or use a typed domain tool. It also covers HogQL differences, system table schemas, functions, query examples, and schema discovery.

2026-10-23

reviewing-warehouse-suggestions

Reviews PostHog's warehouse suggestions with a person and acts on them. Explains why a view should be materialized, unmaterialized, certified or deprecated using the numbers in the suggestion, changes a materialize suggestion's refresh mode, keys or interval when the person wants something else, then accepts or dismisses it. Use when the user asks what PostHog suggests for their data warehouse, whether to materialize a view, why a view should refresh incrementally or every few hours, or wants to accept, change or dismiss a warehouse suggestion.

2026-10-23

View all from this repository

finding-experiments

Source facts

Install options

Install with an AI assistant

Review the source files

More from this repository

Install with an AI assistant

More from this repository