open-source-prep

オープンソース化の準備

非公開プロジェクトを、安全にオープンソース化できるリポジトリに整えます。5 つのフェーズを順番に実行します。後続の手順に進むには、最初に必ずシークレットスキャンに合格する必要があります。

使用場面

ユーザーが次のように言った場合：

• 「このプロジェクトをオープンソース化したい」
• 「オープンソース化する前に何をすればいい？」
• 「オープンソースライセンスを選びたい」
• 「GitHub にアップロードする前に、情報漏えいがないか確認して」

重要な原則

1. シークレットスキャンは通過必須の手順です — 実際のシークレットが見つかった場合は、ユーザーが先に対処できるよう必ず停止します。そのまま続行してはいけません
2. 生成するドキュメントは英語にします — 国際的なコントリビューターを対象とします。ユーザーとの会話は中国語で行います
3. LICENSE ファイルの名前は LICENSE（大文字、拡張子なし）にする必要があります。そうしないと GitHub が認識しません
4. 実際のトークンの例はすべて ...REDACTED... のプレースホルダーに置き換えます — ユーザーが自分から貼り付けた場合も同様です
5. 直接 push したり、公開設定に切り替えたりしてはいけません — まずユーザーに diff を確認してもらい、手動で commit、push、公開設定の切り替えを行ってもらいます

ワークフロー

Phase 1: シークレットと機密ファイルのスキャン（BLOCKING）

必ず最初に実施し、問題が見つかったら停止します。次の 3 か所をスキャンします：

1. 現在のワークスペース内のファイル（未追跡ファイルを含む）
2. staged 済み、または committed 済みの内容
3. git の全履歴（git log --all -p）

スキャンパターンは references/secrets-patterns.md を参照してください。主なパターンは次のとおりです：

種類	パターン
JWT	eyJhbGc[0-9A-Za-z_-]{20,}
GitHub token	gh[posur]_[0-9A-Za-z]{36,}
OpenAI / Anthropic	sk-[a-zA-Z0-9]{20,}, sk-ant-[a-zA-Z0-9-]{40,}
AWS access key	AKIA[0-9A-Z]{16}
Google API key	AIza[0-9A-Za-z_-]{35}
Slack token	xox[baprs]-[0-9A-Za-z-]{10,}
Stripe	sk_live_[0-9A-Za-z]{20,}
秘密鍵 PEM	-----BEGIN.*PRIVATE KEY-----
一般的なパスワード	password\s*[:=]\s*["'][^"']{8,}

機密ファイル名（staged 済みの場合は警告）：

• .env, .env.local, .env.production
• credentials.json, secrets.json
• *.pem, *.key, *.p12, *.pfx
• id_rsa, id_ed25519

実行するコマンド（プロジェクトの規模に応じて調整）：

# 工作区扫描（含未追踪）
git ls-files --others --exclude-standard -z | xargs -0 grep -lE "<pattern>" 2>/dev/null

# 已追踪文件
git grep -nE "<pattern>" 2>/dev/null

# Git 历史
git log --all -p 2>/dev/null | grep -cE "<pattern>"

# 敏感文件名
git ls-files | grep -E "(^|/)(\.env|credentials\.json|.*\.(pem|key|p12|pfx))$"

実際のシークレットとプレースホルダーを区別する：

• ✅ プレースホルダー：... / REDACTED / example / test / xxx / dummy を含む
• ❌ 実際のシークレット：明らかなプレースホルダーの印がなく、実際の形式に合致するもの（例：JWT はピリオドで区切られた 3 つの base64url 部分で構成される、AWS は大文字と数字 20 文字で構成されるなど）

実際のシークレットが見つかった場合：

1. ファイル名、行番号、途中を省略した表示を列挙します（eyJhbGc...[12 chars]...abcd のように、前後それぞれ 4 文字を表示し、中間を省略）
2. 対処方法を提案します：
   • ワークスペース内にある場合 → .env に移動し、.gitignore に追加します
   • commit 済みだが push 前の場合 → git filter-repo または git reset --soft HEAD~1 を使います
   • push 済みの場合 → 必ず直ちにその token を無効化します（このツールでは、漏えいした commit を GitHub から削除できません）。その後、git filter-repo --invert-paths と force push を行います
3. 後続の手順を停止し、ユーザーが対処した後に再実行するよう案内します

Phase 2: ライセンスの選択（対話形式）

判断ツリーに従って推奨します。最初からすべての質問を一度に尋ねてはいけません：

最初の質問：プロジェクトの性質は？

• 個人用ツール／小規模ライブラリ／アプリ → 2 つ目の質問へ進みます
• 商用製品をオープンソース化する／企業が安心して使えるようにしたい → Apache 2.0
• 派生物もすべてオープンソースにしたい → 3 つ目の質問へ進みます

2 つ目の質問（個人プロジェクト向け）：特許を取得できる新規技術が含まれますか？

• いいえ → MIT ⭐
• はい → Apache 2.0

3 つ目の質問（copyleft の希望に応じて）：SaaS 形式（ユーザーはネットワーク経由で利用し、ダウンロードはしない）ですか？

• はい → AGPL v3
• いいえ → GPL v3

デフォルトでは MIT を推奨します — 個人プロジェクトの 95% に適しています。生成する LICENSE には templates/LICENSE-MIT.txt のテンプレートを使用します。著作権者は git config user.name から取得し、年は現在の年にします。

ライセンスの比較：

ライセンス	長さ	特許	商標	copyleft	用途
MIT	20 行	なし	なし	なし	個人用ツールの第一候補
Apache 2.0	200 行	明示的	保護	なし	企業／特許関連
GPL v3	長い	あり	-	強い	強い copyleft のオープンソース
AGPL v3	長い	あり	-	非常に強い	SaaS 形式

Phase 3: 必須ドキュメントの生成

次のファイルを生成します（すでに存在する場合は diff を表示し、ユーザーの確認後に変更します）：

1. LICENSE — ライセンス本文。著作権者と年を記入します
2. CONTRIBUTING.md — 開発環境、PR の手順、テストコマンド（templates/CONTRIBUTING.md を使用）
3. SECURITY.md — 脆弱性の報告手順（templates/SECURITY.md を使用）
4. README.md への追記（Edit tool を使って挿入）：
   • 冒頭：サードパーティに関する免責事項（プロジェクトがサードパーティのサービスに関係する場合）
   • Privacy & Security セクション（機密データを扱う場合）
   • License セクションで LICENSE ファイルを参照

Phase 4: 設定の監査

確認して、変更を促します：

1. .gitignore — 次の項目が含まれていることを確認します：

   src-tauri/target/   # Tauri
   target/             # Rust 通用
   node_modules/       # Node
   dist/ build/ out/   # 构建产物
   .env*               # 环境变量
   .DS_Store Thumbs.db # OS
   coverage/ *.lcov    # 覆盖率报告
   

2. Bundle identifier / package name の確認：

   • src-tauri/tauri.conf.json の identifier フィールド
   • package.json の name フィールド
   • Cargo.toml の [package] name
   • サードパーティ企業名（com.google.*、com.factory.* など）が含まれている場合 → 商標リスクを警告します
   • com.<github-username>.<project-name> に変更するよう提案します

3. サードパーティサービスへの言及：

   • プロジェクト名に商標（「Google X」、「Apple X」など）が含まれていないか grep で検索します
   • README で、これは 非公式のサードパーティツール であることを説明しているか確認します

Phase 5: 任意の拡張

次の作業を行うかユーザーに確認します：

• CHANGELOG.md（git log から初期バージョンを生成）
• GitHub Actions のリリースワークフロー（.github/workflows/release.yml）
• Issue／PR テンプレート（.github/ISSUE_TEMPLATE/）
• リポジトリの公開設定への切り替え（gh repo edit --visibility public）

注意：公開設定への切り替えは、情報を取り消せない形で公開することを意味します。ユーザーが明示的に確認した後にのみ実行し、さらに Phase 1 のシークレットスキャンを再度実行する必要があります。

出力形式

各フェーズの終了後、ユーザーに次の形式で報告します：

## Phase N: xxx

✅ 通过：[...]
⚠️ 警告：[...]
❌ 需处理：[...]

下一步：[...]

最後に、完全なチェックリストを提示します。

工具文件

• templates/LICENSE-MIT.txt — MIT 协议模板（用 {{YEAR}} {{AUTHOR}} 占位）
• templates/LICENSE-Apache-2.0.txt — Apache 2.0 模板
• templates/LICENSE-GPL-3.0.txt — GPL v3 模板（较长，可用 gh api 拉官方文本）
• templates/LICENSE-AGPL-3.0.txt — AGPL v3 模板
• templates/CONTRIBUTING.md — 贡献指南模板
• templates/SECURITY.md — 安全策略模板
• references/secrets-patterns.md — 完整的密钥正则表达式清单
• references/disclaimer-templates.md — 不同场景的免责声明范文