Skip to main content

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.

Quellinformationen

Repository
elastic/kibana
Letzte Quellaktivität
3. August 2026 um 17:06
Erkannte Sprache von SKILL.md
Englisch
Sterne
21.236
Forks
8.623

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

Datei-Explorer
2 Dateien

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
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
# Fix Package Docs Systematically find and fix all actionable API documentation issues in a Kibana plugin or package using `check_package_docs`. ## Non-negotiable conventions - **Only add JSDoc to exported public API** — skip internal helpers that happen to be exported. - **Never change runtime behavior** — documentation edits only (no logic, type, or signature changes). - **Use `/** ... */` style** (not `//`). Single-line `/** Description. */` for simple items; multi-line for complex ones. - **Descriptions are sentences**: start with a capital letter, end with a period. - **`@param name - Description.`** (hyphen separator, not colon). Match every parameter in the signature. - **Destructured object parameters**: document nested properties with dot-notation tags (e.g., `@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>`. - **Use `{@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. ## Workflow ### 1. Resolve the target Given a plugin ID (e.g., `dashboard`), manifest ID (e.g., `@kbn/dashboard-plugin`), or file path: - Plugin ID → use `--plugin <id>` - Manifest ID / package name → use `--package <id>` - File path → find its package first (look for nearest `kibana.jsonc`) To confirm: search for the `plugin.id` in `kibana.jsonc` files if unsure. ```bash grep -r '"id": "dashboard"' --include="kibana.jsonc" -l ``` ### 2. Generate the stats file ```bash 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. ### 3. Read and plan Read the stats file: ``` <pluginDir>/target/api_docs/stats.json ``` The file has this shape: ```json { "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: 1. `missingComments` — highest volume, most impact 2. `missingReturns` — quick wins (add `@returns` to existing JSDoc) 3. `paramDocMismatches` — add missing `@param` tags so all params are documented 4. `missingComplexTypeInfo` — add JSDoc to undocumented interface, object, and union type declarations 5. `isAnyType` — replace `any` with specific types (careful: may require reading more context) 6. `unnamedExports` — skip; flag for human review (requires restructuring exports, which changes the public API surface) 7. `missingExports` — skip; flag for human review 8. `noReferences` — informational only; not a validation failure, no action required ### 4. Fix issues file by file For each file, read it fully first, then make all edits in one pass. #### missingComments — add JSDoc above the declaration **Functions/methods:** ```typescript /** * 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:** ```typescript /** * Parameters for retrieving a dashboard by its saved object ID. */ export interface GetDashboardParams { ``` **Interface properties** (inline `/** ... */`): ```typescript 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:** ```typescript /** Maximum number of panels allowed on a single dashboard. */ export const MAX_PANELS = 100; ``` **Classes:** ```typescript /** * Provides the public API for the Dashboard plugin. */ export class DashboardPlugin implements Plugin<DashboardPluginSetup, DashboardPluginStart> { ``` #### missingReturns — add `@returns` to existing JSDoc Find the existing JSDoc block and add the `@returns` line before the closing `*/`. Match the actual return type: ```typescript /** * 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. */ ``` #### paramDocMismatches — complete partial `@param` documentation This 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: ```typescript // 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`: ```typescript /** * 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.`). #### missingComplexTypeInfo — add JSDoc to undocumented complex type declarations 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**: ```typescript // 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. #### unnamedExports — flag for human review 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. #### isAnyType — replace `any` with specific types Read the context to understand the actual type, then replace. Common patterns: ```typescript // 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. ### 5. After each file, verify locally (optional) For large plugins, re-run after batches of files to track progress: ```bash node scripts/check_package_docs.js --plugin <pluginId> --write ``` Read the updated `stats.json` counts to confirm the numbers are going down. ### 6. Final verification When all actionable issues are addressed: ```bash node scripts/check_package_docs.js --plugin <pluginId> ``` Confirm `All packages passed validation.` (or only `missingExports` remain, which are pending human review). Then run: ```bash node scripts/check_changes.ts ``` ### 7. PR notes In the PR description, include: - Before/after issue counts from `stats.json` - Any `missingExports` or `unnamedExports` skipped (always skipped — flag for a developer) - Any `isAnyType` items skipped because the correct type was ambiguous ## Example: full run on the dashboard plugin ```bash # 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." ```
Auf GitHub ansehen