docs-sync

# Docs Sync Use this skill to decide whether an ioredis change needs documentation, update the right docs, and keep examples aligned with tested behavior. For broad documentation audits, option/API coverage checks, or unclear documentation scope, also read `references/doc-coverage-checklist.md` before deciding what to update. ## Workflow 1. Inspect the changed behavior. - Read the diff and the surrounding implementation. - Identify whether users must know a new capability, option, error case, event, command signature, return shape, or migration concern. - Treat TypeScript declarations and public JSDoc as documentation when command signatures, constructor options, or exported types change. 2. Find the documentation surface. - `README.md`: primary user-facing guide, examples, feature overview, options, and common workflows. - `lib/redis/RedisOptions.ts`: `RedisOptions`, `CommonRedisOptions`, option JSDoc, and `DEFAULT_REDIS_OPTIONS`. - `lib/cluster/ClusterOptions.ts`: `ClusterOptions`, cluster option JSDoc, and `DEFAULT_CLUSTER_OPTIONS`. - `lib/connectors/StandaloneConnector.ts` and `lib/connectors/SentinelConnector/types.ts`: connection option types that contribute to public constructor options. - `docs/`: generated TypeDoc output from public source comments. - `examples/`: runnable snippets that should match current API behavior. - `lib/index.ts` and public TypeDoc comments: exported API documentation surface. - `test/typing/`: executable documentation for TypeScript signatures. 3. Update docs when the change affects users. - Public option or constructor behavior: document option name, default, behavior, topology limitations, and Redis version constraints in JSDoc first; update README/examples when users need prose or usage guidance. - Redis command support: update generator config in `bin/`, regenerate `lib/utils/RedisCommander.ts`, and document only if README/docs mention related command groups or if the change affects command typing, return mapping, or examples. - Pub/Sub, sharded Pub/Sub, monitor, pipeline, transaction, Sentinel, Cluster, TLS, reconnect, or offline queue behavior: update the relevant README/docs section. - New or changed public exports from `lib/index.ts`: update TypeDoc comments and typing tests when the exported type or class is part of the supported API. - Breaking or compatibility-sensitive behavior: add explicit migration or caveat wording. - Internal-only refactors with no behavioral/API impact: state that no docs update is needed and why. 4. Keep examples honest. - Prefer short examples that compile against the current public API. - Avoid documenting behavior that is not covered by tests unless you also add or request coverage. - If an example requires a Redis version, topology, or protocol mode, say so near the example. - Use existing README style and terminology. 5. Verify documentation changes. - For TypeScript examples or declarations, run the focused tsd test or add one when appropriate. - For API docs comments, run `npm run docs` when the change affects generated docs. - For command typing changes, run `node bin/index.js` before validating generated typings. - For Markdown-only edits, inspect nearby formatting and links; run `npm run format-check` only when relevant files are covered by Prettier. ## Documentation Decision Checklist - Does the change alter public exports from `lib/index.ts`? - Does it add, remove, rename, or change JSDoc/defaults for `RedisOptions`, `CommonRedisOptions`, `ClusterOptions`, standalone connection options, or Sentinel connection options? - Does it add, remove, or change a Redis command method signature? - Does it change reply transformation, Buffer variants, callbacks, or Promise behavior? - Does it affect connection lifecycle, retries, ready checks, offline queue, or subscriber mode? - Does it affect Cluster routing, redirections, subscriber groups, Sentinel discovery, or TLS? - Does it add an option, event, error condition, or environment assumption? - Would a user need different code after this change? If any answer is yes, update docs or explicitly explain why existing docs already cover it.