Update to Redis

{
  "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.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 220
    },
    {
      "relative_path": "references/choose-data-structure.md",
      "size_in_bytes": 2330
    },
    {
      "relative_path": "references/key-naming.md",
      "size_in_bytes": 1516
    }
  ],
  "skill_md_contents": "---\nname: redis-core\ndescription: 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.\nlicense: MIT\n---\n\n# Redis Core\n\nFoundational 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.\n\n## When to apply\n\n- Caching objects, sessions, or per-user state.\n- Counters, leaderboards, recent-items lists, unique-membership sets.\n- Reviewing or refactoring Redis key names.\n- Deciding between a Redis Hash and a JSON document for an entity.\n\n## 1. Choose the right data structure\n\nPick the type that matches the *access pattern*, not just the shape of the data.\n\n| Use case | Recommended type | Why |\n|---|---|---|\n| Simple values, counters | String | Atomic `INCR`/`DECR`, `SET`/`GET` |\n| Object with independently updated fields | Hash | Per-field reads/writes, no whole-object rewrite |\n| Queue, recent-N items | List | O(1) push/pop at ends |\n| Unique items, membership checks | Set | O(1) `SADD`/`SISMEMBER`/`SCARD` |\n| Rankings, score-based ranges | Sorted Set | Score-ordered; `ZADD`/`ZRANGE`/`ZRANK` |\n| Nested / hierarchical data | JSON | Path-level updates, nested arrays, RQE indexing |\n| Event log, fan-out messaging | Stream | Persistent, consumer groups |\n| Vector similarity | Vector Set | Native vector storage with HNSW |\n\n**Common anti-pattern:** stuffing a flat object into a serialized string. Updating one field means fetch + parse + mutate + rewrite. Use a Hash instead.\n\nSee [references/choose-data-structure.md](references/choose-data-structure.md) for full rationale and Python/Java examples.\n\n## 2. Use consistent key names\n\nUse `colon-separated` segments with a stable hierarchy:\n\n```\n{entity}:{id}:{attribute}\nuser:1001:profile\nuser:1001:settings\norder:2024:items\nsession:abc123\narticle:987:likes\ngame:space-invaders:leaderboard\n```\n\nRules of thumb:\n\n- **Lowercase, colon-separated.** No spaces, no mixed casing (`User_1001_Profile` is bad).\n- **Keep keys short but readable** — keys live in memory and appear in every command.\n- **Don't use full URLs or long strings as keys.** Extract a short identifier, or use a hash digest of the URL.\n- **Prefix for multi-tenancy** (`tenant:42:user:7:cart`) so scans and ACLs can target a tenant cleanly.\n- **Be consistent.** Pick one convention per service and apply it across all keys.\n\nSee [references/key-naming.md](references/key-naming.md) for cleanup examples and edge cases.\n\n## References\n\n- [Redis: Choosing the right data type](https://redis.io/docs/latest/develop/data-types/compare-data-types/)\n- [Redis: Keys](https://redis.io/docs/latest/develop/use/keyspace/)\n"
}