en un clic
validate-oas
Use when you need a quick VALID or NOT VALID result for a scoped Kibana OAS area, and first ensure the generated `oas_docs` inputs are up to date so validation runs against the current environment rather than stale snapshots.
Menu
Use when you need a quick VALID or NOT VALID result for a scoped Kibana OAS area, and first ensure the generated `oas_docs` inputs are up to date so validation runs against the current environment rather than stale snapshots.
Basé sur la classification professionnelle SOC
Register and implement custom workflow steps from an external Kibana plugin using `@kbn/workflows-extensions`. Use when adding or modifying a step type with `registerStepDefinition`, designing input/output/config Zod schemas, implementing `createServerStepDefinition` / `createPublicStepDefinition`, choosing `StepCategory`, building `editorHandlers` (selection / dynamicSchema), wiring `callKibanaApi` / `onCancel`, deciding sync vs async loader registration, updating `APPROVED_STEP_DEFINITIONS`, or reviewing PRs that touch any of these.
Register and implement custom workflow triggers from an external Kibana plugin using `@kbn/workflows-extensions`. Use when adding or modifying an event-driven trigger with `registerTriggerDefinition`, designing `eventSchema` Zod schemas, writing `documentation` and KQL `snippets`, wiring `emitEvent` via request context or `getClient`, choosing sync vs async public loader registration, updating `APPROVED_TRIGGER_DEFINITIONS`, or reviewing PRs that touch any of these. Always ask for the user's plugin id first to locate the correct plugin and file paths.
Register and roll out managed workflows from a Kibana plugin using `@kbn/workflows-extensions` and `@kbn/workflows/managed`. Use when adding or modifying a code-owned workflow definition, `registerManagedWorkflowOwner`, `initManagedWorkflowsClient`, `install` / `uninstall` / `ready`, choosing `lifecycle` / `versionStrategy` / `enablement`, authoring `yaml` vs `yamlTemplate`, space-scoped vs global installs, `getWorkflowStatus`, or `execute`, or reviewing PRs that touch managed workflow definitions or rollout. Always ask for the user's plugin id first to locate the correct plugin and definition file paths.
Implement and quality-check OpenTelemetry metric instrumentation in Kibana code that uses `@kbn/metrics`. Use whenever the user wants to add, change, or review OTel metrics — including any call to `metrics.getMeter`, `meter.createCounter`/`createUpDownCounter`/`createGauge`/`createHistogram`/`createObservable*`/`addBatchObservableCallback`, edits to `kibana.yml` `telemetry.metrics` config, or questions like "is this metric well-designed?", "what should I name this counter?", or "which instrument type is right here?". Trigger this skill even when the user does not say "OTel" or "OpenTelemetry" but is clearly adding observability to Kibana server code and already knows what they want to measure.
Primary guided playbook for Elasticsearch search in Kibana Agent Builder: intent → data → mapping → Dev Tools API snippets (SENSE), with one question at a time. Load this skill whenever the user wants to learn Elasticsearch search, get started, begin building, take first steps, onboard, follow a walkthrough or tutorial, go from zero to a working query, or get structured help setting up indices and search — including casual openers like hi, help, getting started, new to Elasticsearch, how do I build search, or I want to try search. Use when they need end-to-end onboarding, not a single narrow API answer. If they only ask what they can build with Elastic (exploration without the full playbook), prefer invoking /use-case-library first; you can still load this skill afterward for the guided build.
Topic-driven, hands-on Elasticsearch tutorial flow that runs in Kibana Dev Console. Use whenever the user says "walk me through", "give me a tutorial for", "teach me", "show me how X works", "tutorial on", or similar topical learning intent — and they are NOT asking you to build their real, specific use case. Topics are open-ended: any Elasticsearch / Kibana search concept the user names (e.g. mappings, analyzers, bool queries, semantic_text, kNN, RRF, aggregations, ingest pipelines, reranking, data streams, ES|QL). Tutorials use sample data on isolated resources, present every step as a SENSE snippet to run in Dev Tools, and end with cleanup plus pointers to docs and the onboarding / pattern skills.
| name | validate-oas |
| description | Use when you need a quick VALID or NOT VALID result for a scoped Kibana OAS area, and first ensure the generated `oas_docs` inputs are up to date so validation runs against the current environment rather than stale snapshots. |
| user-invocable | true |
| disable-model-invocation | true |
Use node ./scripts/validate_oas_docs.js for a fast pass/fail check of a specific API area.
This skill is intentionally minimal:
VALID or NOT VALID.NOT VALID, mention the debug-oas skill for detailed issue debugging.debug-oas when the developer wants issue categorization or examples.Before validating, make sure the generated OAS artifacts in oas_docs are current. Treat stale generated files as an environment/setup problem, not a validation result.
Refresh the generated OAS inputs before validation when:
oas_docs may be stale after switching branches or pulling changesDo not refresh first when:
oas_docs in this session and no relevant inputs changed since thenRefresh flow:
yarn kbn bootstrap
node scripts/capture_oas_snapshot \
--include-path /api/status \
--include-path /api/alerting/rule/ \
--include-path /api/alerting/rules \
--include-path /api/actions \
--include-path /api/security/role \
--include-path /api/spaces \
--include-path /api/streams \
--include-path /api/fleet \
--include-path /api/saved_objects \
--include-path /api/maintenance_window \
--include-path /api/agent_builder \
--include-path /api/workflows \
--include-path /api/security/entity_store \
--include-path /api/dashboards \
--include-path /api/visualizations
bash .buildkite/scripts/steps/openapi_bundling/security_solution_openapi_bundling.sh
bash .buildkite/scripts/steps/openapi_bundling/final_merge.sh
cd oas_docs && make api-docs
After this refresh flow completes, run the scoped validation command.
Source of truth:
capture_oas_snapshot include-path list aligned with .buildkite/scripts/steps/checks/capture_oas_snapshot.sh..buildkite/scripts/steps/openapi_bundling/./api/fleet/agent_policies).oas_docs is up to date first when needed by following the environment setup flow above.--path filters with --only traditional by default and always include --skip-printing-issues.VALID, orNOT VALID (and mention debug-oas for details).Do not skip questions (1) and (2) unless the developer already provided the API paths.
Use normal route-style API paths for --path:
/api/fleet/agent_policies/api/fleet/agent_policies/{agentPolicyId}Do not manually convert to JSON pointers. The CLI handles conversion for error filtering internally.
Environment refresh:
yarn kbn bootstrap
node scripts/capture_oas_snapshot \
--include-path /api/status \
--include-path /api/alerting/rule/ \
--include-path /api/alerting/rules \
--include-path /api/actions \
--include-path /api/security/role \
--include-path /api/spaces \
--include-path /api/streams \
--include-path /api/fleet \
--include-path /api/saved_objects \
--include-path /api/maintenance_window \
--include-path /api/agent_builder \
--include-path /api/workflows \
--include-path /api/security/entity_store \
--include-path /api/dashboards \
--include-path /api/visualizations
bash .buildkite/scripts/steps/openapi_bundling/security_solution_openapi_bundling.sh
bash .buildkite/scripts/steps/openapi_bundling/final_merge.sh
cd oas_docs && make api-docs
Default scoped validation:
node ./scripts/validate_oas_docs.js --only traditional --skip-printing-issues --path <api_route_prefix>
Multiple path filters are supported:
node ./scripts/validate_oas_docs.js --only traditional \
--skip-printing-issues \
--path /api/fleet/agent_policies \
--path /api/fleet/agent_policies/{agentPolicyId}
Optional (only when explicitly requested):
node ./scripts/validate_oas_docs.js --only serverless --skip-printing-issues --path <api_route_prefix>
Default scoping note:
--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.Found 0 errors in ... -> VALIDFound N errors in ... where N > 0 -> NOT VALIDoas_docs, note that the result may reflect outdated generated inputs and refresh before concluding the spec is clean or broken.None of the provided --path filters matched any content), keep status as VALID but include an explicit warning.VALIDVALID (WARNING: no actual paths were matched.)NOT VALID. Use the debug-oas skill for detailed issues.Use exactly one of these responses:
VALID
VALID (WARNING: no actual paths were matched.)
NOT VALID. Use the debug-oas skill for detailed issues.