Skip to main content

Our Stack vs omp

Feature gap analysis. Our stack: Claude Code (primary) + Pi (council/multi-provider) + MCP servers (Playwright, Firecrawl, GitHub, Figma, context7, qmd) + superpowers skills.

Verdict

~55% feature parity. Hard gaps cluster around tool quality primitives — hashline editing, LSP integration into writes, DAP debugging, stream rules. These require native/Rust implementation and can’t be approximated with scripts or MCP servers. Our wins are in orchestration patterns, knowledge management, and MCP ecosystem depth. omp is better inside a single session (fewer failed edits, real debugger, LSP-aware writes).
Our setup is better across sessions (wiki, memory patterns, structured orchestration).
Control-plane implication: use omp as L2 execution substrate, not as L3 bus or L5 UI. The right integration is commandr-omp-runner first, then omp custom tools that speak Commandr events/approvals/artifacts. Do not collapse Commandr into omp session state.

Feature Table


Hard Gaps — Closing Cost

These require native implementation. Can’t be closed with MCP servers or shell hooks:

Our Wins — What omp Doesn’t Match


Migration Considerations

omp inherits existing .claude config, rules, and MCP servers on first run. Switching primary agent from CC to omp would preserve:
  • MCP server connections (Figma, context7, Firecrawl, etc.)
  • AGENTS.md / CLAUDE.md rules
  • Existing skills (as TS extensions or SKILL.md files)
What would be lost immediately:
  • CC-specific hook system (PreToolUse/PostToolUse/Stop) — omp has extension hooks but different surface
  • CC permission model (allowlist/denylist settings.json) — omp is YOLO by default (use srt for sandboxing)
  • Claude oauth session (CC uses device auth; omp uses its own oauth per provider)