// Create and name git branches following project conventions. Use when creating branches, checking out new branches, or the user mentions branch naming.
| name | branches |
| description | Create and name git branches following project conventions. Use when creating branches, checking out new branches, or the user mentions branch naming. |
Use lowercase kebab-case with type prefix and issue/ticket identifier.
# Pattern: <type>/<issue-ref>/<short-title>
# INTERNAL (JIRA - RI-XXX)
feature/RI-123/add-user-profile
bugfix/RI-789/memory-leak
fe/feature/RI-567/add-dark-mode
be/bugfix/RI-345/fix-redis-connection
docs/RI-333/update-docs
test/RI-444/add-unit-tests
e2e/RI-555/add-integration-tests
# OPEN SOURCE (GitHub - XXX)
feature/123/add-export-feature
bugfix/789/fix-connection-timeout
# Special branches
release/v2.0.0
ric/RI-666/custom-prefix
feature/ - New features and refactoring (affects multiple areas)bugfix/ - Bug fixes (affects multiple areas)fe/feature/ - Frontend-only features (only redisinsight/ui/ folder)fe/bugfix/ - Frontend-only bug fixes (only redisinsight/ui/ folder)be/feature/ - Backend-only features (only redisinsight/api/ folder)be/bugfix/ - Backend-only bug fixes (only redisinsight/api/ folder)docs/ - Documentation changestest/ - Test-related changese2e/ - End-to-end test changesrelease/ - Release branchesric/ - Custom prefix for special casesNote: When a bug fix affects only the redisinsight/ui/ folder, use fe/bugfix/ prefix instead of bugfix/.
RI-XXX (JIRA ticket)XXX (GitHub issue number)# only in commit messages, not branch namesNestJS backend development patterns for the RedisInsight API: module structure, services, controllers, DTOs, dependency injection, and error handling. Use when editing any file under redisinsight/api/**, writing or modifying NestJS modules, controllers, services, DTOs, providers, or when the user mentions the backend, API, or NestJS.
Code-quality standards for RedisInsight: TypeScript strictness, 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.
Playwright end-to-end testing standards for RedisInsight: page object models, test structure, fixtures, navigation patterns, and flaky-test prevention. Use when editing files under tests/e2e-playwright/**, writing Playwright tests, adding page objects, or when the user mentions Playwright, E2E tests, page objects, or end-to-end testing.
React/Redux frontend development patterns for RedisInsight UI: component folder structure, styled-components, hooks, named exports, barrel files, layout components, and theme usage. Use when editing any file under redisinsight/ui/**, writing or modifying React components, Redux slices, styled-components, custom hooks, or when the user mentions UI, frontend, React, Redux, or styled-components.
Critical safety guardrails for protected branches: never commit, push, or force-push directly to main, latest, or release branches; no destructive history rewrites without explicit user approval. Use before any git operation that touches protected branches, before force-push, reset --hard, history rewrite, or branch deletion, or whenever the user asks about merging, pushing, or release branches.
Unit/integration testing standards for RedisInsight using Jest and Testing Library: test structure, the `renderComponent` helper, faker for test data, mocking patterns, and `waitFor` instead of fixed time waits. Use when writing or modifying any `*.spec.ts` or `*.spec.tsx` file, when adding component or slice tests, when debugging flaky tests, or when the user mentions jest, testing library, faker, or test patterns.