agentleFS
jackchukajackchuka/skills/gh-oss-release/SKILL.md

gh-oss-release

Skill15 starsChanged 9 days agoMITView on GitHub

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"

  • Commits and pushes

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 9 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

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

    line 29
  2. Distinctive:

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

    line 31
  3. Very specific:

    If ALL commits are deps/ci/chore, recommend patch.

    line 51
  4. Distinctive:

    Use AskUserQuestion or wait for explicit user confirmation before proceeding.

    line 63
  5. Distinctive:

    After confirmation, create releases in parallel:

    line 67
  6. Very specific:

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

    line 75
  7. Distinctive:

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

    line 79
  8. Distinctive:

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

    line 81
  9. Very specific:

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

    line 87
  10. Distinctive:

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

    line 93
  11. Distinctive:

    Ask the user if they want to update the homebrew tap before proceeding.

    line 97
  12. Distinctive:

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

    line 99
  13. Distinctive:

    Never force: Always confirm with user before creating any releases.

    line 110

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 patternBump
deps:, deps-dev:, ci:, chore:, maintenance-onlypatch
feat:, new functionality, non-breaking additionsminor
BREAKING CHANGE, !: suffix, API removalsmajor

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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.