Prepare an extension

Start with the user’s task

Write one sentence describing the problem: “Show my project’s test results in a panel,” for example. Decide whether it needs a view, a command, a provider or a new runtime. Prototype supported panels and commands as a foundation plugin.

Do not invent an installation manifest for a contract that has not shipped. The broader versioned extension manifest and marketplace distribution are still design work.

Document the proposed contract

• Identity, version, maintainer, license and supported Lyre versions.
• Activation conditions and the views or commands contributed.
• Filesystem, network, process, secret and native-device access needed.
• Configuration, failure messages, cleanup and uninstall behavior.
• Supported client platforms and behavior when a capability is unavailable.

Respect host and device boundaries

Use public contribution interfaces. Do not import private Lyre modules or mutate the app’s global state. Keep privileged execution on the host and return only the data the client needs.

A desktop capture feature needs separate capture and input consent. An app-viewing grant cannot authorize control of the entire computer. A native module needs its own build and platform review.

Prepare for review

Provide source, a small demo, installation and removal instructions, supported versions and negative tests for denied permissions. Describe any unsandboxed prototype honestly. A working local plugin is a useful prototype; it is not a signed, sandboxed extension release.