Skip to content

Plugins

A plugin is created with definePlugin and declares an id, a name, a version, and apiVersion: 1. Aura v1 loads only plugins declaring apiVersion: 1; anything else is rejected at registration.

Every slot is optional.

Slot Purpose
adapters Detect an agent application, declare files for core to read, parse contents into a normalized snapshot.
checks Synchronously inspect the WorkspaceModel and optionally return a FixPlan.
snippets Reference Markdown files.
skills Reference skill directories.
skillSources Build-time drivers that list and resolve external skills.
mcpCatalog Reference JSON MCP catalog entries.
presets Reference JSON preset definitions.

Every contribution id must be namespaced under the plugin’s own id. Plugin acme contributes acme/rules, never rules. The registry validates versions, IDs, collisions, and referenced content before any of it is used.

Content references must be absolute file: URLs, constructed relative to the plugin module:

const url = new URL("./content/preset.json", import.meta.url).href;

Working-directory-relative paths do not work. Existence and schema validation happen when the registry loads the contribution, not at first use.

Plugin authors need @types/node in their tsconfig for the import.meta.url idiom above.

Checks are synchronous and pure. They never read from disk or inspect the process environment. A check emits DetectedFinding values carrying only occurrence-specific data — id, message, and optionally details, locations, metadata, and a severity override. Core stamps on checkId, scope, and the resolved severity, so a finding cannot contradict the check that produced it.

WorkspaceModel spans every application, so a check sees instruction content and MCP configuration contributed by adapters from other plugins. Do not copy InstructionDocument content into a finding.

The SDK README carries the complete type surface and a worked example plugin that is compiled as a type test.