memory-offload

Files (1)

• SKILL.md

SKILL.md (first lines)

# op_pi × filesystem-offloaded memory

Use this skill when you want a Claw OS-style memory system where `MEMORY.md` stays small and points into a structured `memory/` tree.

## What you get

- a clear role for `MEMORY.md` as pointer/index/current-beliefs layer
- a practical read/write workflow for agents
- guidance for sharding memory by time, channel, project, topic, and handoff
- migration guidance away from monolithic memory files

## Read order

1. Read `MEMORY.md` first.
2. Follow the pointer to the smallest relevant shard.
3. Read subtree indexes only when needed.
4. Avoid loading the whole memory tree by default.

## Write order

1. Write detailed updates to the canonical leaf shard.
2. Update `MEMORY.md` only when the pointer map or current beliefs changed.
3. If a section grows noisy, split it into a dedicated file.
4. Archive cold history to keep the hot path small.

## Default shard map

- `memory/daily/YYYY-MM-DD.md` -> chronological execution log
- `memory/channels/<channel>.md` -> one lane/channel
- `memory/projects/<project>.md` -> project/repo state
- `memory/agents/<agent>.md` -> agent/operator profile
- `memory/topics/rules.md` -> durable operating rules
- `memory/topics/lessons.md` -> reusable lessons
- `memory/handoffs/YYYY-MM-DD-<slug>.md` -> bounded handoffs
- `memory/archive/YYYY-MM/` -> cold history

## Offload triggers

Offload when:

- `MEMORY.md` stops being easy to scan
- one topic dominates the root file
- detail is only relevant to one entity or workflow
- logs or history start crowding out current beliefs

## Start here

- `docs/memory-offload-architecture.md`
- `docs/memory-offload-guide.md`
- `docs/examples/MEMORY.example.md`
- `docs/examples/memory/README.example.md`

From IYENTeam/op_pi, MIT.

More from IYENTeam/op_pi