Add Codex skills sync on release

[leenk7991]

What

Adds .github/workflows/sync-skills.yml: after a release ships, opens a PR against Corgea/skills updating the CLI skills to match what shipped.

Requires Documentation Update: - [ ] Yes - [x] No

Why release-triggered

Skills describe the CLI the reader already has installed. Diffing main would publish unreleased commands into a public skill, so the job diffs tag to tag.

Why not release.published

RELEASING.md documents two release paths, and that trigger only covers one. On the tag-first path the GitHub Release ends up created by action-gh-release using GITHUB_TOKEN, and GitHub does not start workflow runs for GITHUB_TOKEN events — so the sync would be silently skipped for a supported way of releasing.

This keys off the Native Binary Release workflow instead, which runs on the tag push under either path. npm-publish.yml already uses the same pattern. That payload carries no release object, so draft and prerelease filtering moved from the job condition into the script, and the tag comes from head_branch.

Notes

• Whether a ref is a published release is resolved via the API, not a v-prefix match: history mixes v1.9.1 and 1.8.8, and a prefix match would skip the latter. Branch pushes, which also run Native Binary Release, resolve to no release and exit cleanly.
• The previous release is resolved by publishedAt, not by excluding the current tag. Excluding the tag means a manual dispatch of an older tag selects a newer release as the base and produces a reversed diff, which reads as commands being removed.
• queue: max on the concurrency group. The default holds one pending run, so three releases in quick succession would drop the middle one.
• workflow_dispatch takes head_tag plus an optional base_tag. base_tag bypasses release lookup, so a plain tag with no Release can still be synced, and an explicitly named tag overrides draft filtering.
• Reuses an existing repo secret, so there is nothing new to provision here.
• No actions/checkout step: the action checks this repo out to ./source itself, and a root checkout would place skills/corgea/SKILL.md under the model's working directory as a decoy edit target.

Testing

workflow_run only fires from the default branch, so this cannot run until it is on main. The range-resolution logic was exercised against live release data: branch pushes skip, v1.9.2 resolves v1.9.1..v1.9.2, v1.9.1 correctly resolves v1.9.0 rather than the newer v1.9.2, 1.8.8 resolves v1.8.7, and a missing tag errors on dispatch but skips on workflow_run.

Merge order

Last, and strictly after Corgea/internal_actions#2 — the uses: reference resolves to main and 404s until that action lands.

Related: Corgea/internal_actions#2, Corgea/skills#2

[yhoztak]

LGTM

maybe good candidate for auto-approval? If so, please update this one also https://github.com/Corgea/doghouse/blob/main/.github/pr-automation-rules.yaml