From amplitude
Discovers analytics tracking patterns in the codebase: concrete SDK calls, function signatures, imports, file paths, and event/property naming conventions. Use before adding new instrumentation.
npx claudepluginhub amplitude/mcp-marketplace --plugin amplitudeThis skill uses the workspace's default tool permissions.
Your goal is to find out **how** this codebase sends analytics events — not which
Guides Payload CMS config (payload.config.ts), collections, fields, hooks, access control, APIs. Debugs validation errors, security, relationships, queries, transactions, hook behavior.
Builds scalable data pipelines, modern data warehouses, and real-time streaming architectures using Spark, dbt, Airflow, Kafka, and cloud platforms like Snowflake, BigQuery.
Builds production Apache Airflow DAGs with best practices for operators, sensors, testing, and deployment. For data pipelines, workflow orchestration, and batch job scheduling.
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:
taxonomy skill at ../taxonomy/SKILL.mdUse two approaches based on what's available.
Call get_events (or equivalent) to fetch a sample of event names from the
project. Use those results to choose a few representative non-system product
events, then call get_event_properties for those events 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.
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.myEvent(...)) |
amplitude\.track|amplitude\.logEvent | Direct Amplitude SDK calls |
sendEvent | Custom wrapper method names |
from.*amplitude|import.*amplitude|require.*amplitude | Import statements |
https://api2\.amplitude\.com/2/httpapi | HTTP API calls |
Also actively look for custom analytics wrappers — a codebase often wraps the
raw SDK in a utility like trackEvent(), track(), or a React hook like
useAnalytics() or useTracking(). Search for these by looking for functions
that call into Amplitude internally. Treat each wrapper as its own pattern,
separate from the underlying SDK call, even if it ultimately calls
amplitude.track() underneath. Engineers who encounter the wrapper will use
it, not the raw SDK — so it's the more important pattern to document.
To find wrappers: search for files that import the Amplitude SDK, then check whether any of those files export a function or hook that other parts of the codebase import and use for tracking.
Exclude test files (.test., .spec., __tests__) and mock files unless they
are the only place a pattern appears.
Two call sites use the same pattern if they share the same:
For example, these are the same pattern:
amplitude.track('Page Viewed', { page: '/home' })
amplitude.track('Button Clicked', { label: 'signup' })
But these are different patterns — always keep them separate:
amplitude.track('Page Viewed', { page: '/home' }) // direct SDK — one pattern
ampli.pageViewed({ page: '/home' }) // Ampli typed method — different pattern
trackEvent('Page Viewed', { page: '/home' }) // custom wrapper — also a separate pattern
A custom wrapper is always its own pattern, even if it delegates to the SDK
underneath. When documenting a wrapper pattern, note what it wraps (e.g.,
"Custom hook wrapping amplitude.track()") so engineers understand the layering.
Resolve two conventions separately:
event_naming_convention — casing, separators, word order, prefixes, and
tense used for event names in instrumentation code. Examples: Title Case,
snake_case, [Prefix] Action, object-first vs action-first.property_naming_convention — casing, separators, and common suffix/prefix
patterns used for event properties. Examples: snake_case, camelCase,
*_id, is_*, flat keys vs nested objects.Use this precedence order:
eventType values and
property names returned by get_event_properties for a few representative
non-system events show a clear dominant convention, use that. Do not use
bracket-prefixed Amplitude system names as naming evidence.taxonomy skill at ../taxonomy/SKILL.md.Do not guess. If one or both conventions remain unclear even after checking those sources, say so explicitly.
Start with a short conventions section, then list each unique pattern.
event_naming_convention: "<from MCP if clear, otherwise codebase, otherwise taxonomy skill, or 'insufficient evidence'>"
property_naming_convention: "<from MCP if clear, otherwise codebase, otherwise taxonomy skill, or 'insufficient evidence'>"
Then, for each unique pattern, output a section in this format:
<short descriptive name>Description: What this pattern does and when it's typically used in this codebase (e.g., "Used throughout the React frontend for user action tracking").
Example (generalized):
// show the import(s) needed
import { amplitude } from '@/lib/analytics'
// show a representative tracking call with placeholder names
amplitude.track('Event Name', {
propertyOne: value,
propertyTwo: value,
})
Relevant paths:
src/path/to/file.tssrc/another/file.tsxList patterns from most common (most file paths) to least common.
If two patterns are always used together (e.g., an import + a call), show them together in one example.
If no tracking calls are found with any search strategy, say so clearly. Suggest that the user check whether Amplitude (or another analytics library) has been set up in the project, and offer to search for other analytics libraries (Segment, Mixpanel, PostHog, etc.) if relevant.