/store-growth-audit

name: store-growth-audit
description: Stage-by-stage audit of an app's App Store growth machinery against a 54-item P0–P9 playbook — every item scored from an App Store Connect MCP call, a codebase check, or an explicit question to the user, then routed to the skill or command that fixes it. Read-only on App Store Connect. Use for a growth audit or scorecard, a pre-launch growth plan, a quarterly re-audit, or "which growth levers am I missing."
allowed-tools: [Read, Write, Glob, Grep, AskUserQuestion, mcp__asc-metadata__list_apps, mcp__asc-metadata__get_metadata, mcp__asc-metadata__list_locales, mcp__asc-metadata__get_app_pricing, mcp__asc-metadata__list_price_points, mcp__asc-metadata__get_availability, mcp__asc-metadata__list_iap, mcp__asc-metadata__list_subscription_groups, mcp__asc-metadata__list_subscriptions, mcp__asc-metadata__list_app_events, mcp__asc-metadata__list_experiments, mcp__asc-metadata__list_custom_pages, mcp__asc-metadata__get_analytics_report, mcp__asc-metadata__get_sales_report, mcp__asc-metadata__list_reviews]
last_verified: 2026-07-16
review_by: 2027-06-22

Store Growth Audit

Walk an app — new or live — through the full App Store growth playbook, phase by phase, and produce a scorecard: what's installed, what's missing, what to do next, and who fixes it.

> The invariant: **every item has a detection rule**. Status comes from an ASC read, a codebase > check, or an explicit question — never from vibes. If the user doesn't know, the item is > 🟠 *unverified*, not assumed ✅.

Where it fits (read the seams)

• **Not `store-signals`.** That is the continuous *signal → backlog* loop: are the numbers moving,

did last cycle's bets pay off? This is the *structural* audit: is the machinery even installed? Run this quarterly (or pre-launch); run store-signals monthly. Trend questions route there.

• **Not `analytics-interpretation`.** Metric-quality judgments ("is 3.2% conversion good?") route

there; this skill only records the baseline and whether benchmarks were checked.

• **Fixes never happen here.** Every 🔴/🟠 routes to a named sibling skill and (when driven from

SwiftShip) an `/apple:*` command. This skill detects, scores, and routes. Read-only on ASC.

When This Skill Activates

• "Audit my app's growth / store presence / what levers am I missing"
• A new app is approaching first submission and needs a growth plan, not just metadata
• Quarterly re-audit cadence, or after a launch that undershot expectations
• Before deciding to spend on paid acquisition ("is the free machinery done first?")
• Portfolio triage: "which of my apps is leaving the most on the table"

The Model: P0–P9

54 items across ten phases. Each phase is a theme; the item detail lives in the checklist files.

| Phase | Theme | Items | Goal | |-------|-------|-------|------| | P0 | Day-one money toggles | 4 | Free margin + a measurement baseline before anything else | | P1 | On-metadata ASO | 7 | Every indexed field working (title, subtitle, keywords, events, IAPs) | | P2 | Conversion assets | 5 | Icon, screenshots, trust signals that convert impressions | | P3 | Localization | 5 | Metadata-first market expansion + PPP pricing | | P4 | Ratings machinery | 4 | Prompting, replying, and protecting the rating | | P5 | Experimentation | 4 | PPO, CPPs, events as a testing habit | | P6 | Featuring & free discovery | 6 | Nominations, new-OS adoption, storefronts, web presence | | P7 | Paid & external traffic | 8 | Apple Ads ladder, launch spikes, pre-orders, codes | | P8 | Earnings | 7 | Paywall experiments, win-backs, web checkout, bundles | | P9 | Retention loop & ops | 4 | Retention surfaces + the recurring refresh calendar |

**Compressed priority** (used for action selection, not the maturity ladder): P0 money toggles first → P1–P3 (metadata, conversion, localization) → P8.4 web checkout + P8.6 volume purchasing (the 2026-era revenue unlocks) → everything else → P7 paid traffic last. Paid spend on top of broken free machinery is burned money.

Reference Files

| File | Purpose | |------|---------| | `detection-playbook.md` | Gather-once machinery: the MCP batch table, the codebase grep table, the single MANUAL question batch | | `audit-checklist-p0-p4.md` | Items P0.1–P4.4 (25): foundations — money toggles through ratings | | `audit-checklist-p5-p9.md` | Items P5.1–P9.4 (29): growth loops — experimentation through ops |

Audit Process

1. **Resolve app, mode, and scope.** Get the `appId` (from `.planning/STATE.md` when driven by SwiftShip, else `list_apps` + confirm with the user). App live on the store → *existing* mode; not yet shipped → *pre-launch* mode. Scope defaults to the full P0–P9; a named phase runs scoped (see **Scoped Runs**). A prior scorecard (`GROWTH.md`), if present, is the diff baseline. 2. **Gather evidence — one pass, per `detection-playbook.md`.** Run the full MCP read batch, the full codebase grep pass, and ONE batched AskUserQuestion round for every MANUAL item. Never interleave gathering with scoring; never ask questions one at a time. 3. **Score all 54 items** against the gathered evidence using each item's `rule:`. Honor `applies-if:` guards (⚪ N/A) and ⏳ ANNOUNCED flags. Every status carries a terse, citable evidence string (`locales: en-US only`, `SBP: enrolled (user, 2026-07)`). 4. **Compute phase scores + maturity level** (rules below), and — when a prior scorecard exists — per-item deltas: fixed / regressed / new since last audit. 5. **Select the top 5 actions** (rule below). 6. **Write or refresh the scorecard** — in a SwiftShip project this is `.planning/GROWTH.md` (schema in SwiftShip's `templates/GROWTH.md`); standalone, write `GROWTH.md` beside the audit. Append an audit-history row; refresh the recurring calendar's next-due dates. 7. **Print the digest and route.** Maturity level, phase bar, top-5 with routes, deltas, unanswered MANUAL items, next three calendar due-dates, and the suggested next command/