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
À 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.
À é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ûrThis 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
Exemples
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"'
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 annexesCe 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.mdDepuis 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’OpenSkillsopenskills 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 syncMode 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.
Configurer un canal de discussion avec SecretRefs
DevOps
Configurez des canaux de discussion avec des commandes non interactives, les secrets étant uniquement des SecretRefs. Couvre les étapes de collecte, modification, réparation et vérification.
Enquêter sur les échecs CI de ClickHouse
DevOps
Investigue un échec CI de ClickHouse de bout en bout à partir d'une URL de PR ou de rapport S3. Récupère les tests échoués, classe flaky vs vraie régression, et cherche des issues/fixes existants.
Revue de PR Ansible
DevOps
Examine une PR Ansible selon le processus standardisé du projet, incluant la validation des changelogs, la couverture de tests et le suivi des commentaires.