Automatisation de workflows asc

VérifiéSûr

Définissez, validez et exécutez des automatisations multi-étapes locales au dépôt avec `asc workflow` et `.asc/workflow.json`. Idéal pour les pipelines CI et les flux de release.

Spar Skills Guide Bot
DevOpsIntermédiaire
28/07/2026
Claude CodeCursorCodex
#ci-cd#automation#workflow-orchestration#cli#release

Recommandé pour

Synthèse automatique

Cette compétence explique comment définir, valider et exécuter des automatisations multi-étapes locales au dépôt avec la CLI `asc` et le fichier `.asc/workflow.json`.

Points forts

  • Sortie JSON structurée sur stdout et sortie des commandes sur stderr, ce qui permet des vérifications CI fiables via `jq -e '.valid == true'`
  • `asc workflow validate` détecte les références inconnues et les cycles, et `--dry-run` permet de prévisualiser sans effet de bord
  • Règles de précédence d'environnement explicites (définition < workflow < paramètres CLI) avec surcharge `with` pour les sous-workflows
  • Fichier JSONC commenté, lisible et relu en PR, avec formulaires d'étape courts ou objets nommés

Limites

  • Nécessite la CLI `asc` installée et un fichier `.asc/workflow.json` : ce n'est pas un exécuteur de tâches généraliste
  • Profondeur d'imbrication des sous-workflows plafonnée à 16, et aucune exécution parallèle des étapes n'est décrite
  • Les secrets ne doivent pas figurer dans le fichier et doivent être injectés via l'environnement ou les secrets CI
Quand l'utiliser

À utiliser pour migrer d'outils de type lane ou pour câbler des flux de release reproductibles mêlant `asc` et commandes shell dans un pipeline CI.

Quand l'éviter

À éviter pour des commandes ponctuelles ou des pipelines nécessitant du parallélisme ou des graphes de dépendances dynamiques.

Analyse de sécurité

Sûr
Score qualité84/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.

Points d'attention
  • •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
Comment cette analyse est faite

Exemples

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"'

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/asc-workflow-automation-ms47vqis/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

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. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

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 doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/asc-workflow-automation-ms47vqis'

openskills read 'asc-workflow-automation-ms47vqis'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/asc-workflow-automation-ms47vqis/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires