| name | release |
| description | GitHub release creation for cc-foundry plugins: per-plugin tags, release notes as the changelog, and post-push publishing. Invoke whenever task involves pushing commits to master, releasing or publishing a plugin version, bumping plugin versions, or writing release notes. |
Plugin Releases
Every plugin version bump that lands on master ships with a GitHub release. The release notes are the plugin's changelog
— there are no CHANGELOG.md files (see docs/adr/0005). A pushed version bump without a release is an incomplete ship.
When to Release
- After every push to master, check the pushed range for plugin version bumps; create one release per plugin whose
version changed.
- The user's authorization to push covers release creation — do not ask a second time.
- Repo-level changes that bump no plugin version (ADRs, root docs,
.dev/ tooling, this skill) get no release.
- Several plugins bumped in one push → one release each.
Identify What to Release
- Find bumped plugins in the pushed range:
git diff <old-origin-head>..origin/master -- '*/plugin.json'. When the old
head is unknown, compare each plugin's plugin.json version against its latest <plugin>-v* tag from
gh release list.
- For each bumped plugin, resolve:
- the pushed commit that changed its
plugin.json version — the release target
- the previous release tag
<plugin>-v*, if any — the notes range and compare-link anchor
- Collect source material:
git log <prev-tag>..<target> -- plugins/<name>/ plus the diff of that range. For a first
release, use the commits of the bump itself.
Tag and Title Scheme
- Tag —
<plugin>-v<X.Y.Z>, e.g.
Invoke `the-writer:humanize` before drafting. All release prose — the lead sentence and every bullet — is written in
its writing mode and passes its self-audit before `gh release create`. If the skill is unavailable, ask the user to
install the `the-writer` plugin before proceeding.
