Skip to content
Agentmart
Submit a tool

kibana-workflows

Author, validate, test, run, and inspect Elastic Workflow YAML definitions.

Skill by elasticOfficial

IndexedApache-2.0★ 600
Write a review

Install

Works with Claude Code, Claude apps, Codex, Cursor, Gemini CLI, GitHub Copilot, VS Code, OpenCode, Goose, Windsurf. Read the repository before you give any tool access to your data.

npx agentmarket install skill/elastic-kibana-workflows

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

We use your email only for this newsletter. Privacy

About

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.

Use cases: testing, productivity

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this skill can do and what it asks for, from its SKILL.md. Checked Oct 25, 2026.

Tools
No tools found
Secrets
None asked for
Install scripts
None found

Network hosts it talks to 1

  • codeload.github.com · found in install command

Files it touches

  • ~/.claude/skills/kibana-workflows

What's inside

Skill 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.
License
Apache-2.0
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.
Metadata
author: elastic · version: 0.5.0 · universal: true
Instructions
280 lines in SKILL.md · view on GitHub

Files (8)

  • SKILL.md
  • demo-test-loop.md · references/
  • generation-tips.md · references/
  • generator-path.md · references/
  • path-performance.md · references/
  • schema-path.md · references/
  • workflow-patterns.md · references/
  • workflow-yaml-reference.md · references/

SKILL.md (first lines)

# 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, the actions it must take,
   and the desired output. If a required dependency is unknown (e.g. a Slack connector id), ask the user or use a
   clearly-marked placeholder.

2. **Look up only what you'll use.** For the specific step types this workflow needs:
   - `platform.workflows.get_step_definitions` with an exact `stepType` (e.g. `"http"`, `"elasticsearch.esql.query"`,
     `"slack2.sendMessage"`), or with `search` to browse. The response includes input params, config params, an
     `outputSummary` when you pass `includeOutputSummary: true`, and usage examples. Pass `includeFullSchema: true` only
     if the compact summary is insufficient.
   - `platform.workflows.get_trigger_definitions` for the trigger event schema.
   - `platform.workflows.get_connectors` to resolve real `connector-id` values for connector actions.
   - `platform.workflows.get_examples` when you need a working YAML shape for a pattern.

   Write each response to a file and jq the field you need — don't let full tool output land in the transcript.

3. **Draft the whole workflow in one pass.** A workflow requires `name`, at least one trigger, and a non-empty `steps`
   array. Use 2-space indentation. Reference outputs as `steps.<name>.output.*`. Build the complete YAML in a single
   edit rather than growing it across many turns.

4. **Validate once.** Call `platform.workflows.validate_workflow` with `{ "yaml": "..." }`. On failure it returns
   errors + step definitions for referenced step types automatically, so you rarely need a second `get_step_definitions`
   call. Fix all reported issues in a single edit, then re-validate.

5. **Test, save, and run.** See [Test / save / run](#test--save--run) below. Use
   `platform.workflows.workflow_execute_step` to iterate on a single step (with `confirmation_body` for unsafe steps).

## Schema path (last resort)

Only for Kibanas without the `platform.workflows.*` tools (see the probe above). Full recipe:
[references/schema-path.md](references/schema-path.md).

## Test / save / run

Shared final phase for both paths.

1. **Test only an execution-safe draft.** Call `POST kbn:/api/workflows/test` with the YAML inline as `workflowYaml` and
   the run-time `inputs`. For any workflow that writes / notifies / calls external services, replace those steps with
   `console` in the tested copy first, then restore them and save the workflow disabled.

2. **Poll the execution.** The response carries a `workflowExecutionId`. Poll
   `GET kbn:/api/workflows/executions/{executionId}` until `status` is one of `completed`, `failed`, `cancelled`, or
   `timed_out`; then fetch `GET kbn:/api/workflows/executions/{executionId}/logs` for step-by-step output. Only treat

From elastic/agent-skills, Apache-2.0.

More from elastic/agent-skills

Signals

Stars
600
Forks
55
Open issues
4
Last commit (this folder)
Sep 4, 2026 (1 month ago)
Last release
Sep 4, 2026 (1 month ago)

From GitHub (fetched Oct 24, 2026).

Details

Version
0.5.0
License
Apache-2.0
First seen
Oct 24, 2026
Last checked
Oct 24, 2026

Same skill elsewhere

Copies of this SKILL.md published by others; search shows only one of them.

More from elastic

Cite this page

kibana-workflows skill. Agent Mart. https://agentmart.dev/skills/elastic-kibana-workflows (last updated 2026-10-24)