agentsclimarketplace

Github release

Skill ulpi-io/plugin-marketplace/plugins/jezweb/skills/github-release

Prepare and publish GitHub releases. Sanitizes code for public release (secrets scan, personal artifacts, LICENSE/README validation), creates version tags, and publishes via gh CLI. Trigger with 'release', 'publish', 'open source', 'prepare for release', 'create release', or 'github release'.From its SKILL.md

Install
npx -y skills add ulpi-io/plugin-marketplace --skill github-release

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

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 1 stars1 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.

SKILL.md

3.7 KB, 906 tokens by cl100k_base, as published. Nobody here has run it

GitHub Release

Sanitize and release projects to GitHub. Two-phase workflow: safety checks first, then tag and publish.

Prerequisites

  • gh CLI installed and authenticated (gh auth status)
  • gitleaks installed for secrets scanning (brew install gitleaks or download from GitHub)
  • Git repository with a remote configured

Workflow

Phase 1: Sanitize

Run these checks before any public release. Stop on blockers.

1. Scan for Secrets (BLOCKER)

gitleaks detect --no-git --source=. --verbose

If secrets found: STOP. Remove secrets, move to environment variables. Check git history with git log -S "secret_value" — if in history, use BFG Repo-Cleaner.

If gitleaks not installed, do manual checks:

# Check for .env files
find . -name ".env*" -not -path "*/node_modules/*"

# Check config files for hardcoded secrets
grep -ri "api_key\|token\|secret\|password" wrangler.toml wrangler.jsonc .dev.vars 2>/dev/null

2. Remove Personal Artifacts

Check for and remove session/planning files that shouldn't be published:

  • SESSION.md — session state
  • planning/, screenshots/ — working directories
  • test-*.ts, test-*.js — local test files

Either delete them or add to .gitignore.

3. Validate LICENSE

ls LICENSE LICENSE.md LICENSE.txt 2>/dev/null

If missing: create one. Check the repo visibility (gh repo view --json visibility -q '.visibility'). Use MIT for public repos. For private repos, consider a proprietary license instead.

4. Validate README

Check README exists and has basic sections:

grep -i "## Install\|## Usage\|## License" README.md

If missing sections, add them before release.

5. Check .gitignore

Verify essential patterns are present:

grep -E "node_modules|\.env|dist/|\.dev\.vars" .gitignore

6. Build Test (non-blocking)

npm run build 2>&1

7. Dependency Audit (non-blocking)

npm audit --audit-level=high

8. Create Sanitization Commit

If any changes were made during sanitization:

git add -A
git commit -m "chore: prepare for release"

Phase 2: Release

1. Determine Version

Check package.json for current version, or ask the user. Ensure version starts with v prefix.

2. Check Tag Doesn't Exist

git tag -l "v[version]"

If it exists, ask user whether to delete and recreate or use a different version.

3. Show What's Being Released

LAST_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "")
if [ -z "$LAST_TAG" ]; then
  git log --oneline --no-merges HEAD | head -20
else
  git log --oneline --no-merges ${LAST_TAG}..HEAD
fi

4. Create Tag and Push

git tag -a v[version] -m "Release v[version]"
git push origin $(git branch --show-current)
git push origin --tags

5. Create GitHub Release

gh release create v[version] \
  --title "Release v[version]" \
  --notes "[auto-generated from commits]"

For pre-releases add --prerelease. For drafts add --draft.

6. Report

Show the user:

  • Release URL
  • Next steps (npm publish if applicable, announcements)

Reference Files

WhenRead
Detailed safety checksreferences/safety-checklist.md
Release mechanicsreferences/release-workflow.md

What ships with it: 2 files

3.5 KB alongside SKILL.md

Gives 2 of the 12 instructions most ship operate skills give in 906 tokens

Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07

  • Document a rollback plan before deploymentin 41 of 779, across 22 files
  • Update the changelogin 21 of 779, across 19 files
  • Run the test suitein 20 of 779
  • Create an annotated git taghere, and in 20 of 779
  • Clean up feature flags after full rolloutin 18 of 779, across 10 files
  • Verify deployment health after launchin 18 of 779, across 10 files
  • Test both feature flag statesin 17 of 779, across 9 files
  • Verify the working tree is cleanin 17 of 779
  • Make database migrations backward-compatiblein 16 of 779, across 8 files
  • Set up error monitoring before launchin 15 of 779, across 7 files
  • Monitor metrics at each rollout stagein 14 of 779, across 5 files
  • Create a GitHub releasehere, and in 14 of 779

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,144. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.