
Opensource Pipeline
Safely open-source a private repo via a chained fork → sanitize → package pipeline that strips secrets and ships CLAUDE.md, setup.sh, and README.
Overview
opensource-pipeline is an agent skill most often used in Ship (also Launch distribution, Build docs) that open-sources private projects through a 3-agent fork, sanitize, and package pipeline.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill opensource-pipelineWhat is this skill?
- 3-stage pipeline: Fork (strip secrets) → Sanitize (verify clean) → Package (docs and setup)
- Chains 3 agents: forker, sanitizer, packager for `/opensource fork` full run
- Subcommands: verify-only, package-only, list staged projects, per-project status reports
- Resolves project path from cwd, `$HOME/PROJECT`, or user prompt when name is ambiguous
- Triggers on `/opensource`, "open source this", "make this public", "prepare for open source"
- 3 pipeline stages: Fork, Sanitize, Package
- 3 chained agents: forker, sanitizer, packager
- 5 slash subcommands including list and status
Adoption & trust: 3.2k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want to make a repo public but fear `.env` leaks, internal endpoints, and a README that confuses new contributors.
Who is it for?
Indie devs open-sourcing CLI tools, agent skills, or SaaS adjunct repos that lived private with real config history.
Skip if: Repos already public with no secret history, or legal/compliance reviews (license, export control) without human sign-off.
When should I use this skill?
Triggers on '/opensource', 'open source this', 'make this public', 'prepare for open source', or `/opensource fork|verify|package` variants.
What do I get? / Deliverables
You get a staged, verified-clean tree plus CLAUDE.md, setup.sh, and README suitable for public clone—after explicit verify and status checks.
- Sanitized fork in staging path
- Verification reports via status commands
- CLAUDE.md, setup.sh, and README package
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Public release is a Ship concern; security sanitization is the gating step before anything hits GitHub, so security subphase is the canonical shelf. The forker and sanitizer agents exist specifically to verify the tree is secret-free—primary risk is credential leakage, not distribution copywriting alone.
Where it fits
Run `/opensource verify` on a CLI you mined from a client fork before any public remote exists.
Complete `/opensource fork` so Hacker News launch points at a repo with setup.sh that actually works.
Use `/opensource package` only to refresh CLAUDE.md and README after features stabilized pre-release.
Check `/opensource status PROJECT` reports as a gate in your pre-push checklist alongside code review.
How it compares
Multi-agent release hygiene skill—not the same as `git-filter-repo` alone; bundles verification and contributor onboarding artifacts.
Common Questions / FAQ
Who is opensource-pipeline for?
Solo builders using Claude Code who need a repeatable, agent-driven path from private repo to public GitHub with secret scanning and docs packaging.
When should I use opensource-pipeline?
In Ship before any public push; in Launch when preparing distribution assets; in Build docs when generating CLAUDE.md and setup scripts for newcomers.
Is opensource-pipeline safe to install?
Review the Security Audits panel on this page; the skill reads and rewrites repository files—run on copies and inspect sanitizer reports before publishing.
SKILL.md
READMESKILL.md - Opensource Pipeline
# Open-Source Pipeline Skill Safely open-source any project through a 3-stage pipeline: **Fork** (strip secrets) → **Sanitize** (verify clean) → **Package** (CLAUDE.md + setup.sh + README). ## When to Activate - User says "open source this project" or "make this public" - User wants to prepare a private repo for public release - User needs to strip secrets before pushing to GitHub - User invokes `/opensource fork`, `/opensource verify`, or `/opensource package` ## Commands | Command | Action | |---------|--------| | `/opensource fork PROJECT` | Full pipeline: fork + sanitize + package | | `/opensource verify PROJECT` | Run sanitizer on existing repo | | `/opensource package PROJECT` | Generate CLAUDE.md + setup.sh + README | | `/opensource list` | Show all staged projects | | `/opensource status PROJECT` | Show reports for a staged project | ## Protocol ### /opensource fork PROJECT **Full pipeline — the main workflow.** #### Step 1: Gather Parameters Resolve the project path. If PROJECT contains `/`, treat as a path (absolute or relative). Otherwise check: current working directory, `$HOME/PROJECT`, then ask the user. ``` SOURCE_PATH="<resolved absolute path>" STAGING_PATH="$HOME/opensource-staging/${PROJECT_NAME}" ``` Ask the user: 1. "Which project?" (if not found) 2. "License? (MIT / Apache-2.0 / GPL-3.0 / BSD-3-Clause)" 3. "GitHub org or username?" (default: detect via `gh api user -q .login`) 4. "GitHub repo name?" (default: project name) 5. "Description for README?" (analyze project for suggestion) #### Step 2: Create Staging Directory ```bash mkdir -p $HOME/opensource-staging/ ``` #### Step 3: Run Forker Agent Spawn the `opensource-forker` agent: ``` Agent( description="Fork {PROJECT} for open-source", subagent_type="opensource-forker", prompt=""" Fork project for open-source release. Source: {SOURCE_PATH} Target: {STAGING_PATH} License: {chosen_license} Follow the full forking protocol: 1. Copy files (exclude .git, node_modules, __pycache__, .venv) 2. Strip all secrets and credentials 3. Replace internal references with placeholders 4. Generate .env.example 5. Clean git history 6. Generate FORK_REPORT.md in {STAGING_PATH}/FORK_REPORT.md """ ) ``` Wait for completion. Read `{STAGING_PATH}/FORK_REPORT.md`. #### Step 4: Run Sanitizer Agent Spawn the `opensource-sanitizer` agent: ``` Agent( description="Verify {PROJECT} sanitization", subagent_type="opensource-sanitizer", prompt=""" Verify sanitization of open-source fork. Project: {STAGING_PATH} Source (for reference): {SOURCE_PATH} Run ALL scan categories: 1. Secrets scan (CRITICAL) 2. PII scan (CRITICAL) 3. Internal references scan (CRITICAL) 4. Dangerous files check (CRITICAL) 5. Configuration completeness (WARNING) 6. Git history audit Generate SANITIZATION_REPORT.md inside {STAGING_PATH}/ with PASS/FAIL verdict. """ ) ``` Wait for completion. Read `{STAGING_PATH}/SANITIZATION_REPORT.md`. **If FAIL:** Show findings to user. Ask: "Fix these and re-scan, or abort?" - If fix: Apply fixes, re-run sanitizer (maximum 3 retry attempts — after 3 FAILs, present all findings and ask user to fix manually) - If abort: Clean up staging directory **If PASS or PASS WITH WARNINGS:** Continue to Step 5. #### Step 5: Run Packager Agent Spawn the `opensource-packager` agent: ``` Agent( description="Package {PROJECT} for open-source", subagent_type="opensource-packager", prompt=""" Generate open-source packaging for project. Project: {STAGING_PATH} License: {chosen_license} Project name: {PROJECT_NAME} Description: {description} GitHub repo: {github_repo} Generate: 1. CLAUDE.md (commands, architecture, key files) 2. setup.sh (one-command bootstrap,