linuxmirrors-awesome について
LinuxMirrors の利用者、運用担当者、ドキュメント管理者向けの調査・タスク振り分けスキルです。プロジェクトやスクリプトの違いを説明し、変動する情報を確認したうえで、変更作業を実行せず適切な手順へ案内します。
主な機能
- 01プロジェクトとスクリプト情報の確認
- 02メインスクリプトと Lite の比較
- 03公式サイトと現行ソースの照合
- 04システム、Docker、Registry のソース区別
- 05変更依頼の安全な振り分け
活用シーン
- 01LinuxMirrors の位置付けと機能の把握
- 02対応システムや最新情報の確認
- 03メインスクリプトと Lite の選択
- 04ソース変更や Docker 作業の経路計画
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ full-stack-skills/ devops-skills --skill linuxmirrors-awesomeインストール後、Claude Code で/linuxmirrors-awesomeを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
evaluation-report.htmlLICENSE.txtagents/openai.yamlexamples/01-project-introduction.md02-latest-capabilities.md03-main-vs-lite.md04-route-ambiguous-request.md05-source-conflict.md06-os-compatibility.md07-mirror-selection.md08-security-review.md09-cicd-fit.md10-offline-research.mdreferences/official/compatibility.mdfreshness.mdproject-overview.mdsources.mdreferences/operations/quality-checklist.mdrouting.mdsecurity.mdtroubleshooting.md詳細
LinuxMirrors オーソリティブガイド
クイックスタート
まず、問題が「プロジェクトを理解すること」なのか「変更を実行すること」なのかを判断します。紹介、機能、互換性、最新の変更、資料の検証はこのスキルで扱います。システムのソフトウェアソースや Docker の変更については、タスクの振り分けのみを行い、本番環境向けのコマンドを直接組み立てません。
そのまま使える質問:
- 「LinuxMirrors を紹介し、一般的なミラーサイト一覧との違いを説明してください。」
- 「LinuxMirrors が現在サポートしているシステムを、公式サイトとソースコードを引用して確認してください。」
- 「メインスクリプトと Lite スクリプトを比較して、どちらを選ぶべきか教えてください。」
どのような場合に使用するか
ユーザーが LinuxMirrors について知りたい場合、プロジェクトの最新情報を確認したい場合、スクリプトを比較したい場合、またはタスクの進め方を判断したい場合に使用します。ユーザーが実際のシステムソースの切り替え、Docker のインストール、Registry の変更を求めている場合は、資料の検証とタスクの振り分けのみを行い、このスキル内では変更を実行しません。
対象ユーザー
- 初心者:まずプロジェクトの位置付けと3つのタスク経路を確認します。
- 運用担当者:情報の鮮度、互換性、安全性、タスクの振り分けに関する資料を重点的に確認します。
- Skill/ドキュメントのメンテナー:ソース索引と品質チェックリストを使って、事実と引用を検証します。
ワークフロー
Step 1:意図を特定する
プロジェクトの紹介、最新情報、システムソースの切り替え、Docker のインストール、Registry Mirror、ソースコードの分析を区別します。
Step 2:情報の鮮度を確認する
アクセス日を記録します。動的な事実は、少なくとも公式サイトと GitHub/現在のソースコードという2種類の情報源で確認します。
Step 3:資料を特定する
権威ある情報源に従って、公式サイト、ドキュメント、リポジトリ、変更履歴、安全性に関する告知を確認します。
Step 4:相互検証する
情報の鮮度に関するルールに従って、公式サイト、README、ソースコードの差異を扱います。記憶を頼りに内容を補ってはいけません。
Step 5:回答を構成する
まず結論を示し、続けて適用条件、根拠となるリンク、リスク、次のタスクへの振り分けを記載します。
Step 6:出力をセルフチェックする
品質チェックリストを実行し、ドキュメントの説明を実行済みの結果として誤って記載していないことを確認します。
対応範囲と対象外のシナリオ
✅ 得意なこと
- LinuxMirrors のプロジェクトの位置付け、2種類のスクリプト、オープンソースライセンス、典型的なユーザーを説明します。
- 公式サイトとソースコードに基づき、サポート対象システム、パラメーター、メインスクリプトと Lite の違い、最新のコミットを確認します。
- 要件をシステムのソフトウェアソース、Docker CE ソフトウェアソース、Registry Mirror のどの手順に進めるべきか判断します。
⚠️ 条件が必要なこと
- 「自分のマシンがサポートされているか」の判断には、ディストリビューション、バージョン、アーキテクチャ、ネットワーク地域が必要です。
- 「最新バージョンでは何が変わったか」の確認には、公式サイトまたは GitHub にアクセスできることと、確認時刻の明記が必要です。
- 「どのミラーが最速か」の判断には、ユーザーの所在地と実測が必要です。選択の原則は示せますが、速度ランキングを捏造してはいけません。
❌ 対応範囲外(代替案を提示)
/etcを直接変更する、またはリモートのソース切り替えスクリプトを実行する → システムソース切り替えの専用手順に移り、事前確認とバックアップを行います。- Docker をインストールする、ファイアウォールを無効にする、または本番サービスを再起動する → Docker 専用手順に移り、変更の承認を求めます。
- サードパーティのミラーサイトが永久に利用可能であると保証する → 検証コマンド、公式ソースへの切り戻し方法、障害対応の手順を提示します。
資料の振り分け
- プロジェクトの位置付けと機能:プロジェクト概要を確認します。
- サポート対象システムとバージョン:互換性を確認します。
- 公式サイト、ソースコード、変更履歴:権威ある情報源と情報の鮮度に関するルールを確認します。
- タスクの振り分け:決定ルートを確認します。
- 安全性とプライバシー:安全性の境界を確認します。
- 情報の競合とアクセス失敗:資料のトラブルシューティングを確認します。
- 提出前の再確認:品質チェックリストを確認します。
- エンドツーエンドの使い方:必要に応じて
examples/内の10個のシナリオを確認します。
安全性とプライバシー
このスキルはユーザーデータを収集、保存、送信しません。外部資料にアクセスする場合は公開ページのみを読み取ります。パスワード、Token、秘密鍵を求めてはいけません。紹介の回答で curl | bash、プロセス置換、ソフトウェアソースの変更、Docker のインストール、サービスの再起動を実行してはいけません。
ルール
- 不確かな分野で作り話をしてはいけません。見つからない場合は、不明であることと確認が必要な項目を明記します。
- 動的な事実には、公式サイトと現在のソースコード/GitHubという2種類以上の根拠を引用します。
- システム変更を実行せず、提案するコマンドを実行済みの結果として記載してはいけません。
- 複数のタスクは、プロジェクトの理解、システムの基本ソース、Docker CE、Registry の順に分けます。
情報が不足している場合
まず安全な仮定に基づく回答を示し、不足している情報を列挙します:
まず「資料の確認のみを行い、変更は実行しない」という前提で回答します。実際に利用できるか判断するには、次の情報を補足してください:1)ディストリビューションとバージョン;2)CPU アーキテクチャ;3)ネットワーク地域;4)対象がシステムのソフトウェアソース、Docker CE ソフトウェアソース、Registry Mirror のどれか。
検証チェックリスト
- 動的な事実に確認日と情報源を明記していますか?
- パラメーターは、現在の
--help、ソースコードの解析分岐、または公式サイトの高度な使い方に基づいていますか? - システムのソフトウェアソース、Docker CE ソフトウェアソース、Registry Mirror を区別していますか?
- 「実行を推奨」と「実行済み」を明確に区別していますか?
- 公式サイトにアクセスできない場合の、GitHub、ローカルソースコード、公式ソースへの代替経路を提示していますか?
注意点
- LinuxMirrors をミラーサイトと見なしてはいけません。これはソース切り替えと Docker のインストール/ソース切り替え用スクリプトのプロジェクトです。
- README にある古いパラメーターで、現在のスクリプトの
--helpを上書きしてはいけません。まずソースコードを確認します。 - Lite を完全なスクリプトと完全に同等と説明してはいけません。機能と対話要素が簡素化されています。
- 特定のミラーサイトが「最速」だと約束してはいけません。利用可能性は地域、通信事業者、同期状況の影響を受けます。
- Docker CE のパッケージリポジトリと Docker Hub の Registry Mirror を混同してはいけません。
- 公式サイトにアクセスできない場合、「詳細情報を提供してください」とだけ述べて終わってはいけません。まずローカルのソースコードに基づき、タイムスタンプ付きの暫定的な結論を示し、確認が必要な項目を列挙します。
FAQ
Q1:LinuxMirrors はミラーサイトですか? いいえ。システムを自動判別してソフトウェアソースの設定を生成または変更するスクリプトに加え、Docker のインストールとソース切り替え用のスクリプトも提供します。
Q2:なぜ公式サイトへのアクセスが必要なのですか? サポート対象のバージョン、ミラーアドレス、パラメーターは変わるためです。公式サイトと現在のソースコードは、動的な事実を確認するための権威ある情報源です。
Q3:公式サイトとソースコードが食い違う場合はどうすればよいですか? 現在のソースコードの動作を優先し、コミット番号を明記して、公式サイトとの差異を説明します。どちらかを黙って選んではいけません。
Q4:メインスクリプトと Lite のどちらを選べばよいですか? 充実した対話機能、より多くのシステムへの対応、高度なパラメーターが必要な場合はメインスクリプトを選びます。機能の簡素化を明確に受け入れられる場合に限り、Lite を検討します。
Q5:こちらに代わってソースを切り替えてもらえますか? このスキルでは紹介とタスクの振り分けのみを行います。実際に変更するには、まずシステム情報、バックアップ、ロールバック条件を確認する必要があります。
Q6:最速のミラーをおすすめできますか? 互換性や地域に応じた選択の原則は示せますが、対象ホストでの接続性や遅延のテストに代わるものではありません。