{"owner":"elastic","repo":"kibana","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"files":{"AGENTS.md":"# Kibana\n\n## Setup\n- Use the Node version pinned in `.nvmrc` (matches `engines.node` in `package.json`).\n- Run `yarn 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` (or `yarn 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### React / UI Conventions\n- Use functional components; type props explicitly.\n- Keep hooks at the top level; avoid conditional hooks.\n- Avoid inline styles unless consistent with the file’s conventions.\n- Use `@elastic/eui` components with Emotion (`@emotion/react`) for styling.\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."}}