Menu
Fetch a GitHub issue by number or URL and reformat it according to the Kibana bug report or feature request template. Classifies the issue type automatically, then rewrites the body and updates it via the GitHub CLI.
Based on SOC occupation classification
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 | gh-enhance-issue |
| description | Fetch a GitHub issue by number or URL and reformat it according to the Kibana bug report or feature request template. Classifies the issue type automatically, then rewrites the body and updates it via the GitHub CLI. |
| disable-model-invocation | true |
Fetch a GitHub issue and reformat its body to match the appropriate Kibana issue template.
The user provides either:
12345)https://github.com/elastic/kibana/issues/12345)Extract the issue number from whichever form was provided.
gh issue view <NUMBER> --repo elastic/kibana --json number,title,body,labels
Read the title, body, and labels fields from the output.
Determine whether the issue is a bug report or a feature request:
labels array first. If any label contains bug (case-insensitive), treat it as a bug. If any label contains enhancement or feature (case-insensitive), treat it as a feature request.title and body:
Using the original title and body as source material, map existing content to the appropriate template fields. For feature requests, look for scope boundaries, current workarounds, target user, and any mentioned blockers or dependencies. Leave fields blank where no information is available in the original issue.
*** Bug report *** Read .github/ISSUE_TEMPLATE/Bug_report.md to get the required fields.
*** Feature request *** Read .github/ISSUE_TEMPLATE/Feature_request.yml to get the required fields.
After extracting what you can, identify which fields are still empty. Ask the first empty field's question, then end your response and wait for the user to reply. Do not ask the next question or proceed to Step 5 until the user has answered.
Guidelines:
For feature requests, also probe for these common gaps (even if the field is not empty, ensure the draft addresses them):
Display the proposed new body to the user and ask for confirmation before making any changes. End your response and wait for the user to explicitly confirm before proceeding to Step 6.
After the user confirms, update the issue body:
gh issue edit <NUMBER> --repo elastic/kibana --body "<NEW_BODY>"
Pass the body via a shell variable or heredoc to avoid quoting issues:
NEW_BODY=$(cat <<'EOF'
<reformatted body here>
EOF
)
gh issue edit <NUMBER> --repo elastic/kibana --body "$NEW_BODY"
Confirm success by reporting the issue URL.