
Asc Workflow
Author, validate, dry-run, execute, and resume repo-local App Store Connect automation via asc workflow and .asc/workflow.json.
Overview
asc workflow is an agent skill most often used in Ship (also Build integrations) that defines, validates, runs, and resumes repo-local multi-step App Store Connect automations with asc workflow and .asc/workflow.json.
Install
npx skills add https://github.com/rudrankriyam/app-store-connect-cli-skills --skill asc-workflowWhat is this skill?
- End-to-end flow: author .asc/workflow.json → validate → list → dry-run → run with KEY:VALUE params
- Resume failed runs with --resume and run ID without re-passing params
- Stdout stays machine-readable JSON; step output streams to stderr
- Supports safe release and TestFlight-oriented multi-step shell command lanes
- Always discover current flags via asc workflow --help before scripting
- Default workflow path .asc/workflow.json
- Six-step documented flow from author through resume
Adoption & trust: 1.9k installs on skills.sh; 845 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You repeat manual ASC release steps across machines and need resumable, validated workflow files instead of brittle shell one-liners.
Who is it for?
Solo iOS/macOS developers already using the asc CLI who want JSON-friendly CI workflows for beta and release.
Skip if: Builders without App Store Connect API access, Android-only shipping, or teams that refuse repo-local shell execution in workflows.
When should I use this skill?
You need to define, validate, run, resume, or audit repo-local multi-step automations with asc workflow and .asc/workflow.json.
What do I get? / Deliverables
You get validated .asc/workflow.json lanes you can dry-run, execute with parameters, and resume after failures using stored run state.
- Validated workflow.json
- Dry-run and execution JSON results on stdout
- Resumable run IDs for failed lanes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
TestFlight and App Store release lanes belong in Ship as launch prep, even though workflows are authored during Build. Launch subphase is the canonical shelf for repeatable ASC CLI release and beta distribution steps.
Where it fits
Author a beta workflow that uploads a build and assigns a TestFlight group using BUILD_ID and GROUP_ID params.
Dry-run then execute a release lane before App Store submission night.
Resume release-20260312T120000Z-deadbeef after a transient ASC API failure without re-supplying parameters.
How it compares
Repo-local asc workflow JSON lanes—not a hosted CI marketplace or raw Fastfile without asc command discovery.
Common Questions / FAQ
Who is asc-workflow for?
Indie Apple-platform developers automating TestFlight and release steps through the App Store Connect CLI in git-tracked workflow files.
When should I use asc-workflow?
In Ship launch prep to validate and run beta/release workflows, during Build integrations when authoring .asc/workflow.json, and in Operate iterate when resuming a failed run.
Is asc-workflow safe to install?
Workflows execute trusted shell commands with your ASC credentials—review Security Audits on this page and inspect workflow steps before running in production accounts.
SKILL.md
READMESKILL.md - Asc Workflow
# asc workflow Use this skill when you need lane-style automation inside the CLI using: - `asc workflow validate` - `asc workflow list` - `asc workflow run` Workflows are repo-local automation files. They run trusted shell commands, stream step output to stderr, and keep stdout as machine-readable JSON. ## Command discovery Always verify flags with: ```bash asc workflow --help asc workflow validate --help asc workflow list --help asc workflow run --help ``` ## End-to-end flow 1. Author `.asc/workflow.json`. 2. Validate structure and references: ```bash asc workflow validate ``` 3. Discover public workflows: ```bash asc workflow list asc workflow list --all ``` 4. Preview execution: ```bash asc workflow run --dry-run beta BUILD_ID:123456789 GROUP_ID:abcdef ``` 5. Execute: ```bash asc workflow run beta BUILD_ID:123456789 GROUP_ID:abcdef ``` 6. If a recoverable run fails, resume with the run ID from the JSON result: ```bash asc workflow run release --resume "release-20260312T120000Z-deadbeef" ``` Do not pass extra `KEY:VALUE` params with `--resume`; the saved workflow file, params, and persisted outputs are reused. ## File location and format - Default path: `.asc/workflow.json` - Override path: `asc workflow run --file ./path/to/workflow.json <name>` - JSONC comments are supported. - Top-level hooks: `before_all`, `after_all`, `error` - Workflow keys: `description`, `private`, `env`, `steps` - Step forms: - string shorthand: `"echo hello"` - `run` shell command - `workflow` sub-workflow call - `name` label - `if` conditional var name - `with` env overrides for workflow-call steps - `outputs` map for JSON stdout extraction from named run steps ## Outputs Run steps can declare outputs. The command must emit JSON on stdout, so pass `--output json` for `asc` commands that produce outputs. Output references use: ```text ${steps.step_name.OUTPUT_NAME} ``` Rules: - A step that declares `outputs` must have a reference-safe `name`. - Outputs are allowed on `run` steps, not workflow-call steps. - Output-producing names must be unique across workflows that can execute together in the same run graph. - Persisted outputs are stored in workflow run state, so do not map secrets into outputs. ## Runtime params `asc workflow run <name> [KEY:VALUE ...]` supports both separators: ```bash asc workflow run beta VERSION:2.1.0 asc workflow run beta VERSION=2.1.0 ``` Repeated keys are last-write-wins. In shell commands, reference params through shell expansion like `$VERSION`. ## Env precedence Main workflow run: ```text definition.env < workflow.env < CLI params ``` Sub-workflow call with `with`: ```text sub-workflow env < caller env and params < step with ``` ## Conditionals Add `"if": "VAR_NAME"` to a step. Truthy values are `1`, `true`, `yes`, `y`, and `on`, case-insensitive. Lookup checks merged workflow env/params first, then process environment. ## Example workflow ```json { "env": { "APP_ID": "123456789", "VERSION": "1.0.0", "GROUP_ID": "" }, "before_all": "asc auth status", "after_all": "echo workflow_done", "error": "echo workflow_failed", "workflows": { "beta": { "description": "Resolve the latest build and distribute it to TestFlight", "steps": [ { "name": "resolve_build", "run": "asc builds info --app $APP_ID --latest --platform IOS --output json", "outputs": { "BUILD_ID": "$.data.id" } }, { "name": "list_groups", "run": "asc testflight groups list --app $APP_ID --limit 20 --output json" }, { "name": "add_build_to_group", "if": "GROUP_ID", "run": "asc builds add-groups --build-id $