Documenting a direction we looked at and are deliberately not taking right now.
The idea
- Plugins are plain directories: a TOML manifest plus executable commands in any language, no SDK; the
programa CLI is the plugin API, with the socket path injected via env
- Plugins can register actions, open managed panes, react to workspace events, handle link clicks
- Discovery is decentralized: tag a public GitHub repo with a topic (e.g.
programa-plugin) and it appears in the marketplace index, no approval process
Why parked
A plugin surface this open is a large option surface, and the current product direction is the opposite: narrow options, defaults are the product. Until first-class integrations stop covering what users ask for, plugins dilute more than they add.
What keeps the door open
The OpenCode integration already ships as a local plugin (#139 / #156), so the seed exists. If we ever un-park this, that integration becomes the reference plugin and the manifest format gets extracted from it, not designed fresh.
Revisit trigger: two or more user requests that would each need a bespoke integration we don't want to own in-tree.
Documenting a direction we looked at and are deliberately not taking right now.
The idea
programaCLI is the plugin API, with the socket path injected via envprograma-plugin) and it appears in the marketplace index, no approval processWhy parked
A plugin surface this open is a large option surface, and the current product direction is the opposite: narrow options, defaults are the product. Until first-class integrations stop covering what users ask for, plugins dilute more than they add.
What keeps the door open
The OpenCode integration already ships as a local plugin (#139 / #156), so the seed exists. If we ever un-park this, that integration becomes the reference plugin and the manifest format gets extracted from it, not designed fresh.
Revisit trigger: two or more user requests that would each need a bespoke integration we don't want to own in-tree.