用途：在 Kibana 中调试特定 API 区域的 OpenAPI（OAS）问题。核心做法是用 node ./scripts/validate_oas_docs.js 校验 OAS，并始终用 --path 限定输出范围，让开发者聚焦正在改动的 API 区域。需要问题分类或代表性示例时使用本技能；只需快速通过/失败时先用 validate-oas。若结果陈旧或异常，先按 validate-oas 的环境设置流程刷新生成的 OAS，把陈旧的 oas_docs 视为设置问题而非调试结论。
主要能力：校验器会暴露两类问题。structural 为通常阻断正确性的无效 OAS 问题，如 schema 违规、形状无效、未解析引用、路径定义与规范结构不匹配；quality 为文档完整性问题，如缺少 description、summary、example 或 examples。报告时始终分开两类，先列 structural。
使用方式：先询问开发者正在处理哪些 API，再询问一个或多个 HTTP API 路径（如 /api/fleet/agent_policies）；除非已提供路径，否则不要跳过这两步。需要时先刷新生成的 OAS，再用路由风格的 --path 过滤运行校验。默认命令：node ./scripts/validate_oas_docs.js --only traditional --path <api_route_prefix>。支持多个 --path。除非另有要求，默认加 --only traditional；仅在明确要求时用 --only serverless。--path 用普通路由风格路径，不要手动转成 JSON 指针，CLI 内部会转换。输出嘈杂时可选结构性摘要：node ./scripts/validate_oas_docs.js --only traditional --path <api_route_prefix> 2>&1 | node .agents/skills/debug-oas/scripts/extract_structural_oas_issues.js；需保留文档问题时加 --include-docs。该摘要仅作补充，仍保留原始输出用于精确调试。
分类与输出：默认把缺少 description、summary、example、examples 归为 quality，其余归为 structural。structural 视为阻断性无效 OAS，quality 视为文档完整性或打磨问题；混合时先报 structural 数量再报 quality。以 CLI 的 Found N errors in ... 为问题数依据。25 个及以内直接展示原始 CLI 输出；超过 25 个则总结主要模式并建议更窄的 --path。缩小范围顺序：/api/fleet → /api/fleet/epm → /api/fleet/epm/packages。调试时优先完整输出（不要用 --skip-printing-issues）。若所选路径无问题，建议放宽或调整 --path 前缀；若只剩 quality 问题，明确说明剩余工作是文档方向。
限制：资料未提供该技能支持的 Kibana 版本、依赖环境细节及除上述脚本外的其他能力。