Skip to main content
agentsSource-backed

Kibana Repository Contributor Agent for Claude

Source-backed Claude agent prompt for contributing to the official elastic/kibana repository using its AGENTS.md guidance for Kibana modules, plugin lifecycle boundaries, server plugin lazy loading, TypeScript style, i18n, Scout, Jest, FTR, scoped type checks, and focused validation.

by Elastic · submitted by oktofeesh1·added 2026-06-04·
Review first review before installing

Open the source and read safety notes before installing.

Citation facts

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Source URLs
https://github.com/elastic/kibana/blob/main/AGENTS.md, https://github.com/elastic/kibana, https://www.elastic.co/kibana
Brand
Elastic
Brand domain
elastic.co
Brand asset source
manual
Safety notes
This agent is for contributing to the official Kibana source repository, not for operating an Elastic deployment or using the existing Elastic Agent Builder MCP entry., Kibana setup and validation can install dependencies, run package-manager scripts, launch browsers or test servers, connect to local Elasticsearch/Kibana services, and consume significant CPU, memory, disk, and time., Server plugin entry files should avoid eager runtime imports from `./plugin`; use type-only imports and lazy implementation imports according to the reviewed AGENTS.md., Do not suppress TypeScript, ESLint, or test failures with `@ts-ignore`, `@ts-expect-error`, `eslint-disable`, skipped tests, removed tests, or unrelated cleanup., Use focused validation first; full type checks, broad `check.js`, FTR, Scout, or Buildkite interactions can be slow and should match the affected surface.
Privacy notes
Kibana work can expose source paths, plugin names, module IDs, datasource names, local Elasticsearch or Kibana URLs, test fixtures, browser screenshots, functional-test logs, and Buildkite metadata., Do not paste Elastic credentials, cloud IDs, API keys, service tokens, private cluster URLs, customer data, internal package names, proprietary dashboards, or unpublished security details into prompts or public output., Functional, Scout, and integration tests may write screenshots, videos, traces, server logs, browser storage, and local config files that need review before sharing., If using `scripts/devex_feedback.sh`, review the text first because it records repository-instruction feedback that may include local context or task details.
Author
Elastic
Submitted by
oktofeesh1
Claim status
unclaimed
Last verified
2026-06-04

Decision playbook

Review trust signals before you adopt

Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.

Compare context
Selected

0

Current score

78

Baseline

Delta

No baseline selected

No major trust-signal divergence detected in the current selection.

Source and provenance checks

Complete

Confirm ownership and provenance before trusting install instructions.

  • Source link availableRequired

    Open the canonical repository and verify ownership.

    Done
  • Source provenance statusRequired

    Marked as source-backed.

    Done
  • Metadata reviewed

    Registry metadata indicates a reviewed listing.

    Done

Safety and privacy checks

Complete

Validate risk disclosures before installation or API wiring.

  • Safety notes presentRequired

    Review the listed safety guidance before running commands.

    Done
  • Privacy notes presentRequired

    Review data handling notes before connecting accounts or secrets.

    Done
  • Trust level risk gateRequired

    Trust level does not block evaluation.

    Done

Package and install checks

Needs review

Check package metadata and artifact integrity signals.

  • Install payload available

    Install or copy payload is available for review.

    Done
  • Package verification flag

    No package verification flag provided.

    Pending
  • Checksum metadata

    No checksum provided for downloaded artifact.

    Pending

Compare-driven decision checks

Needs review

Use compare context to validate trade-offs before adoption.

  • Compare tray has multiple entries

    Add at least one more entry to compare trust differences.

    Pending
  • Baseline comparison available

    No baseline peer selected yet.

    Pending
  • Diverging trust signals identified

    No major trust-signal divergence found.

    Pending

Setup at a glance

Copy & paste

Copy-ready — paste the snippet to get started.

10 minutes

Adoption plan

Balanced adoption plan

Current risk score 16/100. Use staged verification before broader rollout.

Risk 16

Pre-adoption checks

Validate source and review signals before any execution.

  • Confirm source provenanceRequired

    Source URL/provenance metadata is present.

    Done
  • Confirm metadata review state

    Listing has review metadata.

    Done
  • Verify install payload

    Install/config payload exists and can be inspected.

    Done

Security checks

Confirm safety, privacy, and package integrity signals.

  • Review safety notesRequired

    Safety notes are present.

    Done
  • Review privacy notesRequired

    Privacy notes are present.

    Done
  • Verify package integrity metadata

    No package verification/checksum metadata.

    Pending

Rollout

Adopt in controlled steps based on the selected plan.

  • Run in isolated sandbox firstRequired

    Use a constrained sandbox and observe behavior across multiple tasks.

    Pending
  • Roll out graduallyRequired

    Roll out to a small cohort before wider usage.

    Pending
  • Set monitoring and fallback

    Define rollback path and monitor errors after adoption.

    Pending

Evidence readiness

Evidence readiness matrix · balanced

Required evidence gates are covered (5/6 signals complete).

Risk 15

Source provenance

Present

Source repository/provenance is listed.

Required in this preset

Metadata review

Present

Review metadata is present.

Required in this preset

Safety notes

Present

Safety notes are present.

Required in this preset

Privacy notes

Present

Privacy notes are present.

Optional in this preset

Package integrity

Missing

Package integrity metadata is missing.

Optional in this preset

Install payload

Present

Install payload is available.

Required in this preset

Required evidence gates are covered for this preset.

Decision timeline

Decision timeline · balanced

5/6 steps complete with no blocking gaps for this preset.

Risk 14

triage

Confirm source provenanceRequired

Source/provenance metadata is available.

Done

triage

Check metadata review statusRequired

Review metadata is available.

Done

verify

Review safety notesRequired

Safety notes are available.

Done

verify

Review privacy notes

Privacy notes are available.

Done

verify

Validate package integrity metadata

Package integrity metadata is missing.

Pending

rollout

Verify install payload and commandsRequired

Install payload is available.

Done

No required blockers for this timeline preset.

Prerequisite readiness

Prerequisite readiness

5 prerequisites to line up before setup. Includes a review or approval gate.

0/5 ready
Permissions & scopes1Review & approval1General310 minutes

Safety & privacy surface

Safety & privacy surface

5 safety and 4 privacy notes across 5 risk areas. Review closely: credentials & tokens, network access.

5 areas
  • SafetyGeneralThis agent is for contributing to the official Kibana source repository, not for operating an Elastic deployment or using the existing Elastic Agent Builder MCP entry.
  • SafetyNetwork accessKibana setup and validation can install dependencies, run package-manager scripts, launch browsers or test servers, connect to local Elasticsearch/Kibana services, and consume significant CPU, memory, disk, and time.
  • SafetyLocal filesServer plugin entry files should avoid eager runtime imports from `./plugin`; use type-only imports and lazy implementation imports according to the reviewed AGENTS.md.
  • SafetyExecution & processesDo not suppress TypeScript, ESLint, or test failures with `@ts-ignore`, `@ts-expect-error`, `eslint-disable`, skipped tests, removed tests, or unrelated cleanup.
  • SafetyGeneralUse focused validation first; full type checks, broad `check.js`, FTR, Scout, or Buildkite interactions can be slow and should match the affected surface.
  • PrivacyLocal filesKibana work can expose source paths, plugin names, module IDs, datasource names, local Elasticsearch or Kibana URLs, test fixtures, browser screenshots, functional-test logs, and Buildkite metadata.
  • PrivacyCredentials & tokensDo not paste Elastic credentials, cloud IDs, API keys, service tokens, private cluster URLs, customer data, internal package names, proprietary dashboards, or unpublished security details into prompts or public output.
  • PrivacyLocal filesFunctional, Scout, and integration tests may write screenshots, videos, traces, server logs, browser storage, and local config files that need review before sharing.
  • PrivacyExecution & processesIf using `scripts/devex_feedback.sh`, review the text first because it records repository-instruction feedback that may include local context or task details.

Safety notes

  • This agent is for contributing to the official Kibana source repository, not for operating an Elastic deployment or using the existing Elastic Agent Builder MCP entry.
  • Kibana setup and validation can install dependencies, run package-manager scripts, launch browsers or test servers, connect to local Elasticsearch/Kibana services, and consume significant CPU, memory, disk, and time.
  • Server plugin entry files should avoid eager runtime imports from `./plugin`; use type-only imports and lazy implementation imports according to the reviewed AGENTS.md.
  • Do not suppress TypeScript, ESLint, or test failures with `@ts-ignore`, `@ts-expect-error`, `eslint-disable`, skipped tests, removed tests, or unrelated cleanup.
  • Use focused validation first; full type checks, broad `check.js`, FTR, Scout, or Buildkite interactions can be slow and should match the affected surface.

Privacy notes

  • Kibana work can expose source paths, plugin names, module IDs, datasource names, local Elasticsearch or Kibana URLs, test fixtures, browser screenshots, functional-test logs, and Buildkite metadata.
  • Do not paste Elastic credentials, cloud IDs, API keys, service tokens, private cluster URLs, customer data, internal package names, proprietary dashboards, or unpublished security details into prompts or public output.
  • Functional, Scout, and integration tests may write screenshots, videos, traces, server logs, browser storage, and local config files that need review before sharing.
  • If using `scripts/devex_feedback.sh`, review the text first because it records repository-instruction feedback that may include local context or task details.

Prerequisites

  • A local checkout or source snapshot of the official `elastic/kibana` repository.
  • Review the current official `AGENTS.md` before using this agent, because Kibana module, plugin, testing, and validation guidance can change.
  • Run `yarn kbn bootstrap` for initial setup, after branch switches, or when dependency errors appear, when local validation is required.
  • Understand Kibana module boundaries in `kibana.jsonc`, including core, packages, plugin packages, module IDs, plugin IDs, and visibility rules.
  • Permission to run focused Kibana validation commands such as `node scripts/check.js --scope=local`, scoped Jest, FTR, Scout, type checks, ESLint, or i18n checks.

Schema details

Install type
copy
Troubleshooting
No
Source repository stats
Scope
Source repo
Collection metadata
Estimated setup
10 minutes
Difficulty
advanced
Tool listing metadata
Full copyable content
# Trigger
"Use the Kibana repository contributor agent for this elastic/kibana task."

# Required output
1) AGENTS.md, nearby kibana.jsonc, module, package, plugin, and test context checked
2) Affected core, package, plugin, UI, i18n, Buildkite, or test surface identified
3) Focused validation plan using Kibana scripts such as check.js, jest, jest_integration, functional_tests, scout, type_check, eslint, or i18n_check
4) Safety, privacy, dependency/bootstrap, and remaining-risk notes

About this resource

Agent Definition

Create this file as .claude/agents/kibana-repository-contributor.md:

---
name: kibana-repository-contributor
description: Use when the user asks Claude to investigate, patch, test, or review work in the official elastic/kibana repository from source-backed repository instructions.
tools:
  - bash
  - read
  - edit
  - grep
  - web_fetch
---

You are the Kibana Repository Contributor Agent. Your job is to help work in
the official `elastic/kibana` repository while following current repository
instructions, respecting Kibana module and plugin boundaries, choosing focused
validation, and producing concise, reviewable output.

## Source Order

Use these sources in order:

1. The local `AGENTS.md` in the `elastic/kibana` checkout.
2. Nearby `kibana.jsonc`, package or plugin boundaries, source files, tests,
   config files, i18n guidance, and scripts in the local checkout.
3. The local `CONTRIBUTING.md`, `STYLEGUIDE.mdx`, `FAQ.md`, and relevant
   developer-guide pages when setup or contribution process context is needed.
4. `https://github.com/elastic/kibana` when a local checkout is unavailable or
   stale.
5. `https://www.elastic.co/kibana` only for public product context, not as a
   substitute for repository contributor rules.

Do not rely on memory for plugin lifecycle rules, module visibility, lazy
server plugin loading, TypeScript style, test commands, i18n requirements, or
Kibana contribution process when official sources are available.

## Operating Rules

- Read `AGENTS.md` first and treat it as the current repository instruction
  source.
- Run `yarn kbn bootstrap` for initial setup, after branch switches, or when
  dependency errors appear.
- Understand the affected module through `kibana.jsonc`: core, packages, plugin
  packages, module ID, plugin ID, domain grouping, and visibility.
- Respect package boundaries and use the single public entry point; avoid
  subpath imports unless local rules explicitly allow them.
- Avoid circular plugin dependencies. Depend on setup/start/stop contracts
  returned by lifecycle methods.
- In plugin `server/index.ts`, do not eagerly load `./plugin`. Use `import
  type` and type exports for plugin types, keep shared config outside plugin
  implementation files, and instantiate implementation through `await
  import('./plugin')` inside the async initializer.
- Do not add value exports, `export *` of runtime values, `import './plugin'`,
  or `require('./plugin')` from a server plugin entry when that forces disabled
  plugins to execute.
- Prefer existing patterns in the target area before applying broad defaults.
- Use TypeScript for new code. Avoid `any`, avoid `unknown` unless locally
  justified, prefer explicit return types for public APIs, and use
  `import type` for type-only imports.
- Avoid non-null assertions unless there is a local reason. Prefer `readonly`,
  `as const`, const arrow functions, explicit imports and exports, and
  destructuring where that matches the file.
- Never suppress TypeScript errors with `@ts-ignore` or `@ts-expect-error`.
- Never suppress lint with `eslint-disable`; fix the root cause.
- Follow existing formatting. Prefer single quotes in TS/JS unless the file
  uses double quotes.
- Use `snake_case` for new filenames unless the target area has another
  convention.
- For React/UI work, use functional components, typed props, top-level hooks,
  `@elastic/eui`, and Emotion styling where that matches local conventions.
- For user-facing strings, check i18n guidance and run `node
  scripts/i18n_check --fix` when relevant.
- If a user correction contradicts `AGENTS.md` or missing guidance causes
  avoidable work, propose or run `scripts/devex_feedback.sh` with concise
  feedback after reviewing the text.
- Make focused changes. Update docs and tests when behavior or usage changes.
- Never remove, skip, or comment out tests to make validation pass.

## Workflow

1. State the affected Kibana module, package, plugin, UI area, API surface,
   i18n surface, Buildkite area, or test suite.
2. Read `AGENTS.md`, nearby `kibana.jsonc`, package/plugin entry points,
   relevant source, tests, config, and local conventions before editing.
3. Decide whether the work touches module boundaries, plugin lifecycle,
   server plugin entry loading, TypeScript APIs, React UI, i18n, Buildkite,
   Jest, FTR, Scout, docs, or dependency/bootstrap behavior.
4. Choose focused validation from the current repository instructions and the
   changed surface.
5. Make the smallest source-backed change.
6. Inspect the diff for subpath imports, circular plugin dependencies, eager
   `./plugin` loading from server entries, `any`/unsupported `unknown`,
   non-null assertions, lint suppressions, skipped tests, i18n misses,
   unrelated formatting, and missing tests/docs.
7. Run focused validation and broaden only when shared Kibana behavior, module
   boundaries, plugin lifecycle, UI flows, or CI policy require it.
8. Summarize sources checked, affected surface, validation, safety/privacy
   handling, and remaining risk.

## Command Guidance

- Bootstrap dependencies with `yarn kbn bootstrap`.
- Run the local/staged/branch validation suite with:
  `node scripts/check.js --scope=local`
  `node scripts/check.js --scope=staged`
  `node scripts/check.js --scope=branch`
- Run a focused unit test with:
  `node scripts/jest path/to/test.test.ts`
- Run integration Jest tests with:
  `node scripts/jest_integration path/to/test.test.ts`
- Run Function Test Runner configs with:
  `node scripts/functional_tests --config path/to/config.ts`
- For new UI/API tests, prefer Scout when the local area expects it:
  `node scripts/scout run-tests --arch stateful --domain classic --config path/to/scout_config.ts`
- Scope type checks to one project:
  `node scripts/type_check --project path/to/tsconfig.json`
- Do not run `node scripts/type_check` without `--project` unless a broad check
  is explicitly needed.
- Do not target `.buildkite/` with `scripts/type_check`; typecheck Buildkite
  code from inside `.buildkite/` using its workspace command.
- Fix lint in changed files with NUL-delimited paths and an option terminator:
  `git diff --name-only -z --diff-filter=ACMR | xargs -0 node scripts/eslint --fix --`
- Run i18n checks when user-facing strings change:
  `node scripts/i18n_check --fix`
- Use the `bk` CLI when Buildkite interaction is required and credentials are
  available.

## Safety Boundaries

- Do not treat this as an Elastic operations, Elasticsearch administration, or
  Elastic Agent Builder MCP agent.
- Do not use production Elastic Cloud, Elasticsearch, Kibana, or Buildkite
  credentials unless the user explicitly authorizes that environment.
- Do not broaden validation to slow global checks when a focused package,
  plugin, or test target is enough.
- Do not bypass lint, type, or test failures with suppressions or skipped tests.
- Do not create unrelated refactors while fixing a focused issue.
- If setup, bootstrap, package-manager access, browser testing, local services,
  or Buildkite credentials are unavailable, report the blocker instead of
  claiming validation passed.

Source Notes

  • The official AGENTS.md in elastic/kibana documents bootstrap, module/package/plugin organization, server plugin entry lazy-loading rules, scoped test commands, TypeScript style, linting, i18n, Buildkite, and contribution hygiene.
  • The repository README identifies Kibana as the open source interface for querying, analyzing, visualizing, and managing Elasticsearch data.
  • The root CONTRIBUTING.md points contributors to Elastic's Kibana developer guide for setup and contribution workflow.

Duplicate Check

Checked current content and open PRs for Kibana, elastic/kibana, Kibana AGENTS.md, Elastic Agent Builder, Prometheus, Grafana, Loki, Superset, and Airflow. Existing content includes an Elastic Agent Builder MCP server and generic observability/data-pipeline agents, but no Kibana repository contributor agent or open content PR for the elastic/kibana AGENTS.md source.

Source citations

Add this badge to your README

Show that Kibana Repository Contributor Agent for Claude is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/agents/kibana-repository-contributor-agent.svg)](https://heyclau.de/entry/agents/kibana-repository-contributor-agent)

How it compares

Kibana Repository Contributor Agent for Claude side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

Field

Source-backed Claude agent prompt for contributing to the official elastic/kibana repository using its AGENTS.md guidance for Kibana modules, plugin lifecycle boundaries, server plugin lazy loading, TypeScript style, i18n, Scout, Jest, FTR, scoped type checks, and focused validation.

Open dossier

Source-backed Claude agent prompt for contributing to the official angular/angular repository using its AGENTS.md guidance for pnpm, Bazel test targets, coding standards, commit guidelines, zoneless tests, async stability, and PR handling.

Open dossier

Source-backed Claude agent prompt for contributing to the official home-assistant/core repository using its AGENTS.md guidance for PR templates, setup, Python 3.14, integration tests, translations, snapshots, and quality checks.

Open dossier

Source-backed Claude agent prompt for contributing to the official vercel/next.js monorepo using its AGENTS.md guidance, pnpm workspace commands, package-filtered builds, Turbopack and Rust boundaries, mode-specific tests, PR triage rules, and secrets-safety notes.

Open dossier
Next steps
Trust
Review statusReviewedMaintainer reviewedReviewedMaintainer reviewedReviewedMaintainer reviewedReviewedMaintainer reviewed
Package trustPackage not verifiedPackage not verifiedPackage not verifiedPackage not verified
Source provenanceSource-backedSource-backedSource-backedSource-backed
Submitteroktofeesh1oktofeesh1oktofeesh1oktofeesh1
Install riskReview firstReview firstReview firstReview first
Notes Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓
BrandElastic
Categoryagentsagentsagentsagents
SourceSource-backedSource-backedSource-backedSource-backed
AuthorElasticAngularHome AssistantVercel
Added2026-06-042026-06-042026-06-042026-06-04
Platforms
Harness
Source repo
Safety notesThis agent is for contributing to the official Kibana source repository, not for operating an Elastic deployment or using the existing Elastic Agent Builder MCP entry. Kibana setup and validation can install dependencies, run package-manager scripts, launch browsers or test servers, connect to local Elasticsearch/Kibana services, and consume significant CPU, memory, disk, and time. Server plugin entry files should avoid eager runtime imports from `./plugin`; use type-only imports and lazy implementation imports according to the reviewed AGENTS.md. Do not suppress TypeScript, ESLint, or test failures with `@ts-ignore`, `@ts-expect-error`, `eslint-disable`, skipped tests, removed tests, or unrelated cleanup. Use focused validation first; full type checks, broad `check.js`, FTR, Scout, or Buildkite interactions can be slow and should match the affected surface.This agent is for contributing to the official Angular framework repository, not for generating generic Angular application code or replacing Angular documentation. Repository commands can install dependencies, run Bazel test targets, run package builds, apply formatting, execute TypeScript checks, and invoke tooling that may be expensive on a large monorepo. Use focused `pnpm bazel test //target` validation when possible instead of broad test runs. Angular's reviewed AGENTS.md says tests should assume a zoneless environment where state changes schedule updates asynchronously. Do not use `fixture.detectChanges()` as a manual update trigger in new or modified tests when the repository guidance calls for the Act, Wait, Assert pattern. Use `await fixture.whenStable()` after actions that schedule framework updates, and use `useAutoTick()` or the repository timeout helper where the official guidance applies. Do not change Angular coding-standard, commit-message, build, or testing conventions based on generic TypeScript habits when repository docs provide the rule. Use the GitHub CLI for PR work only after the branch is ready and local validation has been summarized.This agent is for contributing to the official Home Assistant Core repository, not for controlling a live Home Assistant instance or generating generic home-automation automations. Repository setup and validation commands can install dependencies, create or update a virtual environment, run pre-commit hooks, format files, lint code, execute tests, and generate translation artifacts. Follow the repository PR template exactly when preparing upstream pull requests. Do not remove unchecked checkboxes from the template. Do not amend, squash, or rebase commits that have already been pushed to an open Home Assistant PR branch, because the repository guidance says reviewers need to follow commit history. Home Assistant Core officially supports Python 3.14 as its minimum version in the reviewed AGENTS.md. Do not flag Python 3.14-only syntax or lazy annotation behavior as compatibility issues. When changing integration `strings.json`, regenerate the English translation output before running tests, because tests load generated `translations/en.json` files. Entity actions, service/action schemas, and entity selection filters may already validate fields. Add defensive guards only when data bypasses validators or is transformed into a less-safe form. Prefer focused pytest targets and integration-scoped checks before running broad repository-wide validation.This agent is for contributing to the official Next.js framework repository, not for generating generic Next.js applications. Next.js repo commands can trigger watch builds, full JS builds, Rust builds, generated dist output, integration tests, browser tests, or CI-style reproduction work. Prefer focused validation first. `pnpm build-all`, `pnpm lint`, `pnpm lint-fix`, generated tests, snapshots, and formatting can touch many files. Inspect the diff before committing. Mode-specific tests matter. Do not substitute a Turbopack dev test, webpack dev test, production start test, unit test, or type check without explaining why the chosen mode matches the change. When changing source or integration tests, follow the repo guidance around the `pnpm --filter=next dev` watch build unless the task is docs-only, read-only, or CI-only. Do not leave watch builds or dev servers running after verification. Do not add generic Claude-generated footers or co-author lines to upstream Next.js commits or PR text. If GitHub SSH authentication or signing fails through a user key provider, stop and ask for the key provider to be unlocked instead of changing remotes or retrying workarounds.
Privacy notesKibana work can expose source paths, plugin names, module IDs, datasource names, local Elasticsearch or Kibana URLs, test fixtures, browser screenshots, functional-test logs, and Buildkite metadata. Do not paste Elastic credentials, cloud IDs, API keys, service tokens, private cluster URLs, customer data, internal package names, proprietary dashboards, or unpublished security details into prompts or public output. Functional, Scout, and integration tests may write screenshots, videos, traces, server logs, browser storage, and local config files that need review before sharing. If using `scripts/devex_feedback.sh`, review the text first because it records repository-instruction feedback that may include local context or task details.Angular repository work can expose local file paths, package names, Bazel labels, test fixtures, build logs, stack traces, browser output, generated docs, and environment-specific setup details. Do not paste private application code, customer component names, internal design-system examples, proprietary test fixtures, credentials, tokens, private URLs, or local-only paths into prompts, public PRs, docs, or examples. Bazel and test output can include workspace paths, temporary paths, browser logs, and environment details. Summarize and redact sensitive values before sharing. When using Angular examples, prefer synthetic component, directive, service, or fixture names unless the upstream source already contains the public example.Home Assistant Core work can expose integration names, device/entity identifiers, fixture data, config-entry fields, service/action payloads, logs, traceback details, snapshot contents, generated translation strings, and local test environment details. Do not paste real home names, room names, device names, entity IDs from a private installation, tokens, webhook URLs, cloud account identifiers, precise location data, or private diagnostic dumps into prompts or public PR text. Snapshot files and translation outputs can contain user-facing device, entity, or service strings. Review generated diffs before sharing them. When summarizing validation failures, redact private hostnames, local paths, account identifiers, tokens, and device-specific data.Next.js repository work can expose local paths, CI logs, browser output, source maps, stack traces, debug logs, environment variable names, cookies, API keys, and private reproduction details. Never print, paste, commit, or share literal secret values, cookies, tokens, API keys, private issue data, or local secret files. Mirror CI environment variable names and modes when reproducing failures, but keep secret values out of commands and public summaries. When sharing build, lint, type, or test output, summarize and redact sensitive-looking values, internal hostnames, private paths, and credentials.
Prerequisites
  • A local checkout or source snapshot of the official `elastic/kibana` repository.
  • Review the current official `AGENTS.md` before using this agent, because Kibana module, plugin, testing, and validation guidance can change.
  • Run `yarn kbn bootstrap` for initial setup, after branch switches, or when dependency errors appear, when local validation is required.
  • Understand Kibana module boundaries in `kibana.jsonc`, including core, packages, plugin packages, module IDs, plugin IDs, and visibility rules.
  • A local checkout or source snapshot of the official `angular/angular` repository.
  • Review the current official `AGENTS.md` before using this agent, because package, test, coding-standard, and PR guidance can change.
  • pnpm installed and used for repository package management.
  • Repository build dependencies available for the focused Bazel target, test target, package, or documentation area being changed.
  • A local checkout or source snapshot of the official `home-assistant/core` repository.
  • Review the current official `AGENTS.md` before using this agent, because setup, syntax, testing, translation, and PR rules can change.
  • Python and uv environment support compatible with the current Home Assistant Core development requirements.
  • Run `script/setup` when entering a new environment or worktree so the repository virtual environment and development dependencies are available.
  • A local checkout or source snapshot of the official `vercel/next.js` repository.
  • Review the current official `AGENTS.md` on the `canary` branch before using this agent, because repo instructions can change.
  • pnpm workspace setup for the Next.js monorepo and enough dependencies to run the relevant package, build, lint, type, or test commands.
  • Known target area such as `packages/next`, Turbopack, Rust crates, tests, docs, examples, create-next-app, next-swc, font, or server runtime.
Install
Config
Citations
ClaimUnclaimedUnclaimedUnclaimedUnclaimed
Open 4 picks in the interactive comparison tool

Related guides

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.