How plugins work

The core is your notes plus three commands: ingest, recall, and check. Everything else is a plugin you add when you want it and remove with one line. The core finds plugins by the name of their folder and never depends on one (the only plugin names it carries are a display hint for imprnt plugin list).

Every plugin is one of three kinds, by how it reaches the assistant. The switches below are live: pull a kind out of its socket and watch what happens to the core.

corevault + ingest · recall · check

switches flipped: 0edits to core: 0

Data

a mirror that proposes notes

Mirrors an outside service into its own folder. A sync you run refreshes it, then it proposes notes you approve.

Behavior

a prompt fragment, wired in

Feeds the assistant a fixed prompt fragment you wire in. Removing it is deleting one line. The vault never force-feeds it.

Harness

change the session runtime

Changes the session runtime, like a hook or the status line. Plain claude stays plain. Only imp sessions see it.

Each kind leans on the core, and the core depends on none of them. Flip a switch to pull one out and watch the counters.

the one rule

You can add or remove any plugin with zero edits to core code.

If a plugin forces a core edit, the plugin is wrong. That is what stops imprnt from growing to know about every add-on, the rot that bloats this kind of system over time.

a plugin depends on exactly two things

your notes plus the way their headers are written + its own folder the only place it ever writes

Nothing else: not imprnt's own code, not another plugin's folder. The one bend: a plugin may also ask a small helper another plugin runs on your machine, and it keeps working, just with less, when that helper is gone. Each plugin ships as its own package, imprnt-plugin-<name>.

install, list, remove

imprnt plugin list# what is installed
imprnt plugin add anti-slop# add one
imprnt plugin rm anti-slop# remove one

How a plugin reaches Claude

A plugin is a folder with one instruction file, agent.md, that tells the assistant what the plugin is and how to use it. Installing the plugin loads that file into your sessions, and where it loads decides the reach.

project the default

agent.md → this project's sessions, plus every imp session (it inlines the project's plugins from any directory)

add

imprnt plugin add <name>

wires in

CLAUDE.local.md, per-machine, never committed

remove

imprnt plugin rm <name>

global a house style like anti-slop

agent.md → every session imp launches, even with no vault project

add

imprnt global add <name> promotes an installed project plugin (or pass --from <dir>)

wires in

registered with imprnt, never your ~/.claude/CLAUDE.md

remove

imprnt global rm <name>

Four rules keep the core blind

1

A plugin reads your notes, not the core

A plugin opens your note files like any script would, and never imports imprnt's own code. So the core can change without breaking the plugin.

2

A plugin never edits your notes

A plugin writes only inside its own folder. To change one of your notes, the plugin hands you the edit and you approve it.

3

Search only sees your vault

Recall looks at your real notes, never a plugin's folder. A plugin gets into search only by proposing a note you approve.

4

Nothing runs on its own

A plugin acts only when you run or schedule it. Any label a plugin adds to your notes is name-tagged, so the core ignores it.

For the plugins themselves, head to the Plugins section in the sidebar: each page there covers one plugin, what it does, and the command that adds it.