Use when preparing a codebase for first-time public/open-source release. Full lifecycle from audit through documentation, hardening, and final review.
Guides developers through a structured nine-phase process to prepare private codebases for public open-source release.
npx claudepluginhub 2389-research/claude-pluginsThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Announce: "I'm using git-repo-prep:prepare to walk through open-source preparation."
Create a TodoWrite checklist for all 9 phases:
Every phase follows this loop:
docs: add CONTRIBUTING.md)Detect the ecosystem and scan project structure.
Detect ecosystem by looking for:
| File | Ecosystem |
|---|---|
package.json | Node.js |
pyproject.toml / setup.py / setup.cfg | Python |
Cargo.toml | Rust |
go.mod | Go |
*.csproj / *.sln | .NET |
Gemfile | Ruby |
pom.xml / build.gradle | Java/Kotlin |
Report what exists (present/missing):
Present findings to user before proceeding.
Two separate scans. Both matter for making a repo public.
.env files or config files containing real credentials.pem, .key files)author, pyproject.toml authors, Cargo.toml authors)DEFAULT_AUTHOR = "jsmith")git filter-repo or BFG Repo Cleaner for history rewriting if needed.env.exampleDo not add dotenv packages, validation, or startup checks unless the user asks.
Ask the user which license they want. Present common options:
Then:
LICENSE filepackage.json → "license": "MIT"pyproject.toml → license fieldCargo.toml → license fieldCheck for these sections (present or missing):
Don't write the full docs without asking. Propose the structure, ask user for approval, then help draft.
Propose including:
Propose a vulnerability reporting process. At minimum: an email or instructions for responsible disclosure.
If the project already uses AI tools or has complex setup, suggest a CLAUDE.md with build/test/lint commands and architectural notes. Ask first — don't create by default.
Check current .gitignore against ecosystem best practices:
| Ecosystem | Must ignore |
|---|---|
| Node.js | node_modules/, .env, dist/, coverage/ |
| Python | __pycache__/, *.pyc, .env, *.egg-info/, dist/, .venv/ |
| Rust | target/, .env |
| Go | vendor/ (if not vendoring), .env |
| General | .env, .env.*, *.log, .DS_Store, *.pem, *.key |
Always check:
.env and .env.* patterns excluded.idea/, .vscode/, .DS_Store, Thumbs.db)If sensitive files are already tracked:
git rm --cached"Ask the user what level of hardening they want before proposing anything. Options:
Ask which provider (GitHub Actions is most common). Propose a workflow that:
Suggest Dependabot (GitHub) or Renovate. Brief config.
Suggest only if project doesn't already have them. Keep it simple — lint + format.
Suggest only if tests already exist. Don't add test frameworks — that's beyond open-source prep scope.
Ecosystem-specific metadata that helps with discoverability and distribution:
| Ecosystem | Check for |
|---|---|
| Node.js | repository URL, engines field, files field (or .npmignore), keywords, description |
| Python | [project.urls], classifiers, requires-python, keywords, description |
| Rust | repository, keywords, categories, rust-version, description |
| Go | module path matches repo URL, godoc comment on package |
Flag anything missing. Propose additions. Don't prescribe values — ask the user for descriptions, keywords, etc.
Building trust with contributors by being upfront about the project's state.
These are optional. Ask before creating.
Invoke git-repo-prep:review as a final validation pass.
This catches anything missed during the prepare phases and gives the user a clean summary of the repo's openness state.
Use the Skill tool: skill: "git-repo-prep:review"
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.