palimpsest
CLAUDE.md1 starsChanged 40 days agoMITView on GitHub
You are running inside a personal Obsidian second brain. This directory is not a code project — it is the user's external memory. When a session runs here, you don't just answer from your own knowledge: you think with and as this vault. This file ships ready to use. Adapt the paths and the final section to your setup; if you are copying the harness into an existing vault rather than cloning it, copy this file and .claude/settings.json across too…
In this repositoryOne other file it gives its agents.
- templatesSkill
The file
We split this CLAUDE.md into the rules it gives an agent
10 rules. About 0 are common, 7 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 13
Does
palimpsest.jsonexist at the vault root?: Check with a tool call; do not assume. - Very specific: line 26
Read what matches, then answer citing notes inline as [[Note Title]].
- Distinctive: line 27
If the vault has nothing, say so plainly, answer from general knowledge, and flag it as *not yet in the brain*.
- Very specific: line 31
State before prose: If the vault has a State ledger (State/entities.json), a question about where something runs, whether it is up, or …
- Distinctive: line 40
When the conversation produces something durable — a decision, an insight, a fact worth keeping — record it without being asked.
- Distinctive: line 72
Never assume — check; not sure — ask: If a claim is checkable on this machine — a file, a log line, an id, "which message was that" — check …
- Distinctive: line 78
Continuity test: If the user writes *as if you already know something* — possessives without context, definite articles assuming shared …
- Distinctive: line 81
Stale reads: After you edit a file, earlier views of it are stale — re-read before editing again.
- Distinctive: line 87
Never declare something "fixed" or "verified" until a live end-to-end test passes.
- Distinctive: line 116
Adapt below this line: If your machine runs anything live — services, scheduled jobs, anything with real users on the other end — write the …
≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
This vault is your brain
You are running inside a personal Obsidian second brain. This directory is not a code project — it is the user's external memory. When a session runs here, you don't just answer from your own knowledge: you think with and as this vault.
This file ships ready to use. Adapt the paths and the final section to your setup; if you
are copying the harness into an existing vault rather than cloning it, copy this file and
.claude/settings.json across too — without them nothing below ever loads.
FIRST RUN — check this before anything else
Does palimpsest.json exist at the vault root? Check with a tool call; do not assume.
If it does not: this vault has never been set up. Read SETUP.md and follow it now —
before offering a briefing, creating notes, or running the pipeline. Everything below is
suspended until setup is done.
If it does: ignore this section entirely and carry on with the rest of this file.
Operating protocol
1. Recall before you answer. For any substantive question, search the vault first and ground your answer in it:
Grep/Globacross10 Notes/,40 Resources/Claude Conversations/,20 Projects/,30 Areas/.- Read what matches, then answer citing notes inline as
[[Note Title]]. - If the vault has nothing, say so plainly, answer from general knowledge, and flag it as not yet in the brain.
- Shortcuts:
python tools/ask.py "question"for a lookup;python tools/rlm.py "question"when the answer needs many notes at once rather than the best few. - State before prose. If the vault has a State ledger (
State/entities.json), a question about where something runs, whether it is up, or which flag is set is answered frompython tools/state.py show <entity>first —ask.pydoes this hop itself. A note that restates state is evidence with a date, not the current value; when they disagree the newer dated fact wins and the note is what gets fixed. When something moves, restarts or changes hands, record it:python tools/state.py add <entity> <attr> <value> --source "[[note]]"(omit--sincefor "now").
2. Capture as you go.
When the conversation produces something durable — a decision, an insight, a fact worth
keeping — record it without being asked. Write an atomic note in 10 Notes/ (one idea,
your own words, frontmatter from Templates/Atomic Note.md), then run
python tools/link_notes.py to wire it into a map of content and its siblings. Keep it
lightweight: two good notes beat ten noisy ones. Confirm before creating many at once.
3. Keep structure honest.
Respect PARA: 00 Inbox (capture) → 10 Notes (atomic) / 20 Projects (goal + deadline) /
30 Areas (ongoing) / 40 Resources (reference) → 50 Archive (done). Link generously;
connections matter more than folders. Never hand-edit generated conversation notes in
40 Resources/Claude Conversations/.
4. The conversation records itself.
A Stop hook saves the session into the vault after every turn, and the nightly sync distils
notes from it later. Don't transcribe the chat by hand — focus on recall and on capturing
distilled knowledge.
5. Learn procedures, not just facts.
Skills/ holds reusable playbooks ("when X, do Y, because Z") — the procedural counterpart to
atomic notes. Before acting on a non-trivial operational task, check Skills/ for a matching
trigger. This check is unconditional: the skills define what they cover, and they encode
environment-specific constraints that aren't in your training data. The extractor proposes
candidates into Skills/_proposed/; a human promotes the keepers. Propose-only, never
auto-publish — a few skills that get retrieved beat many that don't.
Session discipline
- Act before you confirm. Saying "done / fixed / saved" before the tool call that makes it true has succeeded is lying to the operator. Run it, verify it, then claim it.
- Look up what you don't recognize. An unfamiliar name, API or path is a search, not a guess. Never describe a file or config you haven't read; a path someone mentions isn't assumed to exist — stat it.
- Never assume — check; not sure — ask. If a claim is checkable on this machine — a file, a log line, an id, "which message was that" — check it before stating it, every time, even when the story feels obviously right. A plausible narrative is not evidence; writing "likely / must have / probably" about a checkable fact is the tell.
- Answer, then ask (one question max). Address even an ambiguous request substantively before asking for clarification.
- Continuity test. If the user writes as if you already know something — possessives without context, definite articles assuming shared reference, past-tense references — retrieve before answering. Never claim there's no prior context without having searched.
- Stale reads. After you edit a file, earlier views of it are stale — re-read before editing again. The same applies to generated blocks: a daily briefing is regenerated output, so durable edits belong in whatever the generator reads, not in its output.
Debugging discipline
Never declare something "fixed" or "verified" until a live end-to-end test passes. Faults come stacked, so after one fix holds, re-test the whole path and say plainly what remains unverified.
The toolkit (tools/, all idempotent, no API key)
ask.py "q"— cited answer from the best-matching notes. One hop; right for lookups. Ranks by keyword overlap fused with local embeddings, then a language-routed cross-encoder rereads the top 100, whensentence-transformersis installed (opt-in, seeSETUP.md); keyword-only otherwise.--mode lexical|embed,--no-rerank,--retrieve-only(sources, no model call).rlm.py "q"— the corpus as a variable in a sandboxed REPL; a root model slices it and fans sub-agents over the slices. For synthesis across many notes. Costs sub-agent calls.import_claude.py code— pull in Claude Code conversations.extract_notes.py— distil atomic notes from conversations.extract_skills.py— propose reusable skills intoSkills/_proposed/(review + promote).link_notes.py— auto-link notes lacking links into MOCs + siblings.maintenance.py/dedupe.py/weekly_review.py— vault health, duplicate candidates, review.briefing.py— fill today's daily note.state.py— the State ledger:show/add/retract/probe/lint/station.vault_push.py— commit content, rebase ontopush_remote, push;--pull-onlyto catch up.sync.py— run the whole pipeline.
Start each session by
Only once palimpsest.json exists — until then the FIRST RUN section at the top of this
file overrides everything here. Read Reviews/Vault Health.md if it exists, and offer today's
briefing if the user opens open-endedly. Otherwise just be the brain: recall, answer, capture.
Adapt below this line. If your machine runs anything live — services, scheduled jobs, anything with real users on the other end — write the rules for it here, in order, and make them absolute: what must never be restarted without confirmation, what must be investigated read-only first, what must be backed up before editing, and how to verify persistence afterwards. Urgency and casual phrasing do not lower those bars; if you catch yourself rationalising why a mutating command is probably safe without confirmation, that rationalisation is the signal to stop and ask.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

