Coming soonOOMU is launching soon. Downloads will open at launch.
OOMU
← All documentation

Tutorials

Adding Custom Capabilities (OOMU Mods)

A Mod is a self-contained capability package you can add to OOMU. Mods come as a single .oomu file and can give your assistants new behaviours; a house style, a domain expertise, a custom workflow.

This tutorial shows you how to install one safely and switch it on for an assistant.

What a Mod is (and isn't)

A Mod is a single .oomu file; a sealed package containing everything the capability needs. You add it to OOMU much like dragging an app into Applications: one file, one step, fully contained.

Mods range from simple to powerful. Some just shape how your assistant writes (a house tone, a domain expertise); others add real features; for example, an in-app web-browsing panel for live research, or an optimisation that speeds up on-device thinking. The more a Mod can do, the more it has to declare up front.

Crucially, a Mod is not a traditional plugin with free run of your computer. OOMU installs each Mod into your private workspace, records exactly what it declares it can do, and only ever lets it act through OOMU's permission and safety systems. You stay in control. (For the full reasoning, see Privacy & Sandboxing.)

Step 1; Open or drag in a .oomu package

There are two ways to install a Mod:

  • Choose a file: In the Mods area, select *Install* and pick your .oomu package from disk.
  • Drag and drop: Drag a .oomu file straight into the Mods area.

OOMU only accepts files with the .oomu extension. If you pick anything else, it declines politely rather than guessing.

Step 2; Read the safety summary before you confirm

Before a Mod is installed, OOMU inspects the package and shows you a review card:

  • Who made it, and whether OOMU checked it. OOMU distinguishes two separate things, and never conflates them:
  • Publisher identity; "Made by a known publisher (identity confirmed)" tells you *who* published it. As OOMU puts it, this "tells you who published it, not whether it is safe."
  • Review status; "Reviewed by OOMU" means OOMU inspected what the bundle declares and tested its included workflows. A Mod from outside carries a clear warning: *"No one at OOMU has reviewed what it can do. Only continue if you trust {publisher}."*
  • What this adds; each capability written as a plain sentence: *"Can create and change files in …," "Can connect to … on the internet," "Can use your connected … account," "Can use the … model."* A Mod that asks for nothing extra says so.
  • Which Projects can use it; you choose the Projects a Mod is installed for. It has no access to Projects you didn't select.

OOMU also checks the package itself: it must be a valid .oomu archive, within size limits, and structurally sound, with a verified signature and no forbidden or executable content. Packages that are malformed, oversized, unsigned where signing is required, or contain too many files are rejected before anything is installed.

Signing proves provenance, not safety. A signature identifies *who* built a package; it does not make the package trustworthy. Treat a .oomu file like any other download: install Mods from people and organisations you trust. OOMU's sandbox limits what a Mod can reach and enforces exactly the access it declared, but you are still the one deciding to add it.

When you're comfortable, acknowledge the trust prompt (for unreviewed packages) and confirm the install. OOMU unpacks the Mod into your workspace, transactionally, and adds it to your installed list; with a clean rollback if anything fails.

Step 3; Switch it on

Installing a Mod doesn't automatically make it active. A Mod takes effect only when both of these are true:

  1. The Mod is active (the global on/off toggle in your Mods list), and
  2. The Mod is bound to the assistant you're using.

This two-step design is deliberate: it means a Mod can sit installed-but-dormant until you deliberately attach it to a specific assistant. Nothing changes your assistants' behaviour by surprise.

To switch a Mod on for an assistant:

  1. Toggle the Mod Active in your Mods list.
  2. Open the assistant you want to extend and bind the Mod to it.

That's it. The next message you send to that assistant runs with the Mod's capability applied.

Try it: A simple example Mod might enforce a house tone of voice on every reply. Bind it to one assistant, leave another unbound, and send both the same question; you'll see exactly what the Mod changes, and what it leaves alone.

Step 4; Turn it off or remove it

  • Unbind the Mod from an assistant to stop it affecting that assistant, while keeping it installed.
  • Deactivate the Mod globally to switch it off everywhere at once.
  • Uninstall the Mod to remove its files from your workspace entirely.

You're never locked in.

You've installed your first Mod

You now know how to add a capability, review what it can do, and control exactly which assistants use it.

Where to next