# Smart Memory Guard

> Use when reading from or writing to memory and you need guardrails against stale records, bloated memory files, or low-value writes that will not remain useful after the current workstream

- Skill: `chuanzige/smart-memory-guard` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add chuanzige/smart-memory-guard`
- Raw SKILL.md: https://api.skillmd.com/api/skills/chuanzige/smart-memory-guard/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: chuanzige (https://skillmd.com/u/chuanzige)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/chuanzige/smart-memory-guard

---


# Smart Memory Guard

## Overview

Memory is useful only while it stays accurate, compact, and worth loading. This skill operationalizes the guardrails implied by `src/memdir/memoryTypes.ts`, `src/services/SessionMemory/prompts.ts`, and `src/services/extractMemories/prompts.ts`.

## Three Defenses

### 1. Drift Guard

Treat memory as a snapshot, not as present truth.

Before acting on a memory:

- if it names a file, check the file still exists
- if it names a function or flag, grep for it
- if it describes current state, verify current state directly

If memory conflicts with the repo or source of truth, trust what you observe now and update or remove the stale memory.

### 2. Bloat Guard

Oversized memory degrades prompt quality.

When a memory file starts crowding the prompt:

- condense older detail
- keep the current state crisp
- preserve only the parts another agent would truly need
- prefer short index entries and info-dense bodies

Do not let memory become a second transcript.

### 3. Write Filter

Before saving anything, ask:

- is this non-obvious?
- is this not derivable elsewhere?
- will it still help after the current task is over?

If the answer is no, do not save it.

## Read-Side Rules

- Access memory when it is relevant or explicitly requested.
- If the user says to ignore memory, act as if it were empty.
- Verify recalled facts before recommending action from them.

## Write-Side Rules

- Update existing memory instead of creating duplicates.
- Prefer semantically organized files over chronological dumping.
- Remove or correct memories that have expired.
- Keep sensitive data out of shared memory.

## Typical Rejects

Reject writes like:

- "save this PR list"
- "save what we changed today"
- "save the fix steps for this bug"
- "save the repo structure"

Those are activity logs, not durable memory.

## Typical Accepts

Accept writes like:

- "this project never mocks the database in integration tests"
- "merge freeze starts on 2026-03-05"
- "the user is strong in Go but new to the React side"
- "production latency is watched in this external dashboard"

## Done Condition

You have applied this skill correctly when memory is verified before use, compressed before it becomes noise, and written only when the information is durable enough to earn a place in future context.