wizard

Long-form wizard contracts moved out of the always-on system commandments to keep per-turn prompts small. Load when wiring API keys, before confirm_event_plan, when writing the post-instrumentation events manifest or setup report, or when generating browser SDK init. Pre-staged at .claude/skills/wizard-prompt-supplement/ — use Read on the reference files listed below; do not skip relevant sections for your current phase.

Given a change_brief YAML (output from diff-intake), generates an exhaustive list of candidate analytics events to instrument. Takes the perspective of an engineer with a PM mindset — surfaces everything worth considering so a PM can decide what actually matters. Use this as step 2 of the analytics instrumentation workflow, immediately after diff-intake produces a change_brief. Trigger whenever a user has a change_brief YAML and wants to know what analytics events to add, or asks "what should I track for this PR", "what events should I instrument", "generate event candidates", or any request to surface analytics coverage gaps for a code change.

Given event_candidates YAML (output from discover-event-surfaces), generates a concrete instrumentation plan for priority-3 (critical) events. Acts as a Software Architect: discovers existing analytics patterns in the codebase, reads the hinted files to determine what variables are in scope, designs minimal chart-useful properties, and identifies the exact insertion point for each tracking call. Outputs a structured JSON trackingPlan. Use this as step 3 of the analytics instrumentation workflow, after discover-event-surfaces. Trigger whenever a user has event_candidates and wants to generate tracking code, asks "instrument these events", "generate tracking plan", "add analytics for these events", "where should I put the tracking calls", or any request to turn event candidates into concrete implementation guidance.

Amplitude integration for Android applications using the Kotlin SDK

Amplitude integration for Angular applications

Amplitude integration for Astro hybrid rendering with both static and server-rendered pages

Amplitude integration for server-rendered Astro applications with API routes

Amplitude integration for static Astro sites using SSG

Amplitude integration for Astro with ClientRouter view transitions

Amplitude integration for Django applications

Amplitude integration for Expo applications using @amplitude/analytics-react-native

Amplitude integration for FastAPI applications

Amplitude integration for Flask applications

Amplitude integration for server-side Node.js applications using @amplitude/analytics-node

Amplitude integration for client-side web JavaScript applications using @amplitude/unified (or @amplitude/analytics-browser for existing projects)

Amplitude integration for Laravel applications

Amplitude integration for Next.js App Router applications

Amplitude integration for Next.js Pages Router applications

Amplitude integration for Nuxt versions 3.0 to 3.6

Amplitude integration for Nuxt 4 applications

Amplitude integration for any Python application using the amplitude-analytics package

Amplitude integration for React Native applications using @amplitude/analytics-react-native

Amplitude integration for React Router v6 applications

Amplitude integration for React Router v7 - Data mode applications

Amplitude integration for React Router v7 - Declarative mode applications

Amplitude integration for React Router v7 - Framework mode applications

Amplitude integration for React applications using TanStack Router with code-based routing

Amplitude integration for React applications using TanStack Router with file-based routing

Amplitude integration for React applications built with Vite (no router)

Amplitude integration for Ruby on Rails applications

Amplitude integration for any Ruby application using the amplitude-api gem

Amplitude integration for SvelteKit applications

Amplitude integration for Swift iOS and macOS applications using AmplitudeSwift

Amplitude integration for TanStack Start full-stack applications

Amplitude integration for Vue 3 applications

Amplitude Chart & Dashboard Planning Skill — expert implementation strategist for translating an instrumented event taxonomy into a focused set of Amplitude charts and a single well-organized product dashboard. Use after event instrumentation is complete (SDK installed, events implemented, .amplitude/events.json written). Produces a concrete chart plan and drives chart + dashboard creation via the Amplitude MCP.

Amplitude Quickstart Taxonomy Agent — expert implementation strategist for a "starter kit" tracking plan: 10–30 high-signal events and properties from URL(s), codebase, and user context. Use when naming events, scoping instrumentation, mapping funnels, or producing a JSON taxonomy aligned to Amplitude analysis (funnels, retention, journeys, group analytics). In the wizard, pair with instrumentation skills; there is no Langley web-crawl stack — gather context with Read/Grep/Glob, WebFetch when available, Amplitude MCP get_context, and the user's free-text goals.

Set up Amplitude analytics in this codebase using the Amplitude Wizard agent contract. Use whenever a user asks to install Amplitude, instrument analytics events, configure Amplitude SDK, connect this app to Amplitude, or wire up tracking with @amplitude/wizard.

End-to-end analytics instrumentation workflow for a PR, branch, file, directory, or feature. Reads the code, discovers what events should be tracked, and produces a concrete instrumentation plan — all in one shot. Use this skill whenever a user wants to add analytics to a PR, asks "instrument this PR", "add tracking to this branch", "what analytics does this file need", "instrument the checkout flow", "run the full instrumentation workflow", or any request that implies going from code changes to a tracking plan. Also trigger when the user gives you a PR link, branch name, file path, or feature description and mentions analytics, events, or instrumentation. This is the main entry point for the analytics workflow — prefer it over calling the individual steps (diff-intake, discover-event-surfaces, instrument-events) separately.

Reads a PR or branch diff and produces a structured YAML change brief for downstream analytics instrumentation skills. Use this as the first step whenever a user shares a PR link, branch comparison, or raw diff and wants to understand what changed, what needs tracking, or how to instrument a feature. Trigger on phrases like "review this PR", "what changed in this branch", "help me instrument this diff", "check analytics coverage for this change", or any request to start the analytics review workflow.