Skills

A skill is a workflow guide the agent loads on demand — how to author a Ferro case, how to drive the solver daemon, how to build a conjugate heat-transfer case in OpenFOAM. Skills are what make the agent good at specific engineering work rather than generically capable.

How they work

Each skill is a folder containing a SKILL.md and any reference files it needs. The frontmatter carries a name and a description; the body carries the actual instructions.

The agent sees only the name and description up front. When a task matches one, it reads the body from disk and follows it. That is why skills scale: thirty skills cost thirty one-line descriptions of context, not thirty documents.

Qubis ships its bundled skills to your config directory on first launch and refreshes them when you upgrade:

<config>/prism/skills/
├── .system/          ← bundled skills, replaced on upgrade
│   ├── ferro-config-skill/
│   ├── solver-daemon/
│   └── …
└── my-skill/         ← your own skills, never touched

A skill of yours with the same name as a bundled one overrides it. That is the supported way to customize shipped behaviour — copy it out of .system/, edit it, and it wins.

Browsing and toggling

The Skills scope on the Plugins page lists every skill available — your own, the ones plugins contribute, and Qubis's. They are on by default; turn one off and the agent stops seeing it entirely. A plugin's skills are the exception — they follow the plugin's own switch.

Turning a skill off is useful when it is pulling the agent toward a workflow you do not want for this project.

What ships with Qubis

Design and CAD

Analysis

Third-party solvers

solver-daemon covers the daemon itself and the general run loop, plus a per-solver authoring guide for each supported solver family's input format:

openfoam-cht-multiregion, openfoam-marine-cfd, and openfoam-sand-casting are separate skills, one per OpenFOAM application area, sharing the case grammar that solver-daemon holds for them; Code_Aster, SU2, CalculiX, Elmer, Yade, OpenModelica, ngspice, Basilisk, and Chrono are covered by guides bundled with solver-daemon. openEMS and Palace guides cover the two electromagnetic runtimes.

Deliverables

engineering-reports writes from house Typst templates — structural and CFD analysis, trade study, algorithm description, technical memo — each with the title block, sign-off, and numbering already set, and compiles the document to PDF. It refuses to call a report finished while a template placeholder is still in it.

A CFD or FEA report shows the mesh, the convergence history, and views of the fields themselves, rendered from the run's own volume output rather than left as line plots; views taken from a run that did not converge are labelled provisional, and a rendered view the document never cites is caught before the report is called finished.

Cloud compute

remote-compute covers running a solver command on Qubis Cloud: picking a machine and a registered solver image, uploading inputs, approving a priced job, recovering a submission whose outcome is unknown, and choosing which outputs to download. The agent sees it only where Remote Compute is turned on for the conversation's organization. See Running on Qubis Cloud.

Modeling and simulation

stellarust for building, running, and analyzing Rust block-diagram models, and inspecting .stella and .bode results in Qubis. It covers SDK setup, model composition, control, estimation, and deployment without prescribing a particular application. A Stellarust SDK and Rust toolchain are required separately.

ardupilot covers ArduCopter SITL and MAVLink.

Writing your own

A skill is worth writing when you find yourself explaining the same thing to the agent repeatedly — your organization's material conventions, a naming scheme for cases, the steps in your validation process.

Create one from the Skills tab, by hand, or by asking the agent for it — your own skills folder is a place the agent may write, so it can author and revise skills there under the usual edit rules. Only .system/ is off limits to it.

By hand:

<config>/prism/skills/my-workflow/SKILL.md

---
name: my-workflow
description: One sentence on when the agent should reach for this skill.
---
 
# My workflow
 
The instructions, conventions, and rules the agent should follow.
Reference bundled files in this folder by relative path.

What makes a good skill

• The description is the trigger. It is the only part the agent sees before deciding to load the skill. Write it as "use this when…", concretely, naming the tools and file types involved.
• Be prescriptive in the body. A skill is not documentation for a human — it is instructions. Say what to do, in order, with the exact tool names.
• Name the failure modes. "Do not shell out to docker; use the prism_solver_* tools" is worth more than three paragraphs of context.
• Keep resources beside it. Templates, example inputs, and reference material go in the same folder and are referenced by relative path.

Skills vs. MCP servers

They solve different problems, and it is worth not confusing them:

• A skill is knowledge. It teaches the agent how to do something with tools it already has.
• An MCP server is capability. It gives the agent tools it did not have.

See Plugins & MCP.