Dynamo 部署故障排查
按证据定位不健康的 Dynamo Kubernetes 部署。
证据显示技能明确要求只读采集、不读取 Secret、不打印 Hugging Face token，并通过最小可逆变更和本地脱敏降低风险；但执行前没有明确的用户确认或集群上下文确认，脚本会写入本地调试文件，脱敏规则无法保证覆盖所有敏感信息，且权限边界与数据流披露仍不完整，因此扣10分。
说明、决策树和脚本的主要路径基本一致，脚本包含超时、命令不存在和返回码记录；但 kubectl JSON 失败会静默转为空结果，继续流程，缺少结构化失败反馈，文档中的 --output-dir 与脚本实际的 --outdir 不一致，且未静态证明关键路径可运行。按静态校准不超过10分，扣2分。
目标场景、故障分类、排除范围以及与 recipe-runner、router-starter、interconnect-check 的边界较清楚，评测用例还覆盖正向和负向触发；但对集群版本、Dynamo 版本、权限差异和非 Kubernetes 环境的边界说明有限，没有中文交互支持说明，环境适配证据不足，因此扣4分。
文档包含用途、前置条件、脚本参数、示例、输出契约、限制、故障排查、参考资料和 Apache-2.0 标注，且 skill-card 提供责任方与版本线索；但版本来源未在给定技能目录中验证，缺少明确 changelog 和维护更新路径，存在重复内容，BENCHMARK 报告为 FAIL，另有意外的 skill-card.md 结构问题，因此扣8分。
技能提供从证据收集到故障分类、最强信号和下一步动作的完整框架，脚本输出摘要及命令结果，核心任务具有直接实用性；但 benchmark 总体 FAIL，Tier 3 结果缺失，脚本可能静默漏采集，部分修复建议依赖用户自行验证，且静态评估不能证明实际结果正确。按静态上限7分，扣1分。
给定材料包含脚本源码、决策树、评测用例和静态评估报告，关键声明可追溯，静态发现也暴露了安全与重复内容问题；但没有真实 CI 测试覆盖该技能、没有 Tier 3 执行证据，也没有跨环境复现或第三方 corroboration。按静态上限5分，已给上限。
- 执行前确认当前 kubectl context、目标 namespace 和最小只读 RBAC；不要把调试 bundle 上传到不受信任位置。
- 修复并统一 --output-dir/--outdir 参数，避免脚本失败时静默生成不完整结论。
- 重新运行覆盖该技能关键路径的 CI/实时评测，并处理报告中的 least-privilege、重复内容和意外文件问题。
这个 Skill 能做什么，适合哪些场景？
该技能用于诊断失败或不健康的 NVIDIA Dynamo 部署，覆盖模型缓存、PVC、工作节点、前端或路由器、端点及基准测试作业。它先收集只读证据，再将问题归入平台、存储、镜像、GPU、控制器、服务或性能等类别，并按自上而下的顺序缩小范围。技能只返回修复命令或补丁，不直接修改集群。正常部署启动应先使用 recipe-runner 或 router-starter。
在指定命名空间运行 scripts/collect_dynamo_debug_bundle.py，收集 Pod、事件、作业、PVC 和 DynamoGraphDeployment 状态；随后检查命名空间、存储类、GPU 节点、HF Secret 是否存在、PVC 和模型下载作业、部署状态与事件、Pod 描述和容器日志、前端服务、/v1/models 及 /v1/chat/completions。它使用 references/failure-decision-tree.md 进行故障分类，并输出问题类别、已检查证据、最强信号、可能原因、确切下一条命令或补丁、已排除项，以及是否可以继续部署或基准测试。不会收集 Secret 或打印 Hugging Face token。
- 负责 Kubernetes 运维的用户遇到 Dynamo Pod、事件或作业失败时，用它收集只读诊断证据并确定问题层级。
- 部署人员发现模型下载作业 Pending、PVC 未绑定或 HF Secret 缺失时，用它定位模型缓存路径。
- GPU 平台运维人员遇到 Worker CrashLoopBackOff 或 GPU 调度失败时，用它检查运行时镜像和 GPU 可用性。
- Dynamo 部署人员在进行端点验证或基准测试前，用它确认前端、路由器和 API 是否已就绪。
这个 Skill 有哪些优点和局限？
- 以只读证据为起点，明确禁止收集 Secret 和打印 Hugging Face token。
- 覆盖 Kubernetes、PVC、模型下载、GPU、DynamoGraphDeployment、前端、API 和基准作业等多个故障层。
- 规定了从基础设施到端点、再到基准测试的排查顺序，并要求每次只修复一层。
- 提供可直接运行的诊断脚本和结构化输出契约。
- 需要 Python 3.10+、kubectl、目标命名空间读取权限及集群 API 网络连通性。
- 只读设计意味着修复命令或补丁需要用户自行检查和执行。
- 不会收集 Secret，因此部分认证故障需要用户侧检查。
- 未提供具体平台兼容矩阵、测试套件或性能数据；大型命名空间还可能产生较大的诊断包。
如何安装这个 Skill？
使用仓库 README 中的 skills CLI：
npx skills add nvidia/skills --skill dynamo-troubleshoot --yes
README 未说明具体安装目录；CLI 会提示选择安装目的地。
如何使用这个 Skill？
向已加载该技能的 Agent 提出与 Dynamo 故障排查相关的请求，例如：“Diagnose why my Dynamo deployment is unhealthy.” 正常 bring-up 应先使用 dynamo-recipe-runner 或 dynamo-router-starter。排查时需要先设置命名空间并运行：
python3 scripts/collect_dynamo_debug_bundle.py --namespace "${NAMESPACE}"
若要限定部署，可追加 --deployment-name <deployment-name>。也可通过 agentskills.io 的 run_script() 协议调用该脚本。技能返回修复命令或补丁，但不会执行集群变更。
这个 Skill 与同类方案有什么区别？
该技能专注于部署后的 day-2 故障排查；README 将 dynamo-recipe-runner 和 dynamo-router-starter 定位为正常 bring-up 工具，将 dynamo-interconnect-check 定位为 disagg transport 验证工具。SKILL.md 明确表示，本技能不验证 disagg transport。