Agent Skills › vemetric/vemetric › redis-core

redis-core

GitHub

提供Redis数据建模指导，涵盖数据结构选择与键命名规范。用于设计缓存、会话、计数器、排行榜等场景，优化内存与性能，确保可维护性。

.agents/skills/redis-core/SKILL.md vemetric/vemetric

Trigger Scenarios

设计Redis数据模型决定使用Hash还是JSON存储对象构建计数器或排行榜审查或清理Redis键名

Install

npx skills add vemetric/vemetric --skill redis-core -g -y

More Options

Non-standard path

npx skills add https://github.com/vemetric/vemetric/tree/main/.agents/skills/redis-core -g -y

Use without installing

npx skills use vemetric/vemetric@redis-core

指定 Agent (Claude Code)

npx skills add vemetric/vemetric --skill redis-core -a claude-code -g -y

安装 repo 全部 skill

npx skills add vemetric/vemetric --all -g -y

预览 repo 内 skill

npx skills add vemetric/vemetric --list

SKILL.md

Frontmatter

{
    "name": "redis-core",
    "license": "MIT",
    "metadata": {
        "author": "Redis, Inc.",
        "version": "0.1.0"
    },
    "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."
}

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.