메뉴
Use when debugging OpenAPI (OAS) issues for a specific API area in Kibana by scoping validation output with one or more --path filters, then separating structural invalid-OAS failures from quality or documentation gaps such as missing descriptions.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/elastic/kibana --skill debug-oas명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
Investigate Scout and FTR flaky test failures in Kibana. Use when triaging a failed-test issue, a Buildkite-reported failure, a test path that has been failing intermittently, or any time the user asks to look at a flaky test, deflake a test, or stabilize a test.
Scaffold a new LLM evaluation suite package with Playwright config, evaluate fixture, and package files. Use when creating a new eval suite, adding an evals package for a plugin, or setting up the boilerplate for offline LLM evaluations.
Migrate Kibana Cypress E2E tests (.cy.ts) to Scout (Playwright). Applies to any Kibana plugin or solution. Includes triage gates (duplicate detection, layer analysis, value assessment), Cypress-to-Scout pattern mapping, data cleanup audit, and PR workflow. Use when: (1) migrating a Cypress test to Scout, (2) converting .cy.ts to .spec.ts, (3) planning a Cypress-to-Scout migration batch, (4) rewriting Cypress screens/tasks as Scout page objects, (5) asked "how do I move this Cypress test to Scout/Playwright", (6) asked about differences between Cypress and Scout.
SKILL.md 표시 중
SOC 직업 분류 기준
| name | debug-oas |
| description | Use when debugging OpenAPI (OAS) issues for a specific API area in Kibana by scoping validation output with one or more --path filters, then separating structural invalid-OAS failures from quality or documentation gaps such as missing descriptions. |
| user-invocable | true |
| disable-model-invocation | true |
Use node ./scripts/validate_oas_docs.js to validate Kibana OAS, but always scope output with --path so developers can focus on the API area they are actively changing.
Use this skill when the developer needs issue breakdown, categorization, or representative examples. For quick pass/fail only, use validate-oas first.
If results look stale or surprising, refresh generated OAS first using the environment setup flow in validate-oas. Treat stale oas_docs as a setup problem, not a debugging conclusion.
The validator can surface two broad categories of issues:
structural: invalid OAS problems that usually block correctness, such as schema violations, invalid shapes, unresolved references, or mismatches between path definitions and the spec structure.quality: documentation completeness problems such as missing description, summary, example, or .examplesWhen reporting results, always separate these categories. Lead with structural issues first.
/api/fleet/agent_policies).validate-oas.--path filters.structural vs quality.Do not skip questions (1) and (2) unless the developer already provided the API paths.
Use normal route-style API paths for --path (human-readable):
/api/fleet/agent_policies/internal/fleet/outputsDo not manually convert to JSON pointers. The CLI handles conversion for error filtering internally.
Multiple path filters are supported:
node ./scripts/validate_oas_docs.js \
--path /api/fleet/agent_policies \
--path /internal/fleet/outputs
Default scoped validation:
node ./scripts/validate_oas_docs.js --only traditional --path <api_route_prefix>
Scope to one offering when requested:
node ./scripts/validate_oas_docs.js --only traditional --path <api_route_prefix>
node ./scripts/validate_oas_docs.js --only serverless --path <api_route_prefix>
Default behavior:
--only traditional so validation runs against a single OAS output file.--only traditional by default because it matches the common local debugging path and keeps output narrower.--only serverless only when the developer explicitly asks for it.Optional structural-only summary when the raw output is noisy:
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
If the developer wants to keep documentation issues in that helper output:
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
Only use the helper summary as a supplement. Keep the raw validator output available for exact debugging.
Classify issues using these defaults:
quality:
descriptionsummaryexampleexamplesstructural:
Heuristic:
description, summary, example, or examples, treat it as quality.structural unless the developer explicitly asks for a finer split.Severity guidance:
structural = blocking invalid OASquality = docs completeness or polish problemsIf a run mixes both categories, report structural counts first, then quality counts.
If the initial scope is noisy, narrow in this order:
/api/fleet/api/fleet/epm/api/fleet/epm/packagesSuggest narrower scopes when one area dominates the structural issues.
Found N errors in ... as the source of truth for issue count.--path scope.Structural issues (invalid OAS): ...Quality issues (docs gaps): ...--skip-printing-issues) when debugging.--path prefix.When summarizing, use this shape:
Total issues: N
Structural issues: X
Quality issues: Y