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'.
72
90%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
Sanitize and release projects to GitHub. Two-phase workflow: safety checks first, then tag and publish.
gh CLI installed and authenticated (gh auth status)gitleaks installed for secrets scanning (brew install gitleaks or download from GitHub)Run these checks before any public release. Stop on blockers.
gitleaks detect --no-git --source=. --verboseIf 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/nullCheck for and remove session/planning files that shouldn't be published:
SESSION.md — session stateplanning/, screenshots/ — working directoriestest-*.ts, test-*.js — local test filesEither delete them or add to .gitignore.
ls LICENSE LICENSE.md LICENSE.txt 2>/dev/nullIf 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.
Check README exists and has basic sections:
grep -i "## Install\|## Usage\|## License" README.mdIf missing sections, add them before release.
Verify essential patterns are present:
grep -E "node_modules|\.env|dist/|\.dev\.vars" .gitignorenpm run build 2>&1npm audit --audit-level=highIf any changes were made during sanitization:
git add -A
git commit -m "chore: prepare for release"Check package.json for current version, or ask the user. Ensure version starts with v prefix.
git tag -l "v[version]"If it exists, ask user whether to delete and recreate or use a different version.
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
figit tag -a v[version] -m "Release v[version]"
git push origin $(git branch --show-current)
git push origin --tagsgh release create v[version] \
--title "Release v[version]" \
--notes "[auto-generated from commits]"For pre-releases add --prerelease. For drafts add --draft.
Show the user:
| When | Read |
|---|---|
| Detailed safety checks | references/safety-checklist.md |
| Release mechanics | references/release-workflow.md |
ee91a87
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.