OpenGHz/オープンソースプロジェクトポリッシュ

オープンソースプロジェクトポリッシュ は何をしますか？

目標

既存のプロジェクトフォルダを、元のソースコードを保持したまま、公開ドキュメント、コミュニティファイル、リポジトリメタデータ、Git/GitHub設定を改善することで、高品質なオープンソースリポジトリに変換します。

厳格な制約

• ユーザーが明示的に要求しない限り、オリジナルのプロダクト/ソースコード、生成ロジック、テスト、ノートブック、アセット、または実行時動作を変更しないでください。
• 許可される変更は、README、LICENSE、CONTRIBUTING、CODE_OF_CONDUCT、SECURITY、CHANGELOG、SUPPORT、CITATION、issue/PRテンプレート、リリースノート、バッジ、.gitignore、.gitattributes、.editorconfig、GitHubワークフロー/ドキュメントのスキャフォールディングなど、プロジェクト向けのメタデータとドキュメントに限定されます。
• READMEや公開ドキュメントに、/home/<user>/...、/Users/<user>/...、ドライブレターのパス、個人のワークスペース名、ダウンロードフォルダ、マシン固有の絶対プロジェクトパスなど、ユーザー固有のローカルマシンパスを含めないでください。代わりに相対パス、$HOME、<repo>、またはプレースホルダーを使用してください。
• ライセンスが存在せず、ユーザーの設定もない場合は、デフォルトでMITライセンスを適用します。
• Gitリモートがないフォルダには、デフォルトで自動的な公開GitHubパブリケーションを実施します。ターゲットのオーナー/名前が明確でない場合は判断し、シークレットチェックを通過した後、公開リモートを作成し、ドキュメントのみの変更をプッシュします。
• ネットワーク/GitHubコマンドが失敗した場合は、構成されたローカルプロキシを使用して1回再試行してから、リモート手順がブロックされたと宣言します。
• 既存のドキュメントとコミュニティファイルは可能な限り保存し、有用なコンテンツを置き換えるのではなく、段階的に改善します。

不足時に入力を求める項目

不可逆的または公開向けのアクションに実質的に影響する情報のみを尋ねてください。

1. ターゲットスコープ：ワークスペースのプロジェクトパス、またはすでに明確な場合は現在のフォルダ。
2. 公開アイデンティティ：フォルダと認証済みGitHubアカウントから推測できない場合、リモートを作成する前にGitHubのオーナー/リポジトリ名を確認します。
3. ライセンスの上書き：既存のライセンスがあればそれを使用し、それ以外の場合はユーザーが別のライセンスを要求しない限りデフォルトでMITを適用します。
4. プロジェクトのポジショニング：コード/ドキュメントから推測できない場合、一文のバリュープロポジション、ターゲットユーザー、成熟度を確認します。
5. ソースコードの編集：デフォルトでは禁止と見なし、メタデータ/ドキュメント以外に触れる前に確認します。

手順

1. プロジェクト状態の監査

• フォルダ構造、既存のREADME/ドキュメント、パッケージマニフェスト、ビルドファイル、例、ライセンスファイル、Gitの状態を検査します。
• .gitが存在するか、リモートが構成されているかを確認します。
• リモート作成またはプッシュの前に、シークレットリスクのあるファイル（.env、認証情報、トークン、大きなバイナリ、データセット、プライベートノート、ローカルログ、マシン固有のパス）を特定します。
• 既存の強み、不足しているオープンソースの必須要素、およびユーザーの入力を必要とする不確実性を要約します。

2. 非コード追加の計画

許可されたドキュメントとメタデータの作業のみをカバーする簡潔な計画を作成します。

• create-readmeスキルを構造、トーン、GitHub Flavored Markdownのベースとして使用したREADMEの改善。
• デフォルトでバイリンガルREADME：プライマリ（英語）READMEが完成したら、中国語版を作成しREADME.zh-CN.mdとして保存し、相互リンクします。ミラーを直接作成し、長いまたは用語の多いドキュメントではbaoyu-translateスキルを予約し、グローバルな用語の一貫性を重視します。
• コミュニティ健全性ファイル：デフォルトでMITライセンス、コントリビューションガイド、行動規範、セキュリティポリシー、サポートガイド、変更履歴、引用、ガバナンス、Issueテンプレート、PRテンプレート。
• リポジトリ衛生：.gitignore、.gitattributes、.editorconfig、ドキュメントインデックス、例インデックス、バッジ、プロジェクト説明、トピック、ファンディング/スポンサーメタデータ（該当する場合）。
• Git/GitHub設定：Gitがない場合は初期化、リモートがない場合は公開リモートを作成、デフォルトブランチを設定し、安全チェック後にドキュメントのみの変更をプッシュ。

3. READMEの改善

READMEの作成またはリフレッシュにはcreate-readmeスキルを使用します。READMEが簡潔で魅力的で有用であることを確認します。

• 明確なプロジェクト名、タグライン、短いバリュープロポジション。
• 真実でメンテナンス可能な場合にのみバッジを使用。
• 可能な場合は検証済みのコマンドを使用したクイックスタート。
• コマンドはリポジトリルートからコピー＆ペースト可能であり、現在のユーザーの絶対ローカルパスを含んではなりません。./script.sh、$HOME/...、/path/to/...、または<repo>/...の例を推奨します。
• インストール、使用方法、設定、例、プロジェクト構造、トラブルシューティング、専用ファイルへのリンク。
• README内にLICENSE、CONTRIBUTING、CHANGELOG、SECURITYの内容を完全に複製せず、それらのファイルにリンクします。
• 既存のプロジェクト固有の知識と例を保持します。

英語のREADME.mdが完成したら、デフォルトで中国語翻訳を作成します。

• 英語のREADME.mdは、デフォルトで上部近くに言語切り替え行（例：English | [简体中文](README.zh-CN.md)）を含める必要があります。同じ実行中に中国語ファイルがまだ生成中の場合でも追加します。リンクはワークフロー完了時に存在するパスを指します。
• 中国語のREADME.zh-CN.mdをREADME.mdから作成します。通常のREADME（主に短い散文とそのままのコード/コマンド）では、ミラーを直接作成することを推奨します。READMEが長い、または用語が多く、分析/翻訳/レビューフローと共有用語集の恩恵を受ける場合にのみ、baoyu-translateスキルを呼び出します。
• 中国語のREADME.zh-CN.mdには、上部にミラー切り替え行（例：[English](README.md) | 简体中文）を付けます。
• すべてのコードブロック、コマンド、パス、リンク、バッジ、プレースホルダーは変更せず、散文のみを翻訳します。
• ユーザーが明示的に拒否した場合のみ、中国語版をスキップします。プロジェクトがすでに主に中国語で作成されている場合は、README.mdを中国語版として扱い、README.en.mdに翻訳し、各ファイルの上部に対応する切り替え行を配置します。

4. コミュニティファイルの追加

ファイルがプロジェクトを完全で信頼できるものに見せるのに役立つ場合にのみ、ファイルを追加または更新します。

• LICENSE：既存のライセンスがあればそれを使用し、それ以外の場合はデフォルトでMITライセンスを追加し、検出された現在の年とオーナー/プロジェクト名を適切な場所に使用します。
• CONTRIBUTING.md：開発環境設定、推測可能なブランチ/コミット規約、テストの期待事項、Issue/PRプロセス。
• CODE_OF_CONDUCT.md：ユーザーが別のポリシーを持っていない限り、標準的な簡潔なコントリビューターコベナントスタイルを使用します。
• SECURITY.md：サポート対象バージョン、責任ある開示チャネルのプレースホルダー、脆弱性報告の期待事項。
• CHANGELOG.md：Unreleasedと現在の公開ベースラインで初期化します。リリース履歴を捏造しないでください。
• SUPPORT.md：質問、バグ報告、機能リクエストの場所。
• .github/ISSUE_TEMPLATE/* と .github/PULL_REQUEST_TEMPLATE.md：プロジェクトに合わせた実用的なフォーム/チェックリスト。
• CITATION.cff：研究/学術/科学プロジェクト、または著者メタデータが利用可能な場合のみ。

5. リポジトリ衛生

• 検出された言語/ツールに基づいて.gitignoreを作成または改良しますが、ソースアーティファクトである可能性が高いファイルを除外しないでください。
• テキスト正規化と一般的なバイナリパターンに.gitattributesを追加します（有用な場合）。
• リポジトリのスタイルに一致する控えめな空白のデフォルトで.editorconfigを追加します。
• ビルド/テストコマンドが既知または検証されていない限り、CIワークフローは追加しないでください。追加する場合は、最小限で非侵入的に保ちます。

6. Gitとリモートの処理

Gitがないフォルダの場合：

1. フォルダパスを確認した後、ターゲットフォルダのリポジトリを初期化します。
2. このワークフローで作成または変更されたメタデータ/ドキュメントファイルのみをステージングします。
3. 公開が進行中の場合は、ドキュメントに焦点を当てたメッセージでコミットします。

リモートがないGitリポジトリの場合：

1. 可能な場合はgh認証からGitHubオーナーを、フォルダからリポジトリ名を推測します。曖昧な場合のみ質問します。
2. リモートを作成する前にgh認証を確認します。
3. デフォルトで公開GitHubリポジトリを作成します。
4. originを追加し、デフォルトブランチを設定し、ステージングされた変更を確認し、シークレットが含まれていないことを確認した後にプッシュします。

推奨されるGitHub CLIフロー（プロジェクトに適合）：

git status --short
git remote -v
gh auth status
gh repo create OWNER/REPO --public --source=. --remote=origin --push

ネットワークコマンドが失敗した場合は、以下を使用して1回再試行します。

export {HTTP_PROXY,HTTPS_PROXY,ALL_PROXY,http_proxy,https_proxy,all_proxy}=http://127.0.0.1:7890

7. 品質チェック

完了前に：

• 変更されたMarkdownスニペットを再度開き、見出し、リンク、コードフェンス、コピー＆ペースト可能なコマンドのインデントを確認します。
• READMEと公開ドキュメント内のローカルマシンパス（/home/、/Users/、ドライブレターパス、個人のワークスペース名、現在の環境からコピーされた絶対パスを含む）を完了前に検索します。
• 明示的に承認されていない限り、ソースコードファイルが変更されていないことを確認します。
• ローカルファイルへのすべてのリンクが存在するファイルをターゲットにしていることを確認します。
• 中国語のREADMEが作成された場合は、README.zh-CN.mdが存在し、言語切り替えリンクが両方のファイルで解決され、コード/コマンド/パスが英語版と同一であることを確認します。
• 利用可能な場合は軽量なフォーマットまたはMarkdownリンティングを実行します。ユーザーが同意しない限り、このワークフローだけのために重い依存関係をインストールしないでください。
• git diff --statを表示し、変更されたファイルを要約します。
• リモートが作成された場合は、URL、可視性、デフォルトブランチ、およびプッシュされた内容を報告します。

決定ポイント

• 既存のREADMEが強力な場合：書き換えるのではなく、構造を保持し、欠落しているセクションを修正します。
• 検証済みのインストール/テストコマンドがない場合：コマンドを捏造する代わりに、明確にマークされたプレースホルダーまたは「まだ文書化されていません」というメモを含めます。
• ライセンスが不明な場合：ユーザーが別のライセンスを要求しない限り、デフォルトでMITライセンスを追加します。
• シークレットまたはプライベートデータの可能性がある場合：リモート作成/プッシュを停止し、リスクのあるパスを報告します。
• gh CLIがない、または認証されていない場合：ユーザーが実行するための正確なコマンドを提供しますが、それでもローカルドキュメントのポリッシュを完了し、安全な場合はドキュメントのみのコミットを準備します。
• モノレポの場合：ルートコミュニティファイルを作成または更新し、パッケージ境界が明確な場合にのみ、パッケージごとのREADMEファイルを作成します。

完了サマリー

以下で終了します。

• 追加/更新されたファイル。
• 特にソースコード、意図的に触れなかったもの。
• 実行された検証。
• リモートリポジトリのステータス（該当する場合）。
• CIの有効化、例の追加、最初のリリースの作成、プロジェクトトピックの作成など、推奨される次のステップ。