Source profileQuality 78/100

affaan-m/ECC/docs/ja-JP/skills/opensource-pipeline/SKILL.md

opensource-pipeline

Review opensource-pipeline's use cases, installation, workflow, and original source instructions.

Source repository stars
234,327
Declared platforms
0
Static risk flags
1
Last source update
2026-07-27
Source checked
2026-07-28

Decision brief

What it does—and where it fits

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

Best for

    Not for

    • Tasks that require unconfirmed production actions or broad system permissions.
    • Environments where the pinned source and install steps cannot be inspected.

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/affaan-m/ECC --skill "docs/ja-JP/skills/opensource-pipeline"
    Safe inspection promptEditorial

    Inspect the Agent Skill "opensource-pipeline" from https://github.com/affaan-m/ECC/blob/4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38/docs/ja-JP/skills/opensource-pipeline/SKILL.md at commit 4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    1. 01

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

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

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

      コマンド

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

      Review and apply the “コマンド” source section.
    3. 03

      プロトコル

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

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

      /opensource fork PROJECT

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

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

    Permission review

    Static risk signals and limitations

    Writes files

    medium · line 161

    The documentation asks the agent to create, modify, or delete local files.

    Create repo: gh repo create {github_org}/{github_repo} --public

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score78/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars234,327SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    affaan-m/ECC
    Skill path
    docs/ja-JP/skills/opensource-pipeline/SKILL.md
    Commit
    4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38
    License
    MIT
    Collected
    2026-07-28
    Default branch
    main
    View the original SKILL.md

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

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

    Alternatives

    Compare before choosing