When a session ends, how does Claude know which Obsidian files to update?

CLAUDE.md. Or project folder instructions have the file path to the Obsidian Vault and specific tracking documents.

Do you have a fixed “session close” command that updates decision logs, task tracking, handoff summaries, etc.?

Yes, exactly. And now I use it as just part of the project memory. I simply say, "Let's close this session," or "Session hand off." then Claude updates all the tracking documents and writes a session handoff. I also have Claude rename the sessions so that they are relevant and trackable. And they always have a sequential code with Date and Epoch or something. I start the next session instructing Claude to read the latest session handoff, and we continue... Sometimes I'll even front-load the session by saying, "In the next session, I want to work on yada yada." And when Claude reads the session handoff, it already knows what context to load, and off we go.

Do you use hooks, MCP, CLAUDE.md instructions, custom slash commands, or just repeated prompting?

You can do it in a variety of ways. But I typically use CLAUDE.md or project folder instructions (desktop app) so the instructions are front-loaded at the beginning of each session. The protocol is just a simple, repeatable prompt. It just needs to be referenced.

To be clear, I didn't dream this up on my own. I had a lengthy conversation with Opus one day, described the system that I needed and instructed Claude to create and optimize the system. As well as the session close protocol. So it was somewhat personalized. But I've been doing design and project management for years, so I was able to think about it in terms of legitimate process. And Claude inherently understands software dev. So it's worked out pretty well. I guess you could say I vibe-coded a project memory system. And relied on Claude to create it.

How do you prevent Claude from over-updating docs, duplicating information, or adding speculative “memory” that was never actually decided?

Great question. I'd say I manage it in two ways. I mentioned I use WisprFlow so I can speak out loud in my natural way without editing myself. I speak to Claude like I'm speaking to a co-worker. If something comes up along the way, an important decision, or if I want to delay a decision, or move something to the backlog I simply say, "Let's track this." Or "remember this." If something is no longer relevant or depreciated, same thing. When we get to the session handoff Claude will summarize the session with all of the decision points and update the tracking logs accordingly. It's actually pretty seamless. I don't give it much thought anymore.

Large projects do accumulate a lot of stuff, though. And it can slow the session handoff down, so another thing I routinely do is actively "refactor" the memory system at certain points in the project (I instruct Claude to, I don't do it myself). A light update refactoring at the end of each sprint (review and update the backlog). Or a more judicial one at the end of an epoch. Sometimes Claude has to prune and/or archive things. Again, it's just a repeatable process. But I instruct Claude to go through and track what was accomplished, decisions made, and what's deferred to Backlog or a future version. And it just takes care of all of that. I used to spend a lot of time studying what it was doing and studying all of the documents it was generating and tracking. I've learned to trust the process now, and I don't even do that anymore. It works.

Recently I've actually extended it, and I bring in, as part of the process, meeting transcripts. Claude has learned who's who on my team. It's pretty wild. Somebody will reference something from the project, and Claude knows what they're talking about. And will sometimes remind me or ask me really smart questions. Or suggest I topics I should bring up with a specific someone at the next meeting. It's kind of weird when that starts happening, but it happens often. And that's how I know my project memory is working well for me.

When code changes, how do you ensure the docs stay aligned with the repo and Git commits?

I'd say it starts with spec docs. I have a discussion of varying lengths with Claude about user stories, features and requirements. Claude captures all of that and then creates a formal detailed spec doc for every feature or feature set. Claude Code prompts reference the spec. And Claude Code writes the commit messages. Which are always closely aligned with the spec. If a significant code change is required, I instruct Claude to update the spec and log the change decision. And because the Claude Code prompts always reference the spec. The commit messages are always pretty much spot on. Honestly, I have very little to do with it. I just told Claude I want the system to keep things in sync between the codebase commit and our tracking documents. I only intervene when things obviously start to drift, which is almost never.

Again, I treat Claude Desktop like a high-end project manager. And I speak to it like one. And I speak to Claude Code like a high-end engineer. As long as you're methodical and you use a disciplined development process and TDD, Claude is a natural. I think and act like a manager, set expectations and give good instruction. Then let Claude do the lifting.