github-release
Prepare and publish GitHub releases. Sanitizes code for public release (secrets scan, personal artifacts, LICENSE/README validation), creates versio…
它会碰到什么
逐条看命中(4 条严重或高危)
- 严重
references/safety-checklist.md:19cred-paths| .gitignore has essentials | `grep "node_modules\|\.env" .gitignore` | Add missing patterns |
- 严重
SKILL.md:34cred-paths# Check for .env files
- 严重
SKILL.md:35cred-pathsfind . -name ".env*" -not -path "*/node_modules/*"
- 严重
SKILL.md:74cred-pathsgrep -E "node_modules|\.env|dist/|\.dev\.vars" .gitignore
这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。
技能内容
GitHub 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](references/safety-checklist.md) |
| Release mechanics | [references/release-workflow.md](references/release-workflow.md) |
想直接用这个技能?
本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。