| name | update-workflow-versions |
| description | How to manually regenerate the compiled agentic workflow .lock.yml files when the gh-aw Version Check workflow reports version drift. All workflows track the newest github/gh-aw release or prerelease. |
Updating Agentic Workflow Versions
Use this skill when the gh-aw Version Check workflow
(.github/workflows/gh-aw-version-check.yml) opens a "Workflow version drift"
issue, or whenever you need to bump the versions the compiled workflow
.lock.yml files are pinned to.
There is no automation for the regeneration itself — it is a deliberate,
human-reviewed step. Pushing changes under .github/workflows/ requires a token
with the workflows permission, which the built-in GITHUB_TOKEN lacks, so a
maintainer (or an agent with suitably-permissioned credentials) performs the
recompile locally and opens a PR.
Background
Each agentic workflow source (.github/workflows/*.md) is compiled by the
gh-aw compiler into a committed *.lock.yml. The version baked into a lock is
whatever compiler produced it, and every workflow tracks the same gh-aw
version: the newest github/gh-aw release or prerelease, whichever was
published most recently. There are no per-workflow categories — a bump
recompiles all the locks together.
Only the gh-aw version needs bumping. The detector version is not pinned in
the locks: gh-aw emits the literal latest to
install_threat_detect_binary.sh, which resolves it at runtime from
GET /repos/github/gh-aw-threat-detection/releases/latest — the newest
non-prerelease release. Promoting a detector release is therefore enough to
put it into the smokes; no recompile is required.
