The Open Component Registry (OCR)

The Open Component Registry (OCR, shipped in WP Rig v3.4) is a federated ecosystem for sharing performant, agent-ready theme components. Instead of copy-pasting feature code between projects, you search a registry of verified components, add them with one command, and pull framework-level updates later without losing your customizations.

Why a component registry

Every registry component ships with more than code: a manifest.json declaring its assets and paradigm, a SPEC.md with its technical contract, and a SKILL.md with implementation recipes. That makes components both performance-verified (scored, with conditional asset loading) and agent-ready (AI tools can read the same docs you do).

The component lifecycle

Adding your first component

Before building a feature from scratch, check whether a verified component already exists:

npm run rig:search related-posts
npm run rig:add related-posts

npm run rig:search related-posts
npm run rig:add related-posts

When choosing, prefer components with a performance score of 95+ and the Agent-Ready badge (meaning SPEC.md and SKILL.md ship with the component). After adding, the component docs land in .ai/skills/ — read them (or let your AI assistant read them) before wiring the component into templates.

The manifest and scoped assets

Manifest v2 requires a paradigm field matching the component PARADIGM constant, and supports scoped assets: an asset_mapping entry marked scoped: true is compiled into the theme pipeline but enqueued conditionally by the component own PHP — a block component never adds global CSS to pages that do not use it. Components build through the same Bun/Lightning/esbuild pipeline as core theme assets: no extra HTTP requests, no separate build config.

Paradigm-aware components

A component that serves only one theme-dev paradigm declares it and uses the trait — the theme class skips inactive components automatically during discovery:

// inc/My_Feature/Component.php
class Component implements Component_Interface {
	use Paradigm_Component_Trait;
	const PARADIGM = 'block-based';
	public static function is_active(): bool {
		return self::paradigm_active();
	}
}

// inc/My_Feature/Component.php
class Component implements Component_Interface {
	use Paradigm_Component_Trait;

	const PARADIGM = 'block-based';

	public static function is_active(): bool {
		return self::paradigm_active();
	}
}

Bundled patterns/ directories inside a component are registered by the inc/Block_Patterns component in block-capable themes.

Contributing a component

• Scaffold the structure: npm run create-rig-component "My Feature" --templating --tests — it generates Component.php, manifest.json, SPEC.md, and SKILL.md registry-ready by default.
• Implement the feature and keep everything inside the component directory under inc/.
• Validate locally: npm run rig:test-component my-feature.
• Package and submit: npm run rig:prepare my-feature — it produces exactly what the GitHub PR needs.

Updates are “starter” semantics: after rig:add, the code is yours to modify. rig:update later pulls upstream fixes with a diff-based merge, preserving local customizations.

Private and team registries

The registry is federated: organizations can point a theme at their own GitHub-backed registry (via the inc/Registry_Config component) to serve a private set of curated components alongside the public one — useful for agencies maintaining vetted in-house features.

Related reading

See Theme Paradigms for the gating model, Building Custom Blocks for block components, and WP Rig Node Scripts for the full rig:* command reference.