Asc Release Flow
Check whether an iOS or Mac app can ship to the App Store now and run the exact asc CLI steps to validate, stage, and submit the current version.
Overview
asc-release-flow is an agent skill for the Ship phase that determines App Store submission readiness and drives the current asc release flow with validation, staging, and review submission.
Install
npx skills add https://github.com/rudrankriyam/asc-skills --skill asc-release-flowWhat is this skill?
- Answers readiness first in a fixed four-step order: ready or not, blockers, API vs web vs manual fixes, then the next as
- Classifies blockers into API-fixable (metadata, screenshots, builds, IAP, Game Center), web-session-fixable (availabilit
- Resolves APP_ID, version, VERSION_ID, and BUILD_ID up front with asc auth and optional ./metadata-driven staging
- Covers validation, staging, review submission, subscriptions, IAP, Game Center, and App Privacy checks on the current as
- Treats asc web commands as optional experimental escape hatches when the public API cannot complete a step
- Four-step answer order: readiness, blockers, fix channel split, next command
- Three blocker classes: API-fixable, web-session-fixable, and manual fallback
Adoption & trust: 1.1k installs on skills.sh; 845 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are close to shipping but cannot tell whether App Store Connect blockers are metadata, builds, privacy, IAP, or manual store-setup issues—and which asc command to run next.
Who is it for?
Indie iOS or Mac developers using asc who want a structured submit path with explicit handling of API, web-session, and manual blockers.
Skip if: Teams not on App Store Connect, greenfield apps with no asc auth or identifiers resolved yet, or Android-only or web-only release pipelines.
When should I use this skill?
The question is whether the app can be submitted now, or the user 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, a prioritized blocker list split by fix channel, and the next exact asc command to move the version toward review.
- Submission readiness verdict with named blocking issues
- Next exact asc command and fix-channel classification per blocker
Recommended Skills
Journey fit
App Store submission is the last gated step before public availability—readiness, blockers, and review submission belong on the Ship phase launch shelf. The skill is built around version attachment, review submission, and first-time store setup, which maps directly to launch prep rather than perf tuning or security scanning alone.
How it compares
Use instead of generic mobile checklists that do not map blockers to asc commands or separate public-API fixes from web-session store setup.
Common Questions / FAQ
Who is asc-release-flow for?
Solo and indie builders shipping Apple platform apps who use the asc CLI and need submission readiness and command-level guidance through App Store review prep.
When should I use asc-release-flow?
Use it when you ask whether the app can be submitted now, when preparing an App Store version with asc, or during Ship launch prep when validation, metadata, IAP, Game Center, or App Privacy might block review.
Is asc-release-flow safe to install?
Review the Security Audits panel on this Prism page and the skill source before running asc with your ASC credentials; the skill expects store API access and may guide web-session steps on your account.
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 ##