Files

alex 204bbb4c84 feat: replace megamemory with markdown-based memory system

Remove the megamemory MCP knowledge graph and replace with plain
markdown files in .memory/ for tracking plans, research, knowledge,
and implementation state. This enables collaboration across people
and agentic coding tools (Claude Code, Copilot, Cursor, etc.).

Changes:
- Remove megamemory MCP from opencode.jsonc
- Delete tool/megamemory.ts and .megamemory/ database
- Rewrite all 25 config files to use .memory/ markdown files
- Add cross-tool instruction file awareness (AGENTS.md, CLAUDE.md,
  copilot-instructions.md, .cursorrules)
- Update save-memory, bootstrap-memory, status commands for md workflow
- Update all agent files, skills, and commands consistently

2026-03-08 18:43:46 +00:00

3.2 KiB

Raw Blame History

Save Session Knowledge

You are saving what you learned this session into the project's .memory/ directory. This is YOUR memory — record anything valuable for future sessions: what you understood about the project, what you built, decisions that were made, patterns you noticed, or intent the user shared.

Step 1: Load existing memory files

Read the .memory/ directory and existing files to see what's already recorded. At minimum, check:

.memory/knowledge.md
.memory/decisions.md
.memory/plans/*.md
.memory/research/*.md

Understanding current state prevents duplication and helps you decide what to update.

Step 2: Reflect on this session

Think about what happened this session. Consider:

What did you learn about the project's purpose or intent?
What features, modules, or components did you build or change?
What design or architectural decisions were made and why?
What patterns or conventions did you discover?
What research findings are worth keeping?
Did anything get removed, replaced, or deprecated?

Step 3: Map learnings to memory files

For each thing worth remembering, update the right file:

Project architecture/patterns/conventions → .memory/knowledge.md
Decisions and rationale → .memory/decisions.md
Ongoing feature plans and acceptance criteria → .memory/plans/<feature>.md
Deep research findings → .memory/research/<topic>.md

Prefer updating existing sections over creating duplicates.

Step 4: Write updates using markdown sections

Use standard markdown headings (##) and concise subsections when needed. Do not use concept IDs or graph-style metadata.

When writing, be specific:

include parameter names, defaults, file paths, behavior details
include rationale (why) for decisions
include cross-references to related memory entries

Example cross-reference:

See [Decision: Auth token TTL](../decisions.md#decision-auth-token-ttl)

Step 5: Verify and report

Re-read updated .memory/ files to confirm they reflect current understanding. Report what was added/updated and where.

Step 6: Sync cross-tool instruction files when project knowledge changed

Check whether .memory/knowledge.md was materially updated in this save. Material updates include project-level changes such as architecture, conventions, or build/test/lint commands.

If there was a material knowledge.md update:
- Read current instruction files: AGENTS.md, CLAUDE.md, .github/copilot-instructions.md, .cursorrules
- Update them to reflect the new core project knowledge while preserving tool-specific formatting and project-specific content.
If updates were only plans/research/tracking details (no project-level knowledge change), do not update instruction files.

Guidelines

Record what a future you (with no memory of this session) would need to know.
Outcomes and rationale are more valuable than ceremony.
Don’t log process-only updates like "started phase X".
Keep hierarchy shallow (max 2 heading levels preferred).
Be specific. "Handles auth" is weak. "JWT auth with RS256, validated in src/middleware/auth.ts, refresh tokens in Redis with 7d TTL" is useful.

3.2 KiB Raw Blame History Unescape Escape