discover-analytics-patterns

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
name: discover-analytics-patterns
description: >
  Discovers how analytics tracking calls are actually written in this codebase —
  the concrete SDK calls, function signatures, and import patterns used to send
  events. Use this skill whenever you need to understand the existing analytics
  instrumentation patterns before adding new tracking, when someone asks "how do
  we track events here?", "show me the analytics setup", "what's the analytics
  pattern in this codebase?", or any time the instrument-events or
  discover-event-surfaces skills are about to run and you need to know the
  correct coding style to follow. Outputs a deduplicated list of patterns with
  generalized examples and the file paths where each pattern appears, plus the
  dominant event and property naming conventions inferred from those call sites.
  Always use this skill before writing any analytics instrumentation code.
---

# discover-analytics-patterns

Your goal is to find out **how** this codebase sends analytics events — not which
events exist, but the specific code patterns engineers use to fire a tracking
call. This output helps engineers add new events that look consistent with the
rest of the codebase. It should also tell downstream skills how event names and
property names are typically written in code here.

When determining naming conventions in this skill, use the following sources in strict order of preference:
1. Customer directives in `.amplitude/instrumentation-agent-context.md` (and any files it references), if present — explicit conventions the customer wants followed, so they override everything below.
2. Events and properties observed from the Amplitude MCP server
3. Real tracking call sites in the codebase
4. The `taxonomy` skill at `../taxonomy/SKILL.md`

---

## Step 0: Read repo instrumentation context

Before anything else, check for `.amplitude/instrumentation-agent-context.md`
(repo root, or the subdirectory you're instrumenting). If it exists, read it and
any repo-relative files it references. Any naming conventions, property
standards, or SDK/wrapper patterns it states are **customer directives** — they
take precedence over everything you infer below; record them and skip inference
for whatever they cover. If it's absent, just continue — the `instrument-events`
skill owns prompting the user to add one.

---

## Step 1: Find tracking calls

Use two approaches based on what's available.

### If the Amplitude MCP is connected

Inspect the connected catalog and use its current taxonomy reader to fetch a
sample of event names from the project. Follow only the reader's advertised
schema. When it supports caller attribution, identify this skill with the
`name` from its YAML frontmatter. Use those results to choose a few
representative non-system product events, then use its
event-property read capability to inspect real property names. This is your
primary naming reference.

Do not infer naming conventions from bracket-prefixed Amplitude system names
such as `[Amplitude], [Guides-Surveys], [Assistant], [Experiment]` for either events or properties. Exclude those from
pattern detection. If the MCP sample is dominated by Amplitude system names or otherwise does not provide enough evidence, fall back to codebase
inference for naming.

Then search the codebase for the sampled non-system event names using Grep to
locate the actual tracking call sites.

### If the Amplitude MCP is not available (fallback)

Search the codebase for these signals using Grep. Cast a wide net — you can
narrow down after:

| What to search for                                       | Why                                               |
| -------------------------------------------------------- | ------------------------------------------------- |
| `\.track\(`                                              | Generic `.track()` method calls                   |
| `ampli\.`                                                | Ampli typed SDK calls (e.g. `ampli.myEven