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)
- 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
srtfor sandboxing) - Claude oauth session (CC uses device auth; omp uses its own oauth per provider)
Related Pages
- omp (oh-my-pi) — full omp capability reference
- Pi Agent (pi-mono) — upstream minimal harness; council/adversarial review layer
- Claude Code vs OpenCode Plugin Systems — adjacent comparison
- Agent Harness — harness primitives framing
- Lean Agentic Coding Workflow — our current full-stack workflow