Skip to main content

Plugin manifest (velaclaw.plugin.json)

This page is for the native Velaclaw plugin manifest only. For compatible bundle layouts, see Plugin bundles. Compatible bundle formats use different manifest files:
  • Codex bundle: .codex-plugin/plugin.json
  • Claude bundle: .claude-plugin/plugin.json or the default Claude component layout without a manifest
  • Cursor bundle: .cursor-plugin/plugin.json
Velaclaw auto-detects those bundle layouts too, but they are not validated against the velaclaw.plugin.json schema described here. For compatible bundles, Velaclaw currently reads bundle metadata plus declared skill roots, Claude command roots, Claude bundle settings.json defaults, Claude bundle LSP defaults, and supported hook packs when the layout matches Velaclaw runtime expectations. Every native Velaclaw plugin must ship a velaclaw.plugin.json file in the plugin root. Velaclaw uses this manifest to validate configuration without executing plugin code. Missing or invalid manifests are treated as plugin errors and block config validation. See the full plugin system guide: Plugins. For the native capability model and current external-compatibility guidance: Capability model.

What this file does

velaclaw.plugin.json is the metadata Velaclaw reads before it loads your plugin code. Use it for:
  • plugin identity
  • config validation
  • auth and onboarding metadata that should be available without booting plugin runtime
  • cheap activation hints that control-plane surfaces can inspect before runtime loads
  • cheap setup descriptors that setup/onboarding surfaces can inspect before runtime loads
  • alias and auto-enable metadata that should resolve before plugin runtime loads
  • shorthand model-family ownership metadata that should auto-activate the plugin before runtime loads
  • static capability ownership snapshots used for bundled compat wiring and contract coverage
  • cheap QA runner metadata that the shared velaclaw qa host can inspect before plugin runtime loads
  • channel-specific config metadata that should merge into catalog and validation surfaces without loading runtime
  • config UI hints
Do not use it for:
  • registering runtime behavior
  • declaring code entrypoints
  • npm install metadata
Those belong in your plugin code and package.json.

Minimal example

Rich example

Top-level field reference

providerAuthChoices reference

Each providerAuthChoices entry describes one onboarding or auth choice. Velaclaw reads this before provider runtime loads.

commandAliases reference

Use commandAliases when a plugin owns a runtime command name that users may mistakenly put in plugins.allow or try to run as a root CLI command. Velaclaw uses this metadata for diagnostics without importing plugin runtime code.

activation reference

Use activation when the plugin can cheaply declare which control-plane events should activate it later.

qaRunners reference

Use qaRunners when a plugin contributes one or more transport runners beneath the shared velaclaw qa root. Keep this metadata cheap and static; the plugin runtime still owns actual CLI registration through a lightweight runtime-api.ts surface that exports qaRunnerCliRegistrations.
This block is metadata only. It does not register runtime behavior, and it does not replace register(...), setupEntry, or other runtime/plugin entrypoints. Current consumers use it as a narrowing hint before broader plugin loading, so missing activation metadata usually only costs performance; it should not change correctness while legacy manifest ownership fallbacks still exist.
Current live consumers:
  • command-triggered CLI planning falls back to legacy commandAliases[].cliCommand or commandAliases[].name
  • channel-triggered setup/channel planning falls back to legacy channels[] ownership when explicit channel activation metadata is missing
  • provider-triggered setup/runtime planning falls back to legacy providers[] and top-level cliBackends[] ownership when explicit provider activation metadata is missing

setup reference

Use setup when setup and onboarding surfaces need cheap plugin-owned metadata before runtime loads.
Top-level cliBackends stays valid and continues to describe CLI inference backends. setup.cliBackends is the setup-specific descriptor surface for control-plane/setup flows that should stay metadata-only. When present, setup.providers and setup.cliBackends are the preferred descriptor-first lookup surface for setup discovery. If the descriptor only narrows the candidate plugin and setup still needs richer setup-time runtime hooks, set requiresRuntime: true and keep setup-api in place as the fallback execution path. Because setup lookup can execute plugin-owned setup-api code, normalized setup.providers[].id and setup.cliBackends[] values must stay unique across discovered plugins. Ambiguous ownership fails closed instead of picking a winner from discovery order.

setup.providers reference

setup fields

uiHints reference

uiHints is a map from config field names to small rendering hints.
Each field hint can include:

contracts reference

Use contracts only for static capability ownership metadata that Velaclaw can read without importing the plugin runtime.
Each list is optional:

channelConfigs reference

Use channelConfigs when a channel plugin needs cheap config metadata before runtime loads.
Each channel entry can include:

modelSupport reference

Use modelSupport when Velaclaw should infer your provider plugin from shorthand model ids like gpt-5.4 or claude-sonnet-4.6 before plugin runtime loads.
Velaclaw applies this precedence:
  • explicit provider/model refs use the owning providers manifest metadata
  • modelPatterns beat modelPrefixes
  • if one non-bundled plugin and one bundled plugin both match, the non-bundled plugin wins
  • remaining ambiguity is ignored until the user or config specifies a provider
Fields: Legacy top-level capability keys are deprecated. Use velaclaw doctor --fix to move speechProviders, realtimeTranscriptionProviders, realtimeVoiceProviders, mediaUnderstandingProviders, imageGenerationProviders, videoGenerationProviders, webFetchProviders, and webSearchProviders under contracts; normal manifest loading no longer treats those top-level fields as capability ownership.

Manifest versus package.json

The two files serve different jobs: If you are unsure where a piece of metadata belongs, use this rule:
  • if Velaclaw must know it before loading plugin code, put it in velaclaw.plugin.json
  • if it is about packaging, entry files, or npm install behavior, put it in package.json

package.json fields that affect discovery

Some pre-runtime plugin metadata intentionally lives in package.json under the velaclaw block instead of velaclaw.plugin.json. Important examples: velaclaw.install.minHostVersion is enforced during install and manifest registry loading. Invalid values are rejected; newer-but-valid values skip the plugin on older hosts. velaclaw.install.allowInvalidConfigRecovery is intentionally narrow. It does not make arbitrary broken configs installable. Today it only allows install flows to recover from specific stale bundled-plugin upgrade failures, such as a missing bundled plugin path or a stale channels.<id> entry for that same bundled plugin. Unrelated config errors still block install and send operators to velaclaw doctor --fix. velaclaw.channel.persistedAuthState is package metadata for a tiny checker module:
Use it when setup, doctor, or configured-state flows need a cheap yes/no auth probe before the full channel plugin loads. The target export should be a small function that reads persisted state only; do not route it through the full channel runtime barrel. velaclaw.channel.configuredState follows the same shape for cheap env-only configured checks:
Use it when a channel can answer configured-state from env or other tiny non-runtime inputs. If the check needs full config resolution or the real channel runtime, keep that logic in the plugin config.hasConfiguredState hook instead.

JSON Schema requirements

  • Every plugin must ship a JSON Schema, even if it accepts no config.
  • An empty schema is acceptable (for example, { "type": "object", "additionalProperties": false }).
  • Schemas are validated at config read/write time, not at runtime.

Validation behavior

  • Unknown channels.* keys are errors, unless the channel id is declared by a plugin manifest.
  • plugins.entries.<id>, plugins.allow, plugins.deny, and plugins.slots.* must reference discoverable plugin ids. Unknown ids are errors.
  • If a plugin is installed but has a broken or missing manifest or schema, validation fails and Doctor reports the plugin error.
  • If plugin config exists but the plugin is disabled, the config is kept and a warning is surfaced in Doctor + logs.
See Configuration reference for the full plugins.* schema.

Notes

  • The manifest is required for native Velaclaw plugins, including local filesystem loads.
  • Runtime still loads the plugin module separately; the manifest is only for discovery + validation.
  • Native manifests are parsed with JSON5, so comments, trailing commas, and unquoted keys are accepted as long as the final value is still an object.
  • Only documented manifest fields are read by the manifest loader. Avoid adding custom top-level keys here.
  • providerAuthEnvVars is the cheap metadata path for auth probes, env-marker validation, and similar provider-auth surfaces that should not boot plugin runtime just to inspect env names.
  • providerAuthAliases lets provider variants reuse another provider’s auth env vars, auth profiles, config-backed auth, and API-key onboarding choice without hardcoding that relationship in core.
  • channelEnvVars is the cheap metadata path for shell-env fallback, setup prompts, and similar channel surfaces that should not boot plugin runtime just to inspect env names.
  • providerAuthChoices is the cheap metadata path for auth-choice pickers, --auth-choice resolution, preferred-provider mapping, and simple onboarding CLI flag registration before provider runtime loads. For runtime wizard metadata that requires provider code, see Provider runtime hooks.
  • Exclusive plugin kinds are selected through plugins.slots.*.
    • kind: "memory" is selected by plugins.slots.memory.
    • kind: "context-engine" is selected by plugins.slots.contextEngine (default: built-in legacy).
  • channels, providers, cliBackends, and skills can be omitted when a plugin does not need them.
  • If your plugin depends on native modules, document the build steps and any package-manager allowlist requirements (for example, pnpm allow-build-scripts
    • pnpm rebuild <package>).