alex
204bbb4c84
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
87 lines
2.5 KiB
Markdown
87 lines
2.5 KiB
Markdown
# Bootstrap Project Memory Files
|
|
|
|
RUN { git ls-files; git ls-files --others --exclude-standard; } 2>/dev/null | sort -u
|
|
READ README.md
|
|
|
|
You are bootstrapping `.memory/` files for this project.
|
|
|
|
Your job is to inspect the codebase and create an initial memory baseline in plain
|
|
markdown files. Capture architecture, core modules, conventions, and key decisions
|
|
so future sessions can resume quickly.
|
|
|
|
## Step 1: Create `.memory/` structure
|
|
|
|
Create (if missing):
|
|
|
|
```
|
|
.memory/
|
|
knowledge.md
|
|
decisions.md
|
|
plans/
|
|
research/
|
|
```
|
|
|
|
`.memory/` is tracked in git.
|
|
|
|
## Step 2: Inspect project structure
|
|
|
|
Run `git ls-files` to understand the project layout, then read `README.md` and
|
|
the highest-signal files for architecture and conventions.
|
|
|
|
Identify:
|
|
- What the project does (primary capabilities)
|
|
- Core modules/subsystems and responsibilities
|
|
- Key patterns/conventions (naming, layering, testing, config)
|
|
|
|
## Step 3: Write initial `knowledge.md`
|
|
|
|
Populate `.memory/knowledge.md` with:
|
|
- Project purpose and scope
|
|
- Architecture overview
|
|
- Key modules with file paths
|
|
- Important implementation patterns/conventions
|
|
|
|
Use markdown sections with max 2 heading levels.
|
|
|
|
## Step 4: Seed `decisions.md`
|
|
|
|
Populate `.memory/decisions.md` with any clear, durable decisions found in docs
|
|
or code patterns (for example: stack choices, testing strategy, architectural
|
|
constraints). Include rationale when known.
|
|
|
|
## Step 5: Initialize plans/research folders
|
|
|
|
- If active in-progress work is discoverable, create `.memory/plans/<feature>.md`
|
|
with scope, tasks, and acceptance criteria.
|
|
- If research artifacts are discovered, create `.memory/research/<topic>.md`
|
|
with findings and references.
|
|
|
|
## Step 6: Create/update cross-tool instruction files
|
|
|
|
After `.memory/knowledge.md` is populated, use it as the source of truth to
|
|
create or update all cross-tool instruction files:
|
|
|
|
- `AGENTS.md`
|
|
- `CLAUDE.md`
|
|
- `.github/copilot-instructions.md`
|
|
- `.cursorrules`
|
|
|
|
Each file should include the same core project guidance:
|
|
- project overview and purpose
|
|
- tech stack
|
|
- architecture summary
|
|
- coding conventions/patterns
|
|
- build/test/lint commands
|
|
- project structure overview
|
|
|
|
If any of these files already exist, preserve existing project-specific content
|
|
and merge in new knowledge instead of overwriting wholesale.
|
|
|
|
## Guidelines
|
|
|
|
- Be specific with file paths, APIs, parameters, and behavioral details.
|
|
- Keep sections concise and scannable.
|
|
- Prefer durable knowledge over transient status notes.
|
|
- Add markdown cross-references between related entries (for example,
|
|
knowledge entries linking to decisions).
|