Omnibus

Skill 70 of 200

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…

1 minute · 293 words · 6 sections

Install

$ npx skills add PostHog/skills --skill finding-experiments

$ npx skills add PostHog/skills

» /plugin marketplace add PostHog/skills

The first command installs just this skill, by the name in its SKILL.md; the second installs the whole repository.

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.

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

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

managing-experiment-lifecycle — act on the experiment once you’ve resolved its ID
diagnosing-experiment-results — investigate the experiment you found

About this skill

Trigger

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.

The verbatim description from this skill’s front matter — the string an agent matches on to decide whether to load it.

Colophon for this issue

Colophon

How this issue was made

Source

github.com/PostHog/skills, branch main, last pushed 24 September 2026.

Licence

MIT — the text of every skill is reproduced unmodified, frontmatter included, under the upstream licence.

Discovery

200 skills found by walking the repository tree for SKILL.md, not by matching a directory convention. 2 distinct layouts observed: skills/omnibus/*/SKILL.md, skills/posthog/all/skills/*/SKILL.md.

Issue colours

Resolved from the awesome-design-md registry — hue 38°, chroma 0.190. Two accent tones are generated per issue and each is proven against its own ground before it ships: a single accent that passes AA on both light and dark paper is arithmetically impossible.

Typefaces

Display: IBM Plex Sans Variable is not a face we ship; the reader's own choice is used.
Body: IBM Plex Sans Variable is not a face we ship; the reader's own choice is used.
Mono: Source Code Pro is not a face we ship; the reader's own choice is used.

We never load a typeface at request time from a third-party origin, so a brand face we do not already self-host is substituted rather than fetched.

Heading repairs

1 repair applied to this skill so the document has one h1 and no skipped levels:

Removed “Finding experiments”, a leading h1 that duplicated the skill title.

Spec compliance

7 editorial notes across 7 of 200 skills. They are printed in the margin of each skill rather than as errors here.

Signals Scout General — 1 note
Signals Scout PR Follow Up — 1 note
Signals Scout Product Analytics — 1 note
Signals Scout Replay Vision — 1 note
Signals Scout Skills Store — 1 note
Signals Scout Tasks — 1 note
Signals Scout Web Analytics — 1 note

Images

Images inside a skill come from the upstream repository. Where the author gave no alternative text we mark the image decorative rather than inventing a description — a plausible caption we made up is worse than none for the reader who depends on it.

Marketplace

A plugin manifest is published at .claude-plugin/marketplace.json by PostHog, declaring 6 plugins. It is read for editorial metadata only — never as the skill index, which is always the repository tree.

Signal

Install counts come from skills.sh. They measure downloads, not quality, and an unranked repository is not an unread one.

Agent surfaces

The whole issue is available as one markdown document at /PostHog/skills.md, and each skill at its own .md URL.

Publication

Set by Skills Docs from the source repository. Body text is Literata at the reader’s chosen size and measure; code is Geist Mono. Nothing on this page was written by us except this paragraph.

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.

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

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

managing-experiment-lifecycle — act on the experiment once you’ve resolved its ID
diagnosing-experiment-results — investigate the experiment you found