mcpskills.net
技能MCP智能体提示词
mcpskills.net — A curated directory of AI agent Skills and MCP servers
TermsPrivacy
← 返回技能
DevOps

linuxmirrors-awesome

介绍 LinuxMirrors 的定位、能力、支持范围、源码与权威资料,并在回答项目现状、兼容性、脚本差异、最新变化或资料来源时先核验官网、GitHub 和当前源码。用于认识项目和选择正确工作流;系统软件源实操或 Docker 安装换源应进入对应专项流程,不用本技能替代变更方案。

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. 保证第三方镜像站永久可用 → 提供验证命令、官方源回退和故障排查路径。

资料路由

  • 项目定位与能力:读项目概览。
  • 支持系统与版本:读兼容性。
  • 官网、源码和更新日志:读权威来源与新鲜度规则。
  • 任务分流:读决策路由。
  • 安全与隐私:读安全边界。
  • 信息冲突与访问失败:读资料排障。
  • 交付前复核:读质量清单。
  • 端到端用法:按需读取 examples/ 中的十个场景。

安全与隐私

本技能不收集、存储或传输用户数据。访问外部资料时只读取公开页面;不得要求密码、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:能推荐最快镜像吗? 可给兼容性与区域选择原则,但不能替代目标主机的连通性和延迟测试。