在您提交issue前，请确认以下信息：

• 我已经搜索过现有和历史issues，确认这是一个新需求

背景信息

Motor 部署、验证与诊断 Agent Skills 已由 Issue #528 和 PR #833 建立基础框架，其中motor-diagnosis 负责保存首次失败现场，motor-diagnosis-startup 负责对 deploy/startup失败进行 environment、deployer、config 和 runtime-code 分类。
当前启动诊断仍缺少面向具体故障域的原子 Skill。在 Motor + vLLM + vLLM-AscendPD 分离部署的日常开发验证中，以下问题仍主要依赖人工执行命令并分析日志：

• Kubernetes API、RBAC、admission、调度、镜像拉取、存储挂载、容器启动、probe、Service selector 和 Endpoint 异常；
• Controller/Coordinator readiness、HA 主备角色、NodeManager 注册与重注册、心跳、实例刷新及 prefill/decode 拓扑未收敛；
• curl 无法建立 HTTP 连接时的 DNS、TCP、TLS、ClusterIP、NodePort、node IP、Service port/targetPort 和 kubectl port-forward 问题。
  这些场景的表面现象可能相同。例如 Readiness probe failed 既可能来自容器没有启动，也可能来自网络连接失败，还可能是 Coordinator 已返回 HTTP 但控制面尚未就绪。缺少明确路由边界时，Agent 容易将 K8s 状态直接当作根因，或者用重试覆盖首次失败现场。
  本需求拟在现有诊断 Skill family 下增加 K8s、控制面和服务连通性三个原子诊断 Skill。

需求来源

来源于 Motor PD 分离推理服务的日常开发、部署验证和启动失败定位过程。
首期范围只覆盖 Motor + vLLM + vLLM-Ascend，不扩展 MindIE-LLM、SGLang 或通用engine adapter。Skill 只提供开发、验证和只读诊断自动化，不新增第二套部署系统。

价值/作用

1. 将 Kubernetes 部署拉起问题按 apply、调度、镜像与存储、容器、probe 和 ServiceEndpoint 阶段完成定界。
2. 将控制面未就绪问题沿 NodeManager、Controller、Coordinator 的注册、心跳、刷新和P/D 拓扑链路完成定界。
3. 将“curl 不通”细分为 DNS、TCP、TLS、Service/Endpoint、端口映射和客户端访问方式，
   避免把所有连接错误归因于 Motor。
4. 统一 environment、deployer、config 和 runtime-code 四类归因口径。
5. 统一输出失败阶段、证据链、已排除项、置信度和最小下一步排查命令。
6. 保持只读诊断边界，不自动 retry、restart、repair、修改配置或注入故障。

设计方案

1. 基于 PR #833 建立的 .agents/skills/ 平铺式 Skill family 扩展，不引入新的Python 路由器或仓外执行框架。
2. 新增 motor-diagnosis-k8s：
   • 覆盖 K8s API/RBAC/admission、资源未创建、Pending、调度、镜像、挂载、容器、CrashLoopBackOff、probe、Service selector 和 Endpoint；
   • 关联 deployer 输出、rendered YAML、live 对象、Events、容器状态和日志；
   • 输出最早失败阶段及 environment/deployer/config/runtime-code 分类。
3. 新增 motor-diagnosis-control-plane：
   • 覆盖 Controller/Coordinator readiness、HA 主备角色、注册/重注册、心跳、实例刷新和 prefill/decode 拓扑收敛；
   • 明确 standby 的 Not master 可能是预期保护行为，不能单独判断为故障；
   • 沿 NodeManager → Controller → Coordinator 控制链收集时间化证据。
4. 新增 motor-diagnosis-connectivity：
   • 覆盖 curl 的 DNS、TCP、TLS、timeout、connection refused/reset、ClusterIP、NodePort、Service port/targetPort、EndpointSlice 和 port-forward；
   • 一旦已经获得 HTTP 响应，停止使用连通性 Skill；
   • ready=false/503 转到控制面诊断，推理 HTTP 4xx/5xx 转到功能或运行时分析。
5. 更新 motor-diagnosis 和 motor-diagnosis-startup，通过相对路径将对应失败场景路由到三个原子 Skill。
6. 所有 Skill 保持只读诊断边界，不自动 apply、patch、delete、restart、scale、config edit、主备切换或故障注入。
   本需求是 Issue #528 诊断能力的领域化补充，并基于 PR #833 的 Skill family 结构开发。

感谢您的贡献 🎉!