
Debug Oas
- 2 installs
- 21.2k repo stars
- Updated August 5, 2026
- elastic/kibana
debug-oas skill documents 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 quali
About
debug-oas skill documents 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.. 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.
- Use when debugging OpenAPI (OAS) issues for a specific API area in Kibana by scoping validation output with one or more
- Platform-specific setup patterns for debug-oas.
- Evidence-backed steps from upstream SKILL.md.
- When-to-use criteria for debug-oas versus alternatives.
Debug Oas by the numbers
- 2 all-time installs (skills.sh)
- Ranked #1,786 of 2,203 Security skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
debug-oas capabilities & compatibility
- Capabilities
- debug oas quick start · debug oas when to use guidance · debug oas integration patterns
- Works with
- elasticsearch
- Use cases
- security audit
What debug-oas says it does
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.
npx skills add https://github.com/elastic/kibana --skill debug-oasAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 2 |
|---|---|
| repo stars | ★ 21.2k |
| Last updated | August 5, 2026 |
| Repository | elastic/kibana ↗ |
How do I use debug-oas correctly?
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
Who is it for?
Teams implementing debug-oas workflows from the catalog.
Skip if: Skip when requirements clearly match a different specialized stack.
When should I use this skill?
User asks about debug-oas, use when debugging openapi (oas) issues for a specific api area in kibana by scoping valid.
What you get
Working debug-oas setup with validated configuration and next steps.
Files
Debug OAS
Overview
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 missingdescription,summary,example, orexamples.
When reporting results, always separate these categories. Lead with structural issues first.
Required interaction flow
1. Ask what APIs the developer is working on. 2. Ask for one or more HTTP API paths (for example /api/fleet/agent_policies). 3. Refresh generated OAS first when needed by following the environment setup flow in validate-oas. 4. Run validation with those route-style --path filters. 5. Classify the resulting issues into structural vs quality. 6. Display the command output directly so the developer can see current issues.
Do not skip questions (1) and (2) unless the developer already provided the API paths.
Path format guidance
Use normal route-style API paths for --path (human-readable):
/api/fleet/agent_policies/internal/fleet/outputs
Do 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/outputsCommands
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:
- Unless the developer asks otherwise, always include
--only traditionalso validation runs against a single OAS output file. - Prefer
--only traditionalby default because it matches the common local debugging path and keeps output narrower. - Use
--only serverlessonly 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.jsIf 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-docsOnly use the helper summary as a supplement. Keep the raw validator output available for exact debugging.
Issue categorization
Classify issues using these defaults:
quality:- missing
description - missing
summary - missing
example - missing
examples structural:- everything else by default
- examples include invalid schemas, type mismatches, missing required non-doc fields, invalid parameter definitions, unresolved refs, or malformed response/request structures
Heuristic:
- If the message is a docs-completeness complaint about
description,summary,example, orexamples, treat it asquality. - Otherwise treat it as
structuralunless the developer explicitly asks for a finer split.
Severity guidance:
structural= blocking invalid OASquality= docs completeness or polish problems
If a run mixes both categories, report structural counts first, then quality counts.
Scope narrowing
If the initial scope is noisy, narrow in this order:
- start with a broad product area such as
/api/fleet - narrow to a feature area such as
/api/fleet/epm - narrow again to a route family such as
/api/fleet/epm/packages
Suggest narrower scopes when one area dominates the structural issues.
Output behavior
- Use the CLI line
Found N errors in ...as the source of truth for issue count. - If the run has 25 or fewer issues, show the exact CLI output with no summarization.
- If the run has more than 25 issues, summarize key patterns and suggest a narrower
--pathscope. - When summarizing, include:
- structural issue count
- quality issue count
- a few issues copied verbatim from CLI output, ideally one sample per dominant category
- When summarizing, use language like:
Structural issues (invalid OAS): ...Quality issues (docs gaps): ...- Prefer full issue output (do not use
--skip-printing-issues) when debugging. - If no issues are shown for the selected path, suggest widening or adjusting the
--pathprefix. - If only quality issues remain, say that explicitly so the developer knows the remaining work is documentation-oriented rather than structural.
Output template
When summarizing, use this shape:
Total issues: N
Structural issues: X
Quality issues: Y#!/usr/bin/env node
/*
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
* or more contributor license agreements. Licensed under the "Elastic License
* 2.0", the "GNU Affero General Public License v3.0 only", and the "Server Side
* Public License v 1"; you may not use this file except in compliance with, at
* your election, the "Elastic License 2.0", the "GNU Affero General Public
* License v3.0 only", or the "Server Side Public License, v 1".
*/
require('@kbn/setup-node-env');
var Fs = require('node:fs');
var Path = require('node:path');
var DOC_MESSAGE_PATTERNS = [
/required property 'example'/,
/required property 'examples'/,
/required property 'description'/,
/required property 'summary'/,
];
main();
function main() {
var args = parseArgs(process.argv.slice(2));
readInput(args.inputPath)
.then(function (input) {
var parsedIssues = parseIssues(input);
var filteredIssues = parsedIssues.filter(function (issue) {
return args.includeDocs || !isDocumentationIssue(issue.message);
});
var groupedIssues = groupByMessage(filteredIssues);
printSummary({
inputPath: args.inputPath,
parsedIssues: parsedIssues,
filteredIssues: filteredIssues,
groupedIssues: groupedIssues,
json: args.json,
});
})
.catch(function (error) {
console.error(error instanceof Error ? error.message : String(error));
process.exit(1);
});
}
function parseArgs(argv) {
var parsed = {
includeDocs: false,
inputPath: null,
json: false,
};
var index;
for (index = 0; index < argv.length; index += 1) {
var arg = argv[index];
if (arg === '--help' || arg === '-h') {
printHelp();
process.exit(0);
}
if (arg === '--include-docs') {
parsed.includeDocs = true;
continue;
}
if (arg === '--json') {
parsed.json = true;
continue;
}
if (arg.startsWith('-')) {
printHelp('Unknown argument "' + arg + '"');
process.exit(1);
}
if (parsed.inputPath !== null) {
printHelp('Only one input path may be provided.');
process.exit(1);
}
parsed.inputPath = arg;
}
return parsed;
}
function printHelp(errorMessage) {
if (errorMessage) {
console.error(errorMessage);
console.error('');
}
console.log(`Extract structural OAS issues from validate_oas_docs output.
Usage:
node .agents/skills/debug-oas/scripts/extract_structural_oas_issues.js [validate-output.txt]
node scripts/validate_oas_docs.js --only traditional 2>&1 | node .agents/skills/debug-oas/scripts/extract_structural_oas_issues.js
Options:
--include-docs Keep example/description/summary issues in the output.
--json Print machine-readable JSON.
`);
}
function readInput(inputPath) {
if (inputPath) {
return Promise.resolve(Fs.readFileSync(Path.resolve(inputPath), 'utf8'));
}
if (process.stdin.isTTY) {
printHelp('Provide a path to saved CLI output or pipe input on stdin.');
process.exit(1);
}
return new Promise(function (resolve, reject) {
var chunks = [];
process.stdin.setEncoding('utf8');
process.stdin.on('data', function (chunk) {
chunks.push(chunk);
});
process.stdin.on('end', function () {
resolve(chunks.join(''));
});
process.stdin.on('error', reject);
});
}
function parseIssues(input) {
var issues = [];
var lines = stripAnsi(input).split(/\r?\n/);
var currentPath = null;
var currentMessage = null;
var currentSchemaPath = null;
var index;
function flushIssue() {
if (!currentPath || !currentMessage) {
currentPath = null;
currentMessage = null;
currentSchemaPath = null;
return;
}
issues.push({
path: currentPath,
message: currentMessage,
schemaPath: currentSchemaPath,
});
currentPath = null;
currentMessage = null;
currentSchemaPath = null;
}
for (index = 0; index < lines.length; index += 1) {
var content = normalizeIssueLine(lines[index]);
if (!content) {
flushIssue();
continue;
}
if (content.startsWith('/')) {
flushIssue();
currentPath = content;
continue;
}
if (!currentPath) {
continue;
}
if (content.startsWith('Failed check @ schema path:')) {
currentSchemaPath = content.slice('Failed check @ schema path:'.length).trim();
flushIssue();
continue;
}
if (currentMessage === null) {
currentMessage = content;
continue;
}
}
flushIssue();
return issues;
}
function normalizeIssueLine(line) {
var match = line.match(/^\s*│\s*(.*)$/);
var content = match ? match[1] : line;
return content.trim();
}
function stripAnsi(value) {
return value.replace(/\u001B\[[0-9;]*m/g, '');
}
function isDocumentationIssue(message) {
return DOC_MESSAGE_PATTERNS.some(function (pattern) {
return pattern.test(message);
});
}
function groupByMessage(issues) {
var groups = {};
var sortedEntries;
var index;
for (index = 0; index < issues.length; index += 1) {
var issue = issues[index];
if (!groups[issue.message]) {
groups[issue.message] = [];
}
groups[issue.message].push(issue);
}
sortedEntries = Object.entries(groups).sort(function (left, right) {
if (right[1].length !== left[1].length) {
return right[1].length - left[1].length;
}
return left[0].localeCompare(right[0]);
});
return sortedEntries;
}
function printSummary(options) {
var result = {
inputPath: options.inputPath || '(stdin)',
parsedIssueCount: options.parsedIssues.length,
structuralIssueCount: options.filteredIssues.length,
uniqueStructuralMessages: options.groupedIssues.length,
issuesByMessage: options.groupedIssues.map(function (entry) {
return {
message: entry[0],
count: entry[1].length,
paths: entry[1].map(function (issue) {
return issue.path;
}),
};
}),
};
if (options.json) {
console.log(JSON.stringify(result, null, 2));
return;
}
console.log('Input: ' + result.inputPath);
console.log('Parsed issues: ' + result.parsedIssueCount);
console.log('Structural issues: ' + result.structuralIssueCount);
console.log('Unique structural messages: ' + result.uniqueStructuralMessages);
if (result.structuralIssueCount === 0) {
console.log('');
console.log('No structural issues found.');
return;
}
console.log('');
result.issuesByMessage.forEach(function (entry) {
console.log(entry.count + 'x ' + entry.message);
entry.paths.forEach(function (issuePath) {
console.log(' - ' + issuePath);
});
console.log('');
});
}
Related skills
FAQ
What does debug-oas do?
debug-oas skill documents 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.
When should I use debug-oas?
User asks about debug-oas, use when debugging openapi (oas) issues for a specific api area in kibana by scoping valid.
Is this skill safe to install?
Review the Security Audits panel on this page before installing in production.