All News
NewsDeveloper Experience

OpenClaw Finally Documented Its Plugin System. The Timing Is Revealing.

Three PRs landed on March 22: a rewritten manifest reference, an auto-generated SDK baseline with CI drift detection, and version gating that prevents incompatible plugins from crashing at runtime. Together, they form the foundation OpenClaw's plugin ecosystem should have had from day one.

March 22, 20265 min read
PR #52393

Plugin Manifest Reference Rewritten

by osolmaz · 2 commits · size: XS

The entire docs/plugins/manifest.md rewritten. Complete field tables for top-level manifest fields. Nested references for providerAuthChoices and uiHints. Annotated examples including an OpenRouter reference. Guidance on which fields belong in the manifest vs package.json.

PR #51877

Auto-Generated SDK Reference

by dutifulbob · 9 commits · 39/40 checks passed

A TypeScript generator introspects plugin SDK public exports and produces JSON/JSONL baseline artifacts in docs/.generated/. CI runs drift detection: if the baseline diverges from the actual exports, the build fails. Documentation can't silently fall behind the code.

PR #52094

Plugin Host Version Gating

by vincentkoc · Enforced at install + manifest load

Plugins can now declare openclaw.install.minHostVersion. Incompatible plugins are rejected during installation with a clear error, not at runtime with a cryptic crash. Three failure types: invalid, unknown_host_version, incompatible. Dev builds get warnings instead of hard failures.

Plugin Developer Experience Scorecard

Where OpenClaw's plugin ecosystem stands after March 22.

Plugin manifest field reference

Incomplete, missing fields like enabledByDefault

Full field tables, annotated examples, providerAuthChoices docs

SDK module reference

Non-existent

Auto-generated from source with CI drift detection

Host version compatibility

Plugins fail at runtime on incompatible hosts

Rejected at install time with clear error messages

Manifest vs package.json guidance

Undefined — authors guessed

Explicit rules for which metadata lives where

Plugin changelog / migration guide

Non-existent

Still non-existent

End-to-end plugin tutorial

Community blog posts only

Community blog posts only

You Don't Launch an Ecosystem Without a Map

OpenClaw's plugin system has been available for months. Third-party developers have been building extensions for it. The IRC, Twitch, and voice-call plugins ship as bundled extensions. And until March 22, the documentation for the plugin manifest was incomplete, the SDK had no generated reference, and there was no mechanism to prevent plugins from installing on incompatible hosts.

Think about what that means for a plugin author. You're writing code against an SDK whose public API surface isn't documented. You're declaring manifest fields that aren't fully explained. If your plugin depends on a feature added in host version 1.5, and someone installs it on 1.3, it blows up at runtime with no useful error. The developer experience was “read the source code and hope for the best.”

The Drift Detection Is the Real Story

PR #51877 is the most interesting of the three because it solves a problem most projects never address: documentation rot. The generator introspects the actual TypeScript exports of the plugin SDK and serializes them to a baseline. CI checks the baseline against the current code. If someone adds a new public export and doesn't update the docs, the build fails.

It's not perfect. The Greptile bot caught a declaration aliasing problem where ClawdbotConfig renders as export type OpenClawConfig = OpenClawConfig; instead of using the alias name. And the error messaging repeats “Expected current:” twice in the drift failure output. These are fixable polish issues, not architectural problems.

The concept is sound: make documentation freshness a CI guarantee, not a cultural expectation. Most open-source projects treat docs as a volunteer effort that atrophies between releases. OpenClaw is making it a build requirement. I wish more projects did this.

Version Gating: The Launch Feature That Wasn't

PR #52094 adds minHostVersion enforcement to the plugin installer. The implementation uses a discriminated-union result type with three failure kinds and semantic version comparison. Dev builds get warnings; release builds get hard errors. The manifest cache is keyed by host version to prevent stale compatibility data.

This is textbook plugin architecture. It's also the kind of thing you build before you launch a plugin system, not after. Chrome has had manifest version requirements since extensions launched. VS Code enforces engine compatibility. npm enforces engines fields. This is not novel. This is table stakes that took 52,000 pull requests to arrive.

Three PRs. Three things that should have existed at launch. The work is good. The documentation approach is genuinely innovative. But the timing tells the real story: OpenClaw built a plugin ecosystem and then backfilled the foundation underneath it. That works until it doesn't. Today it worked.

Plugin updates. Deployed automatically.

DeployClaw ships every upstream merge — including plugin compatibility fixes — the moment they land.

DeployClaw News · by Carlos Simpson

DeployClaw hosts OpenClaw instances. Upstream fixes ship automatically. This publication covers development independently.