asc-submission-health

Name: asc-submission-health
Author: rorkai

924stars49forks

How to install asc-submission-health?

rorkai/app-store-connect-cli-skills/asc-submission-health

$npx -y skills add rorkai/app-store-connect-cli-skills --skill asc-submission-health

Installs into the current project.

Summary

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 f

Files · 1

View on GitHub

SKILL.md

1	# App Store submission health
2
3	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`.
4
5	## Ownership boundary
6
7	This skill owns:
8
9	- readiness validation and blocker diagnosis;
10	- public-API, web-session, and manual repair routing;
11	- review status and history;
12	- cancellation and retry decisions.
13
14	Do not stage, upload, publish, or submit a healthy release from this skill.
15
16	## Answer order
17
18	1. State whether the version is ready, blocked, or already under review.
19	2. Name each blocker and the evidence that proves it.
20	3. Separate public-API repairs from web-session and manual work.
21	4. Give one next command. Do not dump the entire repair catalog.
22
23	## Establish the target
24
25	- Resolve `APP_ID`, the version string or `VERSION_ID`, `BUILD_ID`, platform, and any known `SUBMISSION_ID`.
26	- Configure auth with `asc auth login` or `ASC_*` environment variables.
27	- Use `ASC_BYPASS_KEYCHAIN=1` only for repository tests and isolated verification, not normal user sessions.
28	- Prefer IDs once the target is resolved; stop when app, version, or product resolution is ambiguous.
29
30	## Diagnose readiness
31
32	Run the canonical readiness report first:
33
34	```bash
35	asc validate --app "APP_ID" --version "1.2.3" --platform IOS --output table
36	```
37
38	Use `--version-id "VERSION_ID"` when known. Add `--strict` when warnings must fail automation.
39
40	Ask the review-specific doctor for an ordered explanation:
41
42	```bash
43	asc review doctor --app "APP_ID" --version "1.2.3" --platform IOS --output table
44	```
45
46	Collect direct evidence when the report points at the build or version:
47
48	```bash
49	asc builds info --build-id "BUILD_ID" --output table
50	asc versions view --version-id "VERSION_ID" --include-build --include-submission --output table
51	```
52
53	For digital goods, run only the relevant product validator:
54
55	```bash
56	asc validate iap --app "APP_ID" --output table
57	asc validate subscriptions --app "APP_ID" --output table
58	```
59
60	Treat the ordered remediation plan from `asc validate` as the repair queue. Fix and verify one class of blocker before moving to the next.
61
62	## Route repairs
63
64	Use public API commands when the blocker is build processing, metadata, screenshots, review details, encryption, content rights, age rating, availability, or version-scoped product metadata.
65
66	Read [references/readiness-repairs.md](references/readiness-repairs.md) when diagnostics identify one of those common blockers or a first-release availability gap.
67
68	Read [references/digital-goods.md](references/digital-goods.md) only when IAP or subscription validation fails, Apple requires first-review attachment, or a versioned product must join an existing review submission.
69
70	Read [references/app-privacy.md](references/app-privacy.md) only when validation reports an App Privacy advisory or the publish state cannot be confirmed through the public API.
71
72	When validation reports a Game Center component or version blocker, hand it to `asc-release-flow` and request the multi-item reference's Prepare every item section. Do not route Game Center through general readiness or digital-goods repairs.
73
74	Use the web-session commands only for a gap the public API cannot cover, and say that an authenticated Apple web session is required. Keep a manual App Store Connect fallback when the user declines web-session automation.
75
76	## Decide whether the version is healthy
77
78	A version is ready to return to `asc-release-flow` when:
79
80	- `asc validate` has no blocking issues;
81	- the attached build is `VALID`;
82	- metadata, screenshots, app info, review details, content rights, encryption, age rating, pricing, and availability are resolved;
83	- the relevant `asc validate iap` and/or `asc validate subscriptions` checks have no blocking issues, and the required digital-goods versions are prepared;
84	- any Game Center version items have been checked through `asc-release-flow`'s multi-item submission reference;
85	- App Privacy is confirmed or published.
86
87	Do not call a version ready merely because one validator exits successfully. Report any warning that still needs a web-session or manual check.
88
89	## Monitor review
90
91	Use app-scoped status when the submission ID is unknown:
92
93	```bash
94	asc review status --app "APP_ID" --version "1.2.3" --platform IOS --output table
95	```
96
97	Use exact submission or version IDs when available:
98
99	```bash
100	asc submit status --id "SUBMISSION_ID" --output table
101	asc submit status --version-id "VERSION_ID" --output table
102	```
103
104	Use the release dashboard for surrounding build and review sign

People who liked this also viewed

6 picks

Type

asc-submission-health

924stars49forks

View on GitHub

How to install asc-submission-health?

rorkai/app-store-connect-cli-skills/asc-submission-health

$npx -y skills add rorkai/app-store-connect-cli-skills --skill asc-submission-health

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# App Store submission health
2
3	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`.
4
5	## Ownership boundary
6
7	This skill owns:
8
9	- readiness validation and blocker diagnosis;
10	- public-API, web-session, and manual repair routing;
11	- review status and history;
12	- cancellation and retry decisions.
13
14	Do not stage, upload, publish, or submit a healthy release from this skill.
15
16	## Answer order
17
18	1. State whether the version is ready, blocked, or already under review.
19	2. Name each blocker and the evidence that proves it.
20	3. Separate public-API repairs from web-session and manual work.
21	4. Give one next command. Do not dump the entire repair catalog.
22
23	## Establish the target
24
25	- Resolve `APP_ID`, the version string or `VERSION_ID`, `BUILD_ID`, platform, and any known `SUBMISSION_ID`.
26	- Configure auth with `asc auth login` or `ASC_*` environment variables.
27	- Use `ASC_BYPASS_KEYCHAIN=1` only for repository tests and isolated verification, not normal user sessions.
28	- Prefer IDs once the target is resolved; stop when app, version, or product resolution is ambiguous.
29
30	## Diagnose readiness
31
32	Run the canonical readiness report first:
33
34	```bash
35	asc validate --app "APP_ID" --version "1.2.3" --platform IOS --output table
36	```
37
38	Use `--version-id "VERSION_ID"` when known. Add `--strict` when warnings must fail automation.
39
40	Ask the review-specific doctor for an ordered explanation:
41
42	```bash
43	asc review doctor --app "APP_ID" --version "1.2.3" --platform IOS --output table
44	```
45
46	Collect direct evidence when the report points at the build or version:
47
48	```bash
49	asc builds info --build-id "BUILD_ID" --output table
50	asc versions view --version-id "VERSION_ID" --include-build --include-submission --output table
51	```
52
53	For digital goods, run only the relevant product validator:
54
55	```bash
56	asc validate iap --app "APP_ID" --output table
57	asc validate subscriptions --app "APP_ID" --output table
58	```
59
60	Treat the ordered remediation plan from `asc validate` as the repair queue. Fix and verify one class of blocker before moving to the next.
61
62	## Route repairs
63
64	Use public API commands when the blocker is build processing, metadata, screenshots, review details, encryption, content rights, age rating, availability, or version-scoped product metadata.
65
66	Read [references/readiness-repairs.md](references/readiness-repairs.md) when diagnostics identify one of those common blockers or a first-release availability gap.
67
68	Read [references/digital-goods.md](references/digital-goods.md) only when IAP or subscription validation fails, Apple requires first-review attachment, or a versioned product must join an existing review submission.
69
70	Read [references/app-privacy.md](references/app-privacy.md) only when validation reports an App Privacy advisory or the publish state cannot be confirmed through the public API.
71
72	When validation reports a Game Center component or version blocker, hand it to `asc-release-flow` and request the multi-item reference's Prepare every item section. Do not route Game Center through general readiness or digital-goods repairs.
73
74	Use the web-session commands only for a gap the public API cannot cover, and say that an authenticated Apple web session is required. Keep a manual App Store Connect fallback when the user declines web-session automation.
75
76	## Decide whether the version is healthy
77
78	A version is ready to return to `asc-release-flow` when:
79
80	- `asc validate` has no blocking issues;
81	- the attached build is `VALID`;
82	- metadata, screenshots, app info, review details, content rights, encryption, age rating, pricing, and availability are resolved;
83	- the relevant `asc validate iap` and/or `asc validate subscriptions` checks have no blocking issues, and the required digital-goods versions are prepared;
84	- any Game Center version items have been checked through `asc-release-flow`'s multi-item submission reference;
85	- App Privacy is confirmed or published.
86
87	Do not call a version ready merely because one validator exits successfully. Report any warning that still needs a web-session or manual check.
88
89	## Monitor review
90
91	Use app-scoped status when the submission ID is unknown:
92
93	```bash
94	asc review status --app "APP_ID" --version "1.2.3" --platform IOS --output table
95	```
96
97	Use exact submission or version IDs when available:
98
99	```bash
100	asc submit status --id "SUBMISSION_ID" --output table
101	asc submit status --version-id "VERSION_ID" --output table
102	```
103
104	Use the release dashboard for surrounding build and review sign

People who liked this also viewed

6 picks

Type