Open Source Release

Convert a private repository to public open-source. Use when making a repo public, sanitizing personal info from code/docs/git history, or preparing a projec...

Security Scan

Instruction-only skill that gives coherent, proportionate steps for sanitizing and making a repo public; nothing requested or instructed is inconsistent with that purpose.

Purpose & Capability

The name/description match the instructions: scanning code/docs, cleaning history, creating a clean orphan branch, and switching repo visibility are all expected for preparing an open-source release. References to BFG/git-filter-repo and gh are reasonable for the stated tasks.

Instruction Scope

The SKILL.md stays focused on repo sanitization and making a repo public, but contains destructive git operations (force-push, deleting branches) and platform-specific PowerShell examples. It assumes presence of git and optionally the GitHub CLI or repo-cleaning tools; it does not provide explicit backup/mirroring steps or cross-platform command variants — users should test on a clone/mirror and confirm tools before running destructive commands.

Install Mechanism

No install spec or code files — instruction-only. This minimizes surface area; the doc does recommend external tools (BFG, git-filter-repo, gh) but does not attempt to download or execute third-party code automatically.

Credentials

No environment variables, credentials, or config paths are requested. The instructions correctly warn about tokens-in-URLs and check remotes; they do not ask for unrelated secrets or elevated access.

Persistence & Privilege

Skill is user-invocable and not always-enabled. It doesn't request persistent privileges or modify other skills or system-wide settings.

Assessment

This skill is a focused checklist for making a repo public and cleaning history, but it includes destructive git commands. Before using: 1) Make a full mirror backup (git clone --mirror) or work on a copy; 2) Test history-rewriting commands on a clone and confirm tool availability (git, gh, BFG/git-filter-repo); 3) Check CI, package registries, webhooks, and external services for stored secrets or tokens (not just code files); 4) Coordinate with collaborators — force-pushes and branch deletions rewrite history and can disrupt others; 5) If you are on Linux/macOS, translate PowerShell examples or run them in a suitable environment. If you want, I can produce a non-destructive dry-run script and a checklist tailored to your repository (list remotes, create mirror, run safe scans) before you perform any irreversible actions.

Safely convert a private repo to public by sanitizing personal data and cleaning history.

Pre-flight Checklist

1. Scan source code — search for:

   • Absolute paths: C:\Users\, home directory references
   • Usernames: OS-specific account names
   • Internal hostnames / port names
   • API keys / tokens: .env, hardcoded secrets
   • Email / phone numbers in commit author config

2. Check cached artifacts — ensure .gitignore covers:

   • Binary caches (.pkl, .db, checksums.json)
   • __pycache__/, node_modules/, .env, *.egg-info/
   • Project-specific cache directories

Sanitization Steps

Step 1: Code Scan

# Find hardcoded paths and usernames
Get-ChildItem -Recurse -Include "*.py","*.ps1","*.js","*.ts" |
  Select-String -Pattern "C:\\Users|/home/|your-username" -SimpleMatch |
  Where-Object { $_.Path -notmatch "__pycache__|node_modules|\.git" }

Fix: replace with environment variables (os.environ.get / process.env) and add a .env.example.

Step 2: Docs Scan

Get-ChildItem -Recurse -Include "*.md","*.txt","*.yaml","*.yml" |
  Select-String -Pattern "C:\\Users|/home/|your-username" -SimpleMatch |
  Where-Object { $_.Path -notmatch "node_modules|\.git" }

Replace personal paths with generic placeholders ($VAULT_PATH, ~/vault, etc.).

Step 3: Git History Analysis

git log --all -p | Select-String -Pattern "SENSITIVE_TERM" | Select-Object -First 50
git log --all --diff-filter=A -- "cache/*"

Choose a strategy:

• < 50 commits + cache only in history → Option B (clean push)
• Large history with sensitive data → Option A (BFG Repo Cleaner / git filter-repo)
• History is fine, just old paths → Option C (leave as-is)

Step 4: Clean Push (Option B)

git checkout --orphan clean-main
git add -A
git commit -m "feat: initial public release"
git remote set-url origin https://github.com/{owner}/{repo}.git  # verify no token in URL!
git branch -M main
git push origin main --force
git push origin --delete {old-branch}

Step 5: Make Public

gh repo edit {owner}/{repo} --visibility public --accept-visibility-change-consequences --description "Short description"

Step 6: Verify

# Final scan for sensitive strings
Get-ChildItem -Recurse -Include "*.py","*.md","*.yaml","*.js","*.ts" |
  Select-String -Pattern "SENSITIVE_TERM" -SimpleMatch |
  Where-Object { $_.Path -notmatch "__pycache__|node_modules|\.git" }

# Confirm remote URL has no token
git remote -v

# Confirm visibility
gh repo view {owner}/{repo} --json visibility

Step 7: Post-Release Housekeeping (Optional)

• Add issue tracking to HEARTBEAT.md
• Update memory/{project}.md with release notes

Gotchas

• Never include tokens in git remote URLs — always verify before push
• Binary caches not covered by .gitignore may already be in history — check carefully
• Encoding issues on Windows — use UTF-8 explicitly in PowerShell/Python
• Your GitHub username is already public — that is fine to leave as-is
• Never commit .env files — add to .gitignore if not already there