Asc Release Flow
Answer “can I submit now?” and drive App Store version prep and review submission with the asc CLI, including blockers and the next exact command.
Overview
asc-release-flow is an agent skill most often used in Ship (also Validate scope checks and Launch ASO handoff) that drives readiness-first App Store submission with the asc CLI.
Install
npx skills add https://github.com/rudrankriyam/app-store-connect-cli-skills --skill asc-release-flowWhat is this skill?
- Readiness-first flow: readiness verdict, blocking issues, API vs web vs manual fixes, then the next exact `asc` command
- Preconditions checklist: APP_ID, version IDs, build ID, auth, and `./metadata` for metadata-driven staging
- Maps blockers to API-fixable (build, metadata, screenshots, IAP, Game Center) vs web-session vs manual fallback
- Covers validation, staging, review submission, subscriptions, IAP, Game Center, and App Privacy publish checks
- 4-step answer order: readiness, blockers, fix channel split, next exact command
- 3 blocker channels: API-fixable, web-session-fixable, and manual fallback
Adoption & trust: 2.4k installs on skills.sh; 845 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a build and metadata but cannot tell if App Store review submission is blocked or which fix needs the API, web UI, or manual steps.
Who is it for?
Solo iOS developers already using asc who need a structured submit checklist and blocker triage before review.
Skip if: Android Play Console releases, apps with no asc auth setup, or teams that only want marketing copy without release engineering.
When should I use this skill?
User asks “Can my app be submitted now?” or wants to prepare and submit an App Store version with the current asc command surface.
What do I get? / Deliverables
You get a clear ready-or-not verdict, categorized blockers, and the next `asc` command to run toward a submitted App Store version.
- Submit readiness yes/no with named blocking issues
- Next exact asc command and fix-path classification (API, web, manual)
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Release readiness and submission are canonical Ship work even when gaps trace back to metadata or privacy set earlier in the build. App Store version staging, review submission, and first-time availability checks are launch-prep within shipping—not day-two growth analytics.
Where it fits
Before a full build push, list API-fixable vs manual blockers so scope includes privacy, IAP, and Game Center work.
Attach build, stage metadata from ./metadata, and run validation immediately before review submission.
Confirm screenshots, review details, and version strings align with the store listing you are about to ship.
How it compares
Workflow skill for asc-driven release gates—not a replacement for Apple’s web console where first-time availability or privacy publish still requires session access.
Common Questions / FAQ
Who is asc-release-flow for?
Indie and solo iOS builders preparing or submitting App Store versions with the asc CLI who need readiness answers before running more commands.
When should I use asc-release-flow?
At Ship → launch when asking if the app can submit now; during Validate when scoping what blocks release; at Launch → ASO when coordinating version, build, and privacy readiness.
Is asc-release-flow safe to install?
Review the Security Audits panel on this Prism page; asc uses your App Store Connect credentials—store ASC secrets in env vars, not in chat logs.
SKILL.md
READMESKILL.md - Asc Release Flow
# Release flow (readiness-first) Use this skill when the question is "Can my app be submitted now?" or when the user wants to prepare and submit an App Store version with the current `asc` command surface. ## Preconditions - Resolve `APP_ID`, version string, `VERSION_ID` when needed, and `BUILD_ID` up front. - Ensure auth is configured with `asc auth login` or `ASC_*` environment variables. - Have canonical metadata in `./metadata` when using metadata-driven staging. - Treat `asc web ...` commands as optional experimental escape hatches for flows not covered by the public API. ## Answer order 1. Say whether the app is ready right now. 2. Name the blocking issues. 3. Separate public-API fixes from web-session or manual fixes. 4. Give the next exact command to run. Blockers usually fall into: - API-fixable: build validity, metadata, screenshots, review details, content rights, encryption, version/build attachment, IAP readiness, Game Center version and review-submission items. - Web-session-fixable: initial app availability bootstrap, first-review subscription attachment, App Privacy publish state. - Manual fallback: first-time IAP selection on the app-version page when no CLI attach flow exists, or any flow the user does not want to run through experimental web-session commands. ## Canonical current path ### 1. Readiness check Use `asc validate`; the old submit-preflight shortcut is not part of the current CLI. ```bash asc validate --app "APP_ID" --version "1.2.3" --platform IOS --output table ``` Use strict mode when warnings should block automation: ```bash asc validate --app "APP_ID" --version "1.2.3" --platform IOS --strict --output table ``` For apps selling digital goods, run the product readiness checks too: ```bash asc validate iap --app "APP_ID" --output table asc validate subscriptions --app "APP_ID" --output table ``` ### 2. Stage without submitting Use `asc release stage` when the user wants to prepare the version, apply/copy metadata, attach the build, and validate, while stopping before review submission. ```bash asc release stage \ --app "APP_ID" \ --version "1.2.3" \ --build "BUILD_ID" \ --metadata-dir "./metadata/version/1.2.3" \ --dry-run \ --output table ``` Apply the staging mutations after the plan looks correct: ```bash asc release stage \ --app "APP_ID" \ --version "1.2.3" \ --build "BUILD_ID" \ --metadata-dir "./metadata/version/1.2.3" \ --confirm ``` Use `--copy-metadata-from "1.2.2"` instead of `--metadata-dir` when carrying metadata forward from an existing version. ### 3. Submit an already prepared version Use `asc review submit` for explicit App Store review submission. It wraps build attachment plus review submission creation. ```bash asc review submit --app "APP_ID" --version "1.2.3" --build "BUILD_ID" --dry-run --output table asc review submit --app "APP_ID" --version "1.2.3" --build "BUILD_ID" --confirm ``` Use `--version-id "VERSION_ID"` instead of `--version` when you already resolved the exact version ID. ### 4. One-command upload and submit Use `asc publish appstore` when upload/build/local-build and submission should be one high-level flow. ```bash asc publish appstore --app "APP_ID" --ipa "./App.ipa" --version "1.2.3" --submit --dry-run --output table asc publish appstore --app "APP_ID" --ipa "./App.ipa" --version "1.2.3" --submit --confirm ``` Add `--wait` when the command should wait for build processing before attaching/submitting. ### 5. Monitor and cancel ```bash asc status --app "APP_ID" asc submit status --version-id "VERSION_ID" asc submit status --id "SUBMISSION_ID" asc submit cancel --id "SUBMISSION_ID" --confirm ``` ## First-time submission blockers ##