オープンソース準備 は何をしますか？
公開間近のリポジトリに対するプレリリースチェック。スクリプトが機械的なチェックを行い、あなたはプロジェクトを読み、スクリプトでは判断できないことを評価し、レポートし、ユーザーが選んだ項目だけを補完します。
順序が重要なのは、一度ミスを取り消せないからです。リポジトリが公開されると、その履歴のすべてが閲覧可能になります。漏洩した資格情報と個人データが最優先で、ボイラープレートは最後です。
1. スキャン
リポジトリルートからバンドルされたスキャナを実行します（Node 20以降、依存関係なし、読み取り専用）：
node <skill-dir>/scripts/scan.mjs <repo-dir>
これはJSONを出力します：summaryはレベルごとの失敗件数をカウントし、各結果にはid、level（block、warn、info）、status（pass、fail、skip）、evidenceが含まれます。非常に大規模な履歴の場合は、ユーザーがその部分をスキップすることに同意した場合のみ--no-historyを追加し、スキップされたことを伝えてください。gitleaksがインストールされている場合は、gitleaks git <repo-dir> --redact --no-bannerも実行し、その結果を統合してください。gitleaksはより多くのトークンフォーマットを知っています。
スキャナのシークレットルールはパターンベースであるため、誤検知（テストフィクスチャ、ドキュメントの例）が予想され、すべてを捕捉したとは限りません。報告する前に、すべてのヒットを自分で確認してください。oss-prep: allowコメントで意図的であるとマークされた行は除外されます。
2. 読み取りと判断
各チェックの意味、実際の問題とノイズの区別方法、そしてあなただけが実行できるチェックについては、references/checklist.mdを参照してください。要約すると、スクリプトの発見事項以外に：
- 履歴とファイルが明らかにすること。 各シークレットヒットと履歴内の機密ファイル（
git show <commit>:<path>）を確認してください。実際の名前、メールアドレス、電話番号、住所、顧客データや財務データ、内部ホスト名、docsやフィクスチャ内のプライベートデータを含むスクリーンショットを探します。 - ライセンスの一貫性。 LICENSEテキスト、
package.json、SKILL.mdのフロントマター、README、およびファイルごとのヘッダーが一致している必要があります。バンドルされているサードパーティコード、フォント、画像と、それらのライセンスが再配布を許可しているかどうかに注意してください。 - 他人のためのREADME。 検索から訪れた人が、それが何であるかを学び、スクリーンショットやデモリンクで確認し、インストールして実行し、ライセンスを見つけられるように、プライベートなコンテキストなしで記述します。
- 作者にしか動かなかったもの。 ハードコードされたローカルパス、プロジェクトが必要とするがドキュメント化されていない
.envの値、作者のマシンを前提としたスクリプト。
3. レポート
ユーザーの言語で、以下の形式でレポートを記述します：
# オープンソース準備状況: <repo>
**判定:** <準備完了 / ブロッキング項目修正後準備完了 / 未準備>、理由を一文で。
## ブロッキング（公開前に修正）
- ❌ <タイトル>: <発見内容（ファイル:行番号またはコミット）> → <修正方法>
## 修正推奨
- ⚠️ ...
## あると良い
- 💡 ...
## 既に整備済み
- ✅ <各行1項目、グループ化>
## GitHubでの対応が必要
<ユーザー自身が変更する設定と、正確なghコマンドまたは設定パス>
最も深刻な項目を最初に置きます。具体的に記述してください：「シークレットが見つかりました」ではなく、「src/config.ts:12にOpenAIキーがあり、コミットa1b2c3dにも存在します」。チェックしなかったこと（ghなし、履歴スキップ、バイナリファイル）も明記します。
次に、どの項目を補完するかを尋ねます。明白なセットをデフォルトとして提示し（「欠落している全ファイル」）、各選択肢をリストアップしてユーザーが選択できるようにします。
4. ユーザーが選んだ項目を補完
テンプレートはassets/templates/を出発点として使用し、このプロジェクトに適合させます。事前にreferences/fixing.mdを読んでください。要約：
- ファイルを作成するのみで、公開はしない。 ワーキングツリー内でのみファイルを作成または編集します。コミット、プッシュ、リポジトリの可視性や設定の変更、リリースの作成は、ユーザーがその特定のステップを明示的に要求した場合を除き、行わないでください。
- プロジェクトに合わせる。 実際のコマンド、Nodeバージョン、パッケージマネージャー、ライセンス、問い合わせ手段を使用し、READMEの言語で記述します（READMEがバイリンガルの場合は両方）。該当しないセクションは、プレースホルダーを置くのではなく省略します。
- ユーザーに代わってライセンスを選択しない。 ライセンスがない場合は、一般的な選択肢（MIT、Apache-2.0、GPL-3.0、AGPL-3.0、デュアルライセンス）をそれぞれ一文で説明し、ユーザーに尋ねてください。公式のライセンステキストは正確にコピーし、記憶から言い換えたり再入力したりしないでください。
- 履歴内のシークレットはファイルを削除しても修正できない。 資格情報はまず失効させて置き換える必要があります。それはプロバイダーのコンソールでのユーザーの作業です。履歴の書き換え（
git filter-repo）や新しいリポジトリの公開はユーザーの判断に委ねます。両方を説明し、明確な同意なしにどちらも実行しないでください。 - GitHub設定はユーザーのものです。 リファレンスから正確な
ghコマンドまたは設定パスを提供し、ユーザーが要求した場合のみ実行します。
最後にスキャナを再度実行し、どの検出結果が変化したか、またユーザーに残された作業を示して終了します。