---
name: in-app-events
description: Plan an app Product's App Store In-App Events — one brief per event (name, descriptions, badge, dates, purpose) plus the month's calendar. Use for "in-app event", "event card", "Today tab", "challenge", "launch event for the update". For holiday keyword and metadata timing use seasonal-aso; for editorial featuring use app-store-featured.
metadata:
  version: 1.0.0
---

# In-App Events

Plan the event cards that surface in search, on the Today tab, on the product page and as a notification to lapsed users. Output is a set of **event briefs** and an **event calendar** the User submits in App Store Connect.

## Gather

1. `read_context` — positioning, ICP, roadmap moments (launches, seasons, milestones), target keywords, voice.
2. `app_store_listing` — genres and the current version with its release notes, which decide the event types that fit and the update worth an event.
3. `connector_asc_in_app_events` when the ASC Connector exists — every event past, running and planned, with its badge, state, dates and territories (10 may be live or scheduled at once). Without it, assume none are scheduled and say so.
4. `connector_asc_analytics` when the ASC Connector exists — impressions and downloads per source, the baseline an event's spike is measured against.
5. `connector_revenuecat_metrics` when the RevenueCat Connector exists — churned and lapsed subscriber counts, sizing the re-engagement upside.

## Plan

Event types, field limits, copy rules, image direction and the mistakes to avoid are in [`references/event-specs.md`](references/event-specs.md); read it before writing a brief.

1. **Purpose per event** — re-engagement (any badge; the notification to lapsed users is the main lever), acquisition (Challenge or Competition for Today tab reach), or feature launch (Major Update).
2. **Badge from category** — the reference maps app category to the badges that perform.
3. **Copy** — event name (30) leads with the benefit or action and carries 1–2 target keywords, written to work as a notification subject line; short description (50) answers "what's in it for me"; long description (120) says what, when and why.
4. **Timing** — 7 to 31 days long, at least one event per month for recurring placement, submission 4–5 days before start for review.
5. **Calendar** — the next month's slots with buffers, aligned with the moments `seasonal-aso` names.

## Output: event briefs + calendar

Per event: name with `chars/30`, badge, start → end, short description `chars/50`, long description `chars/120`, image direction (scene, style, key element; 2160×1080, legible at 390×195), purpose, KPI (sessions spike, downloads, event page views), submit-by date. Then the calendar by week, existing events from the Connector kept, moved or retired.

Done when every field is within its limit, every event has a submit-by date 4+ days before start, the month carries at least one event, and the Output names the data it lacked (scheduled events, baselines) when a Connector was absent.

## Related Skills

- `seasonal-aso` — the moments the calendar aligns with.
- `screenshot-optimization` — the same visual rules apply to the event image.
- `app-store-featured` — regular events raise editorial eligibility.
- `churn-prevention` — the lapsed users the notification reaches.