Redis Integration In Existing Projects

Guardrails

• Do not introduce a second cache, session, or queue abstraction if the project already has one.
• Do not create Redis clients inside request handlers, controllers, route modules, or job bodies.
• Do not mix multiple Redis client libraries unless the repository already depends on that split and there is a clear reason to keep it.
• Do not treat Redis as a primary database or persistence rewrite unless the user explicitly asks for that architecture change.
• Do not hide missing config, missing health checks, serialization risk, or TTL assumptions.
• Do not claim the integration is complete without verifying startup behavior and at least one failure path or fallback path.
• If the helper script finds no clear seam, stop and report the ambiguity rather than inventing a new architecture.

References

• Read references/stack-discovery.md when you need the exact repo-reading sequence or how to interpret the helper output.
• Read references/integration-patterns.md when you need role-specific guidance for cache, session, queue, or rate-limit use cases.
• Read references/framework-notes.md when the repository is Node, Python, Spring, or Go and you need a stack-specific seam recommendation.

Helper Script

Run:

uv run --python 3.11 D:\Project\skills-test\integrating-redis-into-existing-projects\scripts\discover_redis_surface.py --project-root <repo> --json

Use the JSON output to decide:

• whether the repo already has Redis-related dependencies,
• which seam is the safest insertion point,
• whether config is already wired,
• and which risks must be called out before any code change.