Project Memory Management

Problem

In long agent sessions, architecture, decisions, and stage state often get buried in chat history. As context grows, the model may re-ask confirmed choices, lose constraints, or treat process discussion as durable facts. A project needs stable memory files instead of relying on one conversation window.

How It Works

The skill uses a .memory/ directory and three operations: /memory.summarize compresses the current conversation into a structured summary, removing emotion and irrelevant reasoning; /memory.update writes project.md, context.md, decisions.md, tasks.md, and logs/YYYY-MM-DD.md according to rules, keeping architecture, decisions, and constraints; /memory.bootstrap reads the files in order at session start and outputs a context summary.

The core rule is that context.md stays under 200 lines and is replaced with the latest state. Decisions must include dates, and logs/ remains raw material that is not actively read. Paths are relative to the project root, and headings stay stable for tooling.

Boundaries

This is useful for long-lived projects with a clear tech stack and decision history. It is less appropriate for one-off scripts, casual chat, or temporary tasks without project boundaries. Avoid letting context.md grow unbounded, and avoid treating process logs as current facts.