App launch

A launch is mostly known work: the same research, the same fields, the same rules, the same mistakes waiting to be made. The owner should not have to explain it again for each app. These skills carry the decisions a full launch arrives at, so your job is to do the launch, and to return to the owner only for the things in references/owner-inputs.md: logins, signatures, recordings, a handful of product decisions, and the go-ahead at the few moments that reach the public.

When to use it. From the moment an app works and the owner wants it in the store, which is before the first TestFlight build, not on submission day: the research decides the name the app record is created under, and the legal steps take days. Then again, lighter, for every later version that goes to the store. A single job in between (one over-the-air update, new screenshots, a keyword change, a rejection) goes straight to the skill for that job.

It is a conductor. The work is in eight sibling skills in the same folder as this one; load each when you reach its phase and follow it:

Three references here apply across all of them: references/owner-inputs.md (what to ask the owner, when, and how; the one list of owner steps), references/computer-use.md (who does browser work; the sign-in rule), references/release-sequencing.md (server before app, staging before production, what "deploy" means).

The owner profile. These skills assume nothing about who they are working for: a first app on a new Apple account and a tenth app on an old one get the same defaults. What is particular to this owner (which markets matter, what is already set up on their accounts, how they work, rules of their own) lives in a private file outside the skills, ~/.claude/app-launch-profile.md. Read it first if it exists; where it speaks, it overrides a default below. If it does not exist, nothing is assumed to be in place, and at the end of the launch you offer to write it (references/owner-profile-template.md).

Names. When these skills are installed as a plugin, each appears with the plugin's prefix (app-launch:aso-research, app-launch:store-listing and so on). The plain names used throughout these files mean the same skills.

Paths and commands. In every one of these skills, a path such as scripts/asc.mjs or ../app-store-connect/scripts/asc.mjs is relative to that skill's own folder (the base directory shown when the skill loads; all nine are siblings in one folder). Commands are run from the app's repository root, so call the scripts by absolute path, for example node "<skills folder>/app-store-connect/scripts/asc.mjs" apps. Paths that start with store/ are in the app's repository. On Windows use PowerShell, or in Git Bash quote any argument that starts with / (Git Bash rewrites /v1/… into a Windows path).

The rules

Each of these comes from something that went wrong, or nearly did, in a real launch. They outrank speed. The profile can add to them or relax one by name; nothing else can.

1. Show the whole proposal before editing the store. Research and draft freely; the name, subtitle, keywords, category and locale list are entered in App Store Connect only after the owner has seen and approved them.
2. Five actions need the owner's word each time they happen: submitting for review, releasing an approved version, deploying a production server, publishing an over-the-air update (any channel, staging included), and merging to the main branch. Approval of the plan is not approval of the step. Prepare everything up to the line, say it is ready, and stop there for that item only.
3. Never handle the owner's credentials. Open the sign-in page; they sign in. Do not read password or recovery files on the machine, whatever they are named.
4. Say only what is true. In the store: no invented awards, ratings or user counts; an app with a paywall is "free to start", never "free"; no competitor names in keywords; no feature that is not in the build. In reports: separate done, verified, and not verified. If no one has opened the build on a phone, say that sentence.
5. Research before recommending, and give one answer. When the owner asks which option is better, test it (real search results, not reasoning) and commit to a recommendation with the evidence. Changing the answer each time they push back costs their trust; if new evidence changes it, say what the evidence is.
6. Keep thinking and clicking apart. Research, writing, code and decisions stay with you. Prefer an API over a browser whenever one exists. Browser work that remains goes to a dedicated computer-use agent when the environment offers one (the profile may name which), and its reports are checked, not trusted.
7. Ask in batches, early, and keep working. One message on day one for everything knowable from the repository and the account, one with the proposal after the research. Never end a turn waiting for something when other launch work is available.

Notes and memory about a different app (its markets, its wording, its release state) do not carry over to this one. What carries over between apps is in the profile.

1. Read before anything else

Spend the first minutes learning what is true, from the sources, not from the request:

• The owner profile, ~/.claude/app-launch-profile.md, if there is one.
• The repository: app config (name, bundle ID, version, plugins, permissions, supportsTablet), eas.json, package.json scripts, the i18n folder and languages, auth and account deletion, the paywall and billing code, analytics and tracking SDKs, the backend it calls and how that is deployed.
• Apple's side: node ../app-store-connect/scripts/asc.mjs apps. Is there an app record? A live version? status and preflight on it if so.
• The store: for an app that is already live, node ../aso-research/scripts/store-research.mjs lookup us <id> --full shows what the public sees, which is sometimes not what the owner thinks is there.
• store/launch.md in the repo, if a launch is already under way. Continue it; do not restart.
• Memory and project notes for this app: earlier decisions and standing rules.

From this, decide which phases apply (purchases? new languages? a backend?) and whether this is a first release or an update. An update runs the same phases, lighter: research only if the listing is changing, screenshots only for screens that changed, always release notes, always the review audit for what is new.

Also note what the store requires that the app does not have yet. The usual ones: deleting an account from inside the app, a restore-purchases button and legal links on the paywall, a privacy policy link in the app, a private sign-in option beside Google or Facebook sign-in. "Launch it" includes building these when they are small; do it on a branch and tell the owner in the day-one message. A missing feature that is large (the paywall itself, sign-in) is a question for the owner, not something to improvise.

2. Open the launch file and send the day-one message

Create store/launch.md (format below). Then send the owner the day-one message: the plan in a few lines and the inputs that can be known now, longest lead time first, each finishable from the message alone. Nothing is assumed to be set up unless the profile says so or a command confirms it. references/owner-inputs.md has the list, the checks, and a template for both a new account and an established one.

What depends on the research (the name, the prices, and so the app record) comes in the proposal message after phase one. Say on day one that it is coming.

Then start working. Do not wait for the reply.

3. Run the phases

The dependency order, with what can run side by side:

research (every target country) ──► proposal message ──► owner approves, per locale:
   │                                 name · subtitle · keywords · category · locales · prices
   │                                 └─► owner creates the app record with the approved name
   │
   ├──► per language, in this order:  app strings ─► listing text ─► screenshot content
   │     (languages run side by side, one subagent each; inside a language each step reads
   │      the one before it, so the listing uses the app's words and the captions the listing's)
   ├──► English screenshots and creative assets: design can start during the research
   ├──► purchases (if any): the owner's legal steps were requested on day one
   │
   ├──► server to staging ─► staging build ─► owner tests on their phone
   │
   ├──► review audit: code, listing, account; owner's recording and demo account
   │
   └──► production server (owner's word) ─► production build ─► everything entered in
        App Store Connect ─► preflight ─► readiness report ─► SUBMIT (owner's word)
                                                         ─► approval ─► RELEASE (owner's word)

Working rules across the phases:

• Research first, and deeply. Everything visible in the store (name, captions, the first image's words, the description's first line) uses the vocabulary the research found. Skimping here makes every later phase guesswork.
• Use the waiting. Builds queue for an hour or more, Apple's processing takes time, the owner replies when they reply. There is always other launch work: do it.
• Who owns what. aso-research decides the name, subtitle and keyword field of every locale, and they are approved once, in the proposal message. store-listing writes everything else and does not reopen those three.
• Parallelise by language, not by guesswork: one subagent per language that does app strings, then listing text, then screenshot content for its language, with a checker script to pass at each step. Brief each with the files to read and the rules; a subagent knows only what the brief says.
• Check your own output the way the owner will see it: read the proof sheets, read asc.mjs status after writing, open the URLs you entered.
• When something blocks, route around it and note it in the launch file. A missing login stops one task, not the launch.

4. The readiness report, and the line

When everything is entered and asc.mjs preflight is clean, give the owner one report (the format is in app-review-readiness): what will be submitted, what is blocking, what is risky, what no one has verified, what is still waiting on them. Then stop for their word.

On "submit": check once more that the production server is live and healthy from outside, that the build attached is the production-profile build, then asc.mjs submit --confirm <version>, and confirm the state it reports.

After that: record the submission in the launch file, check on it when asked or when a session resumes, handle a rejection through app-review-readiness, and on approval do what was waiting (server deploy if it was held, then release on the owner's word, then the merge on the owner's word).

5. After release

Worth proposing, not doing unasked:

• The system rating prompt after a moment of success, if the app has none. Ratings count and average move both ranking and conversion, and a new app has zero.
• An Apple Search Ads campaign on the app's own name if store search rewrites the brand to a bigger one.
• A baseline of impressions, page views and downloads a few weeks in (App Analytics needs a browser task or an analytics report request), then one change at a time. Do not read conclusions into a few dozen impressions.
• Promotional text refreshes, which need no new version.

The launch file

store/launch.md is the single place that says where the launch stands. It exists so that a new session, or another agent, can continue without the conversation. Keep it short and current; it is state, not a diary.

# <App> launch: version <x.y.z>

Updated: <date>
App id: <id> · Bundle: <bundle> · First release or update · Sells: <nothing | subscription | …>

## Decisions (approved by the owner on <date>)
- Name / subtitle per locale, category, locales
- Sold: product ids, prices, trial, who is entitled, Family Sharing
- URLs: privacy, terms, support, marketing

## Proposed, awaiting the owner
- …

## Done
- Research: store/research/aso-report.md
- Listing text: store/copy/ (9 locales, checker passes)
- …

## In progress
- Build 12 (production profile) queued at 14:20 …

## Waiting on the owner
- [ ] Paid Apps Agreement (asked <date>)
- [ ] Screen recording → store/review/demo.mp4

## Not verified
- Nobody has run build 12 against production.

## Gates
- Submit: not given · Release: not given · Production deploy: given <date> for <what>

The rest of the launch folder: store/asc.json (App Store Connect settings), store/research/, store/copy/<locale>.json, store/screenshots/, store/review/ (audit, notes, the owner's recording). Keep secrets out of it: passwords are read from environment variables.

Scope

This covers Apple's App Store. Google Play needs its own research (the description is indexed there, there is no keyword field) and its own console work; say so rather than reusing the iOS listing unchanged.