49 lines
3.2 KiB
Markdown
49 lines
3.2 KiB
Markdown
# AMCS Memory Instructions
|
|
|
|
AMCS (Avalon Memory Crystal Server) is an MCP server for capturing and retrieving thoughts, memory, and project context. It is backed by Postgres with pgvector for semantic search.
|
|
|
|
You have access to an MCP memory server named AMCS.
|
|
|
|
Use AMCS as memory with two scopes:
|
|
- Project memory: preferred when the current work clearly belongs to a known project.
|
|
- Global notebook memory: allowed only when the information is not tied to any specific project.
|
|
|
|
## Scope Selection Rules
|
|
|
|
1. Infer the current project from the repo, current working directory, README, package or app name, and any explicit user instruction.
|
|
2. Call `get_active_project`.
|
|
3. If the active project clearly matches the current work, use it.
|
|
4. If not, call `list_projects` and look for a strong match by name or explicit user intent.
|
|
5. If a strong match exists, call `set_active_project` and use project-scoped memory.
|
|
6. If no strong project match exists, you may use global notebook memory with no project.
|
|
7. If multiple projects plausibly match, ask the user before reading or writing project memory.
|
|
|
|
## Project Memory Rules
|
|
|
|
- Use project memory for code decisions, architecture, TODOs, debugging findings, and context specific to the current repo or workstream.
|
|
- Before substantial work, always retrieve context with `get_project_context` or `recall_context` so prior decisions inform your approach.
|
|
- Save durable project facts with `capture_thought` after completing meaningful work.
|
|
- Use `save_file` for project assets the memory should retain, such as screenshots, PDFs, audio notes, and other documents.
|
|
- Link files to a specific memory with `thought_id` when the file belongs to one thought, or to the project with `project` when the file is broader project context.
|
|
- Use `list_files` to browse project files or thought-linked files before asking the user to resend something that may already be stored.
|
|
- Use `load_file` when you need the actual stored file contents back.
|
|
- Do not attach memory to the wrong project.
|
|
|
|
## Global Notebook Rules
|
|
|
|
- Use global memory only for information that is genuinely cross-project or not project-bound.
|
|
- Examples: user preferences, stable personal workflows, reusable conventions, general background facts, and long-lived non-project notes.
|
|
- If information might later be confused as project-specific, prefer asking or keep it out of memory.
|
|
|
|
## Memory Hygiene
|
|
|
|
- Save only durable, useful information.
|
|
- Do not save secrets, raw logs, or transient noise.
|
|
- Prefer concise summaries.
|
|
- Prefer linking a file to a thought plus a concise thought summary instead of storing opaque binary artifacts without context.
|
|
- When saving, choose the narrowest correct scope: project if project-specific, global if not.
|
|
|
|
## Short Operational Form
|
|
|
|
Use AMCS memory in project scope when the current work matches a known project. If no clear project matches, global notebook memory is allowed for non-project-specific information. Store durable notes with `capture_thought`, store supporting binary artifacts with `save_file`, browse them with `list_files`, and load them with `load_file`. Never store project-specific memory globally when a matching project exists, and never store memory in the wrong project. If project matching is ambiguous, ask the user.
|