Skip to content
cccskills
FreePublished on GitHub

nauthilus-redis-runtime

Use for Nauthilus Redis client, Redis Cluster/Sentinel/topology behavior, Redis-backed token/session/flow/cache/bruteforce state, Lua Redis scripts, `NOSCRIPT` recovery, script upload/retry behavior, redismock tests, local cache coordination, and fail-closed runtime state changes.

The English summary is being prepared. Showing the original description.

Works withRedis
See how to install

Files included (1)

  • SKILL.md2.3 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Nauthilus Redis Runtime

Expertise Lens

  • Work as a Redis and distributed-runtime reliability engineer for authentication state.
  • Optimize for fail-closed semantics, explicit Redis ownership, cluster-safe key design, Lua script resilience, redismock coverage, and production recovery behavior.
  • Treat NOSCRIPT, stale script handles, CROSSSLOT hazards, ambiguous Redis errors, real-Redis unit tests, and secret-bearing keys as reliability or security findings.

Sources To Read

  • AGENTS.md
  • POLICY.md
  • README_REDIS_CLUSTER.md
  • server/rediscli/
  • server/lualib/redislib/
  • server/localcache/
  • touched state owners under server/idp/, server/bruteforce/, server/core/, or server/policy/

Redis Rules

  • Use Redis as the explicit production state authority only for the state the code owns.
  • Keep Redis client initialization centralized in server/rediscli.
  • Avoid real Redis in unit tests; prefer redismock and rediscli.NewTestClient.
  • Preserve TLS, auth, Cluster, Sentinel, read/write routing, and timeout behavior when touching client setup.
  • For Lua scripts, keep script identity and source available for reload/retry paths.
  • On NOSCRIPT, re-upload once and retry the intended operation without hiding persistent failures.
  • Keep keys, metrics, and errors free of raw secrets.

Implementation Workflow

  1. Add a focused reproducer for the failing Redis or script behavior.
  2. Model runtime ambiguity explicitly: decide retry, fail-closed, or fallback based on the owning state semantics.
  3. Keep retry and script-upload logic shared instead of copied per command.
  4. Add redismock expectations and ExpectationsWereMet checks where useful.
  5. Consider Cluster hash-slot behavior when Lua scripts touch multiple keys.

Validation

  • Run focused tests with GOEXPERIMENT=runtimesecret.
  • Run Redis Lua package tests when server/lualib/redislib changes.
  • Run GOEXPERIMENT=runtimesecret make test and git diff --check.
  • Run make guardrails before commit or pull request.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Use for Nauthilus OpenAPI, generated management or IdP clients, route contract tests, gRPC protobuf generation, HTTP route registration, management API authentication, public discovery API, `server/openapi`, `server/router`, `server/grpcapi`, `server/grpcclient`, and API-boundary client work.

The English summary is being prepared. Showing the original description.

croessner/nauthilus6Updated Oct 12, 2026

Use for Nauthilus authentication and identity-provider work touching OIDC, OAuth2, SAML, MFA, TOTP, WebAuthn, recovery codes, LDAP-backed identity, browser login and consent flows, token/session/flow state, `private_key_jwt`, introspection, discovery metadata, endpoint-specific client authentication, and security-sensitive auth tests.

The English summary is being prepared. Showing the original description.

croessner/nauthilus6Updated Oct 12, 2026

Use for Nauthilus configuration loading, config schema and defaults, Viper-backed config formats, config dump behavior, vim syntax generation, template validation, prompt guideline sync, documentation under README/IDP/server docs, config converters, and generated documentation or syntax artifacts.

The English summary is being prepared. Showing the original description.

croessner/nauthilus6Updated Oct 12, 2026

Use for Nauthilus Lua plugins, Lua callback tests, policy compiler and registry work, Lua environment and subject sources, Lua actions, hooks, backend scripts, policy facts, obligation targets, `server/lualib`, `server/lua-plugins.d`, `server/policy`, and JSON fixtures under `testdata/lua`.

The English summary is being prepared. Showing the original description.

croessner/nauthilus6Updated Oct 12, 2026

Use for Nauthilus native Go plugin API design or implementation, `pluginapi/v1`, plugin loader, plugin registry, plugin runtime, reload integration, plugin config, extension-point parity with Lua, capability-based host services, lifecycle semantics, and the working draft under `server/docs/go_plugin_api_working_draft.md`.

The English summary is being prepared. Showing the original description.

croessner/nauthilus6Updated Oct 12, 2026

Use for Nauthilus validation, guardrails, dependency patch refreshes, vendoring, generated-output checks, `make release-guardrails`, govulncheck-sensitive publishing, structured commits, branch/tag choreography, website-doc side effects, and final clean-state reporting.

The English summary is being prepared. Showing the original description.

croessner/nauthilus6Updated Oct 12, 2026

See all skills by croessner

Report a problem with this skill