Store Growth Audit

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.

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

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/skill.

Item Record Format

Each checklist item is a stanza:

#### P3.1 Metadata-only localization (ja de fr es pt ko zh-Hans) — core
- detect: MCP `list_locales`
- rule: ✅ ≥7 target locales localized · 🟠 1–6 non-English locales · 🔴 en-only
- new-app: plan — seed target locales in the first submission
- fix: product/localization-strategy → /apple:localize

• ID (P<phase>.<n>) is stable forever — scorecards diff by ID; never renumber.
• Flags after the name: core (phase-gating), RECURRING (calendar-driven), ⏳ ANNOUNCED (WWDC26).
• detect: MCP <tool> · CODE <grep> · MANUAL <question> · HYBRID (combination).
• rule: explicit ✅/🟠/🔴 thresholds; optional applies-if: guard → ⚪ N/A when it fails.
• new-app: how pre-launch mode scores it — plan / code / defer (see Modes).
• fix: sibling-skill → /apple:command — the skill path works standalone; the command half applies when driven from SwiftShip.

Status vocabulary: ✅ done/healthy · 🟠 partial, stale, or unverified · 🔴 missing · ⚪ N/A (applies-if failed; excluded from denominators) · ⏳ ANNOUNCED (not yet scoreable; excluded from denominators; carries prep: and recheck: lines instead of a live rule).

Scoring & Maturity

• Phase score: ✅ n / N applicable — ⚪ and ⏳ items are excluded from N.
• Phase grade:
  • Complete — all applicable items ✅
  • Working — ≥50% ✅ and no core item 🔴
  • Gaps — any core item 🔴, or <50% ✅
  • Not started — no applicable item ✅
• core items (13): P0.1, P0.2, P1.1, P2.2, P2.4, P3.1, P4.1, P4.2, P5.1, P6.1, P8.1, P8.4, P9.2.
• Growth maturity level (0–9): the highest P such that every phase ≤ P grades at least Working. An app with P0–P3 working but P4 in gaps is Level 3, no matter how good P5–P9 look. The ladder follows numeric phase order; the compressed priority shapes only action selection.

Top-5 action selection: from all applicable 🔴 + 🟠 items, order by compressed-priority tier (T1: P0 · T2: P1–P3 · T3: P8.4 + P8.6-when-live · T4: P4–P6, rest of P8, P9 · T5: P7), then within a tier: core first, 🔴 before 🟠, lowest effort first. Two overrides: an overdue RECURRING calendar item jumps to the top; always include at least one metadata-only quick win (shippable without a binary release).