mcpField
L
linuxmirrors-awesome

linuxmirrors-awesome

github.com/full-stack-skills云与 DevOps146 次安装4 周前更新
代码仓库

关于 linuxmirrors-awesome

面向 LinuxMirrors 项目用户、运维人员和文档维护者的资料核验与任务路由技能。它帮助解释项目及脚本差异、核查动态信息,并将系统换源和 Docker 变更导向相应流程,而不直接执行变更。

主要功能

  1. 01核验项目与脚本信息
  2. 02比较主脚本和 Lite
  3. 03检查官网与当前源码
  4. 04区分系统源、Docker 源与 Registry
  5. 05变更任务安全路由

适用场景

  1. 01了解 LinuxMirrors 的定位与能力
  2. 02核对支持系统和最新变化
  3. 03判断应使用主脚本还是 Lite
  4. 04规划换源或 Docker 任务路径

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/full-stack-skills/devops-skills --skill linuxmirrors-awesome

安装后在 Claude Code 中输入/linuxmirrors-awesome确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

evaluation-report.html
LICENSE.txt
agents/
openai.yaml
examples/
01-project-introduction.md
02-latest-capabilities.md
03-main-vs-lite.md
04-route-ambiguous-request.md
05-source-conflict.md
06-os-compatibility.md
07-mirror-selection.md
08-security-review.md
09-cicd-fit.md
10-offline-research.md
references/official/
compatibility.md
freshness.md
project-overview.md
sources.md
references/operations/
quality-checklist.md
routing.md
security.md
troubleshooting.md

详细介绍

来自项目 README

LinuxMirrors 权威指南

Quick Start

先判断问题是“了解项目”还是“执行变更”。介绍、能力、兼容性、最新变化与资料核验留在本技能;系统软件源变更或 Docker 变更只给任务路由,不直接拼装生产命令。

可直接使用:

  • “介绍 LinuxMirrors,并说明它与普通镜像站列表的区别。”
  • “核验 LinuxMirrors 当前支持哪些系统,引用官网与源码。”
  • “比较主脚本和 Lite 脚本,告诉我该选哪个。”

什么时候使用

当用户要了解 LinuxMirrors、核验最新项目事实、比较脚本或判断任务路径时使用。若用户要求实际换系统源、安装 Docker 或修改 Registry,则只完成资料核验与路由,不在本技能内执行变更。

适用用户

  • 新手:先读项目定位与三条任务路径。
  • 运维人员:重点读取新鲜度、兼容性、安全与路由资料。
  • Skill/文档维护者:使用来源索引和质量清单验证事实与引用。

工作流

Step 1:识别意图

区分项目介绍、最新信息、系统换源、Docker 安装、Registry Mirror 或源码分析。

Step 2:检查时效

记录访问日期;动态事实至少核验官网和 GitHub/当前源码两类来源。

Step 3:定位资料

按权威来源读取官网、文档、仓库、更新日志和安全公告。

Step 4:交叉验证

用新鲜度规则处理官网、README 与源码差异,禁止凭记忆补全。

Step 5:组织回答

先给结论,再给适用条件、证据链接、风险和下一步任务路由。

Step 6:自检输出

执行质量清单,确保没有把文档说明误写成已执行结果。

能力边界与不适用场景

✅ 擅长处理
  1. 解释 LinuxMirrors 的项目定位、两类脚本、开源许可与典型用户。
  2. 基于官网和源码核验支持系统、参数、主脚本/Lite 差异及最新提交。
  3. 判断需求应进入系统软件源、Docker CE 软件源或 Registry Mirror 流程。
⚠️ 需要条件
  1. “是否支持我的机器”需要发行版、版本、架构和网络区域。
  2. “最新版本有什么变化”需要可访问官网或 GitHub,并标注核验时间。
  3. “哪个镜像最快”需要用户位置与实测;只能给选择原则,不能虚构测速排名。
❌ 超出范围(给替代方案)
  1. 直接修改 /etc 或运行远程换源脚本 → 转入系统换源专项流程并先做预检与备份。
  2. 安装 Docker、关闭防火墙或重启生产服务 → 转入 Docker 专项流程并要求变更授权。
  3. 保证第三方镜像站永久可用 → 提供验证命令、官方源回退和故障排查路径。

资料路由

安全与隐私

本技能不收集、存储或传输用户数据。访问外部资料时只读取公开页面;不得要求密码、Token 或私钥。不要在介绍性回答中执行 curl | bash、进程替换、软件源修改、Docker 安装或服务重启。

Rules

  1. 禁止在不确定领域胡编;查不到就标记未知和待核验项。
  2. 动态事实至少引用官网与当前源码/GitHub 中的两类证据。
  3. 不执行系统变更,不把建议命令写成已执行结果。
  4. 多任务按项目理解、系统基础源、Docker CE、Registry 的顺序拆分。

信息不足时

先给安全假设版本,再列缺失信息:

先按“仅做资料核验、不执行变更”回答。若要判断实际可用性,请补充:1)发行版与版本;2)CPU 架构;3)网络区域;4)目标是系统软件源、Docker CE 软件源还是 Registry Mirror。

验证清单

  • 动态事实是否注明核验日期和来源?
  • 参数是否来自当前 --help、源码解析分支或官网高级用法?
  • 是否区分系统软件源、Docker CE 软件源和 Registry Mirror?
  • 是否把“建议执行”与“已经执行”明确分开?
  • 是否提供无法访问官网时的 GitHub、本地源码或官方源降级路径?

Gotchas

  1. 不要把 LinuxMirrors 当作镜像站;它是换源与 Docker 安装/换源脚本项目。
  2. 不要用 README 的旧参数覆盖当前脚本 --help;先核验源码。
  3. 不要把 Lite 解释为完整脚本的完全等价物;它会精简功能与交互。
  4. 不要承诺某镜像站“最快”;可用性受地区、运营商和同步状态影响。
  5. 不要把 Docker CE 软件包仓库与 Docker Hub Registry Mirror 混为一谈。
  6. 官网不可达时不要停止在“请提供更多信息”;先基于本地源码给带时间戳的暂定结论并列出待核验项。

FAQ

Q1:LinuxMirrors 是镜像站吗? 不是。它提供自动识别系统并生成或修改软件源配置的脚本,也提供 Docker 安装与换源脚本。

Q2:为什么必须访问官网? 支持版本、镜像地址和参数会变化;官网与当前源码是动态事实的权威入口。

Q3:官网与源码冲突怎么办? 优先当前源码行为,标注提交号,并说明官网差异;不要静默选择。

Q4:主脚本还是 Lite? 需要完整交互、更多系统与高级参数时选主脚本;只在明确接受精简能力时考虑 Lite。

Q5:能直接替我换源吗? 本技能只做介绍和路由。实际变更必须先收集系统信息、备份和回滚条件。

Q6:能推荐最快镜像吗? 可给兼容性与区域选择原则,但不能替代目标主机的连通性和延迟测试。

评论

支持 Markdown