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
Use it when migrating from lane-style tools or wiring repeatable `asc` plus shell release flows into CI.
Avoid it for ad-hoc one-off commands or pipelines that need parallelism or dynamic dependency graphs.
Security analysis
SafeThis 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.
- •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
Examples
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`.Add a CI step that runs `asc workflow validate` and fails the build when the JSON reports `valid` is not true, using jq.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 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 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 filesThis 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.mdFrom 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 installationopenskills 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 syncManual 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.
Configure a Chat Channel with SecretRefs
DevOps
Set up chat channels using non-interactive commands, with secrets only as SecretRefs. Covers gather, mutate, repair, and prove steps for reliable delivery.
Investigate ClickHouse CI Failures
DevOps
Investigate a ClickHouse CI failure end-to-end from a PR or S3 report URL. Fetches failed tests, classifies flaky vs real regression, and checks for existing issues/fixes.
Ansible PR Review
DevOps
Reviews an Ansible PR following the project's standardized process, including changelog checks, test coverage validation, and feedback tracking.