From magic-powers
Step 2 of instrumentation workflow — identify candidate analytics events from code change briefs. Uses mcp__Amplitude__get_event_properties, mcp__Amplitude__get_context.
npx claudepluginhub kienbui1995/magic-powers --plugin magic-powersThis skill uses the workspace's default tool permissions.
- After running `diff-intake` and receiving a structured YAML brief
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
diff-intake and receiving a structured YAML briefAccept the YAML brief from diff-intake. If no brief exists, ask for one or invoke diff-intake first.
Verify brief has: new_surfaces, changed_behaviors, technical_context.
Before creating new events, check what already exists in Amplitude:
mcp__Amplitude__get_event_properties to pull existing event schemasmcp__Amplitude__get_context to understand the project contextcheckout_completed may already exist)Rule: always prefer updating an existing event over creating a new one if the semantic intent is the same.
For each item in new_surfaces, derive one or more candidate events:
| Surface Type | Primary Event | Secondary Events |
|---|---|---|
| New screen | <screen_name>_viewed | — |
| Button / CTA | <action>_clicked | — |
| Form | <form_name>_started, <form_name>_submitted | <form_name>_abandoned |
| Modal / drawer | <modal_name>_opened, <modal_name>_closed | — |
| API-triggered action | <resource>_<past_tense_verb> | — |
| Feature toggle | <feature>_enabled, <feature>_disabled | — |
All event names must follow: verb_noun in snake_case.
Valid examples:
page_viewed ✓checkout_completed ✓filter_applied ✓userClickedCheckout ✗ (camelCase)CheckoutCompleted ✗ (PascalCase)checkout-click ✗ (kebab-case)Check technical_context.existing_tracking_file for the project's actual convention — match it if it differs.
For each candidate event, list the properties needed to answer future analytics questions:
Universal properties (should be on every event):
user_id, session_id, platform, app_version, timestampContextual properties (what makes this event useful for analysis):
page_name, page_section, referrer_pageitem_id, item_type, item_name, pricebutton_label, form_fields_completed, error_messageexperiment_id, variant (if A/B test)Ask: What question would a PM ask about this event in 6 months? Make sure the properties answer it.
Identify events in the critical business funnel and mark them HIGH priority:
signup_started → signup_completed → onboarding_completedRule: every conversion step needs tracking; every intermediate step enables drop-off analysis.
Flag any missing step in a funnel as CRITICAL — you can't compute conversion without it.
Assign priority to each candidate event:
critical: funnel step, revenue event, or legal/compliance requirementhigh: key feature engagement, activation signal, retention indicatormedium: secondary engagement, UX feedback signallow: diagnostic, debug, or informational eventQuery existing events via mcp__Amplitude__get_event_properties to verify:
user_id vs userId)Produce a YAML list of candidate events:
candidates:
- name: checkout_confirmation_viewed
trigger: "User lands on /checkout/confirmation page"
priority: critical
properties:
- order_id: string
- order_total: number
- payment_method: string
- items_count: number
status: new # or: update_existing, deprecate
existing_event_ref: null # or: "checkout_complete" if updating
- name: shipping_address_submitted
trigger: "User clicks 'Save Address' on ShippingForm"
priority: high
properties:
- address_country: string
- is_default_address: boolean
status: new
existing_event_ref: null
mcp__Amplitude__get_event_properties — pull existing event schemas to avoid duplicates and match conventionsmcp__Amplitude__get_context — get project context (project ID, organization, active events)action_object in snake_case)A YAML document with candidates array, each entry containing:
name: <snake_case event name>
trigger: <human description of when this fires>
priority: <critical|high|medium|low>
properties: <list of {name: type} pairs>
status: <new|update_existing|deprecate>
existing_event_ref: <existing event name if updating, null if new>
After output, state: "Found N candidate events. Proceed to instrument-events to generate implementation specs, or to taxonomy to validate naming against existing schema."