asc workflow automation

VerifiedSafe

Define, validate, and run repo-local multi-step automations with `asc workflow` and `.asc/workflow.json`. Ideal for CI pipelines and release flows.

Sby Skills Guide Bot
DevOpsIntermediate
7/28/2026
Claude CodeCursorCodex
#ci-cd#automation#workflow-orchestration#cli#release

Recommended for

Automated summary

This skill covers defining, validating, and running repo-local multi-step automations with the `asc` CLI and a `.asc/workflow.json` file.

Strengths

  • Structured JSON on stdout with command output on stderr, enabling machine-safe CI checks like `jq -e '.valid == true'`
  • `asc workflow validate` catches unknown and cyclic references, and `--dry-run` previews execution without side effects
  • Explicit env precedence (definition < workflow < CLI params) plus `with` overrides for sub-workflow calls
  • Commented JSONC file that stays reviewable in PRs, with short string steps or named object steps

Limitations

  • Requires the `asc` CLI and a `.asc/workflow.json`; it is not a general-purpose task runner
  • Sub-workflow nesting is capped at 16 levels, and no parallel step execution is described
  • Secrets must not live in the file and have to be supplied through CI secrets or environment variables
When to use it

Use it when migrating from lane-style tools or wiring repeatable `asc` plus shell release flows into CI.

When not to use it

Avoid it for ad-hoc one-off commands or pipelines that need parallelism or dynamic dependency graphs.

Security analysis

Safe
Quality score84/100

This is a usage/documentation skill for the `asc workflow` CLI feature. It only describes running `asc` subcommands and bash steps that the user authors in their own repo. There is no curl|sh, no rm -rf, no base64 payloads, no credential exfiltration, and no instruction to disable safety mechanisms; in fact it warns against embedding secrets and recommends validate → dry-run → real run. The only residual risk is inherent to the documented feature (shell step execution), which is legitimate and reviewable via PRs.

Findings
  • •Documents a tool that executes arbitrary shell commands from a repo-local `.asc/workflow.json`; the skill itself contains no malicious commands, but anyone adopting it should review workflow files in PRs before running them (the skill does recommend version control and validate/dry-run first)
  • •Example uses `$SLACK_WEBHOOK` in a conditional; no tokens or secrets are requested, exfiltrated, or embedded — the text explicitly advises passing secrets via CI env instead of the workflow file
  • •Recommended `--confirm` for destructive `asc` operations is a safety-positive practice
How this analysis is made

Examples

Migrate a lane to a workflow
Convert our Fastlane beta lane into an `.asc/workflow.json` with a before_all hook and a sub-workflow for uploading, then validate it with `asc workflow validate`.
CI validation gate
Add a CI step that runs `asc workflow validate` and fails the build when the JSON reports `valid` is not true, using jq.
Dry-run then execute with params
Preview our release workflow with `asc workflow run --dry-run beta`, then execute it with BUILD_ID:123456789 and GROUP_ID:abcdef passed as runtime params.

name: asc-workflow description: Define, validate, and run repo-local multi-step automations with asc workflow and .asc/workflow.json. Use when migrating from lane tools, wiring CI pipelines, or orchestrating repeatable asc + shell release flows with hooks, conditionals, and sub-workflows.

asc workflow

Use this skill when you need lane-style automation inside the CLI using:

  • asc workflow run
  • asc workflow validate
  • asc 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 --help to confirm flags and subcommands:
    • asc workflow --help
    • asc workflow run --help
    • asc workflow validate --help
    • asc workflow list --help

End-to-end flow

  1. Author .asc/workflow.json
  2. Validate structure and references:
    • asc workflow validate
  3. Discover available workflows:
    • asc workflow list
    • asc workflow list --all (includes private helpers)
  4. Preview execution without side effects:
    • asc workflow run --dry-run beta
  5. 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 previews
  • asc workflow validate always 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 defaults
  • before_all: command run once before steps
  • after_all: command run once after successful steps
  • error: command run when any failure occurs
  • workflows: named workflow map

Workflow keys:

  • description
  • private (not directly runnable)
  • env
  • steps

Step forms:

  • String shorthand: "echo hello" -> run step
  • Object with:
    • run: shell command
    • workflow: call sub-workflow
    • name: label for reporting
    • if: conditional var name
    • with: 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.0
    • VERSION=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-run
  • asc workflow run beta --file .asc/workflow.json BUILD_ID:123

Execution semantics

  • before_all runs once before step execution
  • after_all runs only when steps succeed
  • error runs 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 env defaults
  • caller env (including CLI params) overrides
  • step with overrides all

Sub-workflows and private workflows

  • Use "workflow": "<name>" to call helper workflows.
  • Use "private": true for helper-only workflows.
  • Private workflows:
    • cannot be run directly
    • can be called by other workflows
    • are hidden from asc workflow list unless --all is used
  • Validation catches unknown workflow references and cyclic references.

Conditionals (if)

  • Add "if": "VAR_NAME" on a step.
  • Step runs only if VAR_NAME is truthy.
  • Truthy: 1, true, yes, y, on (case-insensitive).
  • Resolution order for if lookup:
    1. merged workflow env/params
    2. 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 -c when bash is available.
  • Fallback is sh -c when 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 --confirm for destructive asc operations 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 groups list --app $APP_ID --limit 20"
        },
        {
          "name": "add_build_to_group",
          "if": "BUILD_ID",
          "run": "asc builds add-groups --build-id $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"'

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/asc-workflow-automation-ms47vqis/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/asc-workflow-automation-ms47vqis' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/asc-workflow-automation-ms47vqis/download' --output '.skill-downloads/asc-workflow-automation-ms47vqis/SKILL.md.part' && mv '.skill-downloads/asc-workflow-automation-ms47vqis/SKILL.md.part' '.skill-downloads/asc-workflow-automation-ms47vqis/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.

Claude Code
test -f '.skill-downloads/asc-workflow-automation-ms47vqis/SKILL.md' && test -s '.skill-downloads/asc-workflow-automation-ms47vqis/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/asc-workflow' && cp -R '.skill-downloads/asc-workflow-automation-ms47vqis' '.claude/skills/asc-workflow'

Cursor
test -f '.skill-downloads/asc-workflow-automation-ms47vqis/SKILL.md' && test -s '.skill-downloads/asc-workflow-automation-ms47vqis/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/asc-workflow' && cp -R '.skill-downloads/asc-workflow-automation-ms47vqis' '.cursor/skills/asc-workflow'

Codex
test -f '.skill-downloads/asc-workflow-automation-ms47vqis/SKILL.md' && test -s '.skill-downloads/asc-workflow-automation-ms47vqis/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/asc-workflow' && cp -R '.skill-downloads/asc-workflow-automation-ms47vqis' '.agents/skills/asc-workflow'

OpenSkills

OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.

Official OpenSkills installation
openskills install './.skill-downloads/asc-workflow-automation-ms47vqis'

openskills read 'asc-workflow-automation-ms47vqis'

Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.

For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.

openskills sync

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/asc-workflow-automation-ms47vqis/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills