redis-core
redis/agent-skills
Choose the right Redis data structure and key-naming convention for your access pattern.
What is redis-core?
Core Redis modeling guidance covering data-type selection (String, Hash, List, Set, Sorted Set, JSON, Stream, Vector Set) and consistent colon-separated key naming. Use when designing a Redis data model, caching objects, deciding between data structures, building counters or leaderboards, or reviewing key-naming conventions.
- Match access patterns to the right Redis data type (String, Hash, List, Set, Sorted Set, JSON, Stream, Vector Set)
- Avoid anti-patterns like serializing objects into strings when a Hash or JSON would be more efficient
- Apply consistent colon-separated key-naming conventions across your service
- Design multi-tenant key hierarchies that support clean scans and ACLs
- Optimize per-field reads/writes and atomic operations based on data structure choice
How to install redis-core
npx skills add https://github.com/redis/agent-skills --skill redis-coreHow to use redis-core
- 1.Identify your primary access pattern (single values, field-level updates, ranges, membership checks, etc.)
- 2.Select the data structure from the provided table that matches your access pattern
- 3.Design your key hierarchy using colon-separated segments (e.g., entity:id:attribute)
- 4.Apply the naming rules: lowercase, short but readable, no full URLs, consistent across your service
- 5.Review existing keys for anti-patterns like serialized objects in Strings
Use cases
- Caching user profiles or session state with independent field updates
- Building counters, leaderboards, or recent-items lists with efficient range queries
- Designing unique-membership sets for tags, followers, or permissions
- Choosing between a Hash and JSON document for nested or hierarchical data
- Refactoring existing Redis keys to follow a consistent naming scheme
- Backend engineers designing or refactoring Redis schemas
- Cache architects choosing between data structures for specific access patterns
- Teams standardizing key-naming conventions across services
- Developers building counters, leaderboards, or session stores
redis-core FAQ
Use a Hash for flat objects with independent field reads/writes. Use JSON for nested/hierarchical data, arrays, or when you need path-level updates and RQE indexing.
Colon-separated keys are readable, compact in memory, and enable clean prefix-based scans and ACL targeting, especially for multi-tenant systems.
Serializing a flat object into a String means every field update requires fetch + parse + mutate + rewrite. Use a Hash instead for O(1) per-field operations.
Prefix keys with the tenant ID at the start: tenant:42:user:7:cart. This allows scans and ACLs to target a specific tenant cleanly.
No. Extract a short identifier or use a hash digest of the URL instead. Keys live in memory and appear in every command, so keep them short.
Full instructions (SKILL.md)
Source of truth, from redis/agent-skills.
name: redis-core description: 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. license: MIT metadata: author: Redis, Inc. version: "0.1.0"
Redis Core
Foundational guidance for modeling data in Redis. Covers data-type selection and key-name conventions — the two decisions that most directly drive memory, performance, and maintainability.
When to apply
- Caching objects, sessions, or per-user state.
- Counters, leaderboards, recent-items lists, unique-membership sets.
- Reviewing or refactoring Redis key names.
- Deciding between a Redis Hash and a JSON document for an entity.
1. Choose the right data structure
Pick the type that matches the access pattern, not just the shape of the data.
| Use case | Recommended type | Why |
|---|---|---|
| Simple values, counters | String | Atomic INCR/DECR, SET/GET |
| Object with independently updated fields | Hash | Per-field reads/writes, no whole-object rewrite |
| Queue, recent-N items | List | O(1) push/pop at ends |
| Unique items, membership checks | Set | O(1) SADD/SISMEMBER/SCARD |
| Rankings, score-based ranges | Sorted Set | Score-ordered; ZADD/ZRANGE/ZRANK |
| Nested / hierarchical data | JSON | Path-level updates, nested arrays, RQE indexing |
| Event log, fan-out messaging | Stream | Persistent, consumer groups |
| Vector similarity | Vector Set | Native vector storage with HNSW |
Common anti-pattern: stuffing a flat object into a serialized string. Updating one field means fetch + parse + mutate + rewrite. Use a Hash instead.
See references/choose-data-structure.md for full rationale and Python/Java examples.
2. Use consistent key names
Use colon-separated segments with a stable hierarchy:
{entity}:{id}:{attribute}
user:1001:profile
user:1001:settings
order:2024:items
session:abc123
article:987:likes
game:space-invaders:leaderboard
Rules of thumb:
- Lowercase, colon-separated. No spaces, no mixed casing (
User_1001_Profileis bad). - Keep keys short but readable — keys live in memory and appear in every command.
- Don't use full URLs or long strings as keys. Extract a short identifier, or use a hash digest of the URL.
- Prefix for multi-tenancy (
tenant:42:user:7:cart) so scans and ACLs can target a tenant cleanly. - Be consistent. Pick one convention per service and apply it across all keys.
See references/key-naming.md for cleanup examples and edge cases.
References
Related skills
More from redis/agent-skills and the wider catalog.
redis-development
Redis performance optimization and best practices for data structures, query engines, vector search, and semantic caching.
redis-observability
Monitor Redis health and diagnose performance issues with key metrics and built-in commands.
redis-search
Redis Search guidance for schema design, vector indexing, and hybrid retrieval queries.
redis-security
Harden Redis with authentication, ACL-based access control, TLS, and network restrictions.
redis-semantic-cache
Semantic caching for LLM responses on Redis Cloud — reduce API costs and latency with embedding-based prompt matching.
agent-ci
Run GitHub Actions CI locally before pushing to validate changes instantly.