USP

Unlike manual processes or fragmented tools, this pack offers a unified, agent-first approach to automate nearly every aspect of App Store Connect, including UI-driven app creation and advanced ASO audits.

Use cases

• 01Automating CI/CD pipelines for iOS/macOS app builds and uploads
• 02Managing TestFlight beta distributions, groups, and testers efficiently
• 03Localizing App Store metadata and generating engaging release notes
• 04Performing ASO audits and optimizing keywords for better discoverability
• 05Troubleshooting and resolving App Store submission blockers

Detected files (8)

• skills/asc-metadata-sync/SKILL.mdskill
  Show content (6118 bytes)

  ---
  name: asc-metadata-sync
  description: Sync, validate, and apply App Store metadata with the current asc canonical metadata workflow. Use when updating metadata, localizations, keywords, or migrating legacy fastlane metadata.
  ---
  
  # asc metadata sync
  
  Use this skill to keep App Store metadata in sync with App Store Connect. Prefer the canonical `asc metadata` workflow for app-info and version localization fields. Use the lower-level `asc localizations` and `asc migrate` commands only when the user specifically needs `.strings` files or legacy fastlane-format metadata.
  
  ## Current canonical workflow
  
  ### 1. Pull canonical metadata
  
  ```bash
  asc metadata pull --app "APP_ID" --version "1.2.3" --platform IOS --dir "./metadata"
  ```
  
  If the app has multiple app-info records, resolve the app-info ID first and pass it explicitly:
  
  ```bash
  asc apps info list --app "APP_ID" --output table
  asc metadata pull --app "APP_ID" --app-info "APP_INFO_ID" --version "1.2.3" --platform IOS --dir "./metadata"
  ```
  
  ### 2. Edit local files
  
  Canonical files are written under:
  
  - `metadata/app-info/<locale>.json` for app-level fields: `name`, `subtitle`, `privacyPolicyUrl`, `privacyChoicesUrl`, `privacyPolicyText`
  - `metadata/version/<version>/<locale>.json` for version fields: `description`, `keywords`, `marketingUrl`, `promotionalText`, `supportUrl`, `whatsNew`
  
  Copyright is not a localization field. Manage it with:
  
  ```bash
  asc versions update --version-id "VERSION_ID" --copyright "2026 Your Company"
  ```
  
  ### 3. Validate before upload
  
  ```bash
  asc metadata validate --dir "./metadata" --output table
  ```
  
  For subscription apps, include the extra Terms of Use / EULA heuristic:
  
  ```bash
  asc metadata validate --dir "./metadata" --subscription-app --output table
  ```
  
  ### 4. Preview and apply
  
  Run a dry run first:
  
  ```bash
  asc metadata push --app "APP_ID" --version "1.2.3" --platform IOS --dir "./metadata" --dry-run --output table
  ```
  
  Apply after the plan looks correct:
  
  ```bash
  asc metadata push --app "APP_ID" --version "1.2.3" --platform IOS --dir "./metadata"
  ```
  
  Use `asc metadata apply` when the user wants the apply-named command shape for the same canonical files:
  
  ```bash
  asc metadata apply --app "APP_ID" --version "1.2.3" --platform IOS --dir "./metadata" --dry-run
  asc metadata apply --app "APP_ID" --version "1.2.3" --platform IOS --dir "./metadata"
  ```
  
  ## Keyword-only workflow
  
  Use this when only the version-localization `keywords` field should change:
  
  ```bash
  asc metadata keywords diff --app "APP_ID" --version "1.2.3" --platform IOS --dir "./metadata"
  asc metadata keywords apply --app "APP_ID" --version "1.2.3" --platform IOS --dir "./metadata" --confirm
  ```
  
  For importing keyword research:
  
  ```bash
  asc metadata keywords import --dir "./metadata" --version "1.2.3" --locale "en-US" --input "./keywords.csv"
  asc metadata keywords sync --app "APP_ID" --version "1.2.3" --platform IOS --dir "./metadata" --input "./keywords.csv"
  ```
  
  ## Quick field updates
  
  For one-off version-localization edits, pass an explicit version selector. Use `--version-id` for deterministic updates when you already have it, or `--version` plus `--platform` when working from a version string.
  
  ```bash
  asc apps info edit --app "APP_ID" --version-id "VERSION_ID" --locale "en-US" --whats-new "Bug fixes and improvements"
  asc apps info edit --app "APP_ID" --version "1.2.3" --platform IOS --locale "en-US" --description "Your app description here"
  asc apps info edit --app "APP_ID" --version "1.2.3" --platform IOS --locale "en-US" --keywords "keyword1,keyword2,keyword3"
  asc apps info edit --app "APP_ID" --version "1.2.3" --platform IOS --locale "en-US" --support-url "https://support.example.com"
  ```
  
  For app-info fields, prefer the post-create setup command:
  
  ```bash
  asc app-setup info set --app "APP_ID" --primary-locale "en-US" --privacy-policy-url "https://example.com/privacy"
  asc app-setup info set --app "APP_ID" --locale "en-US" --name "Your App Name" --subtitle "Your subtitle"
  ```
  
  ## Lower-level localization files
  
  Use `.strings` files when the user specifically wants import/export files instead of canonical JSON:
  
  ```bash
  asc localizations list --version "VERSION_ID" --output table
  asc localizations download --version "VERSION_ID" --path "./localizations"
  asc localizations upload --version "VERSION_ID" --path "./localizations" --dry-run
  asc localizations upload --version "VERSION_ID" --path "./localizations"
  ```
  
  For app-info localizations:
  
  ```bash
  asc apps info list --app "APP_ID" --output table
  asc localizations list --app "APP_ID" --type app-info --app-info "APP_INFO_ID" --output table
  asc localizations download --app "APP_ID" --type app-info --app-info "APP_INFO_ID" --path "./app-info-localizations"
  asc localizations upload --app "APP_ID" --type app-info --app-info "APP_INFO_ID" --path "./app-info-localizations" --dry-run
  asc localizations upload --app "APP_ID" --type app-info --app-info "APP_INFO_ID" --path "./app-info-localizations"
  ```
  
  ## Legacy fastlane metadata
  
  Use this only for existing fastlane-format trees:
  
  ```bash
  asc migrate export --app "APP_ID" --version-id "VERSION_ID" --output-dir "./fastlane"
  asc migrate validate --fastlane-dir "./fastlane"
  asc migrate import --app "APP_ID" --version-id "VERSION_ID" --fastlane-dir "./fastlane" --dry-run
  asc migrate import --app "APP_ID" --version-id "VERSION_ID" --fastlane-dir "./fastlane"
  ```
  
  ## Character limits
  
  | Field | Limit |
  |-------|-------|
  | Name | 30 |
  | Subtitle | 30 |
  | Keywords | 100 comma-separated characters |
  | Description | 4000 |
  | What's New | 4000 |
  | Promotional Text | 170 |
  
  ## Agent behavior
  
  - Start with `asc metadata pull` unless the user specifically asks for `.strings` or fastlane metadata.
  - Always run `asc metadata validate` before remote writes.
  - Preview remote changes with `--dry-run` when the command supports it.
  - For quick edits, always pass `--version-id` or `--version` plus `--platform`; do not rely on ambiguous latest-version behavior.
  - Keep app-info fields and version fields separate.
  - Use `--output table` for human verification and JSON for automation.
  

• skills/asc-app-create-ui/SKILL.mdskill
  Show content (5816 bytes)

  ---
  name: asc-app-create-ui
  description: Create a new App Store Connect app record via browser automation. Use when there is no public API for app creation and you need an agent to drive the New App form.
  ---
  
  # asc app create (UI automation)
  
  Use this skill to create a new App Store Connect app by driving the web UI.
  This is opt-in, local-only automation that requires the user to be signed in.
  
  ## Preconditions
  - A browser automation tool is available (Playwright, Cursor browser MCP, or equivalent).
  - User is signed in to App Store Connect (or can complete login + 2FA).
  - The **bundle ID must already be registered** in the Apple Developer portal.
  - Required inputs are known:
    - app name (max 30 characters)
    - bundle ID (must exist and be unused by another app)
    - SKU
    - platform (iOS, macOS, tvOS, visionOS)
    - primary language
    - user access (Full Access or Limited Access)
  
  ## Safety Guardrails
  - Never export or store cookies.
  - Use a visible browser session only.
  - Pause for a final confirmation before clicking "Create" (for standalone scripts).
  - Do not retry the Create action automatically on failure.
  
  ## Workflow
  
  ### 1. Preflight: register bundle ID and verify no existing app
  ```bash
  # Register the bundle ID via public API (if not already registered)
  asc bundle-ids create --identifier "com.example.app" --name "My App" --platform IOS
  
  # Confirm no app record exists yet
  asc apps list --bundle-id "com.example.app" --output json
  ```
  
  ### 2. Open App Store Connect
  Navigate to `https://appstoreconnect.apple.com/apps` and ensure the user is signed in.
  
  ### 3. Open the New App form
  The "New App" button (blue "+" icon) opens a **dropdown menu**, not a dialog directly.
  - Click the "New App" button to open the dropdown.
  - Click the "New App" **menu item** inside the dropdown.
  - The creation dialog/modal appears.
  
  ### 4. Fill required fields (in order)
  
  #### Platform (checkboxes)
  The platforms are **checkboxes** (not radio buttons). Click the checkbox for the desired platform(s):
  - iOS, macOS, tvOS, visionOS
  - Multiple can be selected.
  
  #### Name (text input)
  - Label: `Name`
  - Max 30 characters.
  
  #### Primary Language (select/combobox)
  - Label: `Primary Language`
  - Use `select_option` or equivalent with the language label (e.g., `"English (U.S.)"`).
  
  #### Bundle ID (select/combobox)
  - Label: `Bundle ID`
  - This is a `<select>` dropdown. The options load asynchronously after platform selection.
  - Wait for the dropdown to finish loading (it shows "Loading..." initially).
  - Select by matching the label text which includes both the name and identifier:
    `"My App - com.example.app"`
  
  #### SKU (text input)
  - Label: `SKU`
  
  #### User Access (radio buttons) -- REQUIRED
  - **This field is required.** The Create button stays disabled until one option is selected.
  - Options: `Limited Access` or `Full Access`.
  - These are custom radio buttons with `<span>` overlays.
  - **Known issue:** Accessibility-based clicks may be intercepted by the overlay `<span>`.
  - **Workaround:** Use `scrollIntoView` on the radio element first, then click the radio ref directly. This bypasses the overlay interception.
  
  ### 5. Click Create
  - The "Create" button is disabled until all required fields are filled **and** User Access is selected.
  - After clicking, the button text changes to "Creating" while processing.
  - Wait for navigation to the new app's page (URL pattern: `/apps/<APP_ID>/...`).
  
  ### 6. Verify creation via API
  ```bash
  asc apps view --id "APP_ID" --output json --pretty
  # or
  asc apps list --bundle-id "com.example.app" --output json
  ```
  
  ### 7. Hand off to post-create setup
  ```bash
  asc app-setup info set --app "APP_ID" --primary-locale "en-US"
  asc app-setup categories set --app "APP_ID" --primary GAMES
  asc web apps availability create \
    --app "APP_ID" \
    --territory "USA,GBR" \
    --available-in-new-territories true
  ```
  
  Use the experimental web flow above only for the first availability bootstrap. If app availability already exists, switch to `asc pricing availability edit --app "APP_ID" ...` for later territory changes.
  
  ## Known UI Automation Issues
  
  ### "New App" is a dropdown menu, not a direct action
  The first click opens a menu with "New App" and "New App Bundle". You must click the menu item, not just the button.
  
  ### User Access radio buttons have span overlays
  Apple's custom radio buttons wrap the `<input type="radio">` in styled `<span>` elements. Direct ref-based clicks may fail with "click target intercepted". The fix is:
  1. Scroll the radio element into view (`scrollIntoView`).
  2. Click the radio ref directly (not via offset or label click).
  
  ### Bundle ID dropdown loads asynchronously
  After selecting a platform, the Bundle ID dropdown shows "Loading..." and is disabled. Wait for it to become enabled and populated before selecting.
  
  ### browser_fill may not trigger form validation
  Apple's Ember.js forms use custom change handlers. `browser_fill` (atomic set) may not trigger validation. If the Create button stays disabled after filling all fields:
  - Retype the value slowly (character-by-character) in at least one text field.
  - Or click the field, clear it, and type slowly.
  
  ## Failure Handling
  - If any field or button cannot be located, stop and request user help.
  - Capture a screenshot and report the last known step.
  - Do not retry the Create click automatically.
  - On failure, the user should check the browser for validation errors (red outlines, inline messages).
  
  ## Notes
  - This skill is a workaround for a missing public API. Apple's docs explicitly state: "Don't use this API to create new apps; instead, create new apps on the App Store Connect website."
  - UI selectors can change without notice. Prefer role/label/text selectors over CSS.
  - The only manual step should be signing in. Everything else is agent-drivable.
  

• skills/asc-localize-metadata/SKILL.mdskill
  Show content (11288 bytes)

  ---
  name: asc-localize-metadata
  description: Automatically translate and sync App Store metadata (description, keywords, what's new, subtitle) to multiple languages using LLM translation and asc CLI. Use when asked to localize an app's App Store listing, translate app descriptions, or add new languages to App Store Connect.
  ---
  
  # asc localize metadata
  
  Use this skill to pull English (or any source locale) App Store metadata, translate it with LLM, and push translations back to App Store Connect — all automated.
  
  ## Command discovery and output conventions
  
  - Always confirm flags with `--help` for the exact `asc` version:
    - `asc localizations --help`
    - `asc localizations download --help`
    - `asc localizations upload --help`
    - `asc apps info edit --help`
  - Prefer explicit long flags (`--app`, `--version`, `--version-id`, `--type`, `--app-info`).
  - Default output is JSON; use `--output table` only for human verification steps.
  - Prefer deterministic ID-based operations. Do not "pick the first row" via `head -1` unless the user explicitly agrees.
  
  ## Preconditions
  - Auth configured (`asc auth login` or `ASC_*` env vars)
  - Know your app ID (`asc apps list` to find it)
  - At least one locale (typically en-US) already has metadata in App Store Connect
  
  ## Supported Locales
  
  App Store Connect locales for version and app-info localizations:
  ```
  ar-SA, ca, cs, da, de-DE, el, en-AU, en-CA, en-GB, en-US,
  es-ES, es-MX, fi, fr-CA, fr-FR, he, hi, hr, hu, id, it,
  ja, ko, ms, nl-NL, no, pl, pt-BR, pt-PT, ro, ru, sk,
  sv, th, tr, uk, vi, zh-Hans, zh-Hant
  ```
  
  ## Two Types of Metadata
  
  ### Version Localizations (per-release)
  Fields: `description`, `keywords`, `whatsNew`, `supportUrl`, `marketingUrl`, `promotionalText`
  
  ### App Info Localizations (app-level, persistent)
  Fields: `name`, `subtitle`, `privacyPolicyUrl`, `privacyChoicesUrl`, `privacyPolicyText`
  
  ## Workflow
  
  ### Step 1: Resolve IDs
  
  ```bash
  # Find app ID
  asc apps list --output table
  
  # Find latest version ID
  asc versions list --app "APP_ID" --state READY_FOR_DISTRIBUTION --output table
  # or for editable version:
  asc versions list --app "APP_ID" --state PREPARE_FOR_SUBMISSION --output table
  
  # Find app info ID (for app-level fields like name/subtitle)
  asc apps info list --app "APP_ID" --output table
  ```
  
  Notes:
  - Version-localization fields (description, keywords, whatsNew, etc.) are per-version.
  - App-info fields (name, subtitle, privacy URLs/text) are app-level and use `--type app-info`.
  - If you only have names (app name, version string) and need IDs deterministically, use `asc-id-resolver`.
  
  ### Step 2: Download source locale
  
  ```bash
  # Download version localizations to local .strings files
  # (description, keywords, whatsNew, promotionalText, supportUrl, marketingUrl, ...)
  asc localizations download --version "VERSION_ID" --path "./localizations"
  
  # Download app-info localizations to local .strings files
  # (name, subtitle, privacyPolicyUrl, privacyChoicesUrl, privacyPolicyText, ...)
  asc localizations download --app "APP_ID" --type app-info --app-info "APP_INFO_ID" --path "./app-info-localizations"
  ```
  
  This creates files like `./localizations/en-US.strings` and `./app-info-localizations/en-US.strings`. If download is unavailable, read fields individually:
  
  ```bash
  # List version localizations to see existing locales and their content
  asc localizations list --version "VERSION_ID" --output table
  ```
  
  ### Step 3: Translate with LLM
  
  For each target locale, translate the source text. Follow these rules:
  
  #### Translation Guidelines
  - **Tone & Register**: Always use formal, polite language. Use formal "you" forms where the language distinguishes them (Russian: «вы», German: «Sie», French: «vous», Spanish: «usted», Dutch: «u», Italian: «Lei», Portuguese: «você» formal, etc.). App Store descriptions are professional marketing copy — never use casual or informal register.
  - **description**: Translate naturally, adapt tone to local market. Keep formatting (line breaks, bullet points, emoji). Stay within 4000 chars.
  - **keywords**: Do NOT literally translate. Research what users in that locale would search for. Comma-separated, max 100 chars total. No duplicates, no app name (Apple adds it automatically).
  - **whatsNew**: Translate release notes. Keep it concise. Max 4000 chars.
  - **promotionalText**: Translate marketing hook. Max 170 chars. This can be updated without a new version.
  - **subtitle**: Translate or adapt tagline. Max 30 chars — this is very tight, may need creative adaptation.
  - **name**: Usually keep the original app name. Only translate if the user explicitly asks. Max 30 chars.
  
  #### LLM Translation Prompt Template
  
  For each target locale, use this approach:
  
  ```
  Translate the following App Store metadata from {source_locale} to {target_locale}.
  
  Rules:
  - description: Natural, fluent translation. Preserve formatting (line breaks, bullets, emoji). Max 4000 chars.
  - keywords: Do NOT literally translate. Choose keywords native speakers would search for in the App Store. Comma-separated, max 100 chars total. Do not include the app name.
  - whatsNew: Translate release notes naturally. Max 4000 chars.
  - promotionalText: Translate marketing tagline. Max 170 chars.
  - subtitle: Adapt tagline creatively to fit 30 chars max.
  - name: Keep the original app name unless explicitly requested to translate it. Max 30 chars.
  - Use formal, polite language and formal "you" forms (Russian: вы, German: Sie, French: vous, Spanish: usted, Dutch: u, etc.). App Store copy is professional marketing — never use informal register.
  - Respect cultural context. A playful tone in English may need adjustment for formal markets (e.g., ja, de-DE).
  
  Source ({source_locale}):
  description: """
  {description}
  """
  
  keywords: {keywords}
  
  whatsNew: """
  {whatsNew}
  """
  
  promotionalText: {promotionalText}
  
  name: {name}
  
  subtitle: {subtitle}
  ```
  
  ### Step 4: Upload translations
  
  #### Option A: Via .strings files (bulk)
  
  Create a `.strings` file per locale in the appropriate directory.
  
  Version localization example:
  
  ```
  // nl-NL.strings
  "description" = "Je app-beschrijving hier";
  "keywords" = "wiskunde,kinderen,tafels,leren";
  "whatsNew" = "Bugfixes en verbeteringen";
  "promotionalText" = "Leer de tafels van vermenigvuldiging!";
  ```
  
  Then upload version localizations:
  ```bash
  asc localizations upload --version "VERSION_ID" --path "./localizations"
  ```
  
  App-info localization example:
  
  ```
  // nl-NL.strings
  "subtitle" = "Leer tafels spelenderwijs";
  ```
  
  Then upload app-info localizations:
  ```bash
  asc localizations upload --app "APP_ID" --type app-info --app-info "APP_INFO_ID" --path "./app-info-localizations"
  ```
  
  #### Option B: Via individual commands (fine control)
  
  ```bash
  # Version localization fields (fine control).
  # Prefer passing the explicit version ID for determinism.
  asc apps info edit --app "APP_ID" --version-id "VERSION_ID" --locale "nl-NL" \
    --description "Je beschrijving..." \
    --keywords "wiskunde,kinderen,tafels" \
    --whats-new "Bugfixes en verbeteringen"
  ```
  
  For app-level fields:
  ```bash
  # Subtitle/name (app-info localization) is managed via app-info localizations.
  # Use the app-info localization .strings + upload flow (there is no `asc app-infos localizations ...` command).
  #
  # 1) Edit: ./app-info-localizations/nl-NL.strings
  # "subtitle" = "Leer tafels spelenderwijs";
  #
  # 2) Upload:
  asc localizations upload --app "APP_ID" --type app-info --app-info "APP_INFO_ID" --path "./app-info-localizations"
  ```
  
  ### Step 5: Verify
  
  ```bash
  # Check all locales are present
  asc localizations list --version "VERSION_ID" --output table
  
  # Check app info localizations
  asc localizations list --app "APP_ID" --type app-info --app-info "APP_INFO_ID" --output table
  ```
  
  ## Character Limits (enforce before upload!)
  
  | Field | Limit |
  |-------|-------|
  | Name | 30 |
  | Subtitle | 30 |
  | Keywords | 100 (comma-separated) |
  | Description | 4000 |
  | What's New | 4000 |
  | Promotional Text | 170 |
  
  **Always validate** translated text fits within limits before uploading. Truncated text looks unprofessional. If translation exceeds the limit, shorten it — do not truncate mid-sentence.
  
  ## Full Example: Add nl-NL and ru to Roxy Math
  
  ```bash
  # 1) Resolve IDs deterministically (do not auto-pick the "first" row)
  # If you only have names, use asc-id-resolver skill.
  asc apps list --output table
  APP_ID="APP_ID_HERE"
  
  asc versions list --app "$APP_ID" --state PREPARE_FOR_SUBMISSION --output table
  VERSION_ID="VERSION_ID_HERE"
  
  asc apps info list --app "$APP_ID" --output table
  APP_INFO_ID="APP_INFO_ID_HERE"
  
  # 2) Download English source (or your chosen source locale)
  asc localizations download --version "$VERSION_ID" --path "./localizations"
  asc localizations download --app "$APP_ID" --type app-info --app-info "$APP_INFO_ID" --path "./app-info-localizations"
  
  # 3) Read en-US.strings, translate to nl-NL and ru (LLM step)
  
  # 4) Write nl-NL.strings and ru.strings to:
  #    - ./localizations/ (version localization fields)
  #    - ./app-info-localizations/ (subtitle/name/privacy fields)
  
  # 5) Upload all
  asc localizations upload --version "$VERSION_ID" --path "./localizations"
  asc localizations upload --app "$APP_ID" --type app-info --app-info "$APP_INFO_ID" --path "./app-info-localizations"
  
  # 6) Verify
  asc localizations list --version "$VERSION_ID" --output table
  asc localizations list --app "$APP_ID" --type app-info --app-info "$APP_INFO_ID" --output table
  ```
  
  ## Agent Behavior
  
  1. **Always start by reading the source locale** — never translate from memory or assumptions.
  2. **Check existing localizations first** — don't overwrite existing translations unless the user asks to update them.
  3. **Version vs app-info is different** — version fields live under `--version "VERSION_ID"`; subtitle/name/privacy live under `--app ... --type app-info`.
  4. **Prefer deterministic IDs** — do not select IDs via `head -1` unless explicitly requested; use `--output table` for selection or `asc-id-resolver`.
  5. **Validate character limits** before uploading. Count characters for each field. If over limit, re-translate shorter.
  6. **Keywords are special** — do not literally translate. Research locale-appropriate search terms. Think like a user searching the App Store in that language.
  7. **Show the user translations before uploading** — present a summary table of all fields × locales for approval. Do not push without confirmation.
  8. **Process one locale at a time** if translating many languages — easier to review and catch errors.
  9. **If upload fails** for a locale, log the error, continue with other locales, report all failures at the end.
  10. **For updates to existing localizations** — download current, show diff of what will change, get approval, then upload.
  
  ## Notes
  - Version localizations are tied to a specific version. Create the version first if it doesn't exist.
  - `promotionalText` can be updated anytime without a new version submission.
  - `whatsNew` is only relevant for updates, not the first version.
  - Use `asc-id-resolver` skill if you only have app/version names instead of IDs.
  - Use `asc-metadata-sync` skill for non-translation metadata operations.
  - For subscription/IAP display name localization, use `asc-subscription-localization` skill instead.
  

• skills/asc-aso-audit/SKILL.mdskill
  Show content (9589 bytes)

  ---
  name: asc-aso-audit
  description: Run an offline ASO audit on canonical App Store metadata under `./metadata` and surface keyword gaps using Astro MCP. Use after pulling metadata with `asc metadata pull`.
  ---
  
  # asc ASO audit
  
  Run a two-phase ASO audit: offline checks against local metadata files, then keyword gap analysis via Astro MCP.
  
  ## Preconditions
  
  - Metadata pulled locally into canonical files via `asc metadata pull --app "APP_ID" --version "1.2.3" --dir "./metadata"`.
  - If metadata came from `asc migrate export` or `asc localizations download`, normalize it into the canonical `./metadata` layout before running this skill.
  - For Astro gap analysis: app tracked in Astro MCP (optional — offline checks run without it).
  
  ## Before You Start
  
  1. Read `references/aso_rules.md` to understand the rules each check enforces.
  2. Identify the **latest version directory** under `metadata/version/` (highest semantic version number). Use this for all version-level fields.
  3. The **primary locale** is `en-US` unless the user specifies otherwise.
  
  ## Metadata File Paths
  
  - **App-info fields** (`subtitle`): `metadata/app-info/{locale}.json`
  - **Version fields** (`keywords`, `description`, `whatsNew`): `metadata/version/{latest-version}/{locale}.json`
  - **App name**: May not be present in exported metadata. If `name` is missing from the app-info JSON, fetch it via `asc apps info list` or ask the user. Do not flag it as a missing-field error.
  
  ## Phase 1: Offline Checks
  
  Run these 5 checks against the local metadata directory. No network calls required.
  
  ### 1. Keyword Waste
  
  Tokenize the `subtitle` field (and `name` if available). Flag any token that also appears in the `keywords` field — it is already indexed and wastes keyword budget.
  
  ```
  Severity: ⚠️ Warning
  Example:  "quran" appears in subtitle AND keywords — remove from keywords to free 6 characters
  ```
  
  How to check:
  1. Read `metadata/app-info/{locale}.json` for `subtitle` (and `name` if present)
  2. Read `metadata/version/{latest-version}/{locale}.json` for `keywords`
  3. Tokenize subtitle (+ name):
     - **Latin/Cyrillic scripts:** split by whitespace, strip leading/trailing punctuation, lowercase
     - **Chinese/Japanese/Korean:** split by `、` `，` `,` or iterate characters — each character or character-group is a token. Whitespace tokenization does not work for CJK.
     - **Arabic:** split by whitespace, then also generate prefix-stripped variants (remove ال prefix) since Apple likely normalizes definite articles. For example, "القرآن" in subtitle should flag both "القرآن" and "قرآن" in keywords.
  4. Split keywords by comma, trim whitespace, lowercase
  5. Report intersection (including fuzzy matches from prefix stripping)
  
  ### 2. Underutilized Fields
  
  Flag fields using less than their recommended minimum:
  
  | Field | Minimum | Limit | Rationale |
  |-------|---------|-------|-----------|
  | Keywords | 90 chars | 100 | 90%+ usage maximizes indexing |
  | Subtitle | 20 chars | 30 | 65%+ usage recommended |
  
  ```
  Severity: ⚠️ Warning
  Example:  keywords is 62/100 characters (62%) — 38 characters of indexing opportunity unused
  ```
  
  ### 3. Missing Fields
  
  Flag empty or missing required fields: `subtitle`, `keywords`, `description`, `whatsNew`.
  
  Note: `name` may not be in the export — only flag it if the app-info JSON explicitly contains a `name` key with an empty value.
  
  ```
  Severity: ❌ Error
  Example:  subtitle is empty for locale en-US
  ```
  
  ### 4. Bad Keyword Separators
  
  Check the `keywords` field for formatting issues:
  - Spaces after commas (`quran, recitation`)
  - Semicolons instead of commas (`quran;recitation`)
  - Pipes instead of commas (`quran|recitation`)
  
  ```
  Severity: ❌ Error
  Example:  keywords contain spaces after commas — wastes 3 characters
  ```
  
  ### 5. Cross-Locale Keyword Gaps
  
  Compare `keywords` fields across all available locales. Flag locales where keywords are identical to the primary locale (`en-US` by default) — this usually means they were not localized.
  
  ```
  Severity: ⚠️ Warning
  Example:  ar keywords identical to en-US — likely not localized for Arabic market
  ```
  
  How to check:
  1. Load keywords for all locales
  2. Compare each non-primary locale against the primary
  3. Flag exact matches (case-insensitive)
  
  ### 6. Description Keyword Coverage
  
  Check whether keywords appear naturally in the `description` field. While Apple does **not** index descriptions for search, users who see their search terms reflected in the description are more likely to download — this improves conversion rate, which indirectly boosts rankings.
  
  ```
  Severity: 💡 Info
  Example:  3 of 16 keywords not found in description: namaz, tarteel, adhan
  ```
  
  How to check:
  1. Load `keywords` and `description` for each locale
  2. For each keyword, check if it appears as a substring in the description (case-insensitive)
  3. Account for inflected forms: Arabic root matches, verb conjugations (e.g., "memorizar" ≈ "memorices"), and case declensions (e.g., Russian "сура" ≈ "суры")
  4. Report missing keywords per locale — recommend weaving them naturally into existing sentences
  5. Do NOT flag: Latin-script keywords in non-Latin descriptions (e.g., "quran" in Cyrillic text) — these target separate search paths
  
  ## Phase 2: Astro MCP Keyword Gap Analysis
  
  If Astro MCP is available and the app is tracked, run keyword gap analysis. **Run this per store/locale, not just for the US store** — keyword popularity varies dramatically across markets.
  
  ### Steps
  
  1. **Get current keywords**: Call `get_app_keywords` with the app ID to retrieve tracked keywords and their current rankings.
  
  2. **Ensure multi-store tracking**: For each locale with a corresponding App Store territory (e.g., `ar-SA` → Saudi Arabia, `fr-FR` → France, `tr` → Turkey), use `add_keywords` to add keyword tracking in that store. Without this, `search_rankings` returns empty for non-US stores.
  
  3. **Extract competitor keywords**: Call `extract_competitors_keywords` with 3-5 top competitor app IDs to find keyword gaps. This is the highest-value Astro tool — it reveals keywords competitors rank for that you don't. Run this per store when possible.
  
  4. **Get suggestions**: Call `get_keyword_suggestions` with the app ID for additional recommendations based on category analysis.
  
  5. **Check current rankings**: Call `search_rankings` to see where the app currently ranks for tracked keywords in each store.
  
  6. **Diff against metadata**: Compare suggested and competitor keywords against the tokens present in `subtitle`, `name` (if available), and `keywords` fields from the local metadata.
  
  7. **Surface gaps**: Report all gaps ranked by popularity score (highest first). Include the source (competitor analysis vs. suggestion).
  
  ### Cross-Field Combo Strategy
  
  When recommending keyword additions, consider how single words combine across indexed fields (title + subtitle + keywords). For example:
  - Adding "namaz" to keywords when "vakti" is already present enables matching the search "namaz vakti" (66 popularity)
  - Adding "holy" to keywords when "Quran" is in the subtitle enables matching "holy quran" (58 popularity)
  
  Flag high-value combos in recommendations.
  
  ### Skip Conditions
  
  - Astro MCP not connected → skip with note: "Connect Astro MCP for keyword gap analysis"
  - App not tracked in Astro → skip with note: "Add app to Astro with `mcp__astro__add_app` for gap analysis"
  - Store not tracked for a locale → add tracking with `add_keywords` before querying
  
  ## Output Format
  
  Present results as a single audit report. The report covers only the latest version directory.
  
  ```
  ### ASO Audit Report
  
  **App:** [name] | **Primary Locale:** [locale]
  **Metadata source:** [path including version number]
  
  #### Field Utilization
  
  | Field | Value | Length | Limit | Usage |
  |-------|-------|--------|-------|-------|
  | Name | ... | X | 30 | X% |
  | Subtitle | ... | X | 30 | X% |
  | Keywords | ... | X | 100 | X% |
  | Promotional Text | ... | X | 170 | X% |
  | Description | (first 50 chars)... | X | 4000 | X% |
  
  #### Offline Checks
  
  | # | Check | Severity | Field | Locale | Detail |
  |---|-------|----------|-------|--------|--------|
  | 1 | Keyword waste | ⚠️ | keywords | en-US | "quran" duplicated in subtitle |
  
  **Summary:** X errors, Y warnings across Z locales
  
  #### Keyword Gap Analysis (Astro MCP)
  
  | Keyword | Popularity | In Metadata? | Suggested Action |
  |---------|-----------|--------------|-----------------|
  | quran recitation | 72 | ❌ | Add to keywords |
  
  #### Recommendations
  
  1. [Highest priority action — errors first]
  2. [Next priority — keyword waste]
  3. [Utilization improvements]
  4. [Keyword gap opportunities]
  ```
  
  ## Notes
  
  - Offline checks work without any network access — they read local files only.
  - Astro gap analysis is additive — the audit is useful even without it.
  - Run this skill after `asc metadata pull` to ensure canonical metadata files are current.
  - For keyword-only follow-up after the audit, prefer the canonical keyword workflow:
    - `asc metadata keywords diff --app "APP_ID" --version "1.2.3" --dir "./metadata"`
    - `asc metadata keywords apply --app "APP_ID" --version "1.2.3" --dir "./metadata" --confirm`
    - `asc metadata keywords sync --app "APP_ID" --version "1.2.3" --dir "./metadata" --input "./keywords.csv"` when importing external keyword research
  - After making changes, re-run the audit to verify fixes.
  - The Field Utilization table includes promotional text for completeness, but no check validates its content (it is not indexed by Apple).
  

• skills/asc-id-resolver/SKILL.mdskill
  Show content (1336 bytes)

  ---
  name: asc-id-resolver
  description: Resolve App Store Connect IDs (apps, builds, versions, groups, testers) from human-friendly names using asc. Use when commands require IDs.
  ---
  
  # asc id resolver
  
  Use this skill to map names to IDs needed by other commands.
  
  ## App ID
  - By bundle ID or name:
    - `asc apps list --bundle-id "com.example.app"`
    - `asc apps list --name "My App"`
  - Fetch everything:
    - `asc apps --paginate`
  - Set default:
    - `ASC_APP_ID=...`
  
  ## Build ID
  - Latest build:
    - `asc builds info --app "APP_ID" --latest --version "1.2.3" --platform IOS`
  - Recent builds:
    - `asc builds list --app "APP_ID" --sort -uploadedDate --limit 5`
  
  ## Version ID
  - `asc versions list --app "APP_ID" --paginate`
  
  ## TestFlight IDs
  - Groups:
    - `asc testflight groups list --app "APP_ID" --paginate`
  - Testers:
    - `asc testflight testers list --app "APP_ID" --paginate`
  
  ## Pre-release version IDs
  - `asc testflight pre-release list --app "APP_ID" --platform IOS --paginate`
  
  ## Review submission IDs
  - `asc review submissions-list --app "APP_ID" --paginate`
  
  ## Output tips
  - JSON is default; use `--pretty` for debug.
  - For human viewing, use `--output table` or `--output markdown`.
  
  ## Guardrails
  - Prefer `--paginate` on list commands to avoid missing IDs.
  - Use `--sort` where available to make results deterministic.
  

• skills/asc-build-lifecycle/SKILL.mdskill
  Show content (1362 bytes)

  ---
  name: asc-build-lifecycle
  description: Track build processing, find latest builds, and clean up old builds with asc. Use when managing build retention or waiting on processing.
  ---
  
  # asc build lifecycle
  
  Use this skill to manage build state, processing, and retention.
  
  ## Find the right build
  - Latest build:
    - `asc builds info --app "APP_ID" --latest --version "1.2.3" --platform IOS`
  - Next safe build number:
    - `asc builds next-build-number --app "APP_ID" --version "1.2.3" --platform IOS`
  - Recent builds:
    - `asc builds list --app "APP_ID" --sort -uploadedDate --limit 10`
  
  ## Inspect processing state
  - `asc builds info --build-id "BUILD_ID"`
  
  ## Distribution flows
  - Prefer end-to-end:
    - `asc publish testflight --app "APP_ID" --ipa "./app.ipa" --group "GROUP_ID" --wait`
    - `asc publish appstore --app "APP_ID" --ipa "./app.ipa" --version "1.2.3" --wait --submit --confirm`
  
  ## Cleanup
  - Preview expiration:
    - `asc builds expire-all --app "APP_ID" --older-than 90d --dry-run`
  - Apply expiration:
    - `asc builds expire-all --app "APP_ID" --older-than 90d --confirm`
  - Single build:
    - `asc builds expire --build-id "BUILD_ID" --confirm`
  
  ## Notes
  - `asc builds upload` prepares upload operations only; use `asc publish` for end-to-end flows.
  - For long processing times, use `--wait`, `--poll-interval`, and `--timeout` where supported.
  

• skills/asc-cli-usage/SKILL.mdskill
  Show content (2388 bytes)

  ---
  name: asc-cli-usage
  description: Guidance for using asc cli in this repo (flags, output formats, pagination, auth, and discovery). Use when asked to run or design asc commands or interact with App Store Connect via the CLI.
  ---
  
  # asc cli usage
  
  Use this skill when you need to run or design `asc` commands for App Store Connect.
  
  ## Command discovery
  - Always use `--help` to discover commands and flags.
    - `asc --help`
    - `asc builds --help`
    - `asc builds list --help`
  
  ## Canonical verbs (current asc)
  - Prefer `view` over legacy `get` aliases for read-only commands in docs and automation.
    - `asc apps view --id "APP_ID"`
    - `asc versions view --version-id "VERSION_ID"`
    - `asc pricing availability view --app "APP_ID"`
  - Prefer `edit` for update-only availability surfaces and other canonical edit flows.
    - `asc pricing availability edit --app "APP_ID" --territory "USA,GBR" --available true`
    - `asc app-setup availability edit --app "APP_ID" --territory "USA,GBR" --available true`
    - `asc xcode version edit --build-number "42"`
  - Keep `set` where the CLI intentionally models a higher-level replacement/configuration flow and `--help` still shows `set` as the canonical verb.
  
  ## Flag conventions
  - Use explicit long flags (e.g., `--app`, `--output`).
  - Prefer explicit flags in automation; some newer commands can prompt for missing fields when run interactively.
  - Destructive operations require `--confirm`.
  - Use `--paginate` when the user wants all pages.
  
  ## Output formats
  - Output defaults are TTY-aware: `table` in interactive terminals, `json` when piped or non-interactive.
  - Use `--output table` or `--output markdown` only for human-readable output.
  - `--pretty` is only valid with JSON output.
  
  ## Authentication and defaults
  - Prefer keychain auth via `asc auth login`.
  - Fallback env vars: `ASC_KEY_ID`, `ASC_ISSUER_ID`, `ASC_PRIVATE_KEY_PATH`, `ASC_PRIVATE_KEY`, `ASC_PRIVATE_KEY_B64`.
  - `ASC_APP_ID` can provide a default app ID.
  - When permissions are unclear, inspect exact API key role coverage with `asc web auth capabilities`.
    - This lives under the experimental web auth surface.
    - It can resolve the current local auth by default, or inspect a specific key with `--key-id`.
  
  ## Timeouts
  - `ASC_TIMEOUT` / `ASC_TIMEOUT_SECONDS` control request timeouts.
  - `ASC_UPLOAD_TIMEOUT` / `ASC_UPLOAD_TIMEOUT_SECONDS` control upload timeouts.
  

• skills/asc-crash-triage/SKILL.mdskill
  Show content (3358 bytes)

  ---
  name: asc-crash-triage
  description: Triage TestFlight crashes, beta feedback, and performance diagnostics using asc. Use when the user asks about TF crashes, TestFlight crash reports, beta tester feedback, app hangs, disk writes, launch diagnostics, or wants a crash summary for a build or app.
  ---
  
  # asc crash triage
  
  Use this skill to fetch, analyze, and summarize TestFlight crash reports, beta feedback, and performance diagnostics.
  
  ## Workflow
  
  1. Resolve the app ID if not provided (use `asc apps list`).
  2. Fetch data with the appropriate command.
  3. Parse JSON output and present a human-readable summary.
  
  ## TestFlight crash reports
  
  List recent crashes (newest first):
  
  - `asc testflight crashes list --app "APP_ID" --sort -createdDate --limit 10`
  - Filter by build: `asc testflight crashes list --app "APP_ID" --build "BUILD_ID" --sort -createdDate --limit 10`
  - Filter by device/OS: `asc testflight crashes list --app "APP_ID" --device-model "iPhone16,2" --os-version "18.0"`
  - All crashes: `asc testflight crashes list --app "APP_ID" --paginate`
  - Table view: `asc testflight crashes list --app "APP_ID" --sort -createdDate --limit 10 --output table`
  
  ## TestFlight beta feedback
  
  List recent feedback (newest first):
  
  - `asc testflight feedback list --app "APP_ID" --sort -createdDate --limit 10`
  - With screenshots: `asc testflight feedback list --app "APP_ID" --sort -createdDate --limit 10 --include-screenshots`
  - Filter by build: `asc testflight feedback list --app "APP_ID" --build "BUILD_ID" --sort -createdDate`
  - All feedback: `asc testflight feedback list --app "APP_ID" --paginate`
  
  ## Performance diagnostics (hangs, disk writes, launches)
  
  Requires a build ID. Resolve via `asc builds info --app "APP_ID" --latest --platform IOS` or `asc builds list --app "APP_ID" --sort -uploadedDate --limit 5`.
  
  - List diagnostic signatures: `asc performance diagnostics list --build "BUILD_ID"`
  - Filter by type: `asc performance diagnostics list --build "BUILD_ID" --diagnostic-type "HANGS"`
    - Types: `HANGS`, `DISK_WRITES`, `LAUNCHES`
  - View logs for a signature: `asc performance diagnostics view --id "SIGNATURE_ID"`
  - Download all metrics: `asc performance download --build "BUILD_ID" --output ./metrics.json`
  
  ## Resolving IDs
  
  - App ID from name: `asc apps list --name "AppName"` or `asc apps list --bundle-id "com.example.app"`
  - Latest build ID: `asc builds info --app "APP_ID" --latest --platform IOS`
  - Recent builds: `asc builds list --app "APP_ID" --sort -uploadedDate --limit 5`
  - Set default: `export ASC_APP_ID="APP_ID"`
  
  ## Summary format
  
  When presenting results, organize by severity and frequency:
  
  1. **Total count** — how many crashes/feedbacks in the result set.
  2. **Top crash signatures** — group by exception type or crash reason, ranked by count.
  3. **Affected builds** — which build versions are impacted.
  4. **Device & OS breakdown** — most affected device models and OS versions.
  5. **Timeline** — when crashes started or spiked.
  
  For performance diagnostics, highlight the highest-weight signatures first.
  
  ## Notes
  
  - Default output is JSON; use `--output table` or `--output markdown` for quick human review.
  - Use `--paginate` to fetch all pages when doing a full analysis.
  - Use `--pretty` with JSON for debugging command output.
  - Crash data from App Store Connect may have 24-48h delay.
  

README

npx skills add rorkai/app-store-connect-cli-skills

Find the right asc command to list all builds for app 123456789 as JSON and paginate through everything.

Create an asc workflow that stages a release, validates it, and only submits when CONFIRM_RELEASE=true.

Create a new App Store Connect app for com.example.myapp with SKU MYAPP123 and primary language English (U.S.).

Archive and export my macOS app as a PKG I can upload to App Store Connect.

Build my iOS app, capture the home and settings screens in the simulator, frame them, and prepare them for upload.

Check whether version 2.4.0 of my iOS app is ready for App Store submission, show the blockers, and tell me the next `asc` command to run.

Set up signing for com.example.app with iCloud enabled, a distribution certificate, and an App Store profile.

Resolve the App Store Connect app ID, latest build ID, and TestFlight group IDs for MyApp.

Pull my App Store metadata into ./metadata, update the privacy policy URL, and push the changes back safely.

Translate my en-US App Store metadata into German, French, and Japanese, then show me the changes before upload.

Audit ./metadata for ASO problems, then show the highest-value keyword gaps from Astro for my latest version.

Turn these release bullet points into polished What's New notes for en-US and localize them across my existing metadata locales.

Preflight my iOS submission, check encryption/content-rights issues, and tell me what will block review.

Export my current TestFlight config, create a new external group, add testers, and attach the latest build.

Find the latest processed build for app 123456789 and preview expiring all TestFlight builds older than 90 days.

Update my subscription pricing for India, Brazil, and Mexico using a PPP-style rollout and verify the result.

Set the display name Monthly Pro across all missing locales for this subscription and verify which locales were created.

Audit my App Store Connect subscriptions and IAPs against RevenueCat, then create any missing mappings after I approve the plan.

Archive my macOS app, export it for Developer ID, notarize the ZIP, and staple the result.

Show me the latest TestFlight crashes and feedback for MyApp, grouped by signature and affected build.

Submit app 1234567890 to the Wall of Apps using the built-in asc apps wall submit flow.