Gh oss release

A lazy engineer's toolkit — why do it yourself when a Skill can?

Install

npx -y skills add jackchuka/skills --skill gh-oss-release

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

15 stars15 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Create GitHub releases across multiple OSS repositories. Checks release status via `gh oss-watch releases`, analyzes unreleased commits to recommend semver bumps, confirms with user, then creates releases. Triggers: "create releases", "release my packages", "check for releases", "oss releases", "gh oss-watch releases", "/oss-release", "release status", "bump versions"

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.7 KB, as published. Nobody here has run it

OSS Release

Batch release workflow for multiple OSS repositories using gh oss-watch releases.

Workflow

Step 1: Check Release Status

Run gh oss-watch releases to identify repos with unreleased commits.

If all repos are up to date, report that and stop.

Step 2: Analyze Unreleased Commits

For each repo needing a release, fetch commit messages since the last tag in parallel:

gh api repos/<owner>/<repo>/compare/<last-tag>...HEAD --jq '[.commits[] | .commit.message | split("\n")[0]] | .[]'

Step 3: Recommend Semver Bump

Classify each commit's first line and recommend the highest applicable bump:

Commit pattern	Bump
`deps:`, `deps-dev:`, `ci:`, `chore:`, maintenance-only	patch
`feat:`, new functionality, non-breaking additions	minor
`BREAKING CHANGE`, `!:` suffix, API removals	major

If ALL commits are deps/ci/chore, recommend patch. If any commit adds a feature, recommend minor. If any commit has breaking changes, recommend major.

Step 4: Present Recommendations

Present a table for user confirmation:

| Repo | Current | Recommended | Commits | Rationale |
|------|---------|-------------|---------|-----------|
| repo-name | v1.2.3 | v1.2.4 | 5 | All dependency bumps |

Use AskUserQuestion or wait for explicit user confirmation before proceeding.

Step 5: Create Releases

After confirmation, create releases in parallel:

gh release create <new-tag> --repo <owner>/<repo> --generate-notes

Step 6: Verify

Run gh oss-watch releases again to confirm all repos show "up to date".

Step 7: Wait for Release Builds

Before updating the homebrew tap, all tag-triggered CI builds must complete successfully so release artifacts exist for formula updates.

Check the most recent run for each released repo in parallel:

gh run list --repo <owner>/<repo> --limit 3

If any run is still in_progress or queued, wait for it to complete:

gh run watch <run-id> --repo <owner>/<repo> --exit-status

If any build fails, stop and surface the failure to the user — do not proceed to the tap update.

Step 8: Update Homebrew Tap

Ask the user if they want to update the homebrew tap before proceeding. If they decline, stop here.

After confirmation, trigger the scheduled workflow which handles formula updates automatically:

gh workflow run scheduled.yml --repo jackchuka/homebrew-tap

Important Notes

Tag-triggered CI: Most repos have CI that triggers on tag push (goreleaser, gh-extension-precompile, npm publish). The gh release create command creates the tag which triggers the CI build.
npm packages with tag-triggered workflows: These repos derive version from the git tag during CI — no package.json bump needed.
Parallel execution: Fetch commits and create releases in parallel across repos for speed.
Never force: Always confirm with user before creating any releases.