with one click
scout-best-practices-reviewer
Review Scout UI/API tests (including Scout test migrations) for best practices, reuse, and parity.
Menu
Review Scout UI/API tests (including Scout test migrations) for best practices, reuse, and parity.
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.
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 | scout-best-practices-reviewer |
| description | Review Scout UI/API tests (including Scout test migrations) for best practices, reuse, and parity. |
Perform a static PR review of Scout UI and API test files (*.spec.ts) against Scout best practices and existing Scout abstractions (fixtures, page objects, API helpers). Produce actionable, PR-review-ready feedback that pushes for reuse over one-off implementations.
Solution-specific skills may extend this skill with additional review criteria. Check if one exists for your solution (e.g., Security Solution has one at <plugin>/.agents/skills/scout-best-practices-reviewer/). Run the general review first, then apply solution-specific checks.
Important: Do not post GitHub comments unless explicitly stated.
Changed *.spec.ts files (and imported helpers/fixtures).
test / spaceTest (usually in **/test/scout/ui/**).apiTest (usually in **/test/scout/api/**).Neighboring Scout code in the same plugin/solution (existing specs + test/scout/**/fixtures/**) to spot reuse opportunities and avoid duplicating helpers.
Removed/previous tests (if this is a migration) to verify behavior parity.
Scout docs (open only what you need — best practices are split by test type so you can skip the irrelevant half):
docs/extend/scout/best-practices.mddocs/extend/scout/ui-best-practices.mddocs/extend/scout/api-best-practices.mddocs/extend/scout/core-concepts.md, docs/extend/scout/fixtures.mddocs/extend/scout/page-objects.md, docs/extend/scout/api-services.mddocs/extend/scout/write-ui-tests.md, docs/extend/scout/write-api-tests.mddocs/extend/scout/api-auth.md, docs/extend/scout/browser-auth.md, docs/extend/scout/parallelism.md, docs/extend/scout/deployment-tags.md, docs/extend/scout/a11y-checks.md, docs/extend/scout/debugging.md, docs/extend/scout/run-tests.mdRule of thumb: always read the general best practices, then open only the UI-specific file for UI reviews or the API-specific file for API reviews. If a PR mixes UI and API specs, open both.
docs/extend/scout/fixtures.md + local test/scout/**/fixtures)@kbn/scout, solution Scout packages, and plugin-local test/scout/**) before suggesting brand-new helpersChecklist items are tagged with the document they're detailed in:
docs/extend/scout/best-practices.md (applies to both UI and API tests)docs/extend/scout/ui-best-practices.mddocs/extend/scout/api-best-practices.mdOpen only the docs relevant to the test type(s) under review.
pageObjects, fixtures, and apiServices; if adding helpers/page objects, place them in the right scope (plugin vs solution vs @kbn/scout) and register via fixtures.apiClient for the endpoint under test; apiServices/kbnClient for setup/teardown only; correct auth + common headers.admin unless required); space-aware behavior covered or explicitly out of scope.waitForTimeout() and time-based assertions/retries; rely on auto-waiting + explicit readiness signals. Some locators are restricted by @kbn/eslint/scout_no_locators (e.g. globalLoadingIndicator).global.teardown.ts is present): cleanup must use esClient/kbnClient/apiServices. esArchiver isn't on the teardown fixture surface — Scout intentionally never exposed archive-unloading (slow and unnecessary; leftover indexes don't break tests with idempotent loadIfNeeded). Flag teardowns that try to use esArchiver at all, that load new data (teardown is for state reset only), or that duplicate work belonging in afterAll/per-test cleanup.Do not review or comment on:
.meta manifest files (e.g., **/.meta/**/*.json): these are auto-generated for CI test planning and lane distribution. No manual regeneration is needed.Use these definitions when assigning severity:
When in doubt, prefer a lower severity. Optimization suggestions (efficiency improvements) should be minor or nit, not major.
test/functional/**, loadTestFile(), FTR configs) alongside new/changed Scout specs.blocker unless explicitly de-scoped.admin vs viewer), spaces behavior, and permission realismignoreErrors, automatic retries)loadTestFile()).This skill does not prescribe an output format. The caller decides how findings are reported:
OUTPUT.md.Offer to generate the updated code, fully incorporating the suggested improvements and resolving any parity gaps.