memory-hygiene
Use to compact agent memory stores that grow append-only and rot — AGENTS.md "Notes to self" sections, bd memories, CLAUDE.md instruction drift — by deduplicating, merging superseded entries, and retiring notes whose subject no longer exists. Triggers: "compact my notes to self", "AGENTS.md is huge", "clean up bd memories", "stale agent memory".
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- memory-hygiene
- metadata
- { "owner": "tze", "status": "active", "authors": [ "tze", "Claude Fable 5" ], "last_reviewed": "2026-06-12" }
- description
- Use to compact agent memory stores that grow append-only and rot — AGENTS.md "Notes to self" sections, bd memories, CLAUDE.md instruction drift — by deduplicating, merging superseded entries, and retiring notes whose subject no longer exists. Triggers: "compact my notes to self", "AGENTS.md is huge", "clean up bd memories", "stale agent memory".
- compatibility
- Operates on AGENTS.md / CLAUDE.md files and the bd CLI where present.
02 资源文件 1
- 参考文档agents/openai.yaml82 B
03 SKILL.md 正文
Memory Hygiene
Agent memory is append-only by habit: every session adds a note, none removes one. The result is the same rot as unused skills — every future session pays to read superseded, duplicate, or orphaned notes. The canonical failure mode (observed in ~/.dotfiles AGENTS.md): a defect is recorded in one bullet and declared fixed three bullets later — both survive forever.
Scope
AGENTS.md"Notes to self" sections (repo-level memory contract)bd memoriesentries where beads is in useCLAUDE.mdfiles only for factual drift (paths/commands that no longer exist) — their instructions are the user's, not yours to compact
Workflow
- Inventory: read the target store end-to-end. For each entry record:
subject, date (if any), and whether its subject still exists (file
paths, skill names, flags — verify with a quick
ls/rg, don't trust the note). - Classify each entry:
- superseded — a later entry updates or reverses it (the defect-then-fixed pair merges into one resolved-state note)
- duplicate — same fact stated twice with different wording
- orphaned — subject was deleted/renamed (e.g. notes about a skill
path that moved to
skills/archive/) - live — still accurate and load-bearing
- Propose the compaction as a diff — merged entries keep the current truth plus the date; history belongs to git, not to the note. Never silently drop a note that encodes a hard-won lesson ("do not reintroduce X") — those stay even when old, they are guardrails, not status.
- Apply on approval, one store per commit, with before/after entry counts in the commit message.
- For
bd memories: list withbd memories, then retire/update via the bd commands available in that version (bd rememberto restate; checkbd --helpfor delete semantics before assuming).
Judgment lines
- A note is a guardrail if removing it could cause a regression (anti-pattern warnings, "don't reintroduce" rules) — keep, even if old.
- A note is status if it describes a point-in-time state ("X is broken", "Y pending") — verify current state and either update or delete.
- When a store mixes both per entry, split the entry rather than keeping the stale half alive.
Hard stops
- Never compact another agent's active coordination state (beads notes
fields used as heartbeats,
.pm/folders) — memory hygiene is for durable knowledge stores only. - Preserve the memory contract header/format of the file you compact; the next session must still know where to append.
04 同仓库更多 Skills
user-run
Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable /home/orca/.tmp/<slug>/run.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: "I'll run it for you", "permission denied on docker.sock", "needs sudo", "sudo: a password is required", "run as tze", "/user-run".
requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
dispatching-parallel-agents
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies