github-release
npx machina-cli add skill jezweb/claude-skills/github-release --openclawGitHub Release
Sanitize and release projects to GitHub. Two-phase workflow: safety checks first, then tag and publish.
Prerequisites
ghCLI installed and authenticated (gh auth status)gitleaksinstalled for secrets scanning (brew install gitleaksor 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 stateplanning/,screenshots/— working directoriestest-*.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 |
Source
git clone https://github.com/jezweb/claude-skills/blob/main/plugins/dev-tools/skills/github-release/SKILL.mdView on GitHub Overview
GitHub Release automates a two-phase workflow: sanitize the project for public release and then publish a GitHub Release using the gh CLI. It enforces secrets scanning, artifact cleanup, license/README validation, and proper tagging before release.
How This Skill Works
Phase 1 (Sanitize) runs pre-release checks: scan for secrets with gitleaks, remove personal artifacts, validate LICENSE and README, ensure a clean .gitignore, and optionally perform a build and dependency audit. Phase 2 (Release) determines the version, creates and pushes a tag, then publishes a GitHub Release with gh release create, supporting prerelease or draft options. The workflow halts on blockers until issues are resolved.
When to Use It
- Preparing a new public release of an open-source project on GitHub
- Scanning for secrets and removing personal artifacts before publishing
- Validating that LICENSE and README exist and are properly structured before release
- Tagging the release, pushing to origin, and publishing via gh release create
- Publishing a prerelease or draft release
Quick Start
- Step 1: Validate prerequisites (gh installed and authenticated, gitleaks installed, repo with remote)
- Step 2: Run Phase 1 sanitization: gitleaks detect --no-git --source=. --verbose; remove secrets and personal artifacts; commit changes as needed
- Step 3: Run Phase 2 release: determine version, create and push tag, then run gh release create v[version] --title "Release v[version]" --notes "[auto-generated from commits]" [--prerelease|--draft]
Best Practices
- Always run gitleaks detect before any public release and stop if secrets are found
- Ensure a LICENSE exists; for public repos use MIT or a suitable license, adjust for private repos
- Verify README contains basic sections (Install/Usage/License) and is up to date
- Check .gitignore includes node_modules, env files, and dist artifacts
- Commit sanitization changes with a clear message like chore: prepare for release
Example Use Cases
- Releasing v2.0.0 of an open-source JavaScript library with a public MIT license
- Releasing a Python package after validating LICENSE and README and removing test artifacts
- Preparing a release for a private repository with a proprietary license policy
- Publishing a feature branch as a prerelease to solicit early feedback
- Creating a draft release to coordinate notes and assets before public publication