Project Memory Management

Problem

When an LLM works across multiple sessions on the same project, two engineering problems appear often: context gets buried under stale details, and the model recreates components, utilities, APIs, or database tables that already exist. Putting everything into one project-memory.md makes the file grow quickly; storing nothing causes the next session to lose established conventions.

How the Skill Works

The skill replaces a single monolithic memory file with a modular file structure:

• project-memory.md keeps only phase state, key decisions, and entry points, ideally under 30 lines.
• dev-docs/index.md maintains a compact index of components, hooks, utils, APIs, and database tables.
• Folders such as dev-docs/components, dev-docs/api, and dev-docs/database store full definitions and are read on demand.
• init_memory.py creates the directory layout, read_memory.py loads the main file and index by default, update_memory.py updates memory and rebuilds the index, and archive_phase.py archives a phase and summarizes existing assets.

When creating a new component, the skill checks the index for similar definitions, writes the doc first, then implements the code. When modifying an existing component, it also updates the doc first, reducing drift between code and memory.

Boundaries

It fits projects with front-end components, APIs, and schema definitions, especially multi-session development. For one-off scripts or small tasks without stable assets, the folder structure adds maintenance overhead. The docs still need human or Agent synchronization; otherwise the index can lag behind the real code.