mcpbeat

Code Quality

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.

1k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
8685
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/RedisInsight --skill code-quality

The instruction itself

13 sections, as written by the author

Code Quality Standards

Critical Rules

  • ALWAYS run linter after code changes: npm run lint
  • Linter must pass before committing
  • No console.log in production code (use console.warn/error only)

TypeScript Standards

Essential Rules

  • Use TypeScript for all new code
  • Avoid any - use proper types or unknown
  • Prefer interfaces for object shapes
  • Use type for unions, intersections, primitives
  • Add explicit return types for non-obvious functions
  • Leverage type inference where clear

Import Organization

Required Order (enforced by ESLint)

  • External libraries (react, lodash, etc.)
  • Built-in Node modules (path, fs - backend only)
  • Internal modules with aliases (uiSrc/*, apiClient)
  • Sibling/parent relative imports
  • Style imports (ALWAYS LAST)

Module Aliases

  • uiSrc/*redisinsight/ui/src/* (UI workspace)
  • apiClientredisinsight/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'

Naming Conventions

  • Components: PascalCase - UserProfile
  • Functions/Variables: camelCase - fetchUserProfile
  • Constants: UPPER_SNAKE_CASE - MAX_RETRY_ATTEMPTS
  • Booleans: Use is/has/should prefix - isLoading, hasError

Comments

Default 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:

  • Restating identifier names in prose (// set loading to true).
  • Comments that duplicate what a clearly-named test already asserts.
  • Block comments that summarize obvious blocks (// loop over items).

SonarJS Rules

  • Keep cognitive complexity low (refactor complex functions)
  • Extract duplicate strings to constants
  • Follow DRY principle - no duplicate code
  • Use immediate return (avoid unnecessary intermediate variables)

Best Practices

  • Use destructuring for objects and arrays
  • Use template literals over string concatenation
  • Use const by default, let only when reassignment needed
  • Use descriptive variable names
  • Handle errors properly
  • Clean up subscriptions and timers
  • Use constants instead of magic numbers

Vite Cache Management

When updating npm packages (especially @redis-ui/* packages):

  • Clear Vite cache after npm install:
   rm -rf node_modules/.vite
   rm -rf redisinsight/ui/node_modules/.vite
  • Restart dev server to rebuild dependencies
  • This ensures new package versions are properly loaded

Pre-Commit Checklist

  • [ ] npm run lint passes
  • [ ] No TypeScript errors
  • [ ] Import order is correct
  • [ ] No any types without reason
  • [ ] No console.log statements
  • [ ] No magic numbers
  • [ ] Descriptive variable names
  • [ ] Low cognitive complexity
  • [ ] No duplicate code
  • [ ] Comments kept to a minimum; any present are short and plain-language
  • [ ] Vite cache cleared (if updated dependencies)

How to use it

Copy the folder

Take redis/code-quality 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 npm. Without those the skill loads but fails at the first command.