How Cursor and Claude Share Project Memory Through Logseq

The problem with giving an AI assistant project memory is that the memory can be wrong by lunchtime.

In the previous post, I described Markdown as the bridge between my Logseq notes, code repositories, blog, and AI tools. The most useful piece was a savepoint: a small block containing the current state, what changed, what is blocked, and what comes next.

That solved half the problem. Cursor and Claude could read the savepoint before work. But if they finished a task and left the vault untouched, the next session still resumed from yesterday’s truth.

So I stopped treating project memory as something an AI has. I treat it as a read/write protocol:

1. Read durable context before material work.
2. Do the work in the repository.
3. Write material outcomes back before claiming completion.

The model still forgets. The workflow does not have to.

Two global rules, one durable layer

Both Cursor and Claude now receive two small global rules from my dotfiles:

• logseq-vault — when a question may depend on prior personal or project context, search the Logseq vault even if the current workspace is another repository.
• project-continuity — before material project work, resume from the current task, plan, or latest savepoint; afterward, write changed state and decisions back.

Cursor reads rules from ~/.cursor/rules/. Claude reads them from ~/.claude/rules/. Their file formats and discovery paths differ, but the instructions should not.

I keep one canonical copy under:

dotfiles/ai-context/shared/rules/
├── logseq-vault.md
└── project-continuity.md

Relative symlinks expose those files with Cursor’s .mdc name and Claude’s .md name. The dotfiles installer then links the tool-specific directories into $HOME.

That sounds like fussy plumbing until the two copies drift. One agent checks the task before work; the other checks the journal. One writes outcomes; the other only leaves a cheerful summary in chat. Congratulations, I have invented distributed inconsistency for two Markdown files.

One source keeps the behavior boring.

The global rule stays thin

The global continuity rule does not contain my entire task schema. It answers two questions:

• Where should an agent look before it starts?
• What must it update before it finishes?

The detailed workflow lives inside the Logseq vault in logseq-project-tasks.mdc. That vault rule owns status values, queue mapping, reminder rollover, savepoint shape, and transition policy.

This split matters. Global rules load across projects, so every extra paragraph consumes context whether I am editing aqno.dev or debugging a homelab service. The global rule should be a signpost, not the city.

The ownership chain is:

global Cursor / Claude rule
        │
        ▼
Logseq continuity rule
        │
        ├── task pages
        ├── project plan
        ├── project hub
        └── daily journal

Rules provide the route. The vault stores the state. Repository code remains the source of truth for implementation.

Reading before work

When a request names a task, the agent starts there. When it does not, the continuity rule gives it a deterministic search order:

1. Resolve the project from the request, workspace, or repository.
2. Check today’s journal for open reminders.
3. Find the newest project savepoint and follow its task link.
4. Read the task, then the active plan and project hub.
5. Use repository history or other journal activity only if the durable context is incomplete.

That order prevents a common AI reflex: scan a Git diff, infer the project plan from filenames, and confidently continue in the wrong direction.

Git is still useful evidence. It shows what happened to files. It is just not asked to explain product intent, rejected options, residual work, or why a task is deliberately waiting.

The vault gets first chance to answer those questions.

Each artifact owns one kind of truth

Write-back creates duplicate-looking information: task status, plan placement, a checkpoint, and a journal savepoint. Without explicit ownership, they slowly fall out of sync.

The workflow assigns each artifact one job:

Artifact	What it owns
Project hub	Scope, purpose, and links to the project’s durable artifacts
Plan	Manual queue order: Now, Next, Later, Done
Task	Canonical status, why, approach, acceptance criteria, verification, outcome, residual work
Plan checkpoint	Only the date and task to resume
Journal savepoint	A dated human-readable snapshot of state, done, blocked, and next
Reminder	Today’s open loop, linked to a task when it needs durable status

The task is canonical. The plan checkpoint is a pointer, not a tiny duplicate task. The journal is a historical snapshot, not a database row that gets rewritten every time the project changes.

That distinction lets the system be redundant in a useful way. Machines can search exact properties such as type:: task and status:: doing. Humans can open today’s journal and understand the day without joining four tables in their head.

Write back before saying “done”

The important rule is not “remember to update notes eventually.” Eventually is where context goes to die.

For material, authorized project work, the agent writes back in one pass before its final response:

1. Update the task’s status, outcome, verification, residuals, and next action.
2. Move the task’s short link to the matching plan section.
3. Refresh the plan checkpoint with the task to resume.
4. Add or update today’s project savepoint.

A savepoint stays small. For the task that moved this blog’s monospace font in-house, it read roughly:

### savepoint
- task: [[Self-host the blog's monospace font]]
- state: JetBrains Mono subset and served locally; the external font request is gone.
- done: Swapped the Google Fonts link for a local `@font-face` with `preload`.
- blocked: nothing.
- next: Re-run Lighthouse on throttled mobile before flipping the task to Done.

This is deliberately not a commit log. Another workflow already owns file and commit summaries. The continuity write-back preserves meaning: the decision, result, boundary, and handoff.

It also happens before the agent reports completion. A rule cannot wake up after I close the session, notice that I disappeared, and tidy the vault like a tiny project librarian. If the durable update matters, it is part of finishing the task.

Guardrails against a very talkative notebook

Automatic write-back can become note spam with impressive speed, so the rule has boundaries.

It does not write for:

• answer-only or read-only requests
• trivial questions
• work that did not materially change status, decisions, verification, residuals, or next actions
• sessions where I explicitly said not to mutate notes

It also does not rewrite old journal savepoints to match the present. Yesterday’s snapshot is allowed to be yesterday.

Day reminders use the same ownership model. A reminder line can say TODO, DONE, or postponed: 3 Days, but the linked task owns the actual status. When an open reminder rolls forward, the journal line moves to today and the postponement count is recomputed from the task’s creation date.

The point is not to record everything. It is to preserve the few facts that make resuming cheap.

What changed in practice

The difference appears at the start and end of ordinary work.

At the start, I no longer need to paste a project biography into a new Cursor or Claude session. The agent can resolve the project, follow the newest savepoint to the task, read the plan around it, and then inspect the repository with the intended direction already visible.

At the end, “done” has a durable meaning. The task says what passed and what remains. The plan no longer shows finished work under Now. Today’s journal contains one current snapshot instead of three competing summaries.

The same continuity layer also works across repositories. The global rule points to ~/workspace/private/logseq/ regardless of whether the active workspace is aqno.dev, Larry, dotfiles, or something unrelated. Project memory is not trapped inside whichever repository happened to be open.

Cursor and Claude still have different capabilities and session behavior. The rule does not make them the same tool. It gives them the same place to read from and the same obligation to leave the desk usable.

What this system does not solve

This is a Markdown workflow, not an autonomous memory service.

• The agents search raw files; there is no semantic Logseq query engine behind the rule.
• A bad or stale task page still produces bad context.
• Rules guide behavior; they do not mathematically guarantee that every model follows every instruction.
• Symlinks prevent Cursor and Claude instructions from drifting, not project facts from drifting.
• Human review still matters when an agent changes canonical status or captures a durable decision.

The system works because the state is inspectable. If an agent puts a task in Done while its verification is empty, I can see the contradiction in plain text and fix it.

Hidden memory would be more magical. Visible memory is easier to debug.

The smallest useful version

You do not need my schema or dotfiles repository to copy the pattern:

1. Pick one durable place for project context.
2. Define which artifact owns status, queue order, and dated history.
3. Give every AI tool a thin global rule that says where and in what order to read.
4. Require material work to write outcome and next action back before completion.
5. Exclude trivial and read-only work so the memory stays signal instead of exhaust.

The previous version of my workflow gave AI a notebook it could read. The latest version gives the notebook closing duties.

The model still starts each session without yesterday in its head. Now it knows where yesterday is—and it has to put today back before leaving.