opensource-pipeline
affaan-m/everything-claude-code
Fork, sanitize, and package private projects for safe public release through a 3-stage pipeline.
What is opensource-pipeline?
Automates the process of preparing private projects for open-source publication by stripping secrets, verifying cleanliness, and generating release artifacts. Use this when you need to safely open-source a project while ensuring no credentials, PII, or internal references remain.
- Forks projects to staging while excluding build artifacts and version control
- Strips secrets, credentials, and internal references; generates .env.example
- Scans for secrets, PII, dangerous files, and internal references with pass/fail verdict
- Generates CLAUDE.md, setup.sh, README.md, LICENSE, CONTRIBUTING.md, and issue templates
- Supports independent sanitization and packaging of existing repositories
- Manages staging directory with progress reports for review before GitHub publication
How to install opensource-pipeline
npx skills add https://github.com/affaan-m/everything-claude-code --skill opensource-pipeline- GitHub CLI (gh) installed and authenticated
- Access to the project directory (absolute or relative path)
- User confirmation for license choice and GitHub org/repo details
How to use opensource-pipeline
- 1.Invoke the skill with '/opensource fork PROJECT' or say 'open source this project'
- 2.Provide project path, license (MIT/Apache-2.0/GPL-3.0/BSD-3-Clause), GitHub org, and description when prompted
- 3.Review the FORK_REPORT.md and SANITIZATION_REPORT.md in the staging directory
- 4.If sanitization fails, fix critical findings and re-run '/opensource verify PROJECT'
- 5.Once sanitization passes, review generated files (CLAUDE.md, setup.sh, README.md) in staging
- 6.Approve GitHub publication when ready; the skill will create and push the public repository
Use cases
- Prepare a private company project for open-source release on GitHub
- Verify that a forked repository has no embedded credentials before pushing
- Generate standardized documentation (CLAUDE.md, setup.sh) for an existing open-source project
- Audit a project for secrets and PII before sharing with external contributors
- Batch-process multiple projects through the sanitization pipeline
- Open-source maintainers preparing private projects for public release
- Security-conscious developers who need to verify no secrets leak
- Teams standardizing documentation and setup for open-source projects
- Project leads managing the transition from private to public repositories
opensource-pipeline FAQ
The pipeline halts with a FAIL verdict. You must fix the critical findings (remove/parameterize secrets) and re-run '/opensource verify PROJECT'. After 3 failed attempts, you must fix issues manually.
Yes. Use '/opensource verify PROJECT' to run only sanitization, or '/opensource package PROJECT' to generate documentation for an existing repository.
All projects are staged in $HOME/opensource-staging/{PROJECT_NAME}. Use '/opensource list' to see all staged projects and their progress.
No. The skill creates the staging directory and generates all artifacts, then asks for your approval before creating and pushing the GitHub repository.
.git, node_modules, __pycache__, .venv, and other build artifacts are excluded. Secrets and credentials are stripped and replaced with .env.example placeholders.
Full instructions (SKILL.md)
Source of truth, from affaan-m/everything-claude-code.
name: opensource-pipeline description: "Open-source pipeline: fork, sanitize, and package private projects for safe public release. Chains 3 agents (forker, sanitizer, packager). Triggers: '/opensource', 'open source this', 'make this public', 'prepare for open source'." metadata: origin: ECC
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:
- "Which project?" (if not found)
- "License? (MIT / Apache-2.0 / GPL-3.0 / BSD-3-Clause)"
- "GitHub org or username?" (default: detect via
gh api user -q .login) - "GitHub repo name?" (default: project name)
- "Description for README?" (analyze project for suggestion)
Step 2: Create Staging Directory
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, make executable)
3. README.md (or enhance existing)
4. LICENSE
5. CONTRIBUTING.md
6. .github/ISSUE_TEMPLATE/ (bug_report.md, feature_request.md)
"""
)
Step 6: Final Review
Present to user:
Open-Source Fork Ready: {PROJECT_NAME}
Location: {STAGING_PATH}
License: {license}
Files generated:
- CLAUDE.md
- setup.sh (executable)
- README.md
- LICENSE
- CONTRIBUTING.md
- .env.example ({N} variables)
Sanitization: {sanitization_verdict}
Next steps:
1. Review: cd {STAGING_PATH}
2. Create repo: gh repo create {github_org}/{github_repo} --public
3. Push: git remote add origin ... && git push -u origin main
Proceed with GitHub creation? (yes/no/review first)
Step 7: GitHub Publish (on user approval)
cd "{STAGING_PATH}"
gh repo create "{github_org}/{github_repo}" --public --source=. --push --description "{description}"
/opensource verify PROJECT
Run sanitizer independently. Resolve path: if PROJECT contains /, treat as a path. Otherwise check $HOME/opensource-staging/PROJECT, then $HOME/PROJECT, then current directory.
Agent(
subagent_type="opensource-sanitizer",
prompt="Verify sanitization of: {resolved_path}. Run all 6 scan categories and generate SANITIZATION_REPORT.md."
)
/opensource package PROJECT
Run packager independently. Ask for "License?" and "Description?", then:
Agent(
subagent_type="opensource-packager",
prompt="Package: {resolved_path} ..."
)
/opensource list
ls -d $HOME/opensource-staging/*/
Show each project with pipeline progress (FORK_REPORT.md, SANITIZATION_REPORT.md, CLAUDE.md presence).
/opensource status PROJECT
cat $HOME/opensource-staging/${PROJECT}/SANITIZATION_REPORT.md
cat $HOME/opensource-staging/${PROJECT}/FORK_REPORT.md
Staging Layout
$HOME/opensource-staging/
my-project/
FORK_REPORT.md # From forker agent
SANITIZATION_REPORT.md # From sanitizer agent
CLAUDE.md # From packager agent
setup.sh # From packager agent
README.md # From packager agent
.env.example # From forker agent
... # Sanitized project files
Anti-Patterns
- Never push to GitHub without user approval
- Never skip the sanitizer — it is the safety gate
- Never proceed after a sanitizer FAIL without fixing all critical findings
- Never leave
.env,*.pem, orcredentials.jsonin the staging directory
Best Practices
- Always run the full pipeline (fork → sanitize → package) for new releases
- The staging directory persists until explicitly cleaned up — use it for review
- Re-run the sanitizer after any manual fixes before publishing
- Parameterize secrets rather than deleting them — preserve project functionality
Related Skills
See security-review for secret detection patterns used by the sanitizer.
Related skills
More from affaan-m/everything-claude-code and the wider catalog.

security-review
Security checklist and patterns for authentication, input validation, secrets, and sensitive features.

golang-patterns
Idiomatic Go patterns, best practices, and conventions for building robust, efficient, and maintainable applications.

coding-standards
Baseline coding conventions for naming, readability, immutability, and quality across projects.

frontend-patterns
React and Next.js patterns for components, state management, performance, and modern frontend practices.

backend-patterns
REST/GraphQL API design, database optimization, and server-side patterns for Node.js, Express, and Next.js.

golang-testing
Go testing patterns: table-driven tests, subtests, benchmarks, fuzzing, and TDD methodology.