# Nxuskit

> Use when a user asks Codex to add, migrate, prototype, or explain nxusKit SDK integrations, provider-agnostic LLM workflows, nxuskit-cli CLI/Bash workflows, CLIPS rules, Bayesian inference, solver/ZEN workflows, or hybrid LLM plus symbolic reasoning patterns.

- Skill: `nxus-systems/nxuskit` (Agent Skill, multi-file: 11 files)
- Install (CLI): `npx skillmds@latest add nxus-systems/nxuskit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nxus-systems/nxuskit/raw
- Safety review: pending (external: skill-scanner PASS, skillspector CAUTION)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: nxus-SYSTEMS (https://skillmd.com/u/nxus-systems)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nxus-systems/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:

```bash
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)

```bash
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`](./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`](./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`](./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`](./references/knowledge-work-lane.md)
  — full pattern, anchor persona, correlation-handle contract.
- [`references/phi-boundary.md`](./references/phi-boundary.md) — user-
  facing PHI boundary copy with citations.