How do I install the Diagnose Redis Data skill?

Run npx skillmds@latest add hiai-gg/diagnose-redis-data in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Diagnose Redis Data safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Diagnose Redis Data?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Diagnose Redis Data free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Diagnose Redis Data?

HiAi-gg (@hiai-gg) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Diagnose Redis Data by hiai-gg — Agent Skill

Name: Diagnose Redis Data
Author: HiAi-gg

Diagnose Redis Data

Diagnose Redis data problems: missing keys, wrong types, stale or expiring values, and mismatches between writers and readers. Use when an application cannot find a value, reads the wrong one, or Redis behavior is surprising.

HiAi-gg Updated Sep 17, 2026

File contents

Diagnose Redis Data Problems

Use this skill when Redis data behaves unexpectedly: missing keys, wrong values, surprise expirations, or type errors.

Workflow

1. Reproduce the read

Identify the key(s) the application reads and the database number it connects to. Database confusion (/0 vs /1) is a classic cause — confirm the URL.
Read the key with the correct tool for its declared type.

2. Check the common failure classes

Missing key: type <key> returns none, or exists/ttl is negative. Causes: never written, expired, evicted, or written to a different db.
Wrong type: the app calls get on a hash (or lrange on a string). type <key> exposes this instantly.
Expired/stale: check TTL. If ttl is near zero or negative, the writer's EXPIRE (or SET ... EX) is the suspect; correlate with the app's expected lifetime.
Pattern mismatch: the writer stores user:123, the reader looks up users:123. Compare actual keys (scan_keys) with the app's key format.
Key exists but wrong value: compare against what the writer should have stored (serialization, encoding, overwrites by a second writer).

3. Verify eviction/memory

info for maxmemory and evicted_keys. If eviction is happening, large keys or no-expiry keys are the usual culprits (see analyze-redis-memory).

4. Report

State: the key and db number checked, the observed facts (type, TTL, existence, value excerpt), the most likely cause, and the narrowest fix. Distinguish "proven by evidence" from "most likely".

Guardrails

Read-only diagnosis. Do not delete, rename, expire, or set to "fix" anything without explicit user intent.

---name: diagnose-redis-datadescription: Diagnose Redis data problems: missing keys, wrong types, stale or expiring values, and mismatches between writers and readers. Use when an application cannot find a value, reads the wrong one, or Redis behavior is surprising.---# Diagnose Redis Data ProblemsUse this skill when Redis data behaves unexpectedly: missing keys, wrongvalues, surprise expirations, or type errors.## Workflow### 1. Reproduce the read- Identify the key(s) the application reads and the database number it connects to. Database confusion (`/0` vs `/1`) is a classic cause — confirm the URL.- Read the key with the correct tool for its declared type.### 2. Check the common failure classes- **Missing key**: `type <key>` returns `none`, or `exists`/`ttl` is negative. Causes: never written, expired, evicted, or written to a different db.- **Wrong type**: the app calls `get` on a hash (or `lrange` on a string). `type <key>` exposes this instantly.- **Expired/stale**: check TTL. If `ttl` is near zero or negative, the writer's `EXPIRE` (or `SET ... EX`) is the suspect; correlate with the app's expected lifetime.- **Pattern mismatch**: the writer stores `user:123`, the reader looks up `users:123`. Compare actual keys (`scan_keys`) with the app's key format.- **Key exists but wrong value**: compare against what the writer should have stored (serialization, encoding, overwrites by a second writer).### 3. Verify eviction/memory- `info` for `maxmemory` and `evicted_keys`. If eviction is happening, large keys or no-expiry keys are the usual culprits (see `analyze-redis-memory`).### 4. ReportState: the key and db number checked, the observed facts (type, TTL, existence,value excerpt), the most likely cause, and the narrowest fix. Distinguish"proven by evidence" from "most likely".## Guardrails- Read-only diagnosis. Do not `delete`, `rename`, `expire`, or `set` to "fix" anything without explicit user intent.

Frequently asked questions