creating-new-builtin-plugins

Creates built-in WASM plugins embedded in and provisioned by the Golem registry service.

1.5k|212|Updated Nov 24, 2023
One-click install
npx skills add https://github.com/golemcloud/golem --skill creating-new-builtin-plugins
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: creating-new-builtin-plugins
Source: https://github.com/golemcloud/golem/tree/main/.agents/skills/creating-new-builtin-plugins
Command: npx skills add https://github.com/golemcloud/golem --skill creating-new-builtin-plugins

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Adding a new built-in plugin to Golem requires coordinating a standalone WASM component, build tooling, and registry-service provisioning code, and missing any step breaks compilation or deployment. This Skill provides the exact workflow to create, build, embed, and register a built-in plugin that ships with Golem and is granted to every environment.

Core Features & Use Cases

  • Plugin scaffolding: Guides creation of a standalone Golem application under plugins/<plugin>/ following the OTLP exporter layout, with the current async golem-rust oplog processor SDK interface.
  • Build and embedding: Extends the build-plugins duckscript task in Makefile.toml, validates output with wasm-tools, and wires the committed WASM into the registry service via include_bytes! and a BuiltinPluginDescriptor entry.
  • Provisioning and verification: Explains the descriptor-driven provisioner, transactional environment grants, and the authoritative verification commands including cargo make integration-tests-group7.
  • Use Case: You want to add a new metrics-exporter plugin that every Golem environment receives automatically; follow the workflow to implement the oplog processor, build the WASM, register the descriptor, and verify provisioning end to end.

Quick Start

Ask the AI to create a new built-in Golem plugin named metrics-exporter following the OTLP exporter pattern and register it in the registry service.

Frequently Asked Questions about creating-new-builtin-plugins

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a built-in plugin for Golem?

Create a standalone Golem application under plugins/<plugin>/ following the OTLP exporter layout, implement the async golem-rust oplog processor interface, extend the build-plugins task in Makefile.toml, and add a BuiltinPluginDescriptor entry with include_bytes in the registry service.

How do I implement the Golem oplog processor interface in Rust?

Implement the OplogProcessorGuest trait from golem-rust with an async process function receiving config, component ID, worker ID, metadata, and oplog entries. Export it using the export_oplog_processor macro with the current wit-bindgen async setup used by the OTLP exporter.

Why must the plugin WASM file be committed to the repository?

The registry service embeds the plugin binary at compile time using include_bytes, so the WASM file must exist in the source tree. Committing it keeps provisioning self-contained in every registry-service deployment without external loading.

How are built-in plugins granted to Golem environments?

The shared provisioner creates the golem-system application and builtin-plugins environment, deploys each descriptor component, and registers plugins idempotently. EnvironmentService::create then grants every built-in plugin transactionally to each new environment, and these grants cannot be deleted.

How do I verify a new built-in plugin works correctly?

Run cargo make build-plugins, validate the output with wasm-tools validate --features all, run cargo check -p golem-registry-service, and execute cargo make integration-tests-group7 which runs the otlp_plugin and plugins integration tests serially.