Playbook · the problemNucleus tried & tested

Wire Nucleus into Claude Code

Claude Code remembers your repo. It forgets everything around it.

Your CLAUDE.md and Auto Memory are genuinely good, but both stop at the repo boundary: memory captured in one repo is invisible in the next, it is capped, and when a session hits compaction the exact code and reasoning get summarized away. The decision you made last month, the pattern in your other service, the live database schema: none of it is in this repo's markdown.

So you re-explain across every repo, and lose the thread every time the window compacts. The memory works. It just does not reach past this one repo, this one session, this one tool.

Built for

Claude Code devs working across repos, tools, and long sessions

The problem

Claude Code remembers your repo. It forgets everything around it.

The core

A single grounded context layer that every agent reads from, so your stack stays consistent across sessions and across tools.

The stance

Keep the built-in memory. Give it somewhere to persist.

Without the layer

This repo's memory

CLAUDE.md + Auto Memory

Session

context window

Compacted away

lost on reset

Auto Memory is per-repo, capped, machine-local
Compaction discards the exact code and reasoning
Cannot reach your DB, other repos, or docs
Cursor and ChatGPT cannot read any of it

With Nucleus

Every repo + session + source

notes + repos + your Postgres

Nucleus

context layer

Any agent

reads the layer

Memory that carries across every repo
Captures the session before compaction drops it
Queried, so scale does not dilute it
Joined to your DB and docs, read by any tool

Without the context layer, the agent reasons over a flat, stale snapshot. That is where it breaks.

The command

Per prompt · type it in any chat

Save this full chat transcript into my Nucleus, complete, including the thinking.

Set once · settings → custom instructions

Update my Nucleus session with the decisions and AI instructions from this work, so future sessions across my repos can use them.

Once it's in your settings, every task starts grounded. You can still say use Nucleus at Attio to point it at a specific source.

Before you start

A Nucleus workspace
Claude Code installed

Steps

Add Nucleus as an MCP server (user scope)

In your terminal, add Nucleus as an MCP server at user scope so it loads in every repo, not just this one:

claude mcp add --transport http nucleus --scope user https://app.nucleus.ae/api/mcp

Use --scope user on purpose: it makes Nucleus available across all your projects on the machine, which is the whole point. --scope project shares it with your team via .mcp.json instead; --scope local keeps it to one repo.

Keep your md files exactly where they are

Do not move your CLAUDE.md or docs into Nucleus. They stay in the repo, version-controlled, auto-loading. Nucleus sits alongside them as the cross-repo, cross-tool memory they cannot be.

Why not just Auto Memory? It is free and on by default, but it is per-repository, capped at 200 lines, and machine-local, and even Dreaming only reviews one repo's own sessions. Nucleus is for when your context spans multiple repos, multiple tools, or live sources.

Capture the session before it compacts

Claude Code auto-compacts when the context window fills up: it summarizes the conversation and discards the exact code and reasoning. Before that happens, save the real transcript to Nucleus so it stays queryable.

Watch for the context warning in your terminal or VS Code status line, that is your cue. Type: 'Save this full chat transcript into my Nucleus, complete, including the thinking.' Now the full session is in the layer, not a lossy summary.

Optional: connect your Postgres, and Claude Code builds against your real data

If you already have a database behind your app, connect your Postgres to Nucleus. Now Claude Code reasons over the real schema, table shapes, foreign keys, and key relationships while it builds, instead of guessing them from a markdown description. It reads the structure of your data, not a doc about it.

Optional. Skip it if you are not building on a database yet, the memory layer stands on its own. This is a real Nucleus capability (read-only DB connect), available via the dashboard.

Bonus: spin up an interface from a ghost database

Have a database running quietly in the background, data preloaded but no front-end yet? Point Nucleus at it, and Claude Code can build an accurate web or mobile interface off its real structure. Nucleus reads the table relationships, the foreign keys, the stale and live key data, so what Claude Code scaffolds matches the actual database, not a guess. We do exactly this at Nucleus when we need a front-end for a silent ghost database.

This uses the database's structure as ground truth (schema, keys, relationships), not your row data as prompt context. That is why the interface comes out accurate: it is shaped by the real data model.

Reason across everything

In any repo, prefix a request with 'use Nucleus' and Claude Code reads the layer over MCP: your past sessions, your other repos, and any source you have connected, database included.

Try these in Claude Code

Each reaches past what this repo's memory holds, to another repo, a live source, or a session that already compacted.

1. "Use Nucleus: how did we solve auth in the other service, and apply that pattern here." (cross-repo)

2. "Use Nucleus: read the actual users table before you write this query, do not guess the columns." (real data / schema)

3. "Use Nucleus: pull up what we decided about rate limiting before the session compacted last week." (pre-compaction recall)

4. "Use Nucleus: scaffold an admin UI from my Postgres, match the real foreign keys and relationships." (ghost-database build)

Auto Memory cannot answer these. It only knows this repo, and only what survived the last compaction.