opensource-pipeline
Skill1 starsChanged 8 months agoMITView on GitHub
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'.
- Reads credentials
- Commits and pushes
7 other projects use a version of this, 4 of them edited.
Adopted by
Most recently taken up by
- Rojios/everything-claude-codeword for word, first seen Nov 8, 2026
- pankaj-mahaur/Agent-Daemonedited, first seen Nov 6, 2026
- renepf/claude-skillsedited, first seen Oct 25, 2026
- davidanthonyn/claude-skillsword for word, first seen Oct 20, 2026
- gongyijie85/dsh-eccedited, first seen Oct 13, 2026
- Fmarzochi/EGCedited, first seen Sep 16, 2026
Other versions7 projects use a version of this.
Word for word · 3
- Rojios/everything-claude-code★ 1100% same
- SamuelNDCE/claude-super-skill-library★ 1100% same
- davidanthonyn/claude-skills★ 0100% same
Edited · 4
- Fmarzochi/EGC★ 6196% same
- gongyijie85/dsh-ecc★ 898% same
- pankaj-mahaur/Agent-Daemon★ 099% same
- renepf/claude-skills★ 099% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository224 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .codex/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- examples/CLAUDE.mdCLAUDE.md
- .cursor/rules/common-agents.mdCursor rule
- .cursor/rules/common-coding-style.mdCursor rule
- .cursor/rules/common-development-workflow.mdCursor rule
- .cursor/rules/common-git-workflow.mdCursor rule
- .cursor/rules/common-hooks.mdCursor rule
- .cursor/rules/common-patterns.mdCursor rule
- .cursor/rules/common-performance.mdCursor rule
- .cursor/rules/common-security.mdCursor rule
- .cursor/rules/common-testing.mdCursor rule
- .cursor/rules/golang-coding-style.mdCursor rule
- .cursor/rules/golang-hooks.mdCursor rule
- .cursor/rules/golang-patterns.mdCursor rule
- .cursor/rules/golang-security.mdCursor rule
- .cursor/rules/golang-testing.mdCursor rule
- .cursor/rules/kotlin-coding-style.mdCursor rule
- .cursor/rules/kotlin-hooks.mdCursor rule
- .cursor/rules/kotlin-patterns.mdCursor rule
- .cursor/rules/kotlin-security.mdCursor rule
- .cursor/rules/kotlin-testing.mdCursor rule
- .cursor/rules/php-coding-style.mdCursor rule
- .cursor/rules/php-hooks.mdCursor rule
- .cursor/rules/php-patterns.mdCursor rule
- .cursor/rules/php-security.mdCursor rule
- .cursor/rules/php-testing.mdCursor rule
- .cursor/rules/python-coding-style.mdCursor rule
- .cursor/rules/python-hooks.mdCursor rule
- .cursor/rules/python-patterns.mdCursor rule
- .cursor/rules/python-security.mdCursor rule
- .cursor/rules/python-testing.mdCursor rule
- .cursor/rules/swift-coding-style.mdCursor rule
- .cursor/rules/swift-hooks.mdCursor rule
- .cursor/rules/swift-patterns.mdCursor rule
- .cursor/rules/swift-security.mdCursor rule
- .cursor/rules/swift-testing.mdCursor rule
- .cursor/rules/typescript-coding-style.mdCursor rule
- .cursor/rules/typescript-hooks.mdCursor rule
- .cursor/rules/typescript-patterns.mdCursor rule
- .cursor/rules/typescript-security.mdCursor rule
- .cursor/rules/typescript-testing.mdCursor rule
- api-designSkill
- article-writingSkill
- backend-patternsSkill
- bun-runtimeSkill
- claude-apiSkill
- coding-standardsSkill
- content-engineSkill
- crosspostSkill
- deep-researchSkill
- dmux-workflowsSkill
- documentation-lookupSkill
- e2e-testingSkill
- eval-harnessSkill
- everything-claude-code-conventionsSkill
- exa-searchSkill
- fal-ai-mediaSkill
- frontend-patternsSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
7 rules. 4 are common, 0 are distinctive, and 3 are very specific to this project.
4
Common
Most of the 4 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 82
Wait for completion. Read {STAGING_PATH}/FORK_REPORT.md.
- Common: line 114
If fix: Apply fixes, re-run sanitizer (maximum 3 retry attempts — after 3 FAILs, present all findings and ask user to fix manually)
- Common: line 115
If abort: Clean up staging directory
- Very specific: line 184
Run sanitizer independently.
- Common: line 197
Run packager independently.
- Very specific: line 244
Never: leave .env, *.pem, or credentials.json in the staging directory
- Common: line 248
Always run the full pipeline (fork → sanitize → package) for new releases
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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.mdStaging 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 filesAnti-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.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

