mcpbeat

Github Release

jezweb/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'.

2k tokens
context cost
the whole folder, loaded on every use
3
files
instructions only
0
copies elsewhere
how many repositories repackaged it
953
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/jezweb/claude-skills --skill github-release

The instruction itself

20 sections, as written by the author

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

| When | Read |

|------|------|

| Detailed safety checks | references/safety-checklist.md |

| Release mechanics | references/release-workflow.md |

How to use it

Copy the folder

Take jezweb/github-release from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.

Install what it needs

The instructions reference brew. Without those the skill loads but fails at the first command.