redis

Provision a Redis Cloud database end-to-end — Essentials (fixed plan) or Pro (custom) — using Redis Cloud MCP tools

Comprehensive pre-operation health check for a Redis Enterprise cluster — verify cluster state, node health, license status, and active alerts before making changes

Advanced Redis Enterprise administration via the redisctl CLI. Use for RBAC, LDAP, cluster policy, licensing, certificates, proxy management, and diagnostics.

Day-to-day Redis Enterprise cluster operations via the redisctl CLI. Use when checking cluster status, managing databases, viewing stats and logs, or monitoring Active-Active deployments.

Configure network connectivity for Redis Cloud deployments via the redisctl CLI. Use when setting up VPC peering, Transit Gateway, Private Service Connect, or PrivateLink.

Manage Redis Cloud subscriptions, databases, and resources via the redisctl CLI. Use when provisioning, updating, or monitoring Redis Cloud infrastructure.

Install and configure redisctl CLI for Redis Cloud, Enterprise, and direct database access. Use when setting up redisctl for the first time, creating profiles, or configuring shell completions.

Prototype and compare 2-3 Redis data model alternatives for the same workload

Find and safely remove unused ("dead") npm dependencies in RedisInsight using a grep + leaf-check + build-gate recipe. Use when cleaning up dependencies, investigating whether a package is still used, removing a suspected leftover, or when the user mentions dead deps, unused dependencies, dependency cleanup, leftover packages, or "is this safe to remove". Complements the weekly vulnerability audit (`scripts/dependency-audit-report.mjs`), which only reports vulnerabilities.

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.

Internationalization conventions for the RedisInsight UI (i18next). Use when adding or changing user-facing strings under redisinsight/ui/**, editing the locale files (en.json/bg.json), translating API errors or notifications, or when the user mentions i18n, translations, locales, i18next, or <Trans>.

Use when creating, modifying, debugging, deploying, or testing Redis Insight Workbench visualization plugins, plugin manifests, package.json visualizations, activationMethod functions, redisinsight-plugin-sdk usage, Parcel/Vite plugin builds, iframe rendering, Redis command parsing, Docker RedisInsight deployment, /api/plugins verification, or Playwright plugin validation.

Locate and modify TypeScript configuration in RedisInsight. Use when adding path aliases, introducing a new TS area, debugging webpack/ts-node/ESLint path resolution, or the user asks about tsconfig, path mappings, or where TypeScript is configured.

Run, refresh, or recover from RedisInsight's per-project TypeScript error baselines (.tscheck.rec.json). Use when CI reports "baseline is outdated" or "more TS errors than previously recorded", when the user mentions tscheck / type-check / .tscheck.rec.json, when introducing or fixing TS errors, or when reviewing PRs that touch baseline files.

Create and review pull requests following project standards including title format, description template, and review checklist. Use when creating PRs, writing PR descriptions, or reviewing pull requests.

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.

Freeze a release-ready-pending-upstream branch as a parked PR — open (or update) the PR with a machine-diffable pickup manifest, apply the parked / do-not-merge labels, and deliberately defer /finalize so the episodic re-check notes survive. Use when docs are written against an unreleased or still-changing external source (an upstream PR, a preview feature) and must wait for it to ship before merging. Pairs with /pickup.

Thaw a parked PR — re-fetch each pinned source, diff it against the manifest snapshot taken at park time, report what changed vs what was predicted, then reconcile the docs and resume the normal pipeline (/reflect → /finalize) toward merge. Run with a PR number, or with no argument to scan all parked PRs and report which triggers have fired. Pairs with /park.

Create a before/after restructuring diagram for a docs section. Use when planning how to reorganise a folder under content/ — produces a draw.io-editable .drawio.svg with two identical columns (current structure left, a copy on the right) joined by arrows, so you can drag the right-hand boxes into their proposed new layout. Reads Hugo weight/linkTitle frontmatter.

Distil a PR's accumulated knowledge into the durable squash commit message — reconcile the /reflect experience notes across its commits with the review feedback into one end-state record, and propose promoting cross-cutting lessons to learning skills/memory. Use just before squash-merging a PR. Prepares the message and the gh merge command; does not merge.

Capture an agent experience note into the commit message — the lived reasoning behind a change (what was learned, what was rejected, what future-you must not break), written where the work happens so it travels with the code. Use right after finishing a meaningful chunk of coding/writing, when about to commit, or to amend the last un-pushed commit. Skip for mechanical changes. Feeds the squash-time distiller and the learning skills.

Map Redis commands to their client-library method signatures for the docs API-mapping tables. Use when adding or updating entries in data/command-api-mapping/ — e.g. a new command family (AR*, BF.*) or refreshing a client's signatures. Produces per-command JSON files in the repo's real schema, then merges them.

Use when asked to independently review Claude-authored docs or code changes, Claude-generated diffs, or Claude PR work in the Redis docs repo.

Port a Redis use-case example (cache-aside, session store, rate limiter, leaderboard, etc.) to all 9 supported client libraries in parallel, with cross-client synthesis and audit

Use when agents need persistent shared storage, when saving or restoring workspace state, or when coordinating file access across multiple agents and machines. Creates Redis-backed workspaces, checkpoints and restores agent state, mounts shared filesystems locally, searches workspace contents, and forks workspaces for parallel work.

Review React components for accessibility, hook correctness, and maintainable state boundaries.

Use when the user wants to migrate Codex state in ~/.codex into Agent Filesystem and mount the same shared Codex memory/settings across multiple computers. Recommends a .afsignore before migration and defaults to excluding worktrees, caches, logs, and temporary files.

"Use before writing, modifying, or reviewing code when the {{serverName}} MCP server is connected. Read the relevant standards files live from standards/, cite the specific path you used, and treat the workspace as read-only."

"Use when Codex has access to the {{serverName}} AFS shared-memory MCP server, or when the user asks to check shared memory, prior cross-agent context, durable learnings, memory entries, workspace memory, saved commands, acronyms, aliases, shorthand such as CPP/CCP, /memory-search, or /memory-record. Before any non-trivial answer in a connected project, fresh-search /shared-memory for the task's key nouns, read relevant entries, and build on them instead of re-deriving. After discovering a durable reusable fact, write a new dated memory entry and append a pointer to /shared-memory/index.md. Skip trivial, purely conversational, or session-only tasks."

"Use when answering non-trivial questions in a project connected to the {{serverName}} MCP server (tools prefixed {{toolPrefix}}*). Read wiki/index.md first, search wiki/ for key nouns, cite relevant wiki paths, and offer to file durable answers back into the Shared LLM Wiki (Karpathy style). When ingesting sources from raw/, update source/topic/entity pages plus wiki/index.md and append to wiki/log.md."

"Use when coordinating project work through the {{serverName}} MCP server: reading the spec, claiming tasks, updating in-progress work, recording done work, or writing open questions. Preserve per-owner task files and append-only shared docs."

Manage Agent Filesystem through the control-plane MCP server. Use when the `agent-filesystem` MCP server is available, or when the user asks Codex to list, create, fork, checkpoint, delete, or connect AFS workspaces using a control-plane token.

Redis Search guidance covering FT.CREATE schema design, field type selection (TEXT, TAG, NUMERIC, GEO, GEOSHAPE, VECTOR, JSON path), DIALECT 2 query syntax, FT.SEARCH / FT.AGGREGATE / FT.HYBRID command selection, vector similarity with HNSW or FLAT, hybrid retrieval combining lexical and vector ranking, RAG pipelines, zero-downtime index updates via aliases, and debugging with FT.PROFILE and FT.EXPLAIN. Use when defining a search index on Hash or JSON documents, writing FT.SEARCH queries with filters, sorting, aggregation, or vector KNN, tuning HNSW parameters, building a RAG retrieval pipeline, or troubleshooting slow or empty search results.

Iris is Redis's umbrella for AI-focused products. Use this skill when integrating with the Iris Redis Agent Memory (RAM) data plane on Redis Cloud — recording session events for an AI agent, creating or searching long-term memories, configuring a memory store, or tuning background memory promotion. Code examples use the official `redis-agent-memory` (Python) and `@redis-iris/agent-memory` (TypeScript) SDKs.

Redis Cluster and replication guidance covering hash tags for multi-key operations, avoiding CROSSSLOT errors, and reading from replicas to scale read-heavy workloads. Use when designing keys for a sharded Redis Cluster, debugging CROSSSLOT errors on MGET / SDIFF / pipelines, configuring a multi-key transaction in a cluster, or routing reads to replicas for caches, analytics, or dashboards.

Redis client and connection guidance covering connection pooling, multiplexing, pipelining, client-side caching with RESP3, avoiding slow commands (KEYS, SMEMBERS, HGETALL), and tuning socket timeouts. Use when configuring a Redis client (redis-py, Jedis, Lettuce, NRedisStack), batching commands for throughput, eliminating per-request connection creation, iterating large keyspaces with SCAN, enabling client-side caching for read-heavy workloads, or setting connect and read timeouts.

Core Redis modeling guidance — choose the right data structure (String, Hash, List, Set, Sorted Set, JSON, Stream, Vector Set) and use consistent colon-separated key names. Use when designing a Redis data model, caching objects, deciding between Hash and JSON, building counters, leaderboards, membership sets, or session stores, or when reviewing/cleaning up Redis key naming.

Redis observability guidance — which metrics to monitor (memory, connections, hit ratio, ops/sec, rejected connections), which built-in commands to reach for during incident triage (SLOWLOG, INFO, MEMORY DOCTOR, CLIENT LIST, FT.PROFILE), and when to use the Redis Insight GUI. Use when setting up monitoring or alerts for a Redis instance, diagnosing a performance regression, profiling a slow FT.SEARCH query, or wiring Redis metrics into Prometheus, Datadog, or similar.

Redis security guidance covering authentication (requirepass and ACL users), TLS, ACL-based least-privilege access control, restricting network exposure via bind and protected-mode, firewall rules, and disabling dangerous commands. Use when deploying Redis to production, defining ACL users for an application, configuring TLS connections, locking down a Redis instance behind a firewall, or auditing a Redis deployment for security hardening.

Redis LangCache guidance for semantic caching of LLM responses on Redis Cloud — calling search/set via the SDK or REST API, tuning the similarity threshold, separating caches per task type, and filtering with custom attributes. Use when caching LLM completions or RAG answers to cut API cost and latency, building a cache-aside layer in front of OpenAI / Anthropic / etc., tuning hit rate vs precision, or splitting one app's LLM workloads into multiple LangCache caches.

Add a new Redis command (or command variant) to node-redis end-to-end — the `<NAME>.ts` Command file, its registration with JSDoc in the package `commands/index.ts`, and a co-located `<NAME>.spec.ts` with arg + behavior tests. Use when asked to implement, add, or wire up a Redis command in the client or a module package (json/search/bloom/time-series).

Bump the default Redis docker test image (redislabs/client-libs-test) in the shared DEFAULT_DOCKER_CONFIG and the CI matrix, then force-push the bump-test-image branch and open a PR against upstream. User-invoked only.

Analyze master branch implementation and configuration to find missing, incorrect, or outdated documentation in docs/, README.md, and per-package READMEs. Use when asked to audit doc coverage, sync docs with code, or propose doc updates/structure changes. Provide a report and ask for approval before editing docs.

Review a GitHub issue or pull request URL as a node-redis maintainer, with a staged assessment of whether the claim is real, practically important, already solvable with supported functionality, correctly scoped, better served by another design, and worth maintainer and contributor effort. Use when assessing issue validity or severity, deciding whether an issue should be prioritized or closed, determining whether a requested feature represents an unmet need rather than a discoverability or usage gap, judging whether a PR is worth bringing to mergeable quality, comparing open PRs or alternative designs, separating code quality from repository readiness, or drafting a concise maintainer assessment. When closure, additional evidence, or code changes should be requested, also produce a polite, concise, complete, copy-paste-ready maintainer comment.

Create the required PR-ready summary block, branch suggestion, title, and draft description for node-redis. Must be used before the final response whenever the actual task diff includes runtime code, tests, examples, build/test configuration, or docs with behavior impact, regardless of perceived change size. Skip only when no eligible files changed, every change is repo-meta or docs-only without behavior impact, the task is conversation-only, or the user explicitly opts out.

Plan and execute runtime-behavior investigations with temporary TypeScript probe scripts, validation matrices, state controls, and findings-first reports. Use only when the user explicitly invokes this skill to verify actual runtime behavior beyond normal code-level checks, especially to uncover edge cases, undocumented behavior, or common failure modes in local or live integrations. A baseline smoke check is fine as an entry point, but do not stop at happy-path confirmation.

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.

Keep ioredis documentation synchronized with code behavior. Use when an agent changes public APIs, options, Redis command support, examples, generated typings, connection behavior, Cluster/Sentinel behavior, Pub/Sub, pipelines, transactions, scan streams, reconnect behavior, TypeScript usage, or release-facing behavior that may require README or docs updates.

Use when adding or updating Redis command support in ioredis, including command metadata checks, generator inputs under bin/, generated RedisCommander typings, return and argument overrides, functional command tests, optional tsd coverage, and validation.

Review an ioredis issue or pull request as an ioredis maintainer, with a staged assessment of whether the claim is real, practically important, already solvable with supported functionality, correctly scoped, better served by another ioredis design, and worth maintainer and contributor effort. Use when assessing ioredis issue validity or severity, deciding whether an issue should be prioritized or closed, determining whether a requested feature represents an unmet need rather than a discoverability or usage gap, judging whether a PR is worth bringing to mergeable quality, comparing open PRs or alternative designs, separating code quality from repository readiness, or drafting a concise maintainer assessment. When closure, additional evidence, or code changes should be requested, also produce a polite, concise, complete, copy-paste-ready maintainer comment.

Create the required PR-ready summary block, branch suggestion, title, and draft description for ioredis. Must be used before the final response whenever the actual task diff includes runtime code, tests, examples, build/test configuration, or docs with behavior impact, regardless of perceived change size. Skip only when no eligible files changed, every change is repo-meta or docs-only without behavior impact, the task is conversation-only, or the user explicitly opts out.

Plan and execute runtime-behavior investigations with temporary TypeScript probe scripts, validation matrices, state controls, and findings-first reports. Use only when the user explicitly invokes this skill to verify actual runtime behavior beyond normal code-level checks, especially to uncover edge cases, undocumented behavior, or common failure modes in local or live integrations. A baseline smoke check is fine as an entry point, but do not stop at happy-path confirmation.

Generate a redis-py GitHub release-notes draft and save it as a Markdown file. Collects the merged PRs/commits since the previous release, maps each commit to its PR labels, categorizes them into the project's release sections (Breaking Changes, Deprecations, Experimental Features, New Features, Bug Fixes, Maintenance) using the skill's pr-labels-guide, infers a category for unlabeled PRs, and assembles the notes with an optional Highlights section and a contributors footer. Trigger this skill whenever the user says "release notes", "create release notes", "generate release notes", "draft release notes", "prepare release notes", "changelog", or asks for the release notes/changelog of a specific version or branch (e.g. "release notes for 8.0", "generate release notes for the 8.0 branch", "what changed since the last release"). A phrase like "release notes for 8.0" means: use branch `8.0` as the release-branch input. Also use when asked to summarize what changed since the last tag.

Review a GitHub issue or pull request URL as a redis-py maintainer, with a staged assessment of whether the claim is real, practically important, already solvable with supported functionality, correctly scoped, better served by another design, and worth maintainer and contributor effort. Use when assessing issue validity or severity, deciding whether an issue should be prioritized or closed, determining whether a requested feature represents an unmet need rather than a discoverability or usage gap, judging whether a PR is worth bringing to mergeable quality, comparing open PRs or alternative designs, separating code quality from repository readiness, or drafting a concise maintainer assessment. When closure, additional evidence, or code changes should be requested, also produce a polite, concise, complete, copy-paste-ready maintainer comment.

Produce PR-ready output for redis-py — a one-line commit message and a copy-pasteable Markdown PR description (Change summary + Test coverage, 5–6 paragraphs) covering all staged changes plus the commits already on the current branch. Trigger whenever the user's message mentions any of these keywords or phrases: "PR", "pr", "PR description", "PR draft", "pull request", "the PR block", "commit msg", "commit message", or otherwise asks for a commit message or PR write-up for their local changes.

Generate a redis-py GitHub release-notes draft and save it as a Markdown file. Collects the merged PRs/commits since the previous release, maps each commit to its PR labels, categorizes them into the project's release sections (Breaking Changes, Deprecations, Experimental Features, New Features, Bug Fixes, Maintenance) using the skill's pr-labels-guide, infers a category for unlabeled PRs, and assembles the notes with an optional Highlights section and a contributors footer. Trigger this skill whenever the user says "release notes", "create release notes", "generate release notes", "draft release notes", "prepare release notes", "changelog", or asks for the release notes/changelog of a specific version or branch (e.g. "release notes for 8.0", "generate release notes for the 8.0 branch", "what changed since the last release"). A phrase like "release notes for 8.0" means: use branch `8.0` as the release-branch input. Also use when asked to summarize what changed since the last tag.

Review a GitHub issue or pull request URL as a redis-py maintainer, with a staged assessment of whether the claim is real, practically important, already solvable with supported functionality, correctly scoped, better served by another design, and worth maintainer and contributor effort. Use when assessing issue validity or severity, deciding whether an issue should be prioritized or closed, determining whether a requested feature represents an unmet need rather than a discoverability or usage gap, judging whether a PR is worth bringing to mergeable quality, comparing open PRs or alternative designs, separating code quality from repository readiness, or drafting a concise maintainer assessment. When closure, additional evidence, or code changes should be requested, also produce a polite, concise, complete, copy-paste-ready maintainer comment.

Produce PR-ready output for redis-py — a one-line commit message and a copy-pasteable Markdown PR description (Change summary + Test coverage, 5–6 paragraphs) covering all staged changes plus the commits already on the current branch. Trigger whenever the user's message mentions any of these keywords or phrases: "PR", "pr", "PR description", "PR draft", "pull request", "the PR block", "commit msg", "commit message", or otherwise asks for a commit message or PR write-up for their local changes.

Use when adding a new Redis command — or a new overload/variant of one — to the Lettuce client. Covers the full flow: writing the command specification, designing the Lettuce API, adding argument types and the API template, running the interface generators, adding the builder/async/reactive/Kotlin implementations, and adding unit + integration tests. Trigger on requests like "add support for the <X> command", "implement <REDIS COMMAND> in Lettuce", "wire up a new command", or adding a new argument/overload to an existing command.

Generate a clear, concise GitHub PR title and description from the diff between two local git branches, and save it to prDescription.md in the repo root. Use this whenever the user asks to write, generate, draft, or update a PR description or PR title from local branch changes — including phrasing like "summarize this diff into a PR description," "write a PR description for my current branch," "create a PR title and description," or any request to compare a base and target branch for PR purposes. Trigger even if the user doesn't name specific branches; this skill knows how to default them.

Use when writing or editing Javadoc for Lettuce public API — new methods, classes, deprecations, or when a reviewer asks to fix or improve doc comments. Points to the full house ruleset in .agents/docs/javadoc.md (imperative method summaries, fixed tag order, @param/@return/@throws/@since/@deprecated house forms) and the rule that command-interface Javadoc is edited in the template, not the generated files. Trigger on "write javadoc for", "document this method", "add a deprecation notice", "fix the doc comment".

Add or extend Redis commands in the Jedis client API — a new core command, a family of new commands, an extension to an existing command's options, or a module command (Search/TimeSeries/JSON/Bloom). Gathers evidence (Redis server PR, HLD document), plans the full implementation matrix in plan mode, then implements with unit and integration tests following Jedis maintainer conventions.

Adversarially review a diff, patch, or plan for memtier_benchmark using the real review standards of the project's senior maintainers (Yossi Gottlieb / yossigo, Oran Agra / oranagra, Paulo Sousa / paulorsousa). Use when asked to "adversarially review", "review like the maintainers", "find what a reviewer would block on", or before opening/merging a PR. Emits skeptical, evidence- backed findings; assumes a problem is real until it can be refuted.

fastapi-redis-sdk development skill. Use when writing code, tests, or configuration for the fastapi-redis-sdk library — the official Redis integration for FastAPI. Covers project setup (uv + nox), DI-based caching patterns, connection lifecycle, async/sync endpoints, testing conventions, and CI workflows. Do NOT use for general Redis or FastAPI questions unrelated to this library.