Skip to content
cccskills
FreePublished on GitHub

nauthilus-plugin-api

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.

See how to install

Files included (1)

  • SKILL.md2.5 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Nauthilus Plugin API

Expertise Lens

  • Work as a language-runtime boundary and extension-platform architect.
  • Optimize for stable public API contracts, trusted-code assumptions, explicit lifecycle, capability-based host services, Lua/Go extension parity, and isolation from server internals.
  • Treat accidental exports of core.AuthState, raw Gin contexts, raw Viper, Redis internals, LDAP queues, Prometheus registerers, or OpenTelemetry providers as API boundary defects.

Sources To Read

  • AGENTS.md
  • POLICY.md
  • server/docs/go_plugin_api_working_draft.md
  • pluginapi/v1/
  • server/pluginloader/
  • server/pluginregistry/
  • server/pluginruntime/
  • Lua extension references under server/lua-plugins.d/ and server/lualib/

Design Rules

  • Keep native Go plugins conceptually aligned with Lua extension points: init, environment sources, subject sources, backends, actions, hooks, policy facts, and shared services.
  • Keep policy as decision authority; plugins emit facts/results/obligations/status, policy decides.
  • Expose stable API-level value objects from pluginapi/v1; do not expose server internals.
  • Use context-first, cancelable, deadline-aware request APIs.
  • Treat loaded Go plugins as trusted in-process code.
  • Make lifecycle explicit: register, start, stop, and reconfigure where supported.
  • Remember Go .so plugins cannot be unloaded; removal or binary replacement normally requires restart.
  • Validate module and component names strictly; do not normalize surprising names into collisions.

Implementation Workflow

  1. Start from the working draft and decide whether the task is design-only or implementation.
  2. Keep public API changes in pluginapi/v1 narrow and documented.
  3. Keep host services capability-based and minimal.
  4. Keep reload behavior explicit and testable.
  5. Add import-boundary and contract tests when public API or server boundary rules change.

Validation

  • Run focused plugin API tests with GOEXPERIMENT=runtimesecret.
  • Run reload/config tests when plugin config or lifecycle 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 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.

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