/kibana-workflows

name: kibana-workflows
description: >
  Author, validate, test, run, and inspect Elastic Workflow YAML definitions. Use
  when the user wants to turn natural language into a Kibana workflow, fix workflow
  YAML, understand triggers or steps, or run a quick test loop against a real Kibana.
metadata:
  author: elastic
  version: 0.5.0
  universal: true
compatibility: Kibana 9.4 or later with matching Elasticsearch and an Enterprise license,
  or an Elastic Serverless project with Workflows available; requires the `elastic`
  CLI ≥ 0.2 with `stack kb workflows` support. When Agent Builder is enabled on the
  target Kibana, the `platform.core.generate_workflow` and `platform.workflows.*`
  tools are preferred over the raw schema.

Author Elastic Workflows

Create and iterate on Elastic Workflow YAML definitions. Workflows are declarative automations that run inside Kibana: they query Elasticsearch, set data, branch, loop, call connectors, create cases, notify external systems, and invoke AI steps.

<!-- begin-partial: preamble -->

Environment Configuration

This skill executes Elasticsearch operations through the `elastic` CLI. If the [`elastic` CLI](https://github.com/elastic/cli#configuration) is not installed, tell the user what it is needed for. Do not guess credentials, call the HTTP API directly, or attempt other workarounds.

This skill references operations in HTTP-shorthand form (e.g., `GET /`, `GET /_cat/indices`, `GET /{index}/_mapping`, `GET /{index}/_settings/index.mode`, `POST /_query`). The [Operations](#operations) table at the end of this document maps each shorthand to the equivalent `elastic` CLI command — always use the CLI rather than calling the HTTP API directly.

<!-- end-partial: preamble -->

If the user asks only for a draft or explanation and explicitly forbids live access, skip connection verification and do not call the CLI or APIs. State that the draft was not validated against a target deployment.

If workflow APIs are unavailable, report the returned status and message. Common causes are an unsupported Kibana version, insufficient license or feature privileges, or Workflows not being offered on the target project. The `workflows:ui:enabled` setting controls the Kibana UI; it does not remove the public Workflows APIs.

Pick the authoring path

Default to the **Discovery-tools path** below — the `platform.workflows.*` tools are registered by default on Kibana 9.5+ and Serverless. Confirm with one probe: `GET kbn:/api/agent_builder/tools` returns `{ "results": [ { "id": ... } ] }`; save it to a file and grep for `"id": "platform.workflows."`. Two fallbacks, both loaded only when needed:

• No `agent_builder` endpoint (404) or no `platform.workflows.*` ids (e.g. Kibana 9.4) → read

[references/schema-path.md](references/schema-path.md) and hand-author from the raw JSON Schema.

• An LLM connector is wired into Agent Builder and the user prefers Kibana's own generator → read

[references/generator-path.md](references/generator-path.md).

State which path you picked and why in one sentence before proceeding. Measured path benchmarks live in [references/path-performance.md](references/path-performance.md).

Guidelines (all paths)

• **Treat tests as executions.** `POST kbn:/api/workflows/test` runs the workflow graph, and

`POST kbn:/api/workflows/step/test` runs the selected step. Test only when every executed action is read-only or the user authorized its effects. Otherwise test a copy whose writes, notifications, and external calls are replaced with `console`, then restore the real steps and save the workflow disabled.

• **Cite endpoints in HTTP shorthand, never raw transport.** This skill's body refers to operations like

`POST kbn:/api/workflows/test`. The [Operations](#operations) table is the single place where shorthand binds to a concrete CLI command.

• **Prefer purpose-built actions over generic `http`.** For Slack/Jira/PagerDuty/etc., prefer the connector step type

(e.g. `slack2.sendMessage`) over a raw `http` call. Discover the exact action type via `get_step_definitions` (or the strict schema on the fallback path).

• **Reference step outputs as `steps.<name>.output`, never `steps.<name>.with.*`.** Trigger event data is `event`, never

`trigger.event` or `triggers.event`.

• **Don't guess connector ids.** Call `platform.workflows.get_connectors` (Discovery-tools path) or

`GET kbn:/api/workflows/connectors` (Schema path), or ask the user. Placeholders should be obviously fake.

• **Handle failure deliberately.** Add retry or fallback behavior where the user's requirements call for resilience. Do

not add `continue: true` everywhere: it can hide a failed action and allow the workflow to report false success.

• **Surface gates, don't paper over them.** If the API returns `403 ... not available`, report the required license or

privileges; do not silently retry or blame the UI setting.

Discovery-tools path

Use when `platform.workflows.*` tools are registered on the target Kibana. All calls go through `POST kbn:/api/agent_builder/tools/_execute` with `{ "tool_id": "...", "tool_params": { ... } }`. Response shape: `{ "results": [ { "type": "other", "data": { ... }, "tool_result_id": "..." } ] }` — the payload you want is `.results[0].data`. Send the request body from a file and write the response to a file (see [Operations](#operations)), then jq against that file; do not inline `python3 -c` on multi-line JSON.

**Keep context small; minimize round-trips.** Do NOT front-load the whole step catalog — pull only the targeted details you need, keep large tool output in files (not the transcript), and author in as few turns as possible (measured rationale: [references/path-performance.md](references/path-performance.md)).

1. **Capture the user's intent before writing YAML.** Identify, in order, the trigger (`manual` / `scheduled` / `alert`), the inputs the workflow will receive at runtime, the data sources it must read,