القائمة
GitHub interactions via gh CLI for the Kibana repo. Use when performing any GitHub interaction — creating, viewing, or modifying PRs or issues, posting comments or reviews, checking CI status, applying labels, creating releases, or making any gh/API call.
| name | kbn-github |
| description | GitHub interactions via gh CLI for the Kibana repo. Use when performing any GitHub interaction — creating, viewing, or modifying PRs or issues, posting comments or reviews, checking CI status, applying labels, creating releases, or making any gh/API call. |
gh CLI for all GitHub interactions.GH_PAGER=cat for all gh calls to avoid interactive pagers.elastic/kibana; when not inside a local clone, prefer -R elastic/kibana for gh subcommands. For gh api, -R is not supported; use explicit repos/elastic/kibana/... endpoints or set GH_REPO=elastic/kibana when using {owner}/{repo} placeholders.gh pr view --json number -q .number.gh pr create --draft.gh pr checks.gh pr view.gh pr diff.gh pr diff --name-only.gh api repos/elastic/kibana/pulls/{number}/comments.Closes #X or Addresses #X before creating the PR.gh issue view {number}.gh issue list --search "query".gh issue create.Read references/review.md before creating or modifying any PR review. It contains mandatory instructions for comment anchoring, verification, and avoiding irreversible API mistakes.
event in a review-creation payload (POST /repos/{o}/{r}/pulls/{n}/reviews). Without event the review stays PENDING; with it, the review is immediately and irreversibly published.gh api repos/{o}/{r}/pulls/{n}/reviews --input <file> with the body in a JSON file. Do not pass -f event=... or -F event=... to the review-creation endpoint — every quoting form (bare, single-quoted, double-quoted, whole-pair quoted, $(...), backticks, ${VAR:-...}) is denied by the strip-review-event hook because the only safe sanitisation is parsing the JSON file."event" key before submitting.POST /repos/{o}/{r}/pulls/{n}/reviews/{id}/events with -f event=APPROVE (or COMMENT / REQUEST_CHANGES). The hook only denies event= on the review-creation endpoint, not on submission.See references/review.md for inline, file-level, threaded reply, and PR-level comment examples.
gh subcommands, use gh api with the GitHub REST or GraphQL endpoints.$'...' so \n becomes real newlines. Do NOT rely on \\n escapes inside normal quotes (especially gh api -f body=...).gh api ... --input /path/to/payload.json over -f/-F flags to avoid shell escaping issues.gh api call, use -X GET. In practice, adding -f or -F without -X GET can cause gh to hit the POST schema by default.?ref=... in endpoints (triggers no matches found). Prefer: gh api -X GET repos/elastic/kibana/contents/PATH -F ref=main.gh/API) and report the URL, identifier, or resulting state.Do not add/modify repo .github/* templates unless the user explicitly asks.
GitHub's sub-issue API creates real parent-child relationships (not tasklists).
Create hierarchy:
Create child issues first with full descriptions.
Get GraphQL IDs:
gh api graphql -f query='{ repository(owner:"elastic",name:"kibana") { issue(number:N) { id } } }'
Link:
gh api graphql -f query="mutation { addSubIssue(input:{issueId:\"PARENT_ID\",subIssueId:\"CHILD_ID\"}) { issue { number } } }"
Verify: gh api repos/elastic/kibana/issues/NUM/sub_issues
Mutations: addSubIssue, removeSubIssue, reprioritizeSubIssue
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.
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.