Repository navigation
Is this compatible with Oh-My-OpenAgent? #1692
|
Considering that this looks like a kitchen sink for agents, I wonder if it works with existing Ralph-esque workflows that has more robust planning/testing plans. The only thing missing there is existing SKILLS collection (ECC?) + robust memory (So maybe LLM Wiki or Mempalace might fix it but not OOTB) https://github.com/code-yeongyu/oh-my-openagent |
Replies: 2 comments
|
Short answer: conceptually compatible, but not a native one-click target today. ECC and Oh-My-OpenAgent overlap at the workflow layer: skills, rules, command vocabulary, MCP conventions, planner/test loops. The safe integration model is to treat ECC as a source kit and port only the pieces you need into the OmO loading model, rather than stacking two full harnesses. Based on the current OmO README, it has its own orchestration loop ( A sane starting point would be:
Avoid double-installing hooks, running two task-enforcement loops at once, copying secrets/API keys, or turning on automatic telemetry without noticing. From the ECC side, the likely product shape is a manual adaptation guide or a small OmO target adapter, not pretending there is full native parity today. The closest current docs are |
|
Building on affaan-m's answer — the port boundary has one non-obvious edge: anything ECC drives through hook events is inert once you copy it out. continuous-learning-v2 is the clearest case: the SKILL.md ports fine, but with no PreToolUse/PostToolUse feeding observe.sh you get the instructions and none of the loop. So rules and skills port; observation and GateGuard do not. Before merging command sets, check for shadowing: find . ~/.config -path '*commands*' -name '*.md' -printf '%f\n' | sort | uniq -dDuplicate names resolve by load order, silently. Want me to take a crack at it? |
Short answer: conceptually compatible, but not a native one-click target today.
ECC and Oh-My-OpenAgent overlap at the workflow layer: skills, rules, command vocabulary, MCP conventions, planner/test loops. The safe integration model is to treat ECC as a source kit and port only the pieces you need into the OmO loading model, rather than stacking two full harnesses.
Based on the current OmO README, it has its own orchestration loop (
ultrawork), Team Mode, built-in MCPs, and telemetry defaults. I would not install all ECC hooks and all OmO automation on top of each other.A sane starting point would be:
skills/*/SKILL.mdfiles that match your workflow.