asc-release-flow

Name: asc-release-flow
Author: rorkai

924stars49forks

How to install asc-release-flow?

rorkai/app-store-connect-cli-skills/asc-release-flow

$npx -y skills add rorkai/app-store-connect-cli-skills --skill asc-release-flow

Installs into the current project.

Summary

Orchestrate App Store releases with asc, including staging a version, uploading or building an artifact, publishing, and submitting for review. Use when the user wants to prepare or execute a release. Keep Game Center item preparation in this skill; route other readiness failures

Files · 1

View on GitHub

SKILL.md

1	# App Store release orchestration
2
3	Use this skill to carry a release from an approved plan to App Store review. Keep Game Center item preparation here; keep other blocker diagnosis and review recovery in `asc-submission-health`.
4
5	## Ownership boundary
6
7	This skill owns:
8
9	- staging metadata and attaching a build;
10	- publishing an IPA or building locally;
11	- submitting a prepared version;
12	- assembling a multi-item review submission.
13
14	Use [the preparation section](references/multi-item-submissions.md#prepare-every-item) for Game Center item preparation or attachment blockers. Use that reference's assembly and submission sections only after the app version is staged and the multi-item lane is selected. Stop and use `asc-submission-health` for other validation blockers, a stuck submission, cancellation, or retry decisions.
15
16	## Preconditions
17
18	- Resolve `APP_ID`, the version string, `VERSION_ID` when needed, and `BUILD_ID` when a build already exists.
19	- Configure auth with `asc auth login` or `ASC_*` environment variables.
20	- Confirm the intended platform. Use `IOS` unless the app targets another platform.
21	- Keep canonical metadata in `./metadata` when the workflow applies metadata.
22	- Require a dry run before a mutating high-level command, then require `--confirm` for submission.
23
24	## Choose the release lane
25
26	\| Intent \| Command \|
27	\| --- \| --- \|
28	\| Prepare metadata and attach an existing build without submitting \| `asc release stage` \|
29	\| Submit an already prepared version \| `asc review submit` \|
30	\| Upload an IPA or build locally, then optionally submit \| `asc publish appstore` \|
31	\| Submit the app version with IAP, subscription, or Game Center version items \| lower-level `asc review` submission commands \|
32
33	Do not mix lanes after one has already created a review submission. Inspect the existing submission first and continue through the matching lower-level commands.
34
35	## Run the readiness gate
36
37	Apply this gate to a version that already has the intended build attached. For the staging lane, first complete [Stage an existing build](#stage-an-existing-build); `asc release stage` attaches the build and runs validation, after which this gate can be evaluated. Do not route an expected pre-staging "build not attached" result to `asc-submission-health`.
38
39	Validate before any submission:
40
41	```bash
42	asc validate --app "APP_ID" --version "1.2.3" --platform IOS --output table
43	```
44
45	Use strict mode when warnings must stop automation:
46
47	```bash
48	asc validate --app "APP_ID" --version "1.2.3" --platform IOS --strict --output table
49	```
50
51	Digital goods are a hard gate. If the release includes IAPs or subscriptions, stop and run the relevant product checks in `asc-submission-health`. Resume this flow only after those checks have no blocking issues and the intended product versions are prepared.
52
53	For Game Center items, complete only [Prepare every item](references/multi-item-submissions.md#prepare-every-item), then return to this flow. Do not assemble or submit the multi-item review submission during readiness.
54
55	If app validation reports a Game Center item blocker, stop and use that preparation section. If the only blocker is an unattached build in the staging lane, continue to the staging section. For every other blocker, stop the release flow and use `asc-submission-health`. Do not bury unrelated remediation inside the release run.
56
57	## Stage an existing build
58
59	Use `asc release stage` to ensure the version, apply or copy metadata, attach the selected build, and run validation without creating a review submission.
60
61	Preview metadata-driven staging:
62
63	```bash
64	asc release stage \
65	--app "APP_ID" \
66	--version "1.2.3" \
67	--build "BUILD_ID" \
68	--metadata-dir "./metadata/version/1.2.3" \
69	--dry-run \
70	--output table
71	```
72
73	Apply the reviewed plan:
74
75	```bash
76	asc release stage \
77	--app "APP_ID" \
78	--version "1.2.3" \
79	--build "BUILD_ID" \
80	--metadata-dir "./metadata/version/1.2.3" \
81	--confirm
82	```
83
84	Use `--copy-metadata-from "1.2.2"` instead of `--metadata-dir` when carrying localization metadata forward. Add `--strict-validate` when warnings should fail the stage.
85
86	## Submit a prepared version
87
88	Use `asc review submit` after metadata, review details, availability, build processing, and product readiness are already resolved.
89
90	```bash
91	asc review submit --app "APP_ID" --version "1.2.3" --build "BUILD_ID" --dry-run --output table
92	asc review submit --app "APP_ID" --version "1.2.3" --build "BUILD_ID" --confirm
93	```
94
95	Use `--version-id "VERSION_ID"` instead of `--version` when the exact version ID is known. `--build` may be omitted only when the intended build is al

People who liked this also viewed

6 picks

Type

asc-release-flow

924stars49forks

View on GitHub

How to install asc-release-flow?

rorkai/app-store-connect-cli-skills/asc-release-flow

$npx -y skills add rorkai/app-store-connect-cli-skills --skill asc-release-flow

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# App Store release orchestration
2
3	Use this skill to carry a release from an approved plan to App Store review. Keep Game Center item preparation here; keep other blocker diagnosis and review recovery in `asc-submission-health`.
4
5	## Ownership boundary
6
7	This skill owns:
8
9	- staging metadata and attaching a build;
10	- publishing an IPA or building locally;
11	- submitting a prepared version;
12	- assembling a multi-item review submission.
13
14	Use [the preparation section](references/multi-item-submissions.md#prepare-every-item) for Game Center item preparation or attachment blockers. Use that reference's assembly and submission sections only after the app version is staged and the multi-item lane is selected. Stop and use `asc-submission-health` for other validation blockers, a stuck submission, cancellation, or retry decisions.
15
16	## Preconditions
17
18	- Resolve `APP_ID`, the version string, `VERSION_ID` when needed, and `BUILD_ID` when a build already exists.
19	- Configure auth with `asc auth login` or `ASC_*` environment variables.
20	- Confirm the intended platform. Use `IOS` unless the app targets another platform.
21	- Keep canonical metadata in `./metadata` when the workflow applies metadata.
22	- Require a dry run before a mutating high-level command, then require `--confirm` for submission.
23
24	## Choose the release lane
25
26	\| Intent \| Command \|
27	\| --- \| --- \|
28	\| Prepare metadata and attach an existing build without submitting \| `asc release stage` \|
29	\| Submit an already prepared version \| `asc review submit` \|
30	\| Upload an IPA or build locally, then optionally submit \| `asc publish appstore` \|
31	\| Submit the app version with IAP, subscription, or Game Center version items \| lower-level `asc review` submission commands \|
32
33	Do not mix lanes after one has already created a review submission. Inspect the existing submission first and continue through the matching lower-level commands.
34
35	## Run the readiness gate
36
37	Apply this gate to a version that already has the intended build attached. For the staging lane, first complete [Stage an existing build](#stage-an-existing-build); `asc release stage` attaches the build and runs validation, after which this gate can be evaluated. Do not route an expected pre-staging "build not attached" result to `asc-submission-health`.
38
39	Validate before any submission:
40
41	```bash
42	asc validate --app "APP_ID" --version "1.2.3" --platform IOS --output table
43	```
44
45	Use strict mode when warnings must stop automation:
46
47	```bash
48	asc validate --app "APP_ID" --version "1.2.3" --platform IOS --strict --output table
49	```
50
51	Digital goods are a hard gate. If the release includes IAPs or subscriptions, stop and run the relevant product checks in `asc-submission-health`. Resume this flow only after those checks have no blocking issues and the intended product versions are prepared.
52
53	For Game Center items, complete only [Prepare every item](references/multi-item-submissions.md#prepare-every-item), then return to this flow. Do not assemble or submit the multi-item review submission during readiness.
54
55	If app validation reports a Game Center item blocker, stop and use that preparation section. If the only blocker is an unattached build in the staging lane, continue to the staging section. For every other blocker, stop the release flow and use `asc-submission-health`. Do not bury unrelated remediation inside the release run.
56
57	## Stage an existing build
58
59	Use `asc release stage` to ensure the version, apply or copy metadata, attach the selected build, and run validation without creating a review submission.
60
61	Preview metadata-driven staging:
62
63	```bash
64	asc release stage \
65	--app "APP_ID" \
66	--version "1.2.3" \
67	--build "BUILD_ID" \
68	--metadata-dir "./metadata/version/1.2.3" \
69	--dry-run \
70	--output table
71	```
72
73	Apply the reviewed plan:
74
75	```bash
76	asc release stage \
77	--app "APP_ID" \
78	--version "1.2.3" \
79	--build "BUILD_ID" \
80	--metadata-dir "./metadata/version/1.2.3" \
81	--confirm
82	```
83
84	Use `--copy-metadata-from "1.2.2"` instead of `--metadata-dir` when carrying localization metadata forward. Add `--strict-validate` when warnings should fail the stage.
85
86	## Submit a prepared version
87
88	Use `asc review submit` after metadata, review details, availability, build processing, and product readiness are already resolved.
89
90	```bash
91	asc review submit --app "APP_ID" --version "1.2.3" --build "BUILD_ID" --dry-run --output table
92	asc review submit --app "APP_ID" --version "1.2.3" --build "BUILD_ID" --confirm
93	```
94
95	Use `--version-id "VERSION_ID"` instead of `--version` when the exact version ID is known. `--build` may be omitted only when the intended build is al

People who liked this also viewed

6 picks

Type