agentsclimarketplace
Sign in

Store signals

Skill rshankras/claude-code-apple-skills/skills/growth/store-signals

Close the post-launch loop — turn a live app's App Store signals (reviews, analytics, sales, crashes, listing conversion) into a metric-tagged backlog for the next version, AND verify whether last cycle's changes moved the metric they promised to move. Read-only on App Store Connect; every change is surfaced and routed to another command, never auto-applied. Use before planning the next version, on a monthly cadence, or ~1-2 weeks after shipping to check if a change worked.From its SKILL.md

Install
npx -y skills add rshankras/claude-code-apple-skills --skill store-signals

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

5.6 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it

Store Signals

Pull what the shipped app is actually telling you and convert it into the next backlog — then verify whether last cycle's bets paid off.

This is the missing arc that turns build → ship into a loop: ship → MEASURE → DIAGNOSE → next PLAN → build → ship → measure again… The ledger (SIGNALS.md) is what makes it a loop and not a monthly report.

Where it fits (read the seams)

  • Not analytics-interpretation. That interprets a metric you hand it (is 14% D7 good?). This is the end-to-end operate loop: gather every signal → cluster → diagnose → write a metric-tagged backlog → close last cycle's hypotheses. It uses analytics-interpretation's benchmarks.
  • Read-only on ASC. Never responds to reviews, never mutates metadata/pricing. It surfaces, gates on explicit OK, and routes the change to the right command (next-version, bugfix, metadata).
  • Feeds planning. Output is a dated backlog appended to ROADMAP.md + rows in SIGNALS.md, consumed by /apple:next-version / /apple:release.

Prerequisites

  • A live (or TestFlight) app; resolve its appId from .planning/STATE.md, else list_apps + confirm.
  • .planning/ context: STATE.md, APP.md, POSITIONING.md (job-to-be-done + guardrails).
  • .planning/SIGNALS.md if present — the OPEN hypotheses from prior runs (each with a target metric, recorded baseline, and "check-after" date). See signals-ledger.md for the ledger + backlog formats.

Flow

  1. Load prior hypotheses. Read SIGNALS.md → the OPEN rows to verify in step 5.
  2. Pull the signals (read-only), this period vs trailing:
    • Reviews / ratings — list_reviews (recent, lowest-star first; flag unanswered), get_review for detail.
    • Analytics — get_analytics_report: retention, funnel/conversion, acquisition, impression→download. No report configured yet → setup_analytics_reports and note "retention/funnel lands next cycle."
    • Sales — get_sales_report: proceeds/units vs trailing 7/30-day.
    • Stability / perf — get_diagnostics (crash/hang signatures) + get_perf_metrics (launch, memory, energy).
    • Beta — list_beta_feedback_crashes if in TestFlight.
    • Listing — get_metadata to spot ASO conversion problems against current copy.
  3. Normalize & cluster. Dedupe reviews into recurring themes (requests / complaints / praise) with frequency; attach magnitude (users / revenue / retention implicated). Weight by frequency × revenue impact, not by how loud one reviewer is.
  4. Diagnose, filter, prioritize. Map each cluster to the core metric it moves (rating · D7 · Pro conversion · crash-free rate · ASO conversion · proceeds); score impact × confidence ÷ effort. Strategy filter: cross-check POSITIONING.md — on-strategy → backlog; off-strategy → list under "Declined (why)" (never silently drop, never silently build). Carry the app's guardrails forward. Small-N (new app): say so, lean on qualitative reviews, flag low confidence.
  5. Close the prior loop. For each OPEN hypothesis whose change shipped and whose "check-after" date passed: compare the target metric now vs its baseline → WIN / REGRESSION / NEUTRAL. WIN → resolve; REGRESSION → open a revert/rethink task; NEUTRAL → keep watching or retire.
  6. Write the backlog. Append a dated, metric-tagged section to ROADMAP.md and update SIGNALS.md (one row per hypothesis; formats in signals-ledger.md). Then output a ranked digest (top 3-5 "what's hurting most, why, the proposed move"), the loop-closure results, and a suggested next command (/apple:next-version, /apple:bugfix for a hot crash, /apple:metadata for an ASO fix).

Portfolio mode

With no single app (or --portfolio): run steps 2-4 across every app in list_apps, then rank which app to invest in next — biggest fixable revenue/retention/rating gap first (pairs with portfolio-health-monitor). Output one line per app + the single highest-ROI move overall.

Done

  • A ranked cited digest, the WIN/REGRESSION/NEUTRAL loop-closure for last cycle, and a metric-tagged backlog written to ROADMAP.md + SIGNALS.md, with a routed next command.

Caveats

  • Read-only on ASC — never auto-apply pricing, metadata, or review responses; surface → gate → route.
  • Evidence over vibes — every backlog item cites its signal + magnitude; the loudest reviewer is not the roadmap.
  • Always verify last cycle (step 5) before planning the next — that closure is the whole point.
  • Apple delivers analytics on its own schedule; a freshly configured report is empty until next cycle.

What ships with it: 1 file

2.7 KB alongside SKILL.md

Gives 0 of the 12 instructions most quality gates skills give in ~1.2k tokens

Counted across 1,524 of the 2,830 authors here whose files we hold, read 2026-09-06

  • Read full output and check exit codein 45 of 1524, across 40 files
  • Verify output confirms the claimin 44 of 1524, across 39 files
  • Identify the command that proves the claimin 43 of 1524, across 39 files
  • Execute the full verification commandin 36 of 1524, across 30 files
  • Produce a verification reportin 34 of 1524, across 18 files
  • Review git diff changesin 30 of 1524, across 16 files
  • Fix build failures immediatelyin 29 of 1524, across 9 files
  • Group findings by severityin 28 of 1524
  • State claim only with evidencein 27 of 1524, across 22 files
  • Verify regression tests with red-green cyclein 26 of 1524, across 22 files
  • Run the full test suitein 26 of 1524, across 25 files
  • Run test suite with coveragein 25 of 1524, across 10 files

Said here and by no other author read

  • read open hypotheses from the signals ledger
  • pull app reviews and analytics reports
  • cluster reviews into recurring themes by frequency
  • weight clusters by frequency and revenue impact
  • filter backlog items against app positioning guardrails
  • verify target metrics for shipped hypotheses

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.