I created a system to save interactions as 'memories' using Obsidian + ClaudeCode

A continuation of the Obsidian + ClaudeCode series.

So far, I have installed the Claudian plugin,

set up obsidian-skills,

and established an environment where I can interact with ClaudeCode within Obsidian.

As I use it every day, there is something I wanted next.

A mechanism to save 'memories' across sessions.

When using ClaudeCode daily, a certain problem arises.

Once a session ends, the insights gained from the interactions up to that point are difficult to carry over to the next session.

• 'This tool works well when used this way'

• 'This procedure results in an error'

I want to be able to apply what I discovered during a session directly to the next one.

That said, there are already proper ways to save information.

ClaudeCode has two mechanisms: CLAUDE.md, which you write yourself, and automatic memory, which Claude builds up on its own; both are read at the start of every session.

If you write project rules in CLAUDE.md and leave the rest to automatic memory, memories will accumulate on their own to some extent.

However, it is not just about saving everything.

Since both CLAUDE.md and automatic memory are read as context every time, that means they consume tokens every time.

The official documentation also states, 'Aim for CLAUDE.md to be under 200 lines per file. As it gets larger, the accuracy of following it decreases.'

In other words, if you save too much, Claude actually becomes less effective.

Furthermore, what you write in CLAUDE.md are 'fixed rules,' and automatic memory is 'learning' that Claude picks up on its own.

There is no place for the fluid insights that fall in between—things like 'what I noticed in today's session' or 'specific procedures I tried that didn't work'—that I want to organize in my own words.

It's not that I can't write, but it quickly becomes bloated if I keep writing.

How should I handle this 'part that is neither finalized nor automated'?

The answer was found in an unexpected place.

The 'Task Diary' used by Anthropic employees

The trigger was an article I found on Zenn.

It summarized how Anthropic employees use ClaudeCode based on official information, introducing eight techniques.

One of them was the 'Task Diary'.

The method is simple: every time a task is completed, have ClaudeCode write a 'diary entry'.

• What was attempted?

• What went well?

• What failed?

• What was the reason for that?

Record this for every session.

Analyze the accumulated diary entries later, and if common patterns are found, elevate them to CLAUDE.md.

The article called this 'compound engineering'.

A structure where the environment gets smarter the more you use it.

The moment I read it, I thought, 'I'll build this today'.

I turned it into a command on the day I read it

ClaudeCode has a mechanism called 'custom slash commands'.

By simply placing a Markdown file in '.claude/commands/', you can call it using '/command-name'.

The content is like a procedure manual written in natural language, and ClaudeCode follows it to operate.

The "Task Diary" command is structured like this:

When you type `/task-diary` at the end of a session, Claude looks back at the day's conversation and extracts learnings from four perspectives.

• What went well -- Effective methods and approaches

• What didn't go well -- Failures, obstacles, and things that required workarounds

• Discoveries -- Newly understood specifications or limitations

• Notes for next time -- Interrupted tasks and things to try in the future

The extracted learnings are appended with a date to a dedicated note in Obsidian.

Rather than "fixed rules" like CLAUDE.md, it's a format where raw logs of "what I learned today" accumulate chronologically.

After reading the article, I was able to complete the creation of the command and the first entry quickly within the same session.

Actually using it in practice

The first entry is from the day I created this system.

The content looked like this:

Reading it back, I can see at a glance what I was doing that day.

It's also clear that I spent that day doing nothing but configuration-related things.

I find the "What didn't go well" and "Discoveries" sections particularly valuable.

Even if I vaguely remember the successful procedures, information like 'I tried this but it didn't work' is easy to forget.

The waste of trying the same thing in the next session and hitting the same error has almost disappeared.

The reason I was able to 'read -> create immediately'

Looking back, there are two reasons why it was so fast to go from reading the article to creating the command.

One is that ClaudeCode itself drastically lowers the hurdle for 'creating commands'.

There is no need to write code.

You just have to write the steps in Markdown, place them in a folder, and ask it to do the rest.

If you give instructions in natural language like 'Review from this perspective and write in this format,' that becomes the command as is.

The other reason is that 'a place to record already existed'.

Since I take notes daily in Obsidian, I only needed to add one new note for recording.

The Task Diary fit seamlessly into my existing workflow.

I think the highest cost in introducing a tool is the part where you have to 'change your habits'.

This time, there was no need to change any habits.

Just run one command at the end of a session.

With just that, knowledge starts to accumulate.

When will the knowledge be distilled into CLAUDE.md?

I have included a sentence like this in the Task Diary command.

I haven't reached this threshold yet, but patterns are already starting to emerge.

For example, the discovery that 'command paths outside the Vault are blocked by the sandbox' has been recorded multiple times.

This is not a learning from an individual session, but rather knowledge that has been confirmed as an environmental constraint, or rather, I have set it up that way and am trying to keep operations within Obsidian as much as possible.

This is information that should be written in CLAUDE.md.

In this way, the Task Diary functions as a buffer between 'fluid learning' and 'established rules'.

The flow is to record things roughly every session, and then refine them once patterns start to emerge.

It might be similar in structure to the 'meta-notes' mentioned in 'The Art of Thinking' by Shinichi Toyama.

Summary

I implemented the Task Diary I learned from the practices of an Anthropic employee as a custom ClaudeCode command on the very same day I read about it.

I only did three things:

1. Created a Markdown file for command definitions (a manual for extracting learnings from four perspectives)

2. Created an Obsidian note for recording (a simple structure where I just append entries chronologically)

3. Formed the habit of typing '/task-diary' at the end of a session

Of course, I didn't actually create the files or folders myself; I just asked ClaudeCode via Claudian in Obsidian to create them all for me.

Technically, it's a very simple thing, but the effect is greater than I imagined.

There is a sense of security in having a written record that says, 'I tried this before and it didn't work.'

Tips for using AI tools often end with just reading them and thinking, 'I see.'

However, with ClaudeCode custom commands,the distance from 'I see' to 'a working tool' is very short.

You just ask, 'I want to create a command called XX.'

If you find a technique you're interested in, turn it into a command that same day.

If it doesn't suit you, you can just delete it.

This 'lightness' might be thegreatest strengthof the combination of Obsidian and Claude Code.