Claude Cursor Skill

redis-core

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,

LLM Mart · 0 points · 11 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download redis-agent-skills-skills_redis-core-172fb9e.zip · 3 KB
Part of redis/agent-skills — 12 skills

Install

skills CLI npx skills add https://github.com/redis/agent-skills/tree/main/skills/redis-core
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install redis-agent-skills@llmmart
Git git clone https://github.com/redis/agent-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole redis/agent-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

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_Profile is 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

Files (agent-skills)
  • references
    • choose-data-structure.md 2.3 KB
      # Choose the Right Data Structure
      
      Selecting the appropriate Redis data type for your use case is fundamental to performance and memory efficiency.
      
      | Use Case | Recommended Type | Why |
      |----------|------------------|-----|
      | Simple values, counters | String | Fast, atomic operations |
      | Object with fields | Hash | Memory efficient, partial updates, field-level expiration |
      | Queue, recent items | List | O(1) push/pop at ends |
      | Unique items, membership | Set | O(1) add/remove/check |
      | Rankings, ranges | Sorted Set | Score-based ordering |
      | Nested/hierarchical data | JSON | Path queries, nested structures, geospatial indexing with RQE |
      | Event logs, messaging | Stream | Persistent, consumer groups |
      | Similarity search | Vector Set | Native vector storage with built-in HNSW indexing |
      
      **Incorrect:** Using strings for everything.
      
      **Python** (redis-py):
      ```python
      # Storing object as JSON string loses atomic field updates
      redis.set("user:1001", json.dumps({"name": "Alice", "email": "alice@example.com"}))
      
      # To update email, must fetch, parse, modify, and rewrite entire object
      user = json.loads(redis.get("user:1001"))
      user["email"] = "new@example.com"
      redis.set("user:1001", json.dumps(user))
      ```
      
      **Java** (Jedis):
      ```java
      // Bad: Storing as delimited string requires manual parsing
      jedis.set("bicycle", "Deimos;Ergonom;Enduro bikes;4972");
      String bike = jedis.get("bicycle");
      String[] fields = bike.split(";");
      String model = fields[0];  // Fragile and error-prone
      ```
      
      **Correct:** Use Hash for objects with fields.
      
      **Python** (redis-py):
      ```python
      # Hash allows atomic field updates
      redis.hset("user:1001", mapping={"name": "Alice", "email": "alice@example.com"})
      
      # Update single field without touching others
      redis.hset("user:1001", "email", "new@example.com")
      ```
      
      **Java** (Jedis):
      ```java
      import java.util.Map;
      import java.util.HashMap;
      
      // Good: Hash models properties naturally
      Map<String, String> hashFields = new HashMap<>();
      hashFields.put("model", "Deimos");
      hashFields.put("brand", "Ergonom");
      hashFields.put("type", "Enduro bikes");
      hashFields.put("price", "4972");
      
      jedis.hset("bicycle", hashFields);
      
      // Read individual field
      String model = jedis.hget("bicycle", "model");
      ```
      
      Reference: [Choosing the Right Data Type](https://redis.io/docs/latest/develop/data-types/compare-data-types/)
      
    • key-naming.md 1.5 KB
      # Use Consistent Key Naming Conventions
      
      Well-structured key names improve code maintainability, debugging, and enable efficient key scanning.
      
      **Correct:** Use colons as separators with a consistent hierarchy.
      
      ```
      # Pattern: service:entity:id:attribute
      user:1001:profile
      user:1001:settings
      order:2024:items
      cache:api:users:list
      session:abc123
      ```
      
      **Python** (redis-py):
      ```python
      # Good: Short, meaningful key
      redis.set("product:8361", cached_html)
      page = redis.get("product:8361")
      ```
      
      **Java** (Jedis):
      ```java
      // Good: Short, meaningful key derived from URL
      jedis.set("product:8361", "<some cached HTML>");
      String page = jedis.get("product:8361");
      ```
      
      **Incorrect:** Inconsistent naming, spaces, or very long keys.
      
      ```
      # These cause confusion and waste memory
      User_1001_Profile
      my key with spaces
      com.mycompany.myapp.production.users.profile.data.1001
      ```
      
      **Java** (Jedis):
      ```java
      // Bad: Using full URL as key wastes memory and slows comparisons
      jedis.set("http://www.verylongurlkey.com/store/products/product.html?id=8361",
                "<some cached HTML>");
      ```
      
      **Key naming tips:**
      - Keep keys short but readable—they consume memory
      - Consider key prefixes for multi-tenant applications
      - Extract short identifiers from URLs or long strings rather than using the whole thing
      - For large binary values, consider using a hash digest as the key instead of the value itself
      - Use consistent separators (colons are conventional)
      
      Reference: [Redis Keys](https://redis.io/docs/latest/develop/use/keyspace/)
      
  • SKILL.md 3 KB
    ---
    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](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_Profile` is 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](references/key-naming.md) for cleanup examples and edge cases.
    
    ## References
    
    - [Redis: Choosing the right data type](https://redis.io/docs/latest/develop/data-types/compare-data-types/)
    - [Redis: Keys](https://redis.io/docs/latest/develop/use/keyspace/)
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related