Classification and Memory Management Principles

General Classification Rules

Short rule: Memory = what, User = who/how they like being talked to, Skill = how (procedure). If a task has ≥5 steps and will repeat → split into a separate Skill.

Technical Limits

• MEMORY.md: ~2,200 character limit (~800 tokens), entries separated by §.
• Each entry should be dense, specific (real paths/IPs/commands), avoid vague statements like “User has a project”.
• Do not use extra markdown headings within Memory.
• When usage exceeds ~80% → merge duplicate entries on the same topic before hitting the write block.
• Merge rule: multiple entries about the same topic (“project uses X” x3) → merge into one comprehensive entry.

Case Study — MEMORY.md (GBrain)

Original state: 1,517/2,200 characters (~69%), 7 entries, valid § syntax.

What worked well:

• Entries are specific, with real addresses/commands/paths (e.g., MCP server IP, docker exec commands).
• No raw data dumps, no ephemeral info from a single session.

Problems:

1. 5/7 entries all talk about “GBrain ingestion”, occupying most of the capacity → need merging, saving ~30–40%.
2. Some entries describe detailed processing procedures (“how”) instead of just stating facts → detailed procedures should go into SKILL.md of the relevant skill (e.g., gbrain-resolver), Memory only needs one line pointing to that skill.
3. One entry describes user behavioral/communication expectations (“report blocker directly instead of stopping silently”) → this belongs in USER.md, not MEMORY.md.

Condensed sample version (reduces old capacity to ~55%):

GBrain: MCP server http://10.10.38.1:7333/mcp. CLI in Docker container `gbrain`; run `docker exec gbrain gbrain extract --stale` (or `docker compose exec -T gbrain ...`) when Docker daemon is accessible.
§
GBrain ingestion convention: save user-uploaded files under `sources/` first (raw layer, immutable); derived pages reference `source_slug` in `sources/`, not just cache path `/opt/data/gbrain/...`. For generic filenames (README.md), set slug based on content/project name, keep original name.
§
GBrain ingestion trigger ("load knowledge/data into brain"): use mcp_gbrain_* + gbrain-resolver skill — skill handles routing, preserve Compiled Truth + Timeline-append, confirm slug/path saved.
§
Updating gbrain-resolver skill: read live `resolver` page via GBrain MCP first, patch skill from there, do not rely on local memory/assumptions.

→ Entry about “report blocker directly” moves to USER.md, e.g.:

User expects agent to proceed with GBrain ingestion even when MCP is down (using resolver rules/local fallback) and report blocker directly instead of silently stopping.

Case Study — USER.md

Original state: 502/1,375 characters (~37%), 2 entries, valid § syntax.

USER.md should contain: name/role/timezone, communication preferences, pet peeves, workflow habits, technical skill level — i.e., “who is the user / how they like being talked to”, not domain knowledge being learned.

Entry 1 — correct place, good quality: persona “Mít” (sharp, blunt, concise, evidence-calibrated) + specific communication rules for Hermes/Buzz troubleshooting (separate transport vs agent/model/tool latency). Good example entry: packs multiple related facts, specific, actionable.

Entry 2 — wrong file: content about learning SMC trading, wants explanations based on stored SMC docs → this is domain-knowledge/task context, not “who is the user”. Correct handling:

• Fact about used resources (e.g., SMC book path/slug) → MEMORY.md.
• Reusable procedure (always answer SMC questions using entry/OB/FVG/BOS format based on original docs) → separate Skill (e.g., smc-explainer).
• Only keep general style preference (likes based on original docs, dislikes generic theory) in USER.md.

Condensed sample version:

User wants Vietnamese replies in the Mít persona: sharp, blunt, concise by default, evidence-calibrated, filler-free, brief in result reports. For Hermes/Buzz troubleshooting, prefers live gateway/log evidence with clear split between transport issues and agent/model/tool latency.
§
When explaining any technical/reference topic (e.g. trading), user prefers answers grounded in the stored reference material, not generic textbook theory.

Detailed SMC content split out:

• MEMORY.md: 1-line fact — “SMC reference book stored at [source]” (if specific path/slug exists).
• Separate Skill (smc-explainer): procedure to always lookup original docs first when answering SMC questions, using entry/OB/FVG/BOS terminology.

Quick Checklist When Adding New Entry

• Is this a static fact about the environment (path/IP/command/convention)? → Memory
• Is this a ≥5-step procedure that will repeat? → Skill
• Is this a user expectation/communication style? → User
• Is the entry specific and dense with information, or vague?
• Are there entries on the same topic that can be merged?
• Has Memory usage exceeded ~80% — needs cleanup before adding more?

Tip: Check Contradictions with Claude

Use Claude to cross-check for contradictions between MEMORY.md, USER.md, AGENTS.md, and SOUL.md. Run this audit periodically to ensure consistency across Hermes configuration files.

Example prompt for Claude:

Review the files MEMORY.md, USER.md, AGENTS.md, and SOUL.md in the Hermes directory. Identify any contradictions, overlapping content, or inconsistencies between them. Report conflicting statements and suggest resolutions.