Build a plugin capability index for intent-driven workflows

[Q00]

Vision

ourocode should understand installed Ouroboros UserLevel plugins as first-class workflow capabilities, not as opaque shell commands.

Issue #2 focuses on dispatching installed plugins safely from inside ourocode. The second proposed scope item there is the foundation for a broader product direction: resolve installed plugins and commands through a stable registry, lockfile, CLI, or MCP surface.

If we get this right, ourocode becomes an intent-driven workflow front door. A user should be able to express what they want to do, and ourocode should know which trusted installed plugin capabilities are available, what inputs they need, what artifacts they produce, and what continuation steps are safe.

Product direction

Create a normalized plugin capability index that ourocode can query before routing a prompt.

The index should describe installed plugin capabilities in a way that is useful for both direct commands and natural-language routing:

• plugin identity and trust state
• command names and aliases
• natural-language descriptions
• required and optional inputs
• declared permissions and risk level
• expected output artifacts, such as handoff files or seed.md
• continuation hints, such as whether a generated Seed can flow into ooo run
• actionable remediation for missing, untrusted, or unavailable plugins

Why this matters

Without a capability index, plugin dispatch risks becoming command-shaped glue code. That would make every plugin integration feel bespoke and brittle.

With a capability index, ourocode can provide a coherent workflow experience:

• direct prompts like ooo superpowers list route deterministically
• natural-language prompts can be matched against known trusted capabilities
• the TUI can explain what capability was selected and why
• generated artifacts can be detected and continued consistently
• trust and firewall boundaries remain explicit instead of being bypassed

Relationship to #2 and #3

• Builds on Support natural-language dispatch for installed Ouroboros UserLevel plugins #2 by deepening proposed scope item 2: plugin and command resolution.
• Complements docs: rescope userlevel plugin dispatch around SSOT #25 (PR 1/5) #3, which documents the first dispatch bridge design.
• This issue is not a replacement for the initial dispatch bridge; it defines the capability model that should keep future plugin routing from becoming ad hoc.

Proposed scope

1. Define a stable internal capability schema for installed UserLevel plugins.
2. Add a resolver that can load capabilities from the Ouroboros plugin registry, lockfile, CLI, or MCP surface.
3. Normalize plugin commands into a routing-friendly structure.
4. Expose trust, permission, and availability state without granting permissions automatically.
5. Make artifact expectations explicit enough for ourocode to detect generated handoffs and Seeds.
6. Add tests around capability loading, normalization, trust-blocked states, and missing plugin states.

Acceptance criteria

• ourocode has an internal representation for installed plugin capabilities that is independent of a single plugin implementation.
• The resolver can identify installed plugin commands, including superpowers commands, from an authoritative Ouroboros source.
• Capability records include trust state, command metadata, input requirements, declared permissions, and expected artifacts where available.
• Routing code can ask the capability index whether a direct or natural-language prompt maps to a known installed plugin command.
• Missing or untrusted plugins return actionable guidance instead of shelling out blindly.
• Tests cover at least one read-only command, one handoff-producing command, an untrusted plugin, and an unknown plugin.

Non-goals

• Building a marketplace UI.
• Auto-installing plugins.
• Auto-trusting plugins or silently expanding permissions.
• Replacing the Ouroboros plugin firewall.
• Hard-coding behavior only for superpowers.