affaan-m/ECC

opensource-pipeline

オープンソースパイプライン: プライベートプロジェクトをフォーク、サニタイズし、安全な公開リリースのためにパッケージ化する。3つのエージェント(フォーカー、サニタイザー、パッケージャー)を連鎖させる。トリガー: '/opensource'、'open source this'、'make this public'、'prepare for open source'。

78CollectingWrites files
See how to use itView GitHub source
npx skills add https://github.com/affaan-m/ECC --skill "docs/ja-JP/skills/opensource-pipeline"
Automated source guide

Source checked Jul 28, 2026·Refresh due Oct 26, 2026

Reorganized from the pinned upstream SKILL.md

Turn opensource-pipeline's source instructions into a guide you can follow

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

npx skills add https://github.com/affaan-m/ECC --skill "docs/ja-JP/skills/opensource-pipeline"
Check the pinned source

Best fit

  • オープンソースパイプライン: プライベートプロジェクトをフォーク、サニタイズし、安全な公開リリースのためにパッケージ化する。3つのエージェント(フォーカー、サニタイザー、パッケージャー)を連鎖させる。トリガー: '/opensource'、'open source this'、'make this public'、'prepare for open source'。

Bring this context

  • A concrete task that matches the documented purpose of opensource-pipeline.
  • The files, examples, or context the task depends on.
  • Your constraints, target environment, and definition of done.

Expected outputs

  • A result that follows the pinned opensource-pipeline instructions.
  • A concise record of assumptions, inputs used, and unresolved questions.
  • A final check against the source workflow and relevant permission signals.

Key source sections

Read opensource-pipeline through these 5 source sections

Sections are extracted automatically from the pinned SKILL.md and link back to the source.

01

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

ユーザーが「このプロジェクトをオープンソース化する」または「これを公開する」と言うとき

SKILL.md · アクティベートするタイミング
ユーザーが「このプロジェクトをオープンソース化する」または「これを公開する」と言うときユーザーがプライベートリポジトリを公開リリースのために準備したいときユーザーがGitHubにプッシュする前にシークレットを除去する必要があるとき
02

コマンド

Review the “コマンド” section in the pinned source before continuing.

SKILL.md · コマンド
Review and apply the “コマンド” source section.
03

プロトコル

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

SKILL.md · プロトコル
「どのプロジェクト?」(見つからない場合)「ライセンス?(MIT / Apache-2.0 / GPL-3.0 / BSD-3-Clause)」「GitHubのorgまたはユーザー名?」(デフォルト: gh api user -q .loginで検出)
04

/opensource fork PROJECT

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

SKILL.md · /opensource fork PROJECT
「どのプロジェクト?」(見つからない場合)「ライセンス?(MIT / Apache-2.0 / GPL-3.0 / BSD-3-Clause)」「GitHubのorgまたはユーザー名?」(デフォルト: gh api user -q .loginで検出)
05

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

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

SKILL.md · ステップ1: パラメータを収集する
「どのプロジェクト?」(見つからない場合)「ライセンス?(MIT / Apache-2.0 / GPL-3.0 / BSD-3-Clause)」「GitHubのorgまたはユーザー名?」(デフォルト: gh api user -q .loginで検出)

SkillSignal prompt templates

Provide the task, context, and acceptance criteria

These prompts were written by SkillSignal from the source structure; they are not upstream text.

Task-start prompt

Confirm source fit, inputs, and outputs before acting.

Use opensource-pipeline to help me with: [specific task]. Context: [files, data, or background]. Constraints: [environment, scope, and prohibited actions]. Before acting, check the pinned SKILL.md and explain which sections apply, what inputs are still missing, and what you will deliver.

Source-guided execution

Make the Agent explicitly follow the key extracted sections.

Apply the pinned opensource-pipeline source to [task]. Pay particular attention to these source sections: “アクティベートするタイミング”, “コマンド”, “プロトコル”, “/opensource fork PROJECT”, “ステップ1: パラメータを収集する”. Preserve the important decision at each step. Mark facts not covered by the source as “needs confirmation” instead of inventing them. Then verify the result against my acceptance criteria: [criteria].

Result-review prompt

Check omissions, permissions, and source drift before delivery.

Review the current opensource-pipeline result: (1) does it satisfy the original task; (2) were any applicable steps or limits in the pinned SKILL.md missed; (3) did it perform any unauthorized file, command, network, or data action; and (4) which conclusions remain unverified? List issues first, then fix only what the source or user authorization supports.

Output checklist

Verify each item before delivery

The task matches the purpose documented in the SKILL.md.

The source section “アクティベートするタイミング” has been checked.

The source section “コマンド” has been checked.

The source section “プロトコル” has been checked.

The source section “/opensource fork PROJECT” has been checked.

Inputs, constraints, and acceptance criteria are explicit.

Unverified facts, compatibility, and outcome claims are clearly marked.

Any file, command, network, or data action has been reviewed.

Choose a different workflow

When another Skill is the better fit

FAQ

What does opensource-pipeline do?

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

How do I start using opensource-pipeline?

The catalog detected this source-specific install command: npx skills add https://github.com/affaan-m/ECC --skill "docs/ja-JP/skills/opensource-pipeline". Inspect the command and pinned source before running it.

Which Agent platforms does it declare?

No dedicated Agent platform is declared in the pinned source record.

Repository stars
234,327
Repository forks
35,711
Quality
78/100
Source repository last pushed

Quality breakdown

Based on traceable docs and repository signals; stars are not treated as quality.

78/100
Documentation28/30
Specificity14/25
Maintenance20/20
Trust signals16/25

Compare before choosing

Related Agent Skills and source variants

These links are selected from shared tasks, functions, stacks, platforms, and same-name variants. Compare the source owner, documentation, permissions, and maintenance signals.

opensource-pipeline by affaan-m

开源流水线:fork、清理并打包私有项目以安全公开发布。串联3个代理(fork代理、清理代理、打包代理)。触发词:'/opensource'、'open source this'、'make this public'、'prepare for open source'。

opensource-pipeline by affaan-m

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'.

ab-testing by coreyhaines31

When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program

churn-prevention by coreyhaines31

When the user wants to reduce churn, build cancellation flows, set up save offers, recover failed payments, or implement retention strategies. Also use when the user mentions 'churn,' 'cancel flow,' 'offboarding,' 'save offer,' 'dunning,' 'failed payment recovery,' 'win-back,' 'retention,' 'exit survey,' 'pause subscription,' 'involuntary churn,' 'people keep canceling,' 'churn rate is too high,' 'how do I keep users,' or 'customers are leaving.' Use this whenever someone is losing subscribers o

design-intelligence by event4u-app

Grounded design brief from the adopted corpus — style, WCAG-checked color tokens, typography, layout pattern, anti-patterns. Use on ui-design-brief or any which-style/palette/font/chart decision.

View original Skill.mdThis page is parsed directly from the repository SKILL.md without editorial rewriting. Collected: Jul 28, 2026 · about 1 min

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

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を参照。

Source repo
affaan-m/ECC
Skill path
docs/ja-JP/skills/opensource-pipeline/SKILL.md
Commit SHA
4e973d3eaf92
Repository license
MIT
Data collected