オープンソースパイプラインスキル
任意のプロジェクトを安全にオープンソース化するための3段階パイプライン：フォーク（シークレット除去）→ サニタイズ（クリーン性確認）→ パッケージ（CLAUDE.md + setup.sh + README）。
起動タイミング
- ユーザーが「このプロジェクトをオープンソース化したい」「これを公開したい」と言ったとき
- ユーザーがプライベートリポジトリを公開リリース用に準備したいとき
- ユーザーがGitHubにプッシュする前にシークレットを除去する必要があるとき
- ユーザーが
/opensource fork、/opensource verify、または/opensource packageを呼び出したとき
コマンド
| コマンド | アクション |
|---|---|
/opensource fork PROJECT | フルパイプライン：フォーク + サニタイズ + パッケージ |
/opensource verify PROJECT | 既存のリポジトリに対してサニタイザーを実行 |
/opensource package PROJECT | CLAUDE.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}"
ユーザーに以下を質問します：
- 「どのプロジェクトですか？」（見つからなかった場合）
- 「ライセンスは？（MIT / Apache-2.0 / GPL-3.0 / BSD-3-Clause）」
- 「GitHub の組織またはユーザー名は？」（デフォルト：
gh api user -q .loginで検出） - 「GitHub リポジトリ名は？」（デフォルト：プロジェクト名）
- 「README の説明は？」（プロジェクトを解析して提案）
ステップ 2：ステージングディレクトリの作成
mkdir -p $HOME/opensource-staging/
ステップ 3：フォーカーエージェントの実行
opensource-forker エージェントを起動します：
Agent(
description="Fork {PROJECT} for open-source",
subagent_type="opensource-forker",
prompt="""
オープンソースリリースのためにプロジェクトをフォークします。
ソース: {SOURCE_PATH}
ターゲット: {STAGING_PATH}
ライセンス: {chosen_license}
以下の完全なフォークプロトコルに従います：
1. ファイルをコピー（.git、node_modules、__pycache__、.venv を除外）
2. すべてのシークレットと認証情報を除去
3. 内部参照をプレースホルダーに置き換え
4. .env.example を生成
5. Git 履歴をクリーンアップ
6. {STAGING_PATH}/FORK_REPORT.md に FORK_REPORT.md を生成
"""
)
完了を待ちます。{STAGING_PATH}/FORK_REPORT.md を読み込みます。
ステップ 4：サニタイザーエージェントの実行
opensource-sanitizer エージェントを起動します：
Agent(
description="Verify {PROJECT} sanitization",
subagent_type="opensource-sanitizer",
prompt="""
オープンソースフォークのサニタイゼーションを検証します。
プロジェクト: {STAGING_PATH}
ソース（参照用）: {SOURCE_PATH}
すべてのスキャンカテゴリを実行します：
1. シークレットスキャン（CRITICAL）
2. PII スキャン（CRITICAL）
3. 内部参照スキャン（CRITICAL）
4. 危険ファイルチェック（CRITICAL）
5. 設定の完全性チェック（WARNING）
6. Git 履歴監査
{STAGING_PATH} 内に PASS/FAIL の判定を含む SANITIZATION_REPORT.md を生成します。
"""
)
完了を待ちます。{STAGING_PATH}/SANITIZATION_REPORT.md を読み込みます。
FAIL の場合： 調査結果をユーザーに表示します。「これらの問題を修正して再スキャンしますか、それとも中止しますか？」と質問します。
- 修正の場合：修正を適用し、サニタイザーを再実行（最大3回リトライ — 3回 FAIL したらすべての調査結果を提示し、ユーザーに手動修正を依頼）
- 中止の場合：ステージングディレクトリをクリーンアップ
PASS または PASS WITH WARNINGS の場合： ステップ5に進みます。
ステップ 5：パッケージャーエージェントの実行
opensource-packager エージェントを起動します：
Agent(
description="Package {PROJECT} for open-source",
subagent_type="opensource-packager",
prompt="""
プロジェクトのオープンソースパッケージを生成します。
プロジェクト: {STAGING_PATH}
ライセンス: {chosen_license}
プロジェクト名: {PROJECT_NAME}
説明: {description}
GitHub リポジトリ: {github_repo}
以下を生成します：
1. CLAUDE.md（コマンド、アーキテクチャ、主要ファイル）
2. setup.sh（ワンコマンドブートストラップ、実行可能に設定）
3. README.md（または既存のものを拡張）
4. LICENSE
5. CONTRIBUTING.md
6. .github/ISSUE_TEMPLATE/（bug_report.md、feature_request.md）
"""
)
ステップ 6：最終レビュー
ユーザーに表示します：
オープンソースフォーク準備完了: {PROJECT_NAME}
場所: {STAGING_PATH}
ライセンス: {license}
生成されたファイル:
- CLAUDE.md
- setup.sh（実行可能）
- README.md
- LICENSE
- CONTRIBUTING.md
- .env.example（{N} 変数）
サニタイゼーション: {sanitization_verdict}
次のステップ:
1. 確認: cd {STAGING_PATH}
2. リポジトリ作成: gh repo create {github_org}/{github_repo} --public
3. プッシュ: git remote add origin ... && git push -u origin main
GitHub 作成を続行しますか？（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="サニタイゼーションを検証: {resolved_path}。6つのスキャンカテゴリすべてを実行し、SANITIZATION_REPORT.md を生成してください。"
)
/opensource package PROJECT
パッケージャーを単独で実行します。「ライセンスは？」と「説明は？」を質問し、その後：
Agent(
subagent_type="opensource-packager",
prompt="パッケージ化: {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 を参照してください。