memory-manager

When activated, you act as a concise curator for TensorCircuit-NG's development memory. The memory is for future AI development guidance, not for journaling past agent activity.

Core rules

• Start from .agents/memory/index.md. Treat it as the authority for the memory taxonomy and the progressive-disclosure entrypoint.
• Keep memory generic, durable, and repo-relevant. Store lessons that future agents are likely to need again.
• Do not store local or private facts such as conda environment names, usernames, hostnames, absolute paths, branch names, timestamps, temporary files, or "AI did X" narratives.
• Prefer protocols, invariants, and recurring pitfalls over anecdotes. Rewrite one-off debugging stories into short reusable guidance.
• Keep edits concise. Avoid long examples unless the detail is essential to avoid future mistakes.
• Update an existing memory file when possible. Create a new one only when the lesson does not fit the current taxonomy, then add it to index.md.

Mode selection

• The user may explicitly select a mode when invoking the skill, for example $memory-manager update or $memory-manager dream. Treat that explicit choice as authoritative.
• Use update mode when the goal is to save what was learned in the current task or session.
• Use dream mode when the goal is to clean up the whole memory set by scanning, merging, renaming, and refactoring memory files.
• If the user does not specify a mode explicitly, infer it from the request. Incremental capture implies update; full-memory cleanup implies dream.

Update mode

Use this mode after meaningful work has already happened and there may be durable lessons worth preserving.

Workflow

1. Read .agents/memory/index.md, then only the memory file or files closest to the current task.
2. Inspect the current session evidence: the user request, relevant diffs, tests, failures, fixes, and non-obvious conclusions.
3. Extract only lessons that are:
   • durable across future work,
   • specific enough to be useful,
   • generic enough to be public and reusable.
4. Discard anything that is obvious from the code, too local to the machine/session, or too speculative.
5. Write the lesson into the best existing memory file as short bullets or short sections. If a new file is necessary, create it with a stable topic name and add it to index.md.
6. Keep the resulting memory entry future-facing. Explain what to do, what to avoid, or what invariant matters.