App Store submission health

Use this skill to explain why a release cannot proceed and to manage an existing review submission. Hand healthy release execution back to asc-release-flow.

Ownership boundary

This skill owns:

• readiness validation and blocker diagnosis;
• public-API, web-session, and manual repair routing;
• review status and history;
• cancellation and retry decisions.

Use asc-release-flow for staging, upload, publication, and submission. Switching skills continues the current task with its resolved targets, authorization, and verified progress; it does not require the user to restart the workflow. Continue authorized repairs and return to release execution when healthy. Ask for new authority only when a repair exceeds scope.

Answer order

1. State whether the version is ready, blocked, or already under review.
2. Name each blocker and the evidence that proves it.
3. Separate public-API repairs from web-session and manual work.
4. Run the read-only checks needed to establish the diagnosis. For diagnosis-only requests, report the evidence and one proposed repair command without executing that repair. For authorized execution, continue the repair queue and report completed work and remaining blockers.

Establish the target

• Resolve APP_ID, the version string or VERSION_ID, BUILD_ID, platform, and any known SUBMISSION_ID.
• Configure auth with asc auth login or ASC_* environment variables.
• Use ASC_BYPASS_KEYCHAIN=1 only for repository tests and isolated verification, not normal user sessions.
• Prefer IDs once the target is resolved; stop when app, version, or product resolution is ambiguous.

Diagnose readiness

Run the canonical readiness report first:

asc validate --app "APP_ID" --version "1.2.3" --platform IOS --output table

Use --version-id "VERSION_ID" when known. Add --strict when warnings must fail automation.

Ask the review-specific doctor for an ordered explanation: