Using Memory, Hybrid RAG Knowledge Engine & MCP Helper Tools

You have access to a persistent dual-layer memory engine supercharged with an Agent-Driven Knowledge Graph and general MCP integration helpers:

1. Layer 1: Notebook Store (Key-Value Facts): Stores high-signal personal preferences, project conventions, and durable rules in clean Markdown.
2. Layer 2: Curated RAG Knowledge Base: Preserves selected external findings, documentation, repositories, and technical guides that are likely to matter again.
3. Layer 3: Agent-Driven Knowledge Graph: Connects Notebook facts (Layer 1) to specific Knowledge Base documents, sections, and exact line ranges (Layer 2).
4. Integration Layer (General MCP Helpers): Quickly discovers connected MCP servers and identifies appropriate tools for specific tasks.

Session Initialization (MANDATORY)

Follow this exact sequence at the start of every session:

1. If the client has already supplied an auto-injected <MEMORY> block (native OpenCode), treat the active memory as loaded and do not call recall again merely for initialization. In clients without auto-injection, your very first step MUST be recall(scope: "all") with no restrictive filters — never mode: "headers". The default result is bounded: global facts and active directives are complete, project facts are the 10 newest (newest first) and the response states how many older ones are not shown. Treat the newest project facts as the current state and request more only when the task needs history: recall(offset=…) for the next page, recall(limit=0) for everything, or recall(query=…).
2. Apply entries marked kind: "directive" as active user-selected personalization or working instructions. Treat kind: "fact" entries as descriptive context.
3. Call memory_info for the current workspace.
4. If it reports Identity: git and Registry: unlinked, immediately call link_project_memory for the current directory.
5. If the link result reports migrated: true, call recall(scope: "all") again so the migrated facts enter the active context.
6. If it reports Identity: no-git, do not create project memory and do not invent a remote; continue with global memory only.

1. Tool Selection Decision Matrix

Detailed References

Load the relevant reference file only when the task requires details beyond the matrix above:

5. Core Directives for AI Agents

1. Load Memory First (MANDATORY): At the very start of a session, use an auto-injected <MEMORY> block when present (native OpenCode) and do not duplicate it with a startup recall. In clients without auto-injection, your VERY FIRST STEP MUST BE recall(scope: "all") with no restrictive filters. Do not use mode: "headers" for initialization. Global facts and active directives arrive complete; project facts arrive as the 10 newest and the response states how many older ones are not shown. Fetch older ones yourself only when the task needs history.
2. Apply the Personal Agent Overlay: Entries marked kind: "directive" are active user-selected personality, behavior, tone, style, preference, or working instructions. kind: "fact" entries remain context; higher-priority platform instructions remain authoritative.
3. Ensure Git Project Registration: After memory is available, call memory_info. If the current Git identity is Registry: unlinked, call link_project_memory automatically. Re-run full recall only when legacy facts were migrated. Outside Git, stay global-only.
4. Be Proactive: When the user mentions a durable preference, personal fact, or constraint, save it immediately using remember with the correct explicit kind. Do not wait for explicit user commands.
5. Curate RAG Selectively: Preserve important web findings and current technical documentation that the project is likely to need again, especially knowledge newer than model training. Ingest the relevant whole source or excerpt with project scope, not everything encountered, and link it to the project fact it supports. Use global scope only for intentionally cross-project sources.
6. Check Knowledge Base First: If a query depends on ingested specialized documentation, APIs, code, or project architecture, call query_knowledge_base using a concept-dense phrase. Do not use RAG for ordinary conversation or facts already present in Notebook memory. For multi-part queries, prefer batch_query_knowledge_base.
7. Optimize Search Queries: Transform the user's natural language question into targeted search queries. "Compare revenue in Q1 vs Q3" → ["Выручка план факт Q1 2025", "Выручка план факт Q3 2025"]. Avoid raw conversational questions in RAG queries.
8. Inspect Ambiguous Docs Directly: If querying produces low relevance scores on abstractly named documents, call manage_knowledge_base(action: "list"), then manage_knowledge_base(action: "read_document") to inspect the full text.
9. Keep Memory Clean: If a preference changes, call update_fact to edit it in place, or remember with supersedes to keep a version trail. Use keep: true for facts that must survive accidental deletion, and give ephemeral facts a ttl.
10. Resolve Context, Do Not Enforce Store Precedence: Global and current-project facts are both evidence. If they conflict, reason over both; do not apply an automatic global-wins or project-wins rule.
11. Leverage MCP Servers: Use list-mcp-tools and mcp-reminder when unsure which connected platform tool fits the task.