asc-workflow
Scannednpx machina-cli add skill rudrankriyam/app-store-connect-cli-skills/asc-workflow --openclawasc workflow
Use this skill when you need lane-style automation inside the CLI using:
asc workflow runasc workflow validateasc workflow list
This feature is best for deterministic automation that lives in your repo, is reviewable in PRs, and can run the same way locally and in CI.
Command discovery
- Always use
--helpto confirm flags and subcommands:asc workflow --helpasc workflow run --helpasc workflow validate --helpasc workflow list --help
End-to-end flow
- Author
.asc/workflow.json - Validate structure and references:
asc workflow validate
- Discover available workflows:
asc workflow listasc workflow list --all(includes private helpers)
- Preview execution without side effects:
asc workflow run --dry-run beta
- Execute with runtime params:
asc workflow run beta BUILD_ID:123456789 GROUP_ID:abcdef
File location and format
- Default path:
.asc/workflow.json - Override path:
asc workflow run --file ./path/to/workflow.json <name> - JSONC comments are supported (
//and/* ... */)
Output and CI contract
stdout: structured JSON result (status,steps, durations)stderr: step command output, hook output, dry-run previewsasc workflow validatealways prints JSON and returns non-zero when invalid
This enables machine-safe checks:
asc workflow validate | jq -e '.valid == true'
asc workflow run beta BUILD_ID:123 GROUP_ID:xyz | jq -e '.status == "ok"'
Schema (what the feature supports)
Top-level keys:
env: global defaultsbefore_all: command run once before stepsafter_all: command run once after successful stepserror: command run when any failure occursworkflows: named workflow map
Workflow keys:
descriptionprivate(not directly runnable)envsteps
Step forms:
- String shorthand:
"echo hello"-> run step - Object with:
run: shell commandworkflow: call sub-workflowname: label for reportingif: conditional var namewith: env overrides for workflow-call steps only
Runtime params (KEY:VALUE / KEY=VALUE)
asc workflow run <name> [KEY:VALUE ...]supports both separators:VERSION:2.1.0VERSION=2.1.0
- If both separators exist, the first one wins.
- Repeated keys are last-write-wins.
- In step commands, reference params via shell expansion (
$VAR). - Avoid putting secrets in
.asc/workflow.json; pass them via CI secrets/env.
Run-tail flags
asc workflow run also accepts core flags after the workflow name:
--dry-run--pretty--file
Examples:
asc workflow run beta --dry-runasc workflow run beta --file .asc/workflow.json BUILD_ID:123
Execution semantics
before_allruns once before step executionafter_allruns only when steps succeederrorruns on failure (step failure, before/after hook failure)- Sub-workflows are executed inline as part of the call step
- Maximum sub-workflow nesting depth is 16
Env precedence
Main workflow run:
definition.env<workflow.env< CLI params
Sub-workflow call step ("workflow": "...", "with": {...}):
- sub-workflow
envdefaults - caller env (including CLI params) overrides
- step
withoverrides all
Sub-workflows and private workflows
- Use
"workflow": "<name>"to call helper workflows. - Use
"private": truefor helper-only workflows. - Private workflows:
- cannot be run directly
- can be called by other workflows
- are hidden from
asc workflow listunless--allis used
- Validation catches unknown workflow references and cyclic references.
Conditionals (if)
- Add
"if": "VAR_NAME"on a step. - Step runs only if
VAR_NAMEis truthy. - Truthy:
1,true,yes,y,on(case-insensitive). - Resolution order for
iflookup:- merged workflow env/params
os.Getenv(VAR_NAME)
Dry-run behavior
asc workflow run --dry-run <name>does not execute commands.- It prints previews to
stderr. - Dry-run shows raw commands (without env expansion), which helps avoid secret leakage in previews.
Shell behavior
- Run steps use
bash -o pipefail -cwhen bash is available. - Fallback is
sh -cwhen bash is unavailable. - Pipelines therefore fail correctly in most CI shells when bash exists.
Practical authoring rules
- Keep workflow files in version control.
- Use IDs in step commands where possible for deterministic automation.
- Use
--confirmfor destructiveascoperations inside steps. - Validate first, then dry-run, then real run.
- Keep hooks lightweight and side-effect aware.
{
"env": {
"APP_ID": "123456789",
"VERSION": "1.0.0"
},
"before_all": "asc auth status",
"after_all": "echo workflow_done",
"error": "echo workflow_failed",
"workflows": {
"beta": {
"description": "Distribute a build to a TestFlight group and notify",
"env": {
"GROUP_ID": ""
},
"steps": [
{
"name": "list_builds",
"run": "asc builds list --app $APP_ID --sort -uploadedDate --limit 5"
},
{
"name": "list_groups",
"run": "asc testflight beta-groups list --app $APP_ID --limit 20"
},
{
"name": "add_build_to_group",
"if": "BUILD_ID",
"run": "asc builds add-groups --build $BUILD_ID --group $GROUP_ID"
},
{
"name": "notify",
"if": "SLACK_WEBHOOK",
"run": "echo sent_release_notice"
}
]
},
"release": {
"description": "Submit a version for App Store review",
"steps": [
{
"workflow": "sync-metadata",
"with": {
"METADATA_DIR": "./metadata"
}
},
{
"name": "submit",
"run": "asc submit create --app $APP_ID --version $VERSION --build $BUILD_ID --confirm"
}
]
},
"sync-metadata": {
"private": true,
"description": "Private helper workflow (callable only via workflow steps)",
"steps": [
{
"name": "migrate_validate",
"run": "echo METADATA_DIR_is_$METADATA_DIR"
}
]
}
}
}
Useful invocations
# Validate and fail CI on invalid file
asc workflow validate | jq -e '.valid == true'
# Show discoverable workflows
asc workflow list --pretty
# Include private helpers
asc workflow list --all --pretty
# Preview a real run
asc workflow run --dry-run beta BUILD_ID:123 GROUP_ID:grp_abc
# Run with params and assert success
asc workflow run beta BUILD_ID:123 GROUP_ID:grp_abc | jq -e '.status == "ok"'
Source
git clone https://github.com/rudrankriyam/app-store-connect-cli-skills/blob/main/skills/asc-workflow/SKILL.mdView on GitHub Overview
asc-workflow enables repo-local, lane-like automations defined in .asc/workflow.json, with JSONC comment support. It supports running, validating, and listing workflows, with hooks, conditionals, and sub-workflows to ensure deterministic behavior in both local and CI environments. This helps migrate from lane tools and orchestrate asc + shell release flows.
How This Skill Works
Author a .asc/workflow.json file and use asc workflow validate to ensure structure. Run or preview with asc workflow run, optionally specifying runtime params like BUILD_ID:123. The system supports before_all, after_all, and error hooks, and can call sub-workflows inline, with up to 16 nesting.
When to Use It
- Migrating from lane tools to repo-local automations
- Wiring CI pipelines with deterministic asc + shell flows
- Orchestrating repeatable release workflows with hooks and sub-workflows
- Previewing workflow execution with dry-run before merge
- Sharing reusable workflows across projects via sub-workflows
Quick Start
- Step 1: Create .asc/workflow.json describing your first workflow
- Step 2: Validate structure and references with asc workflow validate
- Step 3: Run the workflow with runtime params, e.g. asc workflow run beta BUILD_ID:123 GROUP_ID:abc
Best Practices
- Keep the .asc/workflow.json file in the repo to ensure PR-reviewable automation
- Use asc workflow --help to discover flags and subcommands
- Run with --dry-run to preview without side effects
- Leverage before_all, after_all, and error hooks for robust failures
- Mark helper workflows as private to restrict direct runs
Example Use Cases
- Migrate a lane-based release flow to a repo-local asc workflow that runs build, test, sign, and publish steps
- Configure a CI pipeline that triggers a beta workflow with run-time params like BUILD_ID and GROUP_ID
- Create a shared sub-workflow for linting and formatting that is invoked by multiple workflows
- Preview complex flows locally with dry-run to ensure correct step coupling before CI
- Nest sub-workflows to a depth limit (16) to compose modular release pipelines