Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
affaan-m avatar

Opensource Pipeline

  • 1.4k installs
  • 238k repo stars
  • Updated August 5, 2026
  • affaan-m/ecc

This is a copy of opensource-pipeline by affaan-m - installs and ranking accrue to the original listing.

opensource-pipeline is a Claude Code skill that chains three agents—Forker, Sanitizer, and Packager—to strip secrets, verify a clean tree, and generate open-source release files before developers publish a private reposi

About

opensource-pipeline is a three-stage Claude Code skill from affaan-m/ecc that prepares private repositories for safe public release on GitHub. The pipeline forks a project and removes secrets, verifies the sanitized state, then packages required OSS files including CLAUDE.md, setup.sh, and README. Developers invoke it with `/opensource fork`, `/opensource verify`, or `/opensource package`, or by saying phrases like "open source this" or "make this public." The skill is built for teams that need a repeatable, agent-driven checklist instead of manual grep-and-hope secret audits before the first public push.

  • 3-stage agent pipeline: Fork → Sanitize → Package
  • Automatically removes secrets and sensitive data before public release
  • Generates CLAUDE.md, setup.sh, and professional README
  • Supports targeted commands: /opensource fork, verify, package, list, status
  • Chains forker, sanitizer, and packager agents for end-to-end workflow

Opensource Pipeline by the numbers

  • 1,350 all-time installs (skills.sh)
  • +83 installs in the week ending Aug 4, 2026 (Skillselion tracking)
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/affaan-m/ecc --skill opensource-pipeline

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1.4k
repo stars238k
Last updatedAugust 5, 2026
Repositoryaffaan-m/ecc

How do you safely open-source a private repo?

Safely strip secrets, sanitize code, and generate required open-source files before releasing a private project publicly.

Who is it for?

Developers preparing a private GitHub repository for its first public release who need automated secret stripping and OSS file scaffolding.

Skip if: Teams already running a mature open-source program with established release automation and no secret-sanitization risk.

When should I use this skill?

A developer says "open source this", "make this public", "prepare for open source", or runs `/opensource fork`, `/opensource verify`, or `/opensource package`.

What you get

Sanitized repository fork, verified clean working tree, and generated CLAUDE.md, setup.sh, and README release bundle.

  • Sanitized repo fork
  • CLAUDE.md
  • setup.sh

By the numbers

  • Chains 3 pipeline agents: Forker, Sanitizer, and Packager
  • Generates 3 OSS artifacts: CLAUDE.md, setup.sh, and README

Files

SKILL.mdMarkdownGitHub ↗

オープンソースパイプラインスキル

3段階のパイプラインを通じて任意のプロジェクトを安全にオープンソース化する: フォーク(シークレット除去)→ サニタイズ(クリーンな状態を確認)→ パッケージ(CLAUDE.md + setup.sh + README)。

アクティベートするタイミング

  • ユーザーが「このプロジェクトをオープンソース化する」または「これを公開する」と言うとき
  • ユーザーがプライベートリポジトリを公開リリースのために準備したいとき
  • ユーザーがGitHubにプッシュする前にシークレットを除去する必要があるとき
  • ユーザーが/opensource fork/opensource verify、または/opensource packageを呼び出すとき

コマンド

コマンドアクション
/opensource fork PROJECT完全なパイプライン: フォーク + サニタイズ + パッケージ
/opensource verify PROJECT既存のリポジトリにサニタイザーを実行
/opensource package PROJECTCLAUDE.md + setup.sh + READMEを生成
/opensource listステージングされたすべてのプロジェクトを表示
/opensource status PROJECTステージングされたプロジェクトのレポートを表示

プロトコル

/opensource fork PROJECT

完全なパイプライン — メインワークフロー。

ステップ1: パラメータを収集する

プロジェクトパスを解決する。PROJECTに/が含まれる場合、パス(絶対または相対)として扱う。それ以外の場合: 現在の作業ディレクトリ、$HOME/PROJECTをチェックし、見つからない場合はユーザーに尋ねる。

SOURCE_PATH="<解決された絶対パス>"
STAGING_PATH="$HOME/opensource-staging/${PROJECT_NAME}"

ユーザーに尋ねる: 1. 「どのプロジェクト?」(見つからない場合) 2. 「ライセンス?(MIT / Apache-2.0 / GPL-3.0 / BSD-3-Clause)」 3. 「GitHubのorgまたはユーザー名?」(デフォルト: gh api user -q .loginで検出) 4. 「GitHubリポジトリ名?」(デフォルト: プロジェクト名) 5. 「READMEの説明?」(提案のためにプロジェクトを分析)

ステップ2: ステージングディレクトリを作成する
mkdir -p $HOME/opensource-staging/
ステップ3: フォーカーエージェントを実行する

opensource-forkerエージェントをスポーン:

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
"""
)

完了を待つ。{STAGING_PATH}/FORK_REPORT.mdを読む。

ステップ4: サニタイザーエージェントを実行する

opensource-sanitizerエージェントをスポーン:

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.
"""
)

完了を待つ。{STAGING_PATH}/SANITIZATION_REPORT.mdを読む。

FAILの場合: 結果をユーザーに表示する。「これらを修正して再スキャンしますか、それとも中止しますか?」と尋ねる。

  • 修正する場合: 修正を適用し、サニタイザーを再実行する(最大3回の再試行 — 3回のFAIL後、すべての結果を提示しユーザーに手動で修正するよう依頼する)
  • 中止する場合: ステージングディレクトリをクリーンアップする

PASSまたはWARNINGS付きPASSの場合: ステップ5に進む。

ステップ5: パッケージャーエージェントを実行する

opensource-packagerエージェントをスポーン:

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)
"""
)
ステップ6: 最終レビュー

ユーザーに提示する:

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)
ステップ7: GitHubへの公開(ユーザーの承認後)
cd "{STAGING_PATH}"
gh repo create "{github_org}/{github_repo}" --public --source=. --push --description "{description}"

---

/opensource verify PROJECT

サニタイザーを独立して実行する。パスを解決: PROJECTに/が含まれる場合、パスとして扱う。それ以外の場合は$HOME/opensource-staging/PROJECT$HOME/PROJECT、現在のディレクトリを確認する。

Agent(
  subagent_type="opensource-sanitizer",
  prompt="Verify sanitization of: {resolved_path}. Run all 6 scan categories and generate SANITIZATION_REPORT.md."
)

---

/opensource package PROJECT

パッケージャーを独立して実行する。「ライセンス?」と「説明?」を尋ねてから:

Agent(
  subagent_type="opensource-packager",
  prompt="Package: {resolved_path} ..."
)

---

/opensource list

ls -d $HOME/opensource-staging/*/

FORK_REPORT.md、SANITIZATION_REPORT.md、CLAUDE.mdの存在でパイプラインの進捗を各プロジェクトと共に表示する。

---

/opensource status PROJECT

cat $HOME/opensource-staging/${PROJECT}/SANITIZATION_REPORT.md
cat $HOME/opensource-staging/${PROJECT}/FORK_REPORT.md

ステージングレイアウト

$HOME/opensource-staging/
  my-project/
    FORK_REPORT.md           # フォーカーエージェントから
    SANITIZATION_REPORT.md   # サニタイザーエージェントから
    CLAUDE.md                # パッケージャーエージェントから
    setup.sh                 # パッケージャーエージェントから
    README.md                # パッケージャーエージェントから
    .env.example             # フォーカーエージェントから
    ...                      # サニタイズされたプロジェクトファイル

アンチパターン

  • ユーザーの承認なしにGitHubにプッシュすることは絶対にしない
  • サニタイザーをスキップすることは絶対にしない — これは安全ゲートである
  • 重大な結果をすべて修正せずにサニタイザーのFAIL後に続行することは絶対にしない
  • ステージングディレクトリに.env*.pem、またはcredentials.jsonを残すことは絶対にしない

ベストプラクティス

  • 新しいリリースには常に完全なパイプライン(フォーク → サニタイズ → パッケージ)を実行する
  • ステージングディレクトリは明示的にクリーンアップされるまで持続する — レビューに使用する
  • 公開前に手動修正後にサニタイザーを再実行する
  • 削除ではなくシークレットをパラメータ化する — プロジェクトの機能を維持する

関連スキル

サニタイザーが使用するシークレット検出パターンについてはsecurity-reviewを参照。

Related skills

How it compares

Pick opensource-pipeline over generic README generators when the primary risk is leaked credentials and you need a verified sanitization gate before publish.

FAQ

What stages does opensource-pipeline run?

opensource-pipeline runs three chained stages: Fork (secret removal), Sanitize (clean-state verification), and Package (CLAUDE.md, setup.sh, and README generation). Each stage maps to a `/opensource` subcommand.

When should developers invoke opensource-pipeline?

opensource-pipeline should run when a private project is about to go public on GitHub and secrets must be removed first. Trigger it with `/opensource fork` or phrases like "open source this" and "make this public."

Release Managementdevopsgitintegrations

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.