code-change-verification

name	code-change-verification
description	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.

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.