Quox as a Claude extension · Quoxpert
Point your Claude at Quoxpert. It becomes a pro user of your estate.
Quoxpert is an installable Agent Skill family that teaches a Claude to drive your Quox estate through its own governed tooling, so "set up Quox and connect my fleet" produces the actual sequence and the correct flags instead of a confident guess.
Proven daily inClaude CodeTeachesCLI · MCP · flow · fleetLicenceApache-2.0Releasev0.1 early accessIn plain words
What it is, where it lives, when to reach for it
- What is it
- A family of Agent Skills, plain markdown files that teach a Claude to operate a Quox installation.
- Where do I use it
- In a Claude Code session; that is where it runs proven, other Claude surfaces are untested by us.
- When would I use it
- When you want your Claude to drive Quox with the right commands instead of confident guesses.
- How do I use it
- Not installable today: the repository goes public at launch. Then you install the skill files and ask your Claude for
quoxpert.
The problem
A capable model with no idea which lever is yours
Every other Quox integration points one way: Claude extends Quox. Quoxpert flips the arrow.
Point a frontier model at a platform it has never seen and it will help you confidently in the wrong direction. It will invent a command that reads correctly, reach for an endpoint that does not exist, and route around the approval gate it did not know was there. The model is not the problem. The missing thing is operating knowledge of your specific estate.
Quoxpert is that knowledge, packaged as skills. It is written in the SKILL.md format Anthropic ships for Claude Code, Claude Desktop, claude.ai and the Agent SDK.
Claude Code is where it runs proven, daily, on our own estate; the other surfaces take the same skill format but carry their own setup steps and have not been driven by us end to end. The audience is external on purpose: a customer's Claude, a prospect's Claude evaluating the platform, a plugin developer's Claude.
The rule every line in it is written against: does this work on a machine that has only ever installed Quox from quox.ai? If a recipe assumes a source checkout or internal build tooling, it is not a Quoxpert recipe.
How it works
Skills load, verbs are real, evidence still lands
Four moves separate an installed skill family from a prompt full of pasted documentation. The tag under each card says where that move is true today.
One index, then one sub-skill
The root skill is a routing table, not a manual. Claude reads it, decides that the task is a fleet task, and loads only quoxpert-bastion. Per-load context stays small however far the catalogue grows, which is what keeps the answers specific instead of generic.
Governed verbs, not guesses
A Claude without Quoxpert invents plausible commands. A Claude with it reaches for the real ones: 76 command groups and 384 invocable commands across the quox CLI, the MCP tool surface, and the workflow engine underneath.
It respects the gates it teaches
Quoxpert teaches Claude to work with the approval inbox, not around it. A destructive operation still routes to a human whether it was triggered from the dashboard, the CLI or a Claude wielding QuoxMCP, and every governed action still emits its evidence.
A stale skill teaches wrong Quox
Confidently wrong is worse than absent. Each sub-skill splits into generated blocks regenerated from the source of truth each repo already maintains, and hand-authored recipes verified against a live instance. A drift check fails the build when a surface moves and its sub-skill has not.
The catalogue
14 shipped sub-skills, 9 in validation
Load the root skill to route, then load only the one sub-skill the task needs. The validation set is authored and in daily internal use, held back from the public catalogue until every recipe in it is a verified live transcript.
quoxpert
The root index: orientation, the 30-second mental model, and routing to the sub-skill that matches the task.
quoxpert-core
The QuoxCORE platform itself: architecture, agents, memory, plugins, and which service owns a symptom.
quoxpert-cli
The quox CLI and TUI: scripted, terminal-driven control of an instance, and automating Quox in CI.
quoxpert-mcp
QuoxMCP install and tool-wielding: the RBAC-gated tool surface a Claude can call directly.
quoxpert-flow
The quoxflow workflow engine: node executors, the expression sandbox, the policy DSL, and the HITL gate.
quoxpert-bastion
QuoxBastion and the quoxagent sidecar: host inventory, governed SSH execution, agent deploy, fleet health.
quoxpert-plugin-sdk
Building .quoxplugin extensions: the scaffolder, the runtime helpers, and the install path.
quoxpert-protocols
Reading and verifying evidence across the four governance protocols, in one sub-skill.
quoxpert-deploy
Install, configure, upgrade, back up and restore an instance, including the Compose stack and TLS.
quoxpert-qluster
Qluster, the fleet control plane across your own Quox boxes: monitor, enroll, check, back up, delegate.
quoxpert-convert
Turning an existing tool (an MCP server, a chat-ops bot, a monitoring dashboard) into a Quox plugin.
quoxpert-publish
Distributing and monetising a plugin: signing, licensing, and an honest map of what is not live yet.
quoxpert-repobrain
RepoBrain: structure-first code retrieval that returns the right snippet instead of a whole-file dump.
quoxpert-quoxplan
QuoxPlan: reading and writing roadmap and stream state from the CLI, the TUI, the dashboard or an agent.
In internal validation
quoxpert-qloopin validation
QLoop, the governed agentic loop: capability scopes, live checkpoint gates, and the witnessed turn trail.
quoxpert-qlarityin validation
Qlarity, governed browser inspection: computed styles, DOM reads, and why arbitrary eval is always an approval.
quoxpert-quoxslotsin validation
QuoxSlots: durable, org-scoped session addresses that ephemeral sessions check out and release.
quoxpert-quoxbuildin validation
QuoxBuild: the serialised build queue, coalescing duplicate requests across parallel sessions.
quoxpert-dev-serversin validation
Dev Servers: the hub that turns a managed host into a governed dev server under one capability profile.
quoxpert-gripein validation
Gripe: one-liner complaint to filed issue, and the triage path that picks it up.
quoxpert-discordin validation
Quox Discord Pro: the daemon bridging a Discord server to QuoxCORE, binding modes and health checks.
quoxpert-devsuitein validation
The Dev Suite as a whole: which plugin owns which capability, and which sub-skill to load next.
quoxpert-securityin validation
Quox Security engagements: scopes, risk tiers, target verification, and honest maturity per tool.
Install
Two paths, same skills
Early access. The commands below are the exact install paths that work the moment the repository goes public: quoxai/quoxpert is private while the sub-skills finish drift-checking, so there is nothing to run yet if you are reading this ahead of launch.
The recommended path. Adds the repository as a Claude Code plugin marketplace, then installs the plugin: versioned, with a built-in update path.
/plugin marketplace add quoxai/quoxpert
/plugin install quoxpertThe fallback for bare skill directories, headless boxes, and anything that is not Claude Code's plugin system. Copies the skills into ~/.claude/skills/.
curl -fsSL https://quox.ai/quoxpert/install.sh | bashNever paste a secret into a chat. Quoxpert teaches Claude where your collector URL, org id and service key live and how to wire them in. It never asks you to paste one into the conversation. To connect a live instance, follow the QuoxMCP install guide: the bundle and the CLI prompt for those fields in a form, not in chat.
Imagine this
Many fleets, mostly minding themselves
Read this section as a picture of where the pattern is going, not as a feature list. Nothing below is a purchase you can make today. Where a piece of the picture already exists, the card says which piece and stops there.
Quoxpert is the piece that makes this thinkable: if operating knowledge is installable, then every session on every box starts competent, and the interesting question stops being “can it drive the platform” and becomes “how much should it drive without asking”. That question is answered by governance, which is the part Quox has actually built.
Every box knows the product
A Claude wakes on a fleet host and does not have to be told what Quox is. The skills are already there, delivered by registration, so it opens with the right verb instead of an hour of orientation. That part is real today: the pack reaches dev-capable hosts.
Fleets that keep their own house
Each box runs its own patrols against its own surfaces, files what it finds as evidence-backed findings rather than a log line nobody reads, and fixes what it is scoped to fix. The operator reads findings, not dashboards.
Fleets that talk to each other
One box finishes a migration and tells the next what it learned. Work moves between boxes as governed messages with the evidence attached, so a second fleet starts from the first fleet's proof instead of from scratch.
A human in the loop, only where it counts
Autonomy stops at the approval. Anything irreversible, anything that spends money, anything outside the scope waits in one inbox for a person. That gate is not aspirational: approvals already refuse a non-human actor server-side, everywhere.
The honest summary of the four cards above: the skill delivery is live, the approval gate is live and server-side, the patrols are human-started on a governed dev box, and cross-fleet coordination is not built. The limits band below carries all of it in one place.
The resident pattern
QUOXPERTICUS: a Claude that stays with the instance
Quoxpert teaches a Claude to operate Quox. QUOXPERTICUS is what happens when one of them stops leaving. It is a working internal pattern on a governed dev instance, not a product you can install, and the governance underneath it shipped first on purpose.
A Claude that lives on the box
QUOXPERTICUS is the resident pattern built on Quoxpert: a session that stays with an instance and uses the same skills to operate it as its own first power user. It exercises surfaces the way a customer would and files what breaks.
Off by default, everywhere
The pattern is switched per instance through a server-side mode: OFF, OBSERVE, PARTIAL, FULL. OFF is the default on every instance. The full mode is reachable only on a disposable test instance; a production instance caps below it by construction.
Witnessed individuation
Every agent is born identical. What makes one become someone is retained experience no other instance shares. On each wake it recalls its narrative-self, open loops and last message to its next self; at the end of a run it commits a self-delta onto a hash-chained, witnessed self-log you can inspect, roll back, or prune a bad lesson from.
The slot mode it still needs
At its best the resident pattern holds a durable session address, so you talk to the resident rather than to whichever session happens to be alive. QuoxSlots is the substrate for exactly that. The integration between the two is designed and not yet coded, and the limits band below says so first.
The one designed exception to human-only approvals is a disposable test instance holding a time-boxed, leased test-approver credential, where approvals are performed by a synthetic principal and every one is witnessed as an agent-driven test approval. No agent identity sits on an approval record, even in the sandbox.
Limits
What is real, what is in validation, what is not built
The skill family is real and in daily use. The resident agent is a pattern, not a product. Everything that separates the two is in this band rather than buried in the prose above it.
- The Quoxpert skill family itself: installed on our own machines and used every working day to drive the quox CLI, the MCP tool surface, the workflow engine, the fleet, plugins and the governance protocols
- The routing shape: a root index that loads one sub-skill per task, so a session pays for the recipes it needs and not the catalogue
- Skill delivery to dev-capable hosts through the signed skill pack, so a Claude that wakes on a governed dev server already has the recipes
- Server-side approval hardening at every sink: no agent, resident or otherwise, can resolve an approval, approve its own plan, or skip a pre-start gate in any real context
- The per-instance QUOXPERTICUS mode (OFF, OBSERVE, PARTIAL, FULL) with its admin surface, OFF by default everywhere
- The continuity self-log and its recall/commit tool, and a first-class governed agent identity, both driven on a governed dev instance with the evidence chain intact
- First patrols run under a human-approved gate on a disposable test box, each one growing the continuity chain by one anchored self-delta
- Nine further sub-skills are authored and in daily internal use but held out of the public catalogue until every recipe in them is a verified live transcript rather than a plausible one
- Every recipe in a shipped sub-skill is a transcript run against a live instance during authoring. The bar for the validation set is the same bar, not a lower one
- The public install paths are the exact commands that will work at launch. quoxai/quoxpert is a private repository today, so there is nothing to run yet if you are reading this ahead of it going public
- A drift check fails the build when a Quox surface moves and its sub-skill has not been updated, so the catalogue cannot rot silently. It cannot prove a recipe is still the BEST way to do something, only that it still matches the surface
- QUOXPERTICUS is a working internal pattern, not a shipped product. There is no packaged, installable, supported QUOXPERTICUS you can buy or enable today, and this page will keep saying so until there is
- Its session-based slot mode, the durable session address that the resident pattern needs to be at its best, is DESIGNED AND NOT YET CODED
- An unattended patrol that runs cleanly end to end without a human starting it has not happened. Every patrol so far was human-started behind an approval gate
- Nothing in the resident pattern has been promoted to a production instance. Governed dev today, not prod
- The multi-fleet story on this page (fleets coordinating with each other, handing work and evidence across boxes) is a scenario. Cross-fleet handover is not built, and no part of it should be read as a shipped capability
Quoxpert
Your Claude already knows how to code. Teach it your estate.
Open source, Apache-2.0, early access. Install once and every session after it starts competent.