redis-core/SKILL.md

---

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"

---

BB Skills evidence and version boundaries (2026-10-04)

This package includes the original official Redis skill and all of its relative references. Original instruction bytes are retained under upstream-original; BB Skills scope notes are identified here. No upstream script is executed automatically on download or installation.

Our disposable Redis 7.4.11 / Python 3.13.16 experiment recorded 44 named observations across the core and security resources together. The source, runner, exact environment and command results are under examples. This is an independent native command fixture, not an AI client's execution of this complete skill; runtime_tested remains false. There are no live-site, TLS, Redis Cluster, persistence, replication, JSON, Vector Set, Java or redis-py checks. Field-level expiry and newer data types require their own server-version and module review.

Use an authorized target and review commands before acting. Core writes can replace values and expiry policies; ACL changes can affect other clients. A plain SET removed existing key expiry in our fixture, while KEEPTTL and hash-field changes retained a positive TTL. WATCH detected one controlled conflicting write. Key naming conventions alone do not enforce tenant isolation.

The source's read-only ACL example includes SCAN: in our fixture it revealed a synthetic key name outside the allowed cache prefix even though GET and mixed-prefix MGET were denied. ACL SETUSER updates are additive; explicitly reset the intended key and command grants when tightening an existing role and verify the response. User off prevented new authentication but an existing connection continued reading until an authorized CLIENT KILL USER. These are observed command semantics, not a claim of a Redis vulnerability or complete production hardening.

The upstream production TLS and network references remain guidance to review separately. The runner uses an internal Docker network with no published ports or production mounts and generated in-memory passwords; its container bind is not a recommended production deployment. No paid service, model call or external account was used. MIT covers included skill sources and identified BB Skills additions; runtime server licenses are separate and no server binary is bundled.

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

• Redis: Choosing the right data type
• Redis: Keys