# Asc Submission Health

Diagnose App Store submission blockers and operate review health with asc, including...

- Repository: https://github.com/rorkai/app-store-connect-cli-skills (1119 stars)
- Category: Mobile
- License: MIT
- Last updated: 2026-10-26
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add rorkai/app-store-connect-cli-skills --skill asc-submission-health -g -a claude-code -y`
Codex: `npx skills add rorkai/app-store-connect-cli-skills --skill asc-submission-health -g -a codex -y`
Cursor: `npx skills add rorkai/app-store-connect-cli-skills --skill asc-submission-health -g -a cursor -y`
Gemini CLI: `npx skills add rorkai/app-store-connect-cli-skills --skill asc-submission-health -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add rorkai/app-store-connect-cli-skills`

## Description

Diagnose App Store submission blockers and operate review health with asc, including readiness validation, repair routing, status monitoring, cancellation, and retry decisions. Use when validation fails, a version is not in a valid state, review status is unclear or stuck, or a failed submission must be repaired and retried. For staging, upload, publication, and submission execution, use asc-release-flow.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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:

```bash
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:

The rest: https://github.com/rorkai/app-store-connect-cli-skills/blob/HEAD/skills/asc-submission-health/SKILL.md