mit einem Klick
fix-package-docs
Fix API documentation issues in a Kibana plugin or package. Use when asked to fix, improve, or add JSDoc/API documentation for a Kibana plugin or package, or when check_package_docs validation fails.
Menü
Fix API documentation issues in a Kibana plugin or package. Use when asked to fix, improve, or add JSDoc/API documentation for a Kibana plugin or package, or when check_package_docs validation fails.
Basierend auf der SOC-Berufsklassifikation
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.
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.
| name | fix-package-docs |
| description | Fix API documentation issues in a Kibana plugin or package. Use when asked to fix, improve, or add JSDoc/API documentation for a Kibana plugin or package, or when check_package_docs validation fails. |
| disable-model-invocation | true |
Systematically find and fix all actionable API documentation issues in a Kibana plugin or package using check_package_docs.
/** ... */ style (not //). Single-line /** Description. */ for simple items; multi-line for complex ones.@param name - Description. (hyphen separator, not colon). Match every parameter in the signature.@param options.foo - Description.). The tooling supports arbitrary nesting (e.g., @param fns.fn1.foo.param). Each level must have its own @param tag.@returns for non-void functions: always present; omit only for void/Promise<void>.{@link OtherType} for cross-references to other Kibana types.missingExports items need human judgment to decide whether to export — skip them and note in PR.Given a plugin ID (e.g., dashboard), manifest ID (e.g., @kbn/dashboard-plugin), or file path:
--plugin <id>--package <id>kibana.jsonc)To confirm: search for the plugin.id in kibana.jsonc files if unsure.
grep -r '"id": "dashboard"' --include="kibana.jsonc" -l
node scripts/check_package_docs.js --plugin <pluginId> --write
# or for packages:
node scripts/check_package_docs.js --package <manifestId> --write
This writes <pluginDir>/target/api_docs/stats.json with structured issue data. Exit code 1 is expected when issues exist — that's normal.
Read the stats file:
<pluginDir>/target/api_docs/stats.json
The file has this shape:
{
"counts": {
"apiCount": 145,
"missingComments": 28,
"missingReturns": 10,
"paramDocMismatches": 5,
"missingComplexTypeInfo": 8,
"isAnyType": 3,
"noReferences": 144,
"missingExports": 11,
"unnamedExports": 2
},
"missingComments": [
{ "id": "dashboard.SomeType", "label": "SomeType", "path": "src/.../types.ts", "type": "Interface", "lineNumber": 42, "link": "..." }
],
"missingReturns": [...],
"paramDocMismatches": [...],
"missingComplexTypeInfo": [...],
"isAnyType": [...],
"noReferences": [...],
"missingExports": [{ "source": "...", "references": [...] }],
"unnamedExports": [{ "pluginId": "dashboard", "scope": "public", "path": "src/.../index.ts", "lineNumber": 12, "textSnippet": "export default { ... }" }]
}
Report a summary of the issues in a table before proceeding with fixes.
Group all issues by path so you edit each file once. Prioritize:
missingComments — highest volume, most impactmissingReturns — quick wins (add @returns to existing JSDoc)paramDocMismatches — add missing @param tags so all params are documentedmissingComplexTypeInfo — add JSDoc to undocumented interface, object, and union type declarationsisAnyType — replace any with specific types (careful: may require reading more context)unnamedExports — skip; flag for human review (requires restructuring exports, which changes the public API surface)missingExports — skip; flag for human reviewnoReferences — informational only; not a validation failure, no action requiredFor each file, read it fully first, then make all edits in one pass.
Functions/methods:
/**
* Cleans filters before serialization by removing empty arrays and null values.
*
* @param filters - Array of filter objects to sanitize.
* @returns Cleaned filter array safe for serialization.
*/
export function cleanFiltersForSerialize(filters: Filter[]): Filter[] {
Interfaces/types:
/**
* Parameters for retrieving a dashboard by its saved object ID.
*/
export interface GetDashboardParams {
Interface properties (inline /** ... */):
export interface DashboardLocatorParams {
/** The saved object ID of the dashboard to navigate to. */
dashboardId?: string;
/** When true, the dashboard opens in view mode. */
viewMode?: boolean;
}
Constants/variables:
/** Maximum number of panels allowed on a single dashboard. */
export const MAX_PANELS = 100;
Classes:
/**
* Provides the public API for the Dashboard plugin.
*/
export class DashboardPlugin implements Plugin<DashboardPluginSetup, DashboardPluginStart> {
@returns to existing JSDocFind the existing JSDoc block and add the @returns line before the closing */. Match the actual return type:
/**
* Retrieves the locator params for the current dashboard state.
*
* @param state - Current dashboard application state.
* @returns Locator params derived from the state, suitable for deep-linking.
*/
@param documentationThis flag means some (but not all) parameters already have @param tags — the function has inconsistent docs. Functions where no params are documented are not flagged here; they fall under missingComments instead.
The fix is always to add the missing @param tags so every parameter is covered. Read the function signature and add a @param for each undocumented parameter:
// Before: only `id` is documented, `includeRoles` and `timeout` are missing
/**
* Fetches user data from the API.
*
* @param id - The user ID.
*/
export const getUser = (id: string, includeRoles: boolean, timeout?: number): Promise<User> => { /* ... */ };
// After: all params documented
/**
* Fetches user data from the API.
*
* @param id - The user ID.
* @param includeRoles - When true, includes the user's assigned roles in the response.
* @param timeout - Optional request timeout in milliseconds.
*/
export const getUser = (id: string, includeRoles: boolean, timeout?: number): Promise<User> => { /* ... */ };
Also remove any stale @param entries for parameters that no longer exist in the signature.
Destructured object parameters — document each nested property with dot-notation tags. Every level of nesting needs its own @param:
/**
* Runs a search with the given options.
*
* @param query - The query object.
* @param query.text - The search string.
* @param query.language - Query language (e.g., `kuery`, `lucene`).
* @param options - Runtime options.
* @param options.signal - Abort signal for cancellation.
*/
export const runSearch = (
query: { text: string; language: string },
options: { signal: AbortSignal },
) => { /* ... */ };
For deeply nested properties, continue the dot chain as far as needed (e.g., @param fns.fn1.foo.param - Description.).
A prioritized subset of missingComments for type declarations that lack a top-level JSDoc description. Flagged: interfaces, inline object types, and union/intersection types. Excluded: primitives and functions (self-documenting or tracked elsewhere). Fixing one reduces both missingComplexTypeInfo and missingComments counts.
The fix is to add a JSDoc block to the type declaration itself:
// Before — no description on SearchOptions or FilterSpec
export interface SearchOptions {
query: string;
filters: FilterSpec;
}
export type FilterSpec = {
field: string;
operator: 'eq' | 'neq';
};
// After
/**
* Options for configuring a search request.
*/
export interface SearchOptions {
query: string;
filters: FilterSpec;
}
/**
* Describes a single filter condition applied to a search query.
*/
export type FilterSpec = {
field: string;
operator: 'eq' | 'neq';
};
Inline property docs (e.g., /** ... */ on each field) are a separate concern covered under missingComments for interface members.
This flags an exported declaration that has no identifiable name — meaning ts-morph cannot call getName() on the node. The most common cause is an anonymous export default expression (e.g., export default { ... } or export default function() { ... }).
Do not attempt to fix these. Naming an anonymous default export or removing export default changes the module's public API surface, which is a runtime behavior change outside the scope of documentation fixes. Report them in the PR for a developer to handle.
any with specific typesRead the context to understand the actual type, then replace. Common patterns:
// Before
callback: (result: any) => void
// After
callback: (result: DashboardCreationResult) => void
If the correct type is genuinely unknown, use unknown instead of any. Only change if you're confident — don't guess.
For large plugins, re-run after batches of files to track progress:
node scripts/check_package_docs.js --plugin <pluginId> --write
Read the updated stats.json counts to confirm the numbers are going down.
When all actionable issues are addressed:
node scripts/check_package_docs.js --plugin <pluginId>
Confirm All packages passed validation. (or only missingExports remain, which are pending human review).
Then run:
node scripts/check_changes.ts
In the PR description, include:
stats.jsonmissingExports or unnamedExports skipped (always skipped — flag for a developer)isAnyType items skipped because the correct type was ambiguous# Generate stats
node scripts/check_package_docs.js --plugin dashboard --write
# Read src/platform/plugins/shared/dashboard/target/api_docs/stats.json with the Read tool
# Fix all actionable issues across the plugin files per the rules above
# Verify
node scripts/check_package_docs.js --plugin dashboard
# → "All packages passed validation."