CEXT-6367: implement skills release process and promotion workflow

[obarcelonap]

Description

Implements the skills release process defined in the spec PR. Plugin packages gain package.json files so changesets can version them, the publish-public.yml workflow gains a promotion step that opens a PR in adobe/skills on release, and a shared sync script keeps tile.json and .claude-plugin/plugin.json in sync with the authoritative package.json version.

Related Issue

https://jira.corp.adobe.com/browse/CEXT-6367

Motivation and Context

Commerce plugins in adobe/aio-commerce-sdk have no automated path to adobe/skills. Without this, production consumers cannot install them through the stable channel and promotion requires manual file copying with no traceability.

How Has This Been Tested?

Unit tests cover the full promotion script: plugin version detection, artifact preparation, the full git path (checkout → copy → commit → push → PR create/update), and idempotent reruns. A version-consistency regression test asserts that package.json, tile.json, and .claude-plugin/plugin.json all carry the same version for every plugin.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have read the DEVELOPMENT document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[changeset-bot]

🦋 Changeset detected

Latest commit: d5e5f4f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@adobe/aio-commerce-plugin-app-management	Minor
@adobe/aio-commerce-plugin-app-migration	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[iivvaannxx]

I have a feeling many logic in the promote-skills script can probably be removed and repalced by one of the many packages that changesets offers to work with their files. See their packages (many are published to npm and you can pull them in as deps in the scripts workspace)

[iivvaannxx]

Also, do we want to handle promotion/publish to the Tessl registry?

[obarcelonap]

Also, do we want to handle promotion/publish to the Tessl registry?

Only one set of skills in adobe/skills is published in Tessl registry. From my perspective, the tool is under evaluation, I'd keep it to asses if is useful for us for testing without wasting much effort.
In any case, you can also install directly from a gh repo using tessl install github:owner/repo

[obarcelonap]

I have a feeling many logic in the promote-skills script can probably be removed and repalced by one of the many packages that changesets offers to work with their files. See their packages (many are published to npm and you can pull them in as deps in the scripts workspace)

Looked into this TLDR; none of the packages under changesets actually cover what this script needs.

The core issue: plugins/commerce/app-management and plugins/commerce/app-migration are both "private": true, and changesets' publish path explicitly filters private packages out before publishing (publicPackages = packages.filter(pkg => !pkg.packageJson.private) in @changesets/cli). So there's no changesets output — job output or library — that reports version changes for these plugins; the detection has to happen independently, which is what getChangedPluginPackagePaths/packageVersionChanged does.

I did consider @changesets/git's getChangedPackagesSinceRef as a drop-in for the git-diff part, but it shells out to real git directly rather than going through the injected exec we use everywhere else in scripts/source/ci/release/*, which would mean rewriting the tests to use real git repos instead of the current mocked-exec fixtures. snapshot.ts already made the same call elsewhere in this directory — shelling out to changesets' documented CLI/action outputs rather than depending on its internal helper packages (which the @changesets/git README itself says aren't meant to be a stable public surface).

[iivvaannxx]

Approving. Regarding the Changesets utility packages, I did run Opus to check and it did actually find one potential replacement. Find below what it said.

Review: new scripts/ code vs. Changesets built-ins

I read the three new source files against the upstream Changesets v3 clone in changesets/. One clear reinvention, a couple of weak/partial overlaps, and one thing that is not reinventable. Details:

1. Solid replacement — readChangelogEntries → getChangelogEntry

promote-skills.ts:295-324 hand-rolls a changelog parser: indexOf("## " + version), slice to the next ## , keep lines starting with - .

Changesets already ships this as getChangelogEntry(changelog, version) from @changesets/release-utils (changesets/packages/release-utils/src/utils.ts:33), and it's exported from the package root. It's strictly more robust than the local version — it skips fenced code blocks so it won't match ## headings inside example snippets, and it matches the closing heading by depth instead of any ## .

• Drop: readChangelogEntries (30 lines).
• Replace with: import { getChangelogEntry } from "@changesets/release-utils" (add it as a devDependency — it's not in the lockfile yet, only @changesets/git is present transitively).
• Caveat (behavior change): the local fn returns only - bullet lines as string[]; getChangelogEntry returns { content, highestLevel } where content is the full markdown block (including ### Minor Changes sub-headings). Your buildPromotionPullRequestBody (promote-skills.ts:227) would need to embed content instead of joining a bullet array. The resulting PR body is arguably better (keeps the bump-level subheadings), but it's a visible format change — worth a glance at the promote-skills test snapshots.

[obarcelonap]

Approving. Regarding the Changesets utility packages, I did run Opus to check and it did actually find one potential replacement. Find below what it said.

@iivvaannxx looked into this, the mentioned function it is not stable yet and is part of a major changesets upgrade (3.0.0). Therefore, I just added a note in our function so when the new changesets version is released we revaluate if we can change the impl to rely on the changesets' counterpart.