redis/code-quality
>- naming conventions (camelCase, PascalCase, UPPER_SNAKE_CASE), linting rules, no `any` without reason, no `!important` in styles, and constant extraction. Use when writing or refactoring any TypeScript/JavaScript code in this repo, when ESLint or Prettier issues come up, or when the user mentions code style, lint, naming conventions, or general code quality.
npx skills add https://github.com/redis/RedisInsight --skill code-quality
npm run lintany - use proper types or unknownreact, lodash, etc.)path, fs - backend only)uiSrc/*, apiClient)uiSrc/* → redisinsight/ui/src/* (UI workspace)apiClient → redisinsight/api-client (auto-generated OpenAPI types — the UI's only entry point into BE-defined shapes)desktopSrc/* → redisinsight/desktop/src/* (desktop workspace)The UI workspace must not import from the backend codebase directly. Use apiClient for types and the existing service layer (uiSrc/services) for HTTP calls.
✅ Use aliases: import { Button } from 'uiSrc/components/Button'
❌ Avoid relative: import { Button } from '../../../ui/src/components/Button'
PascalCase - UserProfilecamelCase - fetchUserProfileUPPER_SNAKE_CASE - MAX_RETRY_ATTEMPTSis/has/should prefix - isLoading, hasErrorDefault to fewer comments. Clear names, small functions, and good
tests should carry the meaning. Write a comment only when the code
genuinely can't explain itself — or when the user explicitly asks for
more (for example, on a piece of complex logic).
When you do write one, keep it short and use plain words to say
what the code is doing or why it has to exist — not how it
works under the hood, and not the story of why you made the change
(that belongs in the commit message or PR description).
✅ Good — plain, names the situation:
// When switching keys, hide the previous key's loader/error/result
// until the new key is ready.
const showLoader = isArrayKeyReady && loading
❌ Avoid — long, mechanism-heavy, re-derives what the code shows:
// Gate every aggregate-slice surface (loader, error, result) on
// `isArrayKeyReady`: when the user switches keys, `keyProp` flips
// immediately but `selectedKeyData` lags by a round-trip, so the
// prior key's slice state would otherwise paint under the newly
// selected (or empty) key for one frame before the hook's reset
// effect fires.
const showLoader = isArrayKeyReady && loading
Also avoid:
// set loading to true).// loop over items).const by default, let only when reassignment neededWhen updating npm packages (especially @redis-ui/* packages):
npm install: rm -rf node_modules/.vite
rm -rf redisinsight/ui/node_modules/.vite
npm run lint passesany types without reasonTake redis/code-quality from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
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.
The instructions reference npm.
Without those the skill loads but fails at the first command.