hermes-memory-bridge
Architecture and scripts for syncing Hermes memory into git-tracked .claude/memory/ so all machines get context via git pull. Covers quality gate, drift detection, topic mirroring, and cron automation.
Best use case
hermes-memory-bridge is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Architecture and scripts for syncing Hermes memory into git-tracked .claude/memory/ so all machines get context via git pull. Covers quality gate, drift detection, topic mirroring, and cron automation.
Teams using hermes-memory-bridge should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/hermes-memory-bridge/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How hermes-memory-bridge Compares
| Feature / Agent | hermes-memory-bridge | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Architecture and scripts for syncing Hermes memory into git-tracked .claude/memory/ so all machines get context via git pull. Covers quality gate, drift detection, topic mirroring, and cron automation.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Hermes Memory Bridge
## Problem
Hermes writes memory to `~/.hermes/memories/` (Linux only). Claude Code writes to `~/.claude/projects/*/memory/` (per-machine, not portable). Non-Hermes machines (Windows licensed-win-1) have zero context. Without a bridge, every machine operates with different knowledge.
## Architecture: Memory Lives In The Repo
Instead of sync tools or tarballs, memory files are committed to `.claude/memory/` inside the workspace-hub repo. Git IS the sync mechanism.
```
Hermes memory (~/.hermes/memories/)
→ pre-bridge-quality.sh (quality gate)
→ bridge-hermes-claude.sh (injects into repo memory files)
→ .claude/memory/ (git-tracked)
→ git push
→ any machine: git pull → gets same context
```
## Key Scripts
| Script | Purpose |
|--------|---------|
| `scripts/memory/bridge-hermes-claude.sh` | Main bridge: reads Hermes memory, injects into agents.md via template, mirrors Claude topic files |
| `scripts/memory/pre-bridge-quality.sh` | Quality gate: checks char limits, stale entries, duplicates, content richness. Scored 0-100. ≤50 blocks bridge, 50-70 warns+bridges, 70+ passes |
| `scripts/memory/check-memory-drift.sh` | Drift detection: compares Hermes memory against repo agents.md. Exits 0/1. `--fix` runs bridge |
| `scripts/memory/bootstrap-machine.sh` | One-time setup for new machines: creates ~/.claude/CLAUDE.md |
## Repo Memory Files
| File | Content |
|------|---------|
| `.claude/memory/agents.md` | User profile, AI subscriptions, workflow rules, Hermes-injected facts |
| `.claude/memory/context.md` | Machine conventions, paths, Python rules, workspace layout, legal compliance |
| `.claude/memory/claude-auto-memory.md` | Snapshot of Claude auto-memory MEMORY.md index |
| `.claude/memory/topics/` | 19 mirrored Claude topic files (feedback_*, working-style, etc.) |
| `.claude/memory/templates/agents-template.md` | Template for agents.md with BRIDGE injection markers |
## BRIDGE Marker Pattern
agents.md uses `<!-- BRIDGE:START -->` / `<!-- BRIDGE:END -->` markers in a template:
```
# Agent Workflow Facts
> Git-tracked template file
<!-- BRIDGE:START -->
## Synced from Hermes Memory (date)
- bullet 1
- bullet 2
<!-- BRIDGE:END -->
---
## User
... hardcoded baseline that doesn't change ...
```
The bridge script reads the template, injects Hermes content between markers, and writes the result. This prevents duplication — baseline lives in template, dynamic content lives in bridge injection.
## Quality Gate Scoring
Score starts at 100, deductions:
- Memory file missing: -30
- Memory file empty: -25
- Exceeds char limit (2200 MEMORY.md / 1375 USER.md): -20 per file
- Approaching limit (>90%): -5 per file
- Stale entries (>90 days old): -3 per entry
- Duplicates between MEMORY.md and USER.md (>2): -5
- Nearly empty (<200 chars): -15
Score ≤50: BLOCK bridge (critical failure)
Score 50-70: WARN and bridge (or --fix mode auto-compacts first)
Score ≥70: PASS, bridge runs normally
## Cron Job
Hermes cron `8c797470d7d3` (memory-bridge-daily, 0 4 * * *):
1. Runs check-memory-drift.sh — skips bridge if in sync
2. Runs pre-bridge-quality.sh --fix — gates quality
3. Bridge commits + pushes (with stash/rebase for dirty working dir)
## Pitfalls
- Repo topology changes are high-priority bridge facts. If a session confirms that tier-1 repos moved between nested and sibling layouts, run `check-memory-drift.sh` and bridge the fact into `.claude/memory/agents.md`; otherwise Hermes may know the topology while repo-local agents still follow stale path assumptions.
- Existing quality scripts (compact-memory.py, curate-memory.py, eval-memory-quality.py) are BUGGY — wrong default paths, metrics calibrated for work-queue format not §-delimited memory. Use pre-bridge-quality.sh instead.
- The bridge must handle dirty working dir: stash before `git pull --rebase`, restore after push.
- Scheduled bridge jobs can collide with `scripts/repository_sync` or another Git process holding `.git/index.lock`; if `check-memory-drift.sh`, `git status`, or bridge preflight times out while a `git add`/sync process is active, inspect the owning process, wait briefly for the lock to clear, then rerun drift detection before deciding whether to bridge. Do not remove `.git/index.lock` unless the owning Git process is gone.
- If `pre-bridge-quality.sh --fix` generates bridge changes, stashes them, then exits nonzero because the internal commit sees `nothing to commit, working tree clean` or `nothing added to commit but untracked files present`, recover by checking out only `.claude/memory` from the generated `pre-bridge-stash`, staging `.claude/memory`, committing only `.claude/memory`, pushing, and then rerunning `check-memory-drift.sh` to verify sync. Do not add unrelated untracked files just to make the bridge commit succeed. If `git push` says `Everything up-to-date`, verify `HEAD` equals `origin/main` / `@{u}` because hooks may already have pushed. If the generated stash also contains non-memory paths, preserve the stash after the memory commit instead of dropping it. See `references/pre-bridge-stash-recovery.md` for the exact recovery/verification command sequence.
- Memory topic snapshots can legitimately document merge-conflict marker strings inside fenced code blocks. If the commit hook blocks `.claude/memory/topics/*` with unresolved-marker findings, first verify the markers are forensic/example content, then add the per-line hook exemption suffix `# CONFLICT_MARKER_FORENSIC_OK` to the literal marker lines only; do not disable hooks or rewrite unrelated memory content.
- Template file must exist at `.claude/memory/templates/agents-template.md` or bridge falls back to raw output.
- Windows MINGW64: paths use `/d/workspace-hub/` format, not `D:\\`.
## Ecosystem Health Monitoring
`scripts/upkeep/health-check.sh` provides 16 automated checks:
1. Gateway status (critical if down — cron jobs won't fire)
2. Cron job count and state
3. Cron output freshness
4. Memory bridge freshness (last commit to .claude/memory/)
5. Memory drift (Hermes vs repo)
6-7. Hermes memory char limits (MEMORY.md / USER.md)
8-10. Disk space, ~/.hermes/ size, ~/.claude/ size
11. Repo unpushed commits
12-14. Sub-repo sync (digitalmodel, aceengineer-strategy, worldenergydata)
15-16. Claude topics count and auto-memory snapshot freshness
Exit codes: 0 = all pass, 1 = warnings, 2 = critical failures
Usage: `bash scripts/upkeep/health-check.sh` or `/today --health`
### Operational Findings
- Gateway can go DOWN without warning (found inactive for 7+ hours, cron jobs never fired)
- Memory approaches limits quickly (MEMORY.md hit 98% at 2170/2200 chars, USER.md hit 94% at 1291/1375)
- Quality gate thresholds are well-calibrated: memory at 90%+ triggers warning, forces attention
- Health check revealed gateway status as the most critical single point of failure — if Gateway is down, memory-bridge cron never runs, drift accumulates silentlyRelated Skills
telegram-hermes-bot
Install a private, single-user Telegram bot connected to a Hermes gateway on a Linux host. Covers BotFather provisioning, token hygiene, systemd drop-in override for durable env loading, single-user allowlist enforcement, approval-mode posture, and the mobile destructive-action smoke test. Reusable for any `@<name>Bot` / host pair.
memory-bridge-operations
Operate and recover the Hermes-to-repo memory bridge: drift checks, quality gate, bridge commits, push verification, and stash recovery when pre-bridge scripts fail after generating outputs.
hermes-kanban-readability
Reapply the Hermes Kanban dashboard readability customizations (clickable bare URLs in card descriptions + readable card-text font, a visible horizontal scrollbar so all columns are reachable) as a user-override plugin that survives hermes-agent updates. Use when the Kanban board reverts to the Mondwest display font / plain-text Source URLs after a hermes update, or when bootstrapping a machine whose ~/.hermes was wiped.
extract-skills-from-hermes-sessions
Automatically analyze Codex session transcripts to identify and extract reusable skills using LLM analysis via OpenRouter
bridge-brokerage-market-data-apis
Handle ticker symbol mismatches between brokerage exports and market data APIs
hermes-agent-skill-authoring
Author in-repo SKILL.md: frontmatter, validator, structure.
hermes-config-audit-gotchas
Audit Hermes custom config keys and migrated skill settings safely, with verified command behavior and stale-path checks.
hermes-windows-setup
Install and configure a repo-centric Hermes agent workspace on Windows. Covers prerequisites, repo cloning, Python/uv environment, skills system, memory bridge, and multi-agent coordination — the Windows equivalent of the Linux workspace-hub pattern.
hermes-local-configuration
Class-level Hermes local configuration and setup workflows, including config audit gotchas and Windows installation.
hermes-ecosystem-integration
Wire Hermes into workspace-hub ecosystem — multi-repo skills, config sync, session export to learning pipeline, memory cross-pollination, skill patch tracking, and cross-machine health checks.
memory-bridge-operation
Manage the Hermes ↔ repo memory sync system — bridge, quality gate, compaction, health checks, and cron
memory-bridge-commit-fallbacks
Fallback procedures when the Hermes ↔ Codex memory bridge writes .Codex/memory outputs but the internal git commit/push path fails because of dirty, stale, or broken submodule state.