code-change-verification

# Code Change Verification Use this skill to choose the smallest credible validation set for an ioredis change, run it when feasible, and report exactly what passed, failed, or was skipped. ## Workflow 1. Inspect the diff and changed files before choosing commands. - Use `git diff --stat`, `git diff --name-only`, and targeted file reads. - Do not stage, unstage, or commit unless the user explicitly asks. - Treat `built/` and `lib/utils/RedisCommander.ts` as generated outputs; do not hand-edit them. 2. Classify the change. - Runtime code under `lib/`: run focused tests plus build when the change affects exported declarations or compiled output. - Redis command typing or generated command support: inspect `bin/` config, regenerate with `node bin/index.js` if needed, and run tsd or targeted typing tests. - Functional Redis behavior: run the smallest relevant Mocha files and assume a compatible Redis server is on default host/port. If sandboxed Redis access is blocked, ask for permission rather than assuming Redis is unavailable. - Cluster behavior: use `npm run docker:setup` if infrastructure is needed, then targeted `test/cluster/**/*.ts` or `npm run test:cluster`. - Docs-only changes: run `npm run format-check` only if formatting-sensitive files changed; otherwise inspect rendered Markdown manually. - Build/tooling changes: run `npm run build` and the affected script directly. 3. Prefer focused validation before broad validation. - For self-contained pure unit files, run the test file alone first: `TS_NODE_TRANSPILE_ONLY=true NODE_ENV=test npx mocha --no-experimental-strip-types "test/unit/<file>.ts"`. - Include `test/helpers/*.ts` only when the unit file relies on global hooks or helper setup. - Functional command change: include `test/helpers/*.ts` and the specific `test/functional/...` file. - Typing change: `npm run build` then `npx tsd --files test/typing/<file>.test-d.ts` when a focused file exists. - Public API or cross-cutting behavior: escalate to `npm test` after focused tests pass. - Formatting-only TypeScript edits: run `npm run lint` or `npm run format-check` as appropriate. 4. Handle generated artifacts deliberately. - If `bin/argumentTypes.js`, `bin/returnTypes.js`, `bin/overrides.js`, `bin/sortArguments.js`, `bin/typeMaps.js`, or `bin/template.ts` changes command declarations, regenerate `lib/utils/RedisCommander.ts` with `node bin/index.js`. - If generated output changes unexpectedly, inspect the generator inputs before accepting it. - Build output in `built/` is publish-facing but generated by `npm run build`; mention if it is intentionally not updated. 5. Report results in handoff. - List each command run and its result. - For failures, include the failing test name or key error line and whether it appears related. - For skipped commands, state the concrete reason, such as missing Redis server, blocked sandbox access, or out-of-scope broad suite. ## Command Reference - `npm run build`: remove `built/` and compile TypeScript. - `npm run lint`: ESLint over `lib/`. - `npm run format-check`: Prettier check. - `npm run test:js`: non-cluster Mocha suite over helpers, unit, and functional tests. - `npm run test:cluster`: cluster Mocha suite. - `npm run test:tsd`: build and run all tsd tests. - `npm test`: `test:js` plus `test:tsd`. - `npm run docker:setup` / `npm run docker:teardown`: start/stop Redis test infrastructure.