everything-claude-code/docs/HERMES-OPENCLAW-MIGRATION.md

Hermes / OpenClaw -> ECC Migration

This document is the public migration guide for moving a Hermes or OpenClaw-style operator setup into the current ECC model.

The goal is not to reproduce a private operator workspace byte-for-byte.

The goal is to preserve the useful workflow surface:

• reusable skills
• stable automation entrypoints
• cross-harness portability
• schedulers / reminders / dispatch
• durable context and operator memory

while removing the parts that should stay private:

• secrets
• personal datasets
• account tokens
• local-only business artifacts

Migration Thesis

Treat Hermes and OpenClaw as source systems, not as the final runtime.

ECC is the durable public system:

• skills
• agents
• commands
• hooks
• install surfaces
• session adapters
• ECC 2.0 control-plane work

Hermes and OpenClaw are useful inputs because they contain repeated operator workflows that can be distilled into ECC-native surfaces.

That means the shortest safe path is:

1. extract the reusable behavior
2. translate it into ECC-native skills, hooks, docs, or adapter work
3. keep secrets and personal data outside the repo

Current Workspace Model

Use the current workspace split consistently:

• live code work happens in cloned repos under ~/GitHub
• repo-specific active execution context lives in repo-level WORKING-CONTEXT.md
• broader non-code context can live in KB/archive layers
• durable cross-machine truth should prefer GitHub, Linear, and the knowledge base

Do not rebuild a shadow private workspace inside the public repo.

Translation Map

1. Scheduler / cron layer

Source examples:

• cron/scheduler.py
• jobs.py
• recurring readiness or accountability loops

Translate into:

• Claude-native scheduling where available
• ECC hook / command automation for local repeatability
• ECC 2.0 scheduler work under issue #1050

Today, the repo already has the right public framing:

• hooks for low-latency repo-local automation
• commands for explicit operator actions
• ECC 2.0 as the future long-lived scheduling/control plane

2. Gateway / dispatch layer

Source examples:

• Hermes gateway
• mobile dispatch / remote nudges
• operator routing between active sessions

Translate into:

• ECC session adapter and control-plane work
• orchestration/session inspection commands
• ECC 2.0 control-plane backlog under:
  • #1045
  • #1046
  • #1047
  • #1048

The public repo should describe the adapter boundary and control-plane model, not pretend the remote operator shell is already fully GA.

3. Memory layer

Source examples:

• memory_tool.py
• local operator memory
• business / ops context stores

Translate into:

• knowledge-ops
• repo WORKING-CONTEXT.md
• GitHub / Linear / KB-backed durable context
• future deep memory work under #1049

The important distinction is:

• repo execution context belongs near the repo
• broader non-code memory belongs in KB/archive systems
• the public repo should document the boundary, not store private memory dumps

4. Skill layer

Source examples:

• Hermes skills
• OpenClaw skills
• generated operator playbooks

Translate into:

• ECC-native top-level skills when the workflow is reusable
• docs/examples when the content is only a template
• hooks or commands when the behavior is procedural rather than knowledge-shaped

Recent examples already salvaged this way:

• knowledge-ops
• github-ops
• hookify-rules
• automation-audit-ops
• email-ops
• finance-billing-ops
• messages-ops
• research-ops
• terminal-ops
• ecc-tools-cost-audit

5. Tool / service layer

Source examples:

• custom service wrappers
• API-key-backed local tools
• browser automation glue

Translate into:

• MCP-backed surfaces when a connector exists
• ECC-native operator skills when the workflow logic is the real asset
• adapter/control-plane work when the missing piece is session/runtime coordination

Do not import opaque third-party runtimes into ECC just because a private workflow depended on them.

If a workflow is valuable:

1. understand the behavior
2. rebuild the minimum ECC-native version
3. document the auth/connectors required locally

What Already Exists Publicly

The current repo already covers meaningful parts of the migration:

• ECC 2.0 adapter/control-plane discovery docs
• orchestration/session inspection substrate
• operator workflow skills
• cost / billing / workflow audit skills
• cross-harness install surfaces
• AgentShield for config and agent-surface scanning

This means the migration problem is no longer "start from zero."

It is mostly:

• distilling missing private workflows
• clarifying public docs
• continuing the ECC 2.0 operator/control-plane buildout

What Still Belongs In Backlog

The remaining large migration themes are already tracked:

• #1051 Hermes/OpenClaw migration
• #1049 deep memory layer
• #1050 autonomous scheduling
• #1048 universal harness compatibility layer
• #1046 agent orchestrator
• #1045 multi-session TUI manager
• #1047 visual worktree manager

That is the right place for the unresolved control-plane work.

Do not pretend the migration is "done" just because the public docs exist.

Recommended Bring-Up Order

1. Keep the public ECC repo as the canonical reusable layer.
2. Port reusable Hermes/OpenClaw workflows into ECC-native skills one lane at a time.
3. Keep private auth and personal context outside the repo.
4. Use GitHub / Linear / KB systems as durable truth.
5. Treat ECC 2.0 as the path to a native operator shell, not as a finished product.

Decision Rule

When reviewing a Hermes or OpenClaw artifact, ask:

1. Is this reusable across operators or only personal?
2. Is the asset mainly knowledge, procedure, or runtime behavior?
3. Should it become:
   • a skill
   • a command
   • a hook
   • a doc/example
   • a control-plane issue
4. Does shipping it publicly leak secrets, private datasets, or personal operating state?

Only ship the reusable surface.