Nxuskit

nxusKit Celerat

Help developers implement nxusKit integrations across Rust, Go, Python, and CLI/Bash with less prompting and fewer tier or provider mistakes. Prefer Community Edition (CE) paths when they satisfy the user's intent. Disclose Pro requirements before implementing Pro-only features.

This skill ships instructions and curated references, and the plugin also includes a local read-only MCP discovery server for examples and recipes. The skill itself does not execute application code, and app connectors or lifecycle hooks are outside the current release surface. (See §12.)

---

1. Trigger description and scope

This skill should trigger when a user asks Codex to:

• add basic chat, streaming chat, tool / function calling, structured output, vision / multimodal, retry / fallback, cost-aware routing, multi-provider routing, model discovery, or local provider support (Ollama, LM Studio) using nxusKit
• migrate code that calls a single provider SDK directly (OpenAI, Anthropic, Ollama, LiteLLM-style) over to provider-agnostic nxusKit calls
• add CLIPS rule evaluation, Bayesian inference, Z3-backed solver workflows, solver what-if analysis, ZEN decision tables, or hybrid LLM + symbolic workflows
• prototype any of the above through nxuskit-cli and a Bash / JSON pipeline before editing application code
• explain how to choose between Community Edition and Pro for a specific nxusKit capability
• discover or select a canonical nxusKit example for a given use case

The skill is scoped to the installed Celerat release: it covers shipped, documented capabilities of the nxusKit SDK, nxuskit-cli, the bundled read-only MCP discovery server, and public-safe local intelligence patterns. It does not advertise capabilities that are outside this plugin's installed surface.

The skill helps users use nxusKit. It is not itself a nxusKit runtime plugin — those are signed shared-library SDK extensions in the nxusKit ecosystem and live elsewhere.

---

2. Mandatory project-inspection workflow

Before editing or generating code, inspect the target project. Always check:

• language and framework (Rust crate? Go module? Python package? something else?)
• package manager (cargo, go mod, pip / uv / poetry / hatch)
• existing AI provider SDKs already in use (openai, anthropic, ollama, litellm, etc.)
• environment-variable and credential conventions in use (.env, .envrc, direnv, OS keychain)
• build and test commands (make, cargo make, npm test, pytest, project-local equivalents)
• existing test coverage (so changes can be verified without inventing tests)
• lint and format commands (so generated code matches local style)
• whether nxusKit is already a dependency
• whether nxuskit-cli is on the user's PATH
• whether the request is CE-suitable or Pro-dependent (see §3)

When the project has no obvious build/test command, fall back to the smallest safe smoke path defined in references/setup-and-smoke.md. Do not invent test commands.

---

3. CE-vs-Pro decision tree

Use references/tier-guide.md as the authoritative CE-vs-Pro mapping. The decision tree summary:

• CE-suitable (default — no disclosure required): basic chat, streaming, multi-provider routing, cost routing, capability detection, retry/fallback, structured output, tool calling, vision, local providers, auth helper, CLIPS basics, CLIPS+LLM hybrid validation (no solver step), Bayesian inference.
• Pro-required: Z3-backed solver, solver what-if analysis, ZEN decision tables, BN→solver→CLIPS pipelines whenever the solver step is involved, nxusKit plugin loading and trust policy.

If the request lands in Pro territory, show the Pro disclosure block before generating any Pro-dependent code. The disclosure block content is canonical in references/pro-disclosure.md. Codex MUST show the Pro disclosure block before generating code for any Pro-required workflow above.

If the user has stated they have no Pro license, do not generate Pro-dependent code at all; offer the closest CE alternative or state plainly that no CE alternative exists.

---

4. Language-specific setup notes

Per-language install, credentials, and smoke recipes live in references/setup-and-smoke.md. Sections cover Rust, Go, Python, and CLI/Bash. Use that document — do not duplicate it inline in skill output.

Common rules for every language:

• Never ask for an API key, token, license key, or other secret in chat (FR-009 / §10).
• Direct credential setup to environment variables, credential stores, nxuskit-cli auth helpers, or provider dashboards.
• Do not hard-code model IDs; prefer reading the model name from project config, environment variables, or capability detection.

---

5. CLI/Bash + nxuskit-cli prototype workflow

Treat nxuskit-cli as a first-class surface (FR-015). Recommend it for: license login, license activation, license status verification, provider discovery, provider status checks, loopback or local-provider smoke tests, and JSON-first prototypes that can be piped through Bash before any SDK code is written.

Probe-first behavior (FR-015a)

Before recommending a specific nxuskit-cli subcommand for execution, instruct the user to probe availability:

nxuskit-cli --help
nxuskit-cli --version

If a recommended subcommand is not present in the installed CLI, label it as guidance with a minimum-version note (for example, "requires nxuskit-cli ≥ X") and fall back to the language-specific smoke path defined in references/setup-and-smoke.md. Do not emit an nxuskit-cli command as required when its presence has not been verified.

License status (always safe)

nxuskit-cli license status --json

Run this BEFORE generating any Pro-dependent code so the active tier is known.

JSON-first prototyping pattern

Use --json outputs piped through jq to validate workflow logic in Bash before adding application code. Example sequences live in references/setup-and-smoke.md under "CLI/Bash with nxuskit-cli".

The skill MUST prefer typed, explicit nxuskit-cli commands over arbitrary shell execution. Do not wrap free-form bash -c "$..." invocations.

---

6. Example-selection procedure

Use the local MCP example tools when available; the bundled snapshot covers the full current examples portfolio. When MCP is unavailable, references/example-index.md is the generated fallback index for the core 19 baseline examples. Consult MCP or the fallback index BEFORE inventing code:

1. Identify the user's intent (e.g., "streaming chat with retry").
2. Look up the matching name rows in example-index.md (e.g., streaming + retry-fallback).
3. Confirm the row's tier. If it is Pro, apply §3 disclosure first.
4. Use the source_path as the canonical reference; copy or adapt the pattern rather than inventing a new one.
5. If the closest entry is guidance-only (no canonical example exists yet), state that plainly and degrade gracefully — do not fabricate file paths.

The core fallback names: basic-chat, streaming, multi-provider, capability-detection, cost-routing, retry-fallback, structured-output, vision, auth-helper, clips-basics, clips-llm-hybrid, bayesian-inference, solver, solver-what-if, llm-solver-hybrid, bn-solver-clips-pipeline, zen-decisions, ruler, arbiter. The MCP snapshot additionally exposes portfolio examples such as common-sense-guardrails and model-research-harness.

---

7. Migration procedure (provider SDK → nxusKit)

Migration recipes live in references/migration-recipes.md. Required workflow:

1. Discovery first: grep for the existing provider's import statements, env-var names, client construction, model selection, and retry config. Show the user the discovery results before proposing a swap.
2. Preserved-behavior contract: list every observable behavior that must be preserved (function signatures, env vars, model selection points, retry config, error semantics). Confirm with the user before applying changes.
3. Apply the swap following the recipe for the source provider (OpenAI / Anthropic / Ollama / LiteLLM).
4. Verify with project-local commands per FR-014 (§9).

Do NOT rewrite from scratch when a migration recipe applies. Do NOT introduce new abstractions, retry layers, or config plumbing beyond what the project already has — match local conventions.

---

8. Implementation workflow recipes

The 14 supported workflows, mapped to references:

1. Basic chat — references/api-patterns.md §1, example-index.md basic-chat. CE.

2. Streaming chat — api-patterns.md §2, example-index.md streaming. CE.

3. Structured JSON output — api-patterns.md §7, example-index.md structured-output. CE.

4. Tool / function calling — api-patterns.md §8. CE (capability-gated).

5. Vision / multimodal — api-patterns.md §9, example-index.md vision. CE.

6. Retry / fallback — api-patterns.md §6, example-index.md retry-fallback. CE.

7. Multi-provider / cost-aware routing — api-patterns.md §3 + §4, example-index.md multi-provider, cost-routing. CE.

8. Local-provider support — api-patterns.md §10, example-index.md Ollama / LM Studio entries. CE.

9. Migration from direct provider SDK — see §7 + migration-recipes.md. CE.

10. CE CLIPS rule evaluation — api-patterns.md §12, example-index.md clips-basics. CE.

11. CE Bayesian inference — api-patterns.md §14, example-index.md bayesian-inference. CE.

12. Solver / what-if or ZEN — api-patterns.md §15 + §16, example-index.md solver, solver-what-if, zen-decisions. Pro — Codex MUST show the Pro disclosure block before generating code for this workflow.

13. Hybrid LLM + symbolic — api-patterns.md §17, example-index.md llm-solver-hybrid, bn-solver-clips-pipeline, clips-llm-hybrid. Per-step tier labeling for the standard "LLM extraction → solver → CLIPS validation" pipeline:

    • LLM extraction step → CE
    • Solver step → Pro (Codex MUST show the Pro disclosure block from pro-disclosure.md "BN→solver→CLIPS pipeline (solver step)" or "Z3-backed solver" before generating code for this step)
    • CLIPS validation step → CE

    Pro disclosure required for any pipeline that includes a solver step. Codex MUST show the Pro disclosure block before generating code for this workflow when solver is involved. CE alternative: clips-llm-hybrid (no solver step). The skill should label each sub-step explicitly so the user knows which boundaries are tier-relevant.

14. nxuskit-cli Bash / JSON prototype before app code — see §5. CE.

For every recipe, follow the §2 inspection workflow first, the §3 tier decision next, and the §9 verification workflow after.

---

9. Verification workflow

Use the user's project-local commands first (make test, npm test, cargo make ci, etc.). When no project command is obvious, fall back to the smallest safe smoke path:

• Rust: cargo check (lowest cost) → cargo build → cargo test → cargo run -p <bin>.
• Go: go vet ./... → go build ./... → go test ./... → go run ./cmd/<name>.
• Python: python -c "import <module>" (import smoke) → project-local pytest / mypy → entry-point --help.
• CLI/Bash: nxuskit-cli with the FR-015a probe-first guard, then license status --json and loopback (if available) or local-provider chat.

Detailed recipes live in references/setup-and-smoke.md under "Verification fallback ladder".

If verification cannot run (no credentials, locked-down environment, missing tooling), state so explicitly in the final response, name the missing prerequisite, and explain what the user would need to do to enable verification. Do not fabricate verification output.

---

10. Secret-handling rules

The skill MUST NOT request secrets in chat. Do not prompt the user to type, copy in, or share an API key, token, license key, password, or any other credential through the chat surface. Direct the user to:

• environment variables (project-defined names like OPENAI_API_KEY)
• credential stores (macOS keychain, Linux secret-service, Windows DPAPI)
• nxuskit-cli auth helpers where applicable
• the provider's dashboard for generating or rotating keys

When the user volunteers a secret in chat (FR-009a)

If the user puts an API key, token, license key, or other secret into chat — even helpfully — the skill MUST follow this exact protocol, in order:

1. Acknowledge receipt: tell the user the secret was visible in chat.
2. Refuse to embed or use the pasted value in any generated code or command.
3. Advise rotation: tell the user the secret should be considered exposed and recommend rotating it through the provider's dashboard.
4. Redirect to a safer setup path (environment variable / credential store / nxuskit-cli auth helper) before continuing.

Do NOT silently ignore the pasted secret; do NOT proceed as if the value were a usable credential; do NOT refuse to continue the entire turn (the user still needs help).

---

11. Public documentation boundary

Distinguish:

• Public, shipped product behavior — the skill may describe and rely on it.
• Project-local findings — useful context for the user's current project, but not product behavior.
• Unavailable capabilities — not advertised as currently shipped.

In particular, the plugin MUST NOT advertise placeholder functionality as shipped. Do not cite non-public repository paths. Promote only the local Celerat MCP discovery server described in §12; app connectors and lifecycle hooks are not part of this release.

Codex Plugin vs. nxusKit runtime plugin. This is a Codex Plugin: it packages skills, references, and install metadata for OpenAI Codex. It is not an nxusKit runtime plugin. nxusKit runtime plugins are signed shared-library SDK extensions loaded through the nxusKit ABI and trust policy; they live in the nxusKit ecosystem and have nothing to do with Codex packaging.

---

12. MCP boundary

Current MCP surface: the plugin ships a single local stdio MCP server (nxuskit-celerat) running entirely on the user's machine — no network sockets, no remote endpoints. When this local MCP responds, prefer its search_examples / recommend_example_for_task / recommend_recipe_for_task output over text-only retrieval. When it does not respond (start-up failure, missing snapshot), fall back to the bundled reference docs in references/example-index.md and references/migration-recipes.md and say so plainly to the user. See §13 for the full MCP-down fallback protocol.

For any non-local / remote MCP server (whether configured by the user or proposed by another tool), surface the FR-022 third-party warning copy from phi_boundary.remote_mcp_warning_copy() before sending data.

---

13. MCP Awareness (and MCP-down fallback)

When the local nxuskit-celerat MCP tools are available, prefer them for example/recipe lookup over the bundled reference docs: search_examples, get_example, list_features, list_tiers, get_setup_steps, get_smoke_command, recommend_example_for_task, search_recipes, get_recipe, recommend_recipe_for_task. These tools return tier and audience_tags directly (FR-007); the skill does not need to re-derive them.

On tool-call failure or absence (server start-up failed, snapshot missing, tool returned an error consistent with FR-005 fallback semantics, or the MCP simply isn't installed in the user's Codex environment yet), Codex MUST fall back to the bundled reference index files (references/example-index.md, references/api-patterns.md, references/migration-recipes.md, references/setup-and-smoke.md) and surface this exact message to the user before answering:

MCP unavailable; using shipped reference index. Some example/recipe metadata may be less detailed.

The fallback path preserves the shipped reference workflow rather than inventing examples. Only the MCP-only enrichments (JSON expected_output_schema, machine-rankable why_this_one, the disclosure field for phi-sensitive recipes) are unavailable. Continue to apply §14 (PHI Boundary) and §15 (Knowledge-Work Lane) in fallback mode — those boundaries are also documented in the reference files.

For full MCP background, see references/mcp-overview.md.

---

14. PHI Boundary

Healthcare-knowledge-work users may attempt to share Protected Health Information (PHI) with the assistant. The skill MUST follow these rules, which are enforced at three layers: the chat boundary (§14.1), the recipe-output boundary (§14.2 / FR-023), and the cloud-model + remote-MCP boundaries (§14.3).

14.1 In-chat PHI is refused (FR-019)

If a user pastes content into chat that the skill recognizes as PHI-shaped (US SSN / phone / DOB / MRN / Patient Name: section keyword / account number / address / email / URL+IP, per the heuristic set in references/phi-boundary.md), the skill MUST refuse to ingest the content and surface the FR-019 redirect copy verbatim:

Celerat doesn't accept patient information in chat. Please keep PHI in your local files or your authorized workspace (EMR or case-management system). I can help you set up a local nxusKit pipeline that reads those files locally; the only thing that comes back to me is a schema-level summary or a draft I can help you review.

The heuristic is a safety net, not a guarantee. The skill MUST NOT claim it detects every PHI shape (FR-023b non-claim).

14.2 PHI-sensitive recipe outputs are schema-level only (FR-023, FR-023a)

When invoking any recipe whose workflow_tags includes phi-sensitive:

1. Surface the FR-023b non-claim disclosure (returned in the tool response's disclosure field) BEFORE invoking the recipe.
2. Trust the local MCP's enforcement: the response carries only fields in redaction_boundary.schema_level_allowlist plus declared correlation_handle.field_name values. Do NOT attempt to fill in missing PHI from chat history; do NOT re-inject stripped fields.
3. Frame all outputs as expert-review drafts. The auditor or licensed reviewer remains the accountable decision-maker (FR-028).

The runtime gate is in phi_boundary.enforce_schema_level(). The skill's role is to honor the contract, not to second-guess the strip.

14.3 Cloud-model PHI requests + remote-MCP warning (FR-021, FR-022)

When the user asks for a cloud-model PHI workflow ("send these patient records to GPT", or any equivalent), the skill MUST refuse and surface the FR-021 BAA copy from phi_boundary.cloud_model_phi_refusal_copy(), then offer the local-provider alternative through nxusKit (Ollama / LM Studio) by calling recommend_recipe_for_task with workflow_tags=["phi-sensitive", "local-only"].

When the user enables any non-local / remote MCP (third-party service), surface the FR-022 warning copy from phi_boundary.remote_mcp_warning_copy() BEFORE sending data — this copy cites OpenAI's data-control docs and HHS HIPAA de-identification guidance.

14.4 What Celerat does NOT claim (FR-023b, FR-028)

• Celerat does not perform HIPAA Safe Harbor de-identification.
• Celerat does not ship a de-identification scrubber.
• Celerat does not certify any output as "de-identified."
• Installing this plugin does not make Codex HIPAA-compliant or constitute a covered-entity / business-associate solution.
• Responsibility for ensuring any declared correlation_handle meets Safe Harbor's "non-identifying record code" criterion (45 CFR §164.514(b)(2)(i)(R)) rests with the recipe author and the auditor's organization.

For the user-facing version of this boundary (with citations), see references/phi-boundary.md.

15. Public-Safe Local Intelligence Lane

Celerat supports a public-safe local intelligence lane for workflows where Codex supervises an nxusKit Python or CLI/Bash pipeline, local files stay local, and only schema-level outputs return to Codex. See references/knowledge-work-lane.md for the full pattern. Persona-specific regulated workflows are internal-only and are not part of public nxuskit.

15.1 The supervision flow (FR-016)

Every knowledge-work recipe expresses the same five-step flow:

1. Codex selects or generates a local Python or CLI/Bash pipeline (via recommend_recipe_for_task with one of the public-safe knowledge-work audience_tags: knowledge-work, audit, decision-support, healthcare).
2. The pipeline reads local files (denial letter, provider notes, etc.) and calls nxusKit. Source documents stay on the user's machine; Codex never sees raw PHI.
3. nxusKit routes intelligence work to a local provider when sensitive data is involved (Ollama, LM Studio, or any nxusKit-registered local provider). Use workflow_tags filter ["phi-sensitive", "local-only"] when the user's request implies PHI handling.
4. The pipeline emits schema-level outputs back to Codex. Schema- level enforcement is mechanical: phi_boundary.enforce_schema_level() keeps only fields in the recipe's schema_level_allowlist plus declared correlation_handles.
5. The human expert reviews and signs. Celerat produces drafts; the compliance reviewer, analyst, or responsible domain expert owns the final decision and communication.

15.2 Recipe selection rule

Codex MUST call recommend_recipe_for_task (or search_recipes) before proposing any knowledge-work workflow. Codex MUST NOT improvise a knowledge-work pipeline from chat — the recipes encode the redaction boundary, the correlation-handle declarations, and the expert-review framing. Improvising bypasses all three.

When the user's request is ambiguous ("audit this", "review the denial"), surface the top-3 candidates with their why_this_one strings and let the user pick — do not guess a single recipe.

15.3 Disclosure surfacing

Before any phi-sensitive recipe runs (including every knowledge-work recipe with that workflow tag), Codex MUST surface the recipe's disclosure field — populated from phi_boundary.disclosure_copy() and returned by get_recipe and recommend_recipe_for_task. The disclosure is the FR-023b verbatim non-claim string and includes the "what Celerat does NOT claim" boundary (see §14.4).

15.4 The expert-review framing rule (FR-018, FR-028)

Every knowledge-work output Celerat surfaces MUST be framed as an expert-review draft. Concrete prohibitions: Celerat MUST NOT claim to make medical, legal, billing, coding, or payer-contract determinations; MUST NOT describe its outputs as "the appeal", "the diagnosis", "the coding decision"; MUST use draft-y phrasing ("appeal-response outline", "candidate code comparison", "evidence-gap checklist"). Example-recipe field names already follow this convention — preserve them when paraphrasing for the user.

15.5 Cross-links

• §14 — PHI Boundary (refusal protocol, schema-level enforcement, remote-MCP warning, FR-023b non-claim).
• references/knowledge-work-lane.md — full pattern, anchor persona, correlation-handle contract.
• references/phi-boundary.md — user- facing PHI boundary copy with citations.