# Code Change Verification

> Verify ioredis code changes before handoff. Use when an agent changes or reviews runtime TypeScript, Redis command support, generated typings, tests, docs tied to behavior, build tooling, release-sensitive files, or any task that needs choosing and running the right local validation commands.

- Skill: `redis-ioredis/code-change-verification` (Agent Skill)
- Install (CLI): `npx skillmds@latest add redis-ioredis/code-change-verification`
- Raw SKILL.md: https://api.skillmd.com/api/skills/redis-ioredis/code-change-verification/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: redis (https://skillmd.com/u/redis-ioredis)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/redis-ioredis/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.