Vision
ourocode should use the superpowers UserLevel plugin as the first golden-path compatibility target for plugin-native Ouroboros workflows.
Issue #2 defines the missing bridge: installed Ouroboros UserLevel plugins should be invokable from inside ourocode through direct ooo <plugin> ... prompts and natural language. PR #3 documents that boundary and uses superpowers as the motivating example. The next step is to make that example operationally useful: a stable reference workflow that proves the product direction works end to end.
The goal is not to special-case Superpowers forever. The goal is to choose one real plugin with realistic command shapes, trust requirements, long-running output, generated handoffs, and Seed artifacts, then use it to keep the generic plugin orchestration layer honest.
Product principle
A plugin-native workflow is ready only when a real user can complete the loop without leaving ourocode:
- discover or reference an installed plugin,
- invoke a known plugin command,
- see execution progress in the TUI,
- receive generated artifacts as session state,
- review the suggested continuation, and
- continue into
ooo run only when policy and user intent allow it.
Superpowers is a good first proving ground because it includes both read-only inspection commands and handoff-producing commands such as test-driven-development and systematic-debugging.
Reference journeys
Read-only inspection
Expected behavior:
ourocode resolves superpowers as an installed UserLevel plugin.
- The command dispatches through the Ouroboros plugin trust/firewall boundary.
- Output renders inside the TUI without forcing the user into a shell.
- No continuation is suggested unless the plugin output explicitly declares one.
Handoff generation
ooo superpowers test-driven-development --goal "Add retry behavior"
Expected behavior:
ourocode routes the command through the same generic plugin dispatch path.
- The run directory under stable plugin artifact reference is captured.
- Generated files such as
handoff.md, seed.md, and provenance records are detected when present.
- The generated Seed is shown as a next-step artifact with a command such as:
ooo run seed_path=stable plugin artifact reference.md
Natural-language continuation
Use Superpowers test-driven-development to add retry behavior, then run the generated handoff.
Expected behavior:
ourocode resolves the plugin and command with enough confidence to build a workflow plan.
- Trust, arguments, expected artifacts, and continuation policy are visible before side effects happen.
- The generated Seed continuation runs only when the original prompt and policy explicitly allow it.
Proposed scope
- Define a Superpowers golden-path fixture or integration harness that can run in a controlled test environment.
- Cover at least one read-only command and one handoff-producing command.
- Assert that dispatch uses the generic UserLevel plugin bridge, not a Superpowers-specific shell shortcut.
- Assert artifact detection for stable plugin artifact reference.md` and related handoff files.
- Assert trust-blocked behavior with exact, non-destructive remediation guidance.
- Record routing, dispatch, artifact, and continuation decisions in session or journal state so regressions are easy to diagnose.
- Use failures in this golden path to drive generic plugin contract improvements rather than one-off exceptions.
Acceptance criteria
- There is a documented Superpowers golden-path scenario linked from the plugin dispatch work.
- The scenario proves direct command dispatch, natural-language routing, trust-blocked handling, artifact capture, and continuation policy.
- The implementation remains generic enough that another UserLevel plugin can be added as a second compatibility target without rewriting the dispatch path.
- Tests or fixtures make it clear when
ourocode regresses into shell-only behavior, loses artifact provenance, or auto-runs a continuation without policy approval.
- The golden path can be used as a release checklist for plugin-native workflow support.
Non-goals
- Hardcoding Superpowers behavior into the terminal event loop.
- Requiring every plugin to copy Superpowers file layouts.
- Auto-installing or auto-trusting Superpowers.
- Blocking the generic dispatch bridge until every Superpowers command is supported.
Related
Vision
ourocodeshould use thesuperpowersUserLevel plugin as the first golden-path compatibility target for plugin-native Ouroboros workflows.Issue #2 defines the missing bridge: installed Ouroboros UserLevel plugins should be invokable from inside
ourocodethrough directooo <plugin> ...prompts and natural language. PR #3 documents that boundary and usessuperpowersas the motivating example. The next step is to make that example operationally useful: a stable reference workflow that proves the product direction works end to end.The goal is not to special-case Superpowers forever. The goal is to choose one real plugin with realistic command shapes, trust requirements, long-running output, generated handoffs, and Seed artifacts, then use it to keep the generic plugin orchestration layer honest.
Product principle
A plugin-native workflow is ready only when a real user can complete the loop without leaving
ourocode:ooo runonly when policy and user intent allow it.Superpowers is a good first proving ground because it includes both read-only inspection commands and handoff-producing commands such as
test-driven-developmentandsystematic-debugging.Reference journeys
Read-only inspection
Expected behavior:
ourocoderesolvessuperpowersas an installed UserLevel plugin.Handoff generation
Expected behavior:
ourocoderoutes the command through the same generic plugin dispatch path.handoff.md,seed.md, and provenance records are detected when present.Natural-language continuation
Expected behavior:
ourocoderesolves the plugin and command with enough confidence to build a workflow plan.Proposed scope
Acceptance criteria
ourocoderegresses into shell-only behavior, loses artifact provenance, or auto-runs a continuation without policy approval.Non-goals
Related