Menu
Creates a new connector spec for Kibana. Use when asked to create (or add) a new connector, integration, or data source.
Baseado na classificação ocupacional 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 | create-connector |
| description | Creates a new connector spec for Kibana. Use when asked to create (or add) a new connector, integration, or data source. |
| allowed-tools | WebFetch, WebSearch, Read, Grep, Glob, Write, Edit, Bash, Skill |
| context | fork |
| argument-hint | ["3rd-party-service-name"] |
We're going to create a new connector spec for $0. The connector will enable Kibana to interact with the third-party service and expose operations as tools for AI agents.
Check if $0 has an official hosted MCP server. If so, creating an MCP-native connector is preferred.
MCP server available? → Read reference/mcp-connector-setup.md and follow its steps.
No MCP server available? → Read reference/custom-connector-setup.md and follow its steps.
Follow only the steps for the chosen path. Do not mix them.
Create the connector spec in src/platform/packages/shared/kbn-connector-specs/src/specs/{connector_name}/.
Follow the patterns in reference/connector-patterns.md:
{connector_name}.ts — ConnectorSpec definition with metadata, auth, schema, and actionstypes.ts — Zod input schemas and inferred TypeScript types for each action{connector_name}.test.ts — Unit testsicon/index.tsx — Brand icon componentRegister in src/platform/packages/shared/kbn-connector-specs/src/all_specs.ts and connector_icons_map.ts.
Replace the placeholder icon with a proper brand icon. Search for existing SVG/PNG files in:
src/platform/packages/shared/kbn-connector-specs/src/specs/*/icon/x-pack/platform/plugins/shared/stack_connectors/public/connector_types/{connector}/AI agents rely on descriptions to choose the right action and construct valid inputs. Every action and parameter must have high-quality descriptive text.
isTool and action descriptionsActions should set isTool: true to be discoverable by AI agents in Agent Builder. This is the default for most actions. Use isTool: false only for actions that should not be invoked autonomously (e.g. destructive or admin-only operations).
Every entry MUST have a description field (plain string, NOT i18n.translate()) that explains:
Every Zod parameter in input schemas MUST have a .describe() call that includes:
See the ServiceNow, Slack, and GitHub connector specs for examples of strong description quality.
skill propertyAdd a skill property to the ConnectorSpec — a markdown string providing higher-level LLM guidance:
Use the [...].join('\n') pattern to keep the string readable in source:
skill: [
'## $0 Connector',
'',
'Use this connector to ...',
'',
'### Common patterns',
'- To do X, first call `actionA` then `actionB`',
].join('\n'),
Add tests following the existing examples:
google_drive/google_drive.test.ts or slack/slack.test.ts for the pattern.You do not need to execute the tests — just create the files.
Create a connector doc page in docs/reference/connectors-kibana/{name}-action-type.md.
This step requires documentation skills from https://github.com/elastic/elastic-docs-skills. Check availability by invoking docs-check-style (use the Skill tool). If it fails with "skill not found", stop and tell the user:
Documentation skills are not installed. Please install them:
curl -sSL https://raw.githubusercontent.com/elastic/elastic-docs-skills/main/install.sh | bashThen re-run this step.
docs/reference/connectors-kibana/ as templates (for example, zendesk-action-type.md, jira-cloud-action-type.md). Follow the same structure.docs-syntax-help if unsure about MyST Markdown syntax.frontmatter-description — generate the description frontmatter fieldpage-opening-optimizer — verify H1 and opening paragraphapplies-to-tagging — validate applies_to blockdocs-check-style — check Elastic style guide compliancedocs/reference/toc.yml under the connectors section.docs/reference/connectors-kibana/_snippets/elastic-connectors-list.md.Once you are done developing the connector spec, tests, and documentation, let the user review your work before next steps.
skill property with multi-step patterns and gotchas