Guide — Best Practices
Best Practices
Step-by-step workflows to get the most out of AxiomSeal.
No technical knowledge required. Just follow the steps.
New here? Take the guided tour
A 60-second walkthrough of all key features.
1. Setting up a new project
You just created a new project and want your AI to understand it from the start. Follow these 4 steps in order:
Step 1: Create the project
Go to the Projects page in your dashboard and click “Create Project”. Give it a clear name (e.g. “my-webapp” or “client-api”). This name will be used to organize all your memories.
Step 2: Deep Scan your codebase
Open Claude Code in your project folder and paste this prompt. It will read the important files and create a memory for each one. After this, your AI has detailed memories of the key parts of your codebase.
Paste into Claude Code. Takes 2-10 minutes depending on project size.
Scan my project and create detailed memories for every important file: Determining project_id (do this first, it decides where everything lands): - If ~/.claude/eon_config.json has a project_map entry matching this directory, use that value. An explicit entry always wins. - Otherwise use the name of the folder containing .git (the repository root), lowercased, umlauts spelled out (ae/oe/ue/ss), and anything else that is not a letter or digit turned into a dash. "AT24 Shop" becomes "at24-shop", "Baeckerei Mueller" written with umlauts becomes "baeckerei-mueller". - No repository? Use the current folder's name under the same rule. - This is exactly what the hooks derive, so your memories and the automatic ones stay in one place. Note: eon_scan does NOT work here. It only reads directories inside your AxiomSeal workspace on the server, never your local machine. For a local project, read the files yourself and save each one with eon_create. For each source file in the project, read it and create a memory with eon_create containing: For API routes: HTTP method, path, parameters, response format, status codes, imports, error handling For database files: Full CREATE TABLE with types and constraints, relationships, example queries For components: Props interface, state hooks, event handlers, dependencies For config files: All settings with defaults, environment variables For lib/utils: Function signatures with types, return values, side effects Use category "context" and the project_id from the rule above. IMPORTANT: Each memory must be detailed enough that another AI could write or debug code from it alone, without reading the original file. Skip: node_modules, .git, build output, lock files, binaries, anything in .gitignore. Never put credentials into a memory — if a config file contains secrets, describe the KEY and its purpose, not the value. Start by listing all source files, then process them one by one. Before creating the first memory, call eon_search for that filename: a re-scan should update the existing memory with eon_update, not add a second copy.
Step 3: Create a roadmap
Now that your AI knows the code, ask it to create a roadmap. This gives you and your AI a shared plan of what needs to happen next.
Paste into Claude Code. Creates a roadmap memory for your project.
Create a project roadmap memory for this project: Determining project_id (do this first, it decides where everything lands): - If ~/.claude/eon_config.json has a project_map entry matching this directory, use that value. An explicit entry always wins. - Otherwise use the name of the folder containing .git (the repository root), lowercased, umlauts spelled out (ae/oe/ue/ss), and anything else that is not a letter or digit turned into a dash. "AT24 Shop" becomes "at24-shop", "Baeckerei Mueller" written with umlauts becomes "baeckerei-mueller". - No repository? Use the current folder's name under the same rule. - This is exactly what the hooks derive, so your memories and the automatic ones stay in one place. Step 1: Analyze current state Call eon_search with query "project overview architecture" to understand what exists Call eon_goals_list to check existing goals Step 2: Create the roadmap Call eon_create with: - title: "PROJECT ROADMAP — [Project Name]" - content: A structured roadmap with: * Current State: What's built, what works, what's deployed * Short-term (this week): Immediate tasks and fixes * Medium-term (this month): Features and improvements * Long-term (this quarter): Strategic goals * Risks & Blockers: What could go wrong * Definition of Done: How we know each milestone is complete - category: "roadmap" - project_id: from the rule above Step 3: Create matching goals For each short-term item, call eon_goals_create with appropriate priority and deadline. NOTE: Only ONE roadmap per project. Search first — if a roadmap for this project already exists, change it with eon_update(memory_id, ...) instead of creating a second one. If the old roadmap is genuinely obsolete rather than merely outdated in places, create the new one with supersedes: [old_id].
Step 4: Verify
Go to your Projects page and click on your project. You should see all the memories that were created. Check that:
- • Each important file has its own memory
- • The roadmap memory exists with clear goals
- • Quality tiers are mostly Silver or Gold
2. Adding AxiomSeal to an existing project
You already have a project with code and want to start using AxiomSeal. The process is the same as a new project, but with one extra consideration:
Quick start (5 minutes)
- 1. Open your project folder in the terminal
- 2. Run:
npx eon-memory init - 3. Enter your API key when asked (get it from Settings)
- 4. Open Claude Code in the same folder
- 5. Say: “Run eon_health to check the connection”
- 6. If it says “OK” — you're ready. Run the Deep Scan prompt from Step 2 above.
What happens after the Deep Scan?
Your AI now has detailed memories of the important files in your project. In the next session, it will search those memories before answering your questions — so you rarely need to explain your codebase again.
3. Daily workflow
Follow this simple routine every day to keep your AI's memory sharp and useful:
| When | What to do | How |
|---|---|---|
| Start of day | Check that everything is connected and review your stats | Health Check button on Memories page |
| During work | When you make an important decision or learn something new, tell your AI to save it | Say: “Save a memory about [what happened]” |
| End of day | Merge today's short notes into clean, structured knowledge | Consolidation button on Memories page |
Tip: You don't need to save everything. Focus on decisions (“we chose X because Y”), errors (“this broke because Z”), and context (“the client wants A not B”).
4. Weekly maintenance
Once a week, spend 5 minutes cleaning up your memories. This keeps your AI fast and accurate:
Deep Consolidation
This merges all your short memories from the past week into a few comprehensive ones. Instead of 30 small notes, you get 5 well-structured reference documents.
Paste into Claude Code once per week.
Perform a Deep Memory Consolidation — merge short-term memories into long-term knowledge: Step 1: Load ALL recent memories Call eon_list with limit 50 to get the full list Identify memories that are: session summaries, small updates, incremental progress notes Keep their ids — step 3 needs them. Step 2: Group into clusters Group related memories by topic/feature (e.g., "auth system", "database", "deployment") Aim for 3-7 clusters Step 3: For each cluster, create ONE consolidated memory Call eon_create for each cluster: - title: "[Topic] — Consolidated Knowledge" - content: Merge all related short-term memories into one comprehensive reference that includes: * What was built/changed * Key decisions and WHY they were made * Current state * Known issues * Code patterns and file locations - category: "context" - supersedes: the ids of the short-term memories this cluster absorbs Supersede only the routine notes you actually merged — session summaries and incremental updates. Leave decisions, error reports and anything citable on its own untouched; when unsure, leave it out. Without supersedes this prompt does not consolidate, it duplicates: the originals stay and every search returns both. Every memory must answer BOTH: - WHY: the problem, the cause, why it matters - HOW: the concrete step, file path, command or signature A memory with only one of the two is stored but scored incomplete. Step 4: Report Show: how many memories were analyzed, how many clusters created, which ids were superseded. This should run weekly or after every major work phase. It transforms scattered session notes into structured, searchable knowledge.
Review quality scores
Go to your Memories page. Look at the quality tier badges:
- • Gold — Excellent. No action needed.
- • Silver — Good. Could be improved with more detail.
- • Bronze — Too vague. Add file paths, function names, or reasons.
- • Review — Needs attention. Consider rewriting or deleting.
5. Writing high-quality memories
The difference between a useful memory and a useless one is detail. Here are the rules:
Bad memories
- “Fixed the login bug”
- “15 API routes exist”
- “Updated the database”
- “Refactored some components”
No detail. In 2 weeks, nobody knows what this means.
Good memories
- “Login bug: session cookie was missing SameSite=Lax, fixed in auth.ts:42”
- “POST /api/vote — session-based, returns {success, count}, 429 on rate limit”
- “Added user_preferences table with 4 columns: id, user_id, theme, language”
- “Split UserProfile into UserAvatar + UserSettings, reduced re-renders by 60%”
Specific. Another AI can act on this immediately.
The golden rule
Ask yourself: “Could another AI use this memory to write code in 6 months?”
If the answer is no, add more detail: file paths, function names, parameter types, error codes, or the reason behind the decision.
6. Using agents
AxiomSeal comes with optional AI agents that automate common tasks. Install them from the customer package:
All agents are installed automatically
When you run npx eon-memory init, all 3 agents are installed to ~/.claude/agents/ automatically. No manual setup needed.
Jarvis (Orchestrator)
For complex, multi-step tasks. Jarvis searches your memories first, breaks down the work, delegates to the right tools, and saves what was done. Best for: “Build feature X”, “Fix bug Y and write tests”, “Refactor module Z”.
Uses Opus model for highest quality reasoning.
Memory Manager
Manages your AxiomSeal memories automatically. Creates, searches, updates, and organizes. Best for: “Clean up my memories”, “Find everything about feature X”, “Organize memories by project”.
X-Ethics Reviewer
Reviews your code against the X-Ethics framework (Truth, Freedom, Justice, Service). Generates an alignment score from 0-100. Best for: code reviews, compliance checks.
Uses Sonnet model for fast reviews.
7. Ready-to-use prompts
These prompts are also available as buttons on your Memories page. Copy any of them and paste into Claude Code:
Health Check
Verifies connection, counts memories, checks quality scores, tests search.
Available as button on the Memories page or via Setup Guide.
Deep Project Scan
Reads the important files in your project and creates a detailed memory for each. Use when starting with a new codebase.
Takes 2-10 minutes depending on project size.
Scan my project and create detailed memories for every important file: Determining project_id (do this first, it decides where everything lands): - If ~/.claude/eon_config.json has a project_map entry matching this directory, use that value. An explicit entry always wins. - Otherwise use the name of the folder containing .git (the repository root), lowercased, umlauts spelled out (ae/oe/ue/ss), and anything else that is not a letter or digit turned into a dash. "AT24 Shop" becomes "at24-shop", "Baeckerei Mueller" written with umlauts becomes "baeckerei-mueller". - No repository? Use the current folder's name under the same rule. - This is exactly what the hooks derive, so your memories and the automatic ones stay in one place. Note: eon_scan does NOT work here. It only reads directories inside your AxiomSeal workspace on the server, never your local machine. For a local project, read the files yourself and save each one with eon_create. For each source file in the project, read it and create a memory with eon_create containing: For API routes: HTTP method, path, parameters, response format, status codes, imports, error handling For database files: Full CREATE TABLE with types and constraints, relationships, example queries For components: Props interface, state hooks, event handlers, dependencies For config files: All settings with defaults, environment variables For lib/utils: Function signatures with types, return values, side effects Use category "context" and the project_id from the rule above. IMPORTANT: Each memory must be detailed enough that another AI could write or debug code from it alone, without reading the original file. Skip: node_modules, .git, build output, lock files, binaries, anything in .gitignore. Never put credentials into a memory — if a config file contains secrets, describe the KEY and its purpose, not the value. Start by listing all source files, then process them one by one. Before creating the first memory, call eon_search for that filename: a re-scan should update the existing memory with eon_update, not add a second copy.
Create Roadmap
Analyzes your project and creates a structured plan with goals and milestones.
Creates one roadmap memory per project.
Create a project roadmap memory for this project: Determining project_id (do this first, it decides where everything lands): - If ~/.claude/eon_config.json has a project_map entry matching this directory, use that value. An explicit entry always wins. - Otherwise use the name of the folder containing .git (the repository root), lowercased, umlauts spelled out (ae/oe/ue/ss), and anything else that is not a letter or digit turned into a dash. "AT24 Shop" becomes "at24-shop", "Baeckerei Mueller" written with umlauts becomes "baeckerei-mueller". - No repository? Use the current folder's name under the same rule. - This is exactly what the hooks derive, so your memories and the automatic ones stay in one place. Step 1: Analyze current state Call eon_search with query "project overview architecture" to understand what exists Call eon_goals_list to check existing goals Step 2: Create the roadmap Call eon_create with: - title: "PROJECT ROADMAP — [Project Name]" - content: A structured roadmap with: * Current State: What's built, what works, what's deployed * Short-term (this week): Immediate tasks and fixes * Medium-term (this month): Features and improvements * Long-term (this quarter): Strategic goals * Risks & Blockers: What could go wrong * Definition of Done: How we know each milestone is complete - category: "roadmap" - project_id: from the rule above Step 3: Create matching goals For each short-term item, call eon_goals_create with appropriate priority and deadline. NOTE: Only ONE roadmap per project. Search first — if a roadmap for this project already exists, change it with eon_update(memory_id, ...) instead of creating a second one. If the old roadmap is genuinely obsolete rather than merely outdated in places, create the new one with supersedes: [old_id].
Weekly Consolidation
Merges short-term memories into clean, structured reference documents.
Run once per week to keep your memory clean.
Perform a Deep Memory Consolidation — merge short-term memories into long-term knowledge: Step 1: Load ALL recent memories Call eon_list with limit 50 to get the full list Identify memories that are: session summaries, small updates, incremental progress notes Keep their ids — step 3 needs them. Step 2: Group into clusters Group related memories by topic/feature (e.g., "auth system", "database", "deployment") Aim for 3-7 clusters Step 3: For each cluster, create ONE consolidated memory Call eon_create for each cluster: - title: "[Topic] — Consolidated Knowledge" - content: Merge all related short-term memories into one comprehensive reference that includes: * What was built/changed * Key decisions and WHY they were made * Current state * Known issues * Code patterns and file locations - category: "context" - supersedes: the ids of the short-term memories this cluster absorbs Supersede only the routine notes you actually merged — session summaries and incremental updates. Leave decisions, error reports and anything citable on its own untouched; when unsure, leave it out. Without supersedes this prompt does not consolidate, it duplicates: the originals stay and every search returns both. Every memory must answer BOTH: - WHY: the problem, the cause, why it matters - HOW: the concrete step, file path, command or signature A memory with only one of the two is stored but scored incomplete. Step 4: Report Show: how many memories were analyzed, how many clusters created, which ids were superseded. This should run weekly or after every major work phase. It transforms scattered session notes into structured, searchable knowledge.
Need the installation guide?
If you haven't set up AxiomSeal yet, start with the Setup Guide.