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 Astro hybrid rendering with both static and server-rendered pages
Amplitude integration for server-rendered Astro applications with API routes
| name | integration-angular |
| description | Amplitude integration for Angular applications |
| metadata | {"author":"Amplitude","version":"1.2.6"} |
This skill helps you add Amplitude analytics to Angular applications.
Follow these steps in order to complete the integration:
references/basic-integration-1.0-begin.md - Amplitude Setup - Begin ← Start herereferences/basic-integration-1.1-edit.md - Amplitude Setup - Editreferences/basic-integration-1.2-revise.md - Amplitude Setup - Revisereferences/basic-integration-1.3-conclude.md - Amplitude Setup - Conclusionreferences/EXAMPLE.md - Angular example project codereferences/browser-unified-sdk.md - Amplitude documentation for Browser Unified Sdkreferences/browser-sdk-2.md - Amplitude documentation for Browser Sdk 2references/amplitude-quickstart.md - Amplitude documentation for Amplitude Quickstartreferences/basic-integration-1.0-begin.md - Amplitude setup - beginreferences/basic-integration-1.1-edit.md - Amplitude setup - editreferences/basic-integration-1.2-revise.md - Amplitude setup - revisereferences/basic-integration-1.3-conclude.md - Amplitude setup - conclusionThe example project shows the target implementation pattern. Consult the documentation for API details.
@amplitude/unified as the default SDK — it bundles Analytics, Session Replay, Experiment, and Guides & Surveys in a single package. Initialize with initAll(). Only use @amplitude/analytics-browser if the project already has it installed.track() event properties. PII belongs in identify() user properties only.autocapture config option (not the deprecated defaultTracking).Identify users during login and signup events. Refer to the example code and documentation for the correct identify pattern for this framework. Call amplitude.setUserId(userId) to associate events with a known user, and use amplitude.identify() with an Identify object to set user properties. Call amplitude.reset() on logout to unlink future events from the current user. If both frontend and backend code exist, pass a consistent user/device ID via custom request headers to maintain event correlation.