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.

Informations de source

Dépôt
elastic/kibana
Dernière activité de la source
3 août 2026 à 17:06
Langue détectée de SKILL.md
anglais
Étoiles
21 236
Forks
8 623

Options d'installation

Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.

Vérifiez les fichiers source

Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.

Explorateur de fichiers
2 fichiers

Affichage de SKILL.md

SKILL.md
Instructions source · Aperçu en lecture seule
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." ```
Voir sur GitHub