{"owner":"elastic","repo":"kibana","hasSkills":true,"totalSkillsCount":4,"totalTokensCount":2668,"categories":["root-instruction","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"kibana":{"command":"npx","args":["-y","@modelcontextprotocol/server-kibana"]}}},"found":["AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"AGENTS.md":"# Kibana\n\n## Setup\n- Use the Node version pinned in `.nvmrc` (matches `engines.node` in `package.json`).\n- Run `node scripts/kbn bootstrap` for initial setup, after switching branches, or when encountering dependency errors\n\n## Overview\n- Kibana is organized into modules, each defined by a `kibana.jsonc`: core, packages, and plugin packages. Aside from tooling and testing, most code lives in these modules.\n- Packages are reusable units with explicit boundaries and a single public entry point (no subpath imports), usually with a focused purpose.\n- Plugins are a package type (`type: \"plugin\"`) that include a plugin class with setup/start/stop lifecycles, utilized by the core platform to enable applications.\n- **Server plugin entry (`server/index.ts`)** should not load `./plugin` until the plugin may run. Use `import type` (and `export type`) for types from `./plugin`, keep shared config in `config.ts` / `../common/config` (not re-exported runtime values from `./plugin` at the entry), and instantiate the implementation with `await import('./plugin')` inside the async `plugin` initializer. Static value imports, `export { … }` / `export *` of values, `import './plugin'`, and `require('./plugin')` in that entry force Node to parse and execute `plugin.ts` even when the plugin is disabled. `@kbn/eslint/no_sync_import_from_plugin` in `@kbn/eslint-config` enforces this on plugin `server/index.ts` files (see [PR #170856](https://github.com/elastic/kibana/pull/170856) and [issue #171080](https://github.com/elastic/kibana/issues/171080)).\n- Plugins that depend on other plugins rely on the contracts returned by those lifecycles, so circular dependencies must be avoided.\n- Module IDs (typically `@kbn/...`) live in `kibana.jsonc`; `package.json` names are derived where present.\n- Plugin IDs are additional camelCase IDs under `plugin.id` in `kibana.jsonc`, used by core platform and other plugins.\n- Modules are grouped by domain (platform vs solutions) with visibility rules (`shared` vs `private`) that limit cross-group access.\n- Utility scripts live in `scripts/` (e.g., `node scripts/generate.js`).\n- If a user correction contradicts this doc or any skills you followed, or missing guidance caused avoidable work, submit DevEx feedback: `echo \"...\" | scripts/devex_feedback.sh` (include the gap and suggested fix).\n\n## Testing\nRun `node scripts/check.js --scope=local|staged|branch` to validate changes (Jest, types, linting).\n\n### Jest unit\n`node scripts/jest [--config=<pathToConfigFile>] [TestPathPattern]`\n- Config is auto-discovered from the test file path (walks up to nearest `jest.config.js`). Simplest usage:\n  `node scripts/jest src/core/packages/http/server-internal/src/http_server.test.ts`\n- Only one `--config` per run. To test multiple packages, run separate commands.\n\n### Jest integration\n`node scripts/jest_integration [--config=<pathToConfigFile>] [TestPathPattern]`\n- Auto-discovers `jest.integration.config.js` (not `jest.config.js`). Same single-config constraint as above.\n\n### Function Test Runner (FTR)\n`node scripts/functional_tests [--config <file1> [--config <file2> ...]]`\n- For new tests, prefer using Scout\n\n### Scout (UI/API with Playwright)\n`node scripts/scout run-tests --arch stateful --domain classic --config <scoutConfigPath>` (or `--testFiles <specPath1,specPath2>`)\n- When iterating, start the stack once with `node scripts/scout start-server --arch stateful --domain classic` and run `run-tests` against it, instead of rebooting ES+Kibana on every run.\n\n## Code Style Guidelines\nFollow existing patterns in the target area first; below are common defaults.\n\n### Type check\n`node scripts/type_check [--project path/to/tsconfig.json]`\n- Without `--project` it checks **all** projects (very slow). Always scope to a single project:\n  `node scripts/type_check --project src/core/packages/http/server-internal/tsconfig.json`\n- Only one `--project` per run. To check multiple packages, run separate commands.\n- `.buildkite/` is **not** a valid target for `scripts/type_check`. Buildkite scripts live in a separate workspace; typecheck them with `npm run typecheck` from inside `.buildkite/`.\n\n### TypeScript & Types\n- Use TypeScript for all new code; avoid `any` and `unknown`.\n- Prefer explicit return types for public APIs and exported functions.\n- Use `import type` for type-only imports.\n- Avoid non-null assertions (`!`) unless locally justified.\n- Prefer `readonly` and `as const` for immutable structures.\n- Prefer const arrow functions\n- Prefer explicit import/exports over \"*\"\n- Prefer destructuring of variables, rather than property access\n- Never suppress type errors with `@ts-ignore`, `@ts-expect-error`; fix the root cause.\n\n### Linting\n`node scripts/eslint --fix $(git diff --name-only)`\n- Never suppress linting errors with `eslint-disable`; fix the root cause.\n- Plugin `server/index.ts` files are checked by `@kbn/eslint/no_sync_import_from_plugin` (see plugin server entry note above).\n\n### Formatting\n- Follow existing formatting in the file; do not reformat unrelated code.\n- Prefer single quotes in TS/JS unless the file uses double quotes.\n\n### Naming\n- `PascalCase` for classes, types, and React components.\n- `camelCase` for functions, variables, and object keys.\n- New filenames must be `snake_case` (lowercase with underscores) unless an existing convention requires otherwise.\n- Use descriptive names; avoid single-letter names outside tight loops.\n\n### Control Flow & Error Handling\n- Prefer early returns and positive conditions.\n- Handle errors explicitly; return typed errors from APIs when possible.\n- Keep async logic linear; avoid nested `try` blocks when possible.\n\n### UI Component Selection and Styling\n- Reuse existing components from the target module and shared packages it can depend on. Prefer `@kbn/ui-*` packages under `src/platform/kbn-ui` over equivalent `@elastic/eui` components — they encode Kibana-specific behavior and conventions.\n- Treat every component you consume as encapsulated; customize it through its public props and supported composition points.\n- Do not target a component's internal DOM, internal or generated class names, or use `!important` to override its appearance. Existing instances of these patterns are not precedent.\n- When the public API cannot meet the requirement: if changing the component is in scope, extend its public API; otherwise implement the closest supported result and recommend consulting its owning team (`owner` in `kibana.jsonc`; `@elastic/eui-team` for EUI). Treat duplicating a component as a last resort.\n- Style with Emotion (`@emotion/react`) and EUI design tokens; reserve inline styles for runtime-computed values.\n\n### Schema validation\n- When adding `schema.string()` / `schema.arrayOf()` (`@kbn/config-schema`) or `z.string()` / `z.array()` (`zod`) for HTTP request input, always bound them (`maxLength` / `maxSize` / `.max()`) to prevent unbounded-input DoS.\n\n## Internationalization (i18n)\n- Guidelines are found in src/platform/packages/shared/kbn-i18n/GUIDELINE.md\n- Run `node scripts/i18n_check --fix` to check for and fix errors.\n\n## CI\n- Use the `bk` CLI when interacting with Buildkite.\n\n## Contribution Hygiene\n- Unsure: read more code; if still stuck, ask w/ short options. Never guess.\n- Fix root cause (not band-aid).\n- Make focused changes; avoid unrelated refactors.\n- Update docs and tests when behavior or usage changes.\n- Never remove, skip, or comment out tests to make them pass; fix the underlying code.\n- Only comment exported functions with one concise sentence and non-trivial code paths.",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elastic/kibana/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elastic/kibana/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elastic/kibana/HEAD/.claude-plugin/plugin.json)"},"files":{"AGENTS.md":"# Kibana\n\n## Setup\n- Use the Node version pinned in `.nvmrc` (matches `engines.node` in `package.json`).\n- Run `node scripts/kbn bootstrap` for initial setup, after switching branches, or when encountering dependency errors\n\n## Overview\n- Kibana is organized into modules, each defined by a `kibana.jsonc`: core, packages, and plugin packages. Aside from tooling and testing, most code lives in these modules.\n- Packages are reusable units with explicit boundaries and a single public entry point (no subpath imports), usually with a focused purpose.\n- Plugins are a package type (`type: \"plugin\"`) that include a plugin class with setup/start/stop lifecycles, utilized by the core platform to enable applications.\n- **Server plugin entry (`server/index.ts`)** should not load `./plugin` until the plugin may run. Use `import type` (and `export type`) for types from `./plugin`, keep shared config in `config.ts` / `../common/config` (not re-exported runtime values from `./plugin` at the entry), and instantiate the implementation with `await import('./plugin')` inside the async `plugin` initializer. Static value imports, `export { … }` / `export *` of values, `import './plugin'`, and `require('./plugin')` in that entry force Node to parse and execute `plugin.ts` even when the plugin is disabled. `@kbn/eslint/no_sync_import_from_plugin` in `@kbn/eslint-config` enforces this on plugin `server/index.ts` files (see [PR #170856](https://github.com/elastic/kibana/pull/170856) and [issue #171080](https://github.com/elastic/kibana/issues/171080)).\n- Plugins that depend on other plugins rely on the contracts returned by those lifecycles, so circular dependencies must be avoided.\n- Module IDs (typically `@kbn/...`) live in `kibana.jsonc`; `package.json` names are derived where present.\n- Plugin IDs are additional camelCase IDs under `plugin.id` in `kibana.jsonc`, used by core platform and other plugins.\n- Modules are grouped by domain (platform vs solutions) with visibility rules (`shared` vs `private`) that limit cross-group access.\n- Utility scripts live in `scripts/` (e.g., `node scripts/generate.js`).\n- If a user correction contradicts this doc or any skills you followed, or missing guidance caused avoidable work, submit DevEx feedback: `echo \"...\" | scripts/devex_feedback.sh` (include the gap and suggested fix).\n\n## Testing\nRun `node scripts/check.js --scope=local|staged|branch` to validate changes (Jest, types, linting).\n\n### Jest unit\n`node scripts/jest [--config=<pathToConfigFile>] [TestPathPattern]`\n- Config is auto-discovered from the test file path (walks up to nearest `jest.config.js`). Simplest usage:\n  `node scripts/jest src/core/packages/http/server-internal/src/http_server.test.ts`\n- Only one `--config` per run. To test multiple packages, run separate commands.\n\n### Jest integration\n`node scripts/jest_integration [--config=<pathToConfigFile>] [TestPathPattern]`\n- Auto-discovers `jest.integration.config.js` (not `jest.config.js`). Same single-config constraint as above.\n\n### Function Test Runner (FTR)\n`node scripts/functional_tests [--config <file1> [--config <file2> ...]]`\n- For new tests, prefer using Scout\n\n### Scout (UI/API with Playwright)\n`node scripts/scout run-tests --arch stateful --domain classic --config <scoutConfigPath>` (or `--testFiles <specPath1,specPath2>`)\n- When iterating, start the stack once with `node scripts/scout start-server --arch stateful --domain classic` and run `run-tests` against it, instead of rebooting ES+Kibana on every run.\n\n## Code Style Guidelines\nFollow existing patterns in the target area first; below are common defaults.\n\n### Type check\n`node scripts/type_check [--project path/to/tsconfig.json]`\n- Without `--project` it checks **all** projects (very slow). Always scope to a single project:\n  `node scripts/type_check --project src/core/packages/http/server-internal/tsconfig.json`\n- Only one `--project` per run. To check multiple packages, run separate commands.\n- `.buildkite/` is **not** a valid target for `scripts/type_check`. Buildkite scripts live in a separate workspace; typecheck them with `npm run typecheck` from inside `.buildkite/`.\n\n### TypeScript & Types\n- Use TypeScript for all new code; avoid `any` and `unknown`.\n- Prefer explicit return types for public APIs and exported functions.\n- Use `import type` for type-only imports.\n- Avoid non-null assertions (`!`) unless locally justified.\n- Prefer `readonly` and `as const` for immutable structures.\n- Prefer const arrow functions\n- Prefer explicit import/exports over \"*\"\n- Prefer destructuring of variables, rather than property access\n- Never suppress type errors with `@ts-ignore`, `@ts-expect-error`; fix the root cause.\n\n### Linting\n`node scripts/eslint --fix $(git diff --name-only)`\n- Never suppress linting errors with `eslint-disable`; fix the root cause.\n- Plugin `server/index.ts` files are checked by `@kbn/eslint/no_sync_import_from_plugin` (see plugin server entry note above).\n\n### Formatting\n- Follow existing formatting in the file; do not reformat unrelated code.\n- Prefer single quotes in TS/JS unless the file uses double quotes.\n\n### Naming\n- `PascalCase` for classes, types, and React components.\n- `camelCase` for functions, variables, and object keys.\n- New filenames must be `snake_case` (lowercase with underscores) unless an existing convention requires otherwise.\n- Use descriptive names; avoid single-letter names outside tight loops.\n\n### Control Flow & Error Handling\n- Prefer early returns and positive conditions.\n- Handle errors explicitly; return typed errors from APIs when possible.\n- Keep async logic linear; avoid nested `try` blocks when possible.\n\n### UI Component Selection and Styling\n- Reuse existing components from the target module and shared packages it can depend on. Prefer `@kbn/ui-*` packages under `src/platform/kbn-ui` over equivalent `@elastic/eui` components — they encode Kibana-specific behavior and conventions.\n- Treat every component you consume as encapsulated; customize it through its public props and supported composition points.\n- Do not target a component's internal DOM, internal or generated class names, or use `!important` to override its appearance. Existing instances of these patterns are not precedent.\n- When the public API cannot meet the requirement: if changing the component is in scope, extend its public API; otherwise implement the closest supported result and recommend consulting its owning team (`owner` in `kibana.jsonc`; `@elastic/eui-team` for EUI). Treat duplicating a component as a last resort.\n- Style with Emotion (`@emotion/react`) and EUI design tokens; reserve inline styles for runtime-computed values.\n\n### Schema validation\n- When adding `schema.string()` / `schema.arrayOf()` (`@kbn/config-schema`) or `z.string()` / `z.array()` (`zod`) for HTTP request input, always bound them (`maxLength` / `maxSize` / `.max()`) to prevent unbounded-input DoS.\n\n## Internationalization (i18n)\n- Guidelines are found in src/platform/packages/shared/kbn-i18n/GUIDELINE.md\n- Run `node scripts/i18n_check --fix` to check for and fix errors.\n\n## CI\n- Use the `bk` CLI when interacting with Buildkite.\n\n## Contribution Hygiene\n- Unsure: read more code; if still stuck, ask w/ short options. Never guess.\n- Fix root cause (not band-aid).\n- Make focused changes; avoid unrelated refactors.\n- Update docs and tests when behavior or usage changes.\n- Never remove, skip, or comment out tests to make them pass; fix the underlying code.\n- Only comment exported functions with one concise sentence and non-trivial code paths.",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elastic/kibana/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elastic/kibana/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elastic/kibana/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/elastic/kibana/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Kibana\n\n## Setup\n- Use the Node version pinned in `.nvmrc` (matches `engines.node` in `package.json`).\n- Run `node scripts/kbn bootstrap` for initial setup, after switching branches, or when encountering dependency errors\n\n## Overview\n- Kibana is organized into modules, each defined by a `kibana.jsonc`: core, packages, and plugin packages. Aside from tooling and testing, most code lives in these modules.\n- Packages are reusable units with explicit boundaries and a single public entry point (no subpath imports), usually with a focused purpose.\n- Plugins are a package type (`type: \"plugin\"`) that include a plugin class with setup/start/stop lifecycles, utilized by the core platform to enable applications.\n- **Server plugin entry (`server/index.ts`)** should not load `./plugin` until the plugin may run. Use `import type` (and `export type`) for types from `./plugin`, keep shared config in `config.ts` / `../common/config` (not re-exported runtime values from `./plugin` at the entry), and instantiate the implementation with `await import('./plugin')` inside the async `plugin` initializer. Static value imports, `export { … }` / `export *` of values, `import './plugin'`, and `require('./plugin')` in that entry force Node to parse and execute `plugin.ts` even when the plugin is disabled. `@kbn/eslint/no_sync_import_from_plugin` in `@kbn/eslint-config` enforces this on plugin `server/index.ts` files (see [PR #170856](https://github.com/elastic/kibana/pull/170856) and [issue #171080](https://github.com/elastic/kibana/issues/171080)).\n- Plugins that depend on other plugins rely on the contracts returned by those lifecycles, so circular dependencies must be avoided.\n- Module IDs (typically `@kbn/...`) live in `kibana.jsonc`; `package.json` names are derived where present.\n- Plugin IDs are additional camelCase IDs under `plugin.id` in `kibana.jsonc`, used by core platform and other plugins.\n- Modules are grouped by domain (platform vs solutions) with visibility rules (`shared` vs `private`) that limit cross-group access.\n- Utility scripts live in `scripts/` (e.g., `node scripts/generate.js`).\n- If a user correction contradicts this doc or any skills you followed, or missing guidance caused avoidable work, submit DevEx feedback: `echo \"...\" | scripts/devex_feedback.sh` (include the gap and suggested fix).\n\n## Testing\nRun `node scripts/check.js --scope=local|staged|branch` to validate changes (Jest, types, linting).\n\n### Jest unit\n`node scripts/jest [--config=<pathToConfigFile>] [TestPathPattern]`\n- Config is auto-discovered from the test file path (walks up to nearest `jest.config.js`). Simplest usage:\n  `node scripts/jest src/core/packages/http/server-internal/src/http_server.test.ts`\n- Only one `--config` per run. To test multiple packages, run separate commands.\n\n### Jest integration\n`node scripts/jest_integration [--config=<pathToConfigFile>] [TestPathPattern]`\n- Auto-discovers `jest.integration.config.js` (not `jest.config.js`). Same single-config constraint as above.\n\n### Function Test Runner (FTR)\n`node scripts/functional_tests [--config <file1> [--config <file2> ...]]`\n- For new tests, prefer using Scout\n\n### Scout (UI/API with Playwright)\n`node scripts/scout run-tests --arch stateful --domain classic --config <scoutConfigPath>` (or `--testFiles <specPath1,specPath2>`)\n- When iterating, start the stack once with `node scripts/scout start-server --arch stateful --domain classic` and run `run-tests` against it, instead of rebooting ES+Kibana on every run.\n\n## Code Style Guidelines\nFollow existing patterns in the target area first; below are common defaults.\n\n### Type check\n`node scripts/type_check [--project path/to/tsconfig.json]`\n- Without `--project` it checks **all** projects (very slow). Always scope to a single project:\n  `node scripts/type_check --project src/core/packages/http/server-internal/tsconfig.json`\n- Only one `--project` per run. To check multiple packages, run separate commands.\n- `.buildkite/` is **not** a valid target for `scripts/type_check`. Buildkite scripts live in a separate workspace; typecheck them with `npm run typecheck` from inside `.buildkite/`.\n\n### TypeScript & Types\n- Use TypeScript for all new code; avoid `any` and `unknown`.\n- Prefer explicit return types for public APIs and exported functions.\n- Use `import type` for type-only imports.\n- Avoid non-null assertions (`!`) unless locally justified.\n- Prefer `readonly` and `as const` for immutable structures.\n- Prefer const arrow functions\n- Prefer explicit import/exports over \"*\"\n- Prefer destructuring of variables, rather than property access\n- Never suppress type errors with `@ts-ignore`, `@ts-expect-error`; fix the root cause.\n\n### Linting\n`node scripts/eslint --fix $(git diff --name-only)`\n- Never suppress linting errors with `eslint-disable`; fix the root cause.\n- Plugin `server/index.ts` files are checked by `@kbn/eslint/no_sync_import_from_plugin` (see plugin server entry note above).\n\n### Formatting\n- Follow existing formatting in the file; do not reformat unrelated code.\n- Prefer single quotes in TS/JS unless the file uses double quotes.\n\n### Naming\n- `PascalCase` for classes, types, and React components.\n- `camelCase` for functions, variables, and object keys.\n- New filenames must be `snake_case` (lowercase with underscores) unless an existing convention requires otherwise.\n- Use descriptive names; avoid single-letter names outside tight loops.\n\n### Control Flow & Error Handling\n- Prefer early returns and positive conditions.\n- Handle errors explicitly; return typed errors from APIs when possible.\n- Keep async logic linear; avoid nested `try` blocks when possible.\n\n### UI Component Selection and Styling\n- Reuse existing components from the target module and shared packages it can depend on. Prefer `@kbn/ui-*` packages under `src/platform/kbn-ui` over equivalent `@elastic/eui` components — they encode Kibana-specific behavior and conventions.\n- Treat every component you consume as encapsulated; customize it through its public props and supported composition points.\n- Do not target a component's internal DOM, internal or generated class names, or use `!important` to override its appearance. Existing instances of these patterns are not precedent.\n- When the public API cannot meet the requirement: if changing the component is in scope, extend its public API; otherwise implement the closest supported result and recommend consulting its owning team (`owner` in `kibana.jsonc`; `@elastic/eui-team` for EUI). Treat duplicating a component as a last resort.\n- Style with Emotion (`@emotion/react`) and EUI design tokens; reserve inline styles for runtime-computed values.\n\n### Schema validation\n- When adding `schema.string()` / `schema.arrayOf()` (`@kbn/config-schema`) or `z.string()` / `z.array()` (`zod`) for HTTP request input, always bound them (`maxLength` / `maxSize` / `.max()`) to prevent unbounded-input DoS.\n\n## Internationalization (i18n)\n- Guidelines are found in src/platform/packages/shared/kbn-i18n/GUIDELINE.md\n- Run `node scripts/i18n_check --fix` to check for and fix errors.\n\n## CI\n- Use the `bk` CLI when interacting with Buildkite.\n\n## Contribution Hygiene\n- Unsure: read more code; if still stuck, ask w/ short options. Never guess.\n- Fix root cause (not band-aid).\n- Make focused changes; avoid unrelated refactors.\n- Update docs and tests when behavior or usage changes.\n- Never remove, skip, or comment out tests to make them pass; fix the underlying code.\n- Only comment exported functions with one concise sentence and non-trivial code paths.","isInternal":false,"tokens":1768,"sizeBytes":7574},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/elastic/kibana/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elastic/kibana/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":193},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/elastic/kibana/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elastic/kibana/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":179},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/elastic/kibana/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elastic/kibana/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":172}],"systemPromptSnippet":"<yakaai_skills repo=\"elastic/kibana\">\n<!-- File: AGENTS.md (Tokens: ~1768 | Category: root-instruction) -->\n# Kibana\n\n## Setup\n- Use the Node version pinned in `.nvmrc` (matches `engines.node` in `package.json`).\n- Run `node scripts/kbn bootstrap` for initial setup, after switching branches, or when encountering dependency errors\n\n## Overview\n- Kibana is organized into modules, each defined by a `kibana.jsonc`: core, packages, and plugin packages. Aside from tooling and testing, most code lives in these modules.\n- Packages are reusable units with explicit boundaries and a single public entry point (no subpath imports), usually with a focused purpose.\n- Plugins are a package type (`type: \"plugin\"`) that include a plugin class with setup/start/stop lifecycles, utilized by the core platform to enable applications.\n- **Server plugin entry (`server/index.ts`)** should not load `./plugin` until the plugin may run. Use `import type` (and `export type`) for types from `./plugin`, keep shared config in `config.ts` / `../common/config` (not re-exported runtime values from `./plugin` at the entry), and instantiate the implementation with `await import('./plugin')` inside the async `plugin` initializer. Static value imports, `export { … }` / `export *` of values, `import './plugin'`, and `require('./plugin')` in that entry force Node to parse and execute `plugin.ts` even when the plugin is disabled. `@kbn/eslint/no_sync_import_from_plugin` in `@kbn/eslint-config` enforces this on plugin `server/index.ts` files (see [PR #170856](https://github.com/elastic/kibana/pull/170856) and [issue #171080](https://github.com/elastic/kibana/issues/171080)).\n- Plugins that depend on other plugins rely on the contracts returned by those lifecycles, so circular dependencies must be avoided.\n- Module IDs (typically `@kbn/...`) live in `kibana.jsonc`; `package.json` names are derived where present.\n- Plugin IDs are additional camelCase IDs under `plugin.id` in `kibana.jsonc`, used by core platform and other plugins.\n- Modules are grouped by domain (platform vs solutions) with visibility rules (`shared` vs `private`) that limit cross-group access.\n- Utility scripts live in `scripts/` (e.g., `node scripts/generate.js`).\n- If a user correction contradicts this doc or any skills you followed, or missing guidance caused avoidable work, submit DevEx feedback: `echo \"...\" | scripts/devex_feedback.sh` (include the gap and suggested fix).\n\n## Testing\nRun `node scripts/check.js --scope=local|staged|branch` to validate changes (Jest, types, linting).\n\n### Jest unit\n`node scripts/jest [--config=<pathToConfigFile>] [TestPathPattern]`\n- Config is auto-discovered from the test file path (walks up to nearest `jest.config.js`). Simplest usage:\n  `node scripts/jest src/core/packages/http/server-internal/src/http_server.test.ts`\n- Only one `--config` per run. To test multiple packages, run separate commands.\n\n### Jest integration\n`node scripts/jest_integration [--config=<pathToConfigFile>] [TestPathPattern]`\n- Auto-discovers `jest.integration.config.js` (not `jest.config.js`). Same single-config constraint as above.\n\n### Function Test Runner (FTR)\n`node scripts/functional_tests [--config <file1> [--config <file2> ...]]`\n- For new tests, prefer using Scout\n\n### Scout (UI/API with Playwright)\n`node scripts/scout run-tests --arch stateful --domain classic --config <scoutConfigPath>` (or `--testFiles <specPath1,specPath2>`)\n- When iterating, start the stack once with `node scripts/scout start-server --arch stateful --domain classic` and run `run-tests` against it, instead of rebooting ES+Kibana on every run.\n\n## Code Style Guidelines\nFollow existing patterns in the target area first; below are common defaults.\n\n### Type check\n`node scripts/type_check [--project path/to/tsconfig.json]`\n- Without `--project` it checks **all** projects (very slow). Always scope to a single project:\n  `node scripts/type_check --project src/core/packages/http/server-internal/tsconfig.json`\n- Only one `--project` per run. To check multiple packages, run separate commands.\n- `.buildkite/` is **not** a valid target for `scripts/type_check`. Buildkite scripts live in a separate workspace; typecheck them with `npm run typecheck` from inside `.buildkite/`.\n\n### TypeScript & Types\n- Use TypeScript for all new code; avoid `any` and `unknown`.\n- Prefer explicit return types for public APIs and exported functions.\n- Use `import type` for type-only imports.\n- Avoid non-null assertions (`!`) unless locally justified.\n- Prefer `readonly` and `as const` for immutable structures.\n- Prefer const arrow functions\n- Prefer explicit import/exports over \"*\"\n- Prefer destructuring of variables, rather than property access\n- Never suppress type errors with `@ts-ignore`, `@ts-expect-error`; fix the root cause.\n\n### Linting\n`node scripts/eslint --fix $(git diff --name-only)`\n- Never suppress linting errors with `eslint-disable`; fix the root cause.\n- Plugin `server/index.ts` files are checked by `@kbn/eslint/no_sync_import_from_plugin` (see plugin server entry note above).\n\n### Formatting\n- Follow existing formatting in the file; do not reformat unrelated code.\n- Prefer single quotes in TS/JS unless the file uses double quotes.\n\n### Naming\n- `PascalCase` for classes, types, and React components.\n- `camelCase` for functions, variables, and object keys.\n- New filenames must be `snake_case` (lowercase with underscores) unless an existing convention requires otherwise.\n- Use descriptive names; avoid single-letter names outside tight loops.\n\n### Control Flow & Error Handling\n- Prefer early returns and positive conditions.\n- Handle errors explicitly; return typed errors from APIs when possible.\n- Keep async logic linear; avoid nested `try` blocks when possible.\n\n### UI Component Selection and Styling\n- Reuse existing components from the target module and shared packages it can depend on. Prefer `@kbn/ui-*` packages under `src/platform/kbn-ui` over equivalent `@elastic/eui` components — they encode Kibana-specific behavior and conventions.\n- Treat every component you consume as encapsulated; customize it through its public props and supported composition points.\n- Do not target a component's internal DOM, internal or generated class names, or use `!important` to override its appearance. Existing instances of these patterns are not precedent.\n- When the public API cannot meet the requirement: if changing the component is in scope, extend its public API; otherwise implement the closest supported result and recommend consulting its owning team (`owner` in `kibana.jsonc`; `@elastic/eui-team` for EUI). Treat duplicating a component as a last resort.\n- Style with Emotion (`@emotion/react`) and EUI design tokens; reserve inline styles for runtime-computed values.\n\n### Schema validation\n- When adding `schema.string()` / `schema.arrayOf()` (`@kbn/config-schema`) or `z.string()` / `z.array()` (`zod`) for HTTP request input, always bound them (`maxLength` / `maxSize` / `.max()`) to prevent unbounded-input DoS.\n\n## Internationalization (i18n)\n- Guidelines are found in src/platform/packages/shared/kbn-i18n/GUIDELINE.md\n- Run `node scripts/i18n_check --fix` to check for and fix errors.\n\n## CI\n- Use the `bk` CLI when interacting with Buildkite.\n\n## Contribution Hygiene\n- Unsure: read more code; if still stuck, ask w/ short options. Never guess.\n- Fix root cause (not band-aid).\n- Make focused changes; avoid unrelated refactors.\n- Update docs and tests when behavior or usage changes.\n- Never remove, skip, or comment out tests to make them pass; fix the underlying code.\n- Only comment exported functions with one concise sentence and non-trivial code paths.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elastic/kibana/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elastic/kibana/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/elastic/kibana/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}