mcpbeat

Code Change Verification

redis/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.

953 tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
15314
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/redis/ioredis --skill code-change-verification

The instruction itself

3 sections, as written by the author

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

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

How to use it

Copy the folder

Take redis/code-change-verification from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.

Install what it needs

The instructions reference npx. Without those the skill loads but fails at the first command.