Tooling releases

Changes to the tooling commands go into .eddy/tooling/, where the scaffold's own tests and builds use them straight away. Generated projects get them later, through the drevops/eddy-tooling package.

Publishing the package

On every push to main, .github/workflows/eddy-publish-tooling.yml mirrors the .eddy/tooling/ directory to the main branch of drevops/eddy-tooling, which Packagist serves. The workflow pushes with the EDDY_TOOLING_DEPLOY_KEY secret, a deploy key with write access to that repository.

A branch whose name contains eddy-tooling, such as feature/123-eddy-tooling-fix, is published too, into the mirror branch of the same name. A generated project can then try the change before it merges by requiring that branch in composer.dev.json, for example "drevops/eddy-tooling": "dev-feature/123-eddy-tooling-fix". Other branches leave the mirror untouched, and a published branch stays on the mirror until you delete it there.

Releasing the package

Releases are created on the mirror by hand:

1. Create a release on drevops/eddy-tooling in the GitHub UI, with a new tag on main, for example 1.0.1. Generated projects require ~1.0.0, so they pick up a patch release on their next fresh install. Save it as a draft or publish it straight away.
2. From a clone of Eddy, ask Claude Code for the tooling release notes, or run /create-eddy-tooling-release-notes. The skill lists the commits that changed .eddy/tooling/ since the previous release, describes each one from its pull request, and writes the notes to .artifacts/release-notes-tooling-<version>.md.
3. Paste the notes into the release description, and publish the release if it's still a draft.
4. For a new minor version, also raise the constraint in composer.dev.json (for example to ~1.1.0). Generated projects receive it with their next scaffold update.