Living with Claude Code
This page has been translated by machine translation. View original
Introduction
Hello, I'm Morishige from Classmethod's Manufacturing Business Technology Department.
Have you just started using Claude Code but still treat it like "just a slightly smarter terminal"? Or maybe you use it every day but feel like "it's a shame that context resets every time a session ends."
AI coding tools are convenient, but if you use them as-is, they tend to become "a smart but amnesiac pair programming partner." The background behind a bug you debugged yesterday, the reason for a design decision from last week — it all starts fresh in a new session. Anyone who has thought "...do I really have to explain this all over again?" knows exactly what I mean. The more projects you have, the more this "context fragmentation" starts to wear on you.
In the Claude Code community, solutions for memory persistence and development efficiency — including Claude-Mem — are emerging every day. We're entering an era where ambient AI acts automatically on your behalf, but honestly, I haven't yet found myself truly leveraging that wave. So for now, I'm centering my workflow around "actions I trigger myself" — using Claude Code's standard hook features and custom commands — and building systems within my own reach. I might be saying something different next month, but please read this as a snapshot from January 2026.
In this article, I focus less on the system itself and more on how I spend my day using it. I hope you'll find some discovery — "oh, you can use Claude Code like that" — and maybe some hints you can incorporate not just into your development workflow, but into your everyday life as well.
The Workspace as "Mothership"
My entire day starts from one workspace. Rather than individual project repositories, I use a knowledge management workspace as my "mothership," loading projects from there.
workspace/（mothership）
├── knowledge/ # Daily logs, meeting notes, research, news
├── blog/ # Technical article writing
├── scratchpad/ # Brainstorming & per-project notes (tends to get messy)
├── .claude/ # Custom commands, hooks, agent definitions
└── second-brain-server/ # Memory persistence infrastructure
Project code is dynamically added with the /add-dir command. The workspace's CLAUDE.md applies as the base ruleset, while project-specific rules take precedence where they exist.
The "Memory Infrastructure" in the bottom right of the diagram is the heart of this setup. Simply put, it combines two approaches for saving and retrieving memories. The first is a knowledge graph via Graphiti + FalkorDB, which excels at tracing causal relationships like "what was decided when and why." The second is vector search via PostgreSQL + pgvector, suited for fuzzy memory searches like "I feel like I saw a similar bug before." Both are processed by Ollama (a local LLM runtime), with no dependency on external APIs. Everything runs in Docker Compose, so the entire setup can be migrated to another machine container by container. I'll go into more detail in the "Behind the Memory Infrastructure" section later.
The reason I chose this setup is to accumulate knowledge across projects. Know-how from dealing with an iOS Safari bug in Project A might be useful in another project. A technology explored during a feature brainstorm might find use in a new project. By starting from the workspace, all session histories and decision logs collect in one place.
Let me now walk through a day in the life starting from this mothership.
Morning: Starting with Context in Place
My day begins by typing /morning first thing in the morning.
While I'm brewing coffee, today's schedule and tasks come out in an organized state. Behind the scenes, it fetches events from Google Calendar and checks my task list in Craft via MCP (I manage personal documents and notes in Craft). The result is that I can enter planning mode with "what I should do today" already visible.
What I quietly appreciate is that things I wrote "do tomorrow" in the previous day's session carry over via the Graphiti knowledge graph introduced earlier. It lets me pick up naturally from where I left off — like "In yesterday's session, you mentioned you'd revisit the CSP header configuration."
Morning: Diving Into a Project
When I start development, I first type /context-load project-a in the workspace.
This pulls up past decisions about Project A, the current state of work, and known issues. The sources aren't limited to Graphiti's knowledge graph — documents and related materials accumulated in the project directory are also loaded. Meeting notes organized with /meeting-note in past meetings are also reflected via Graphiti, so I already have context in my head before reading the code — things like "Cognito authentication was implemented using a custom UI approach" or "this is the reasoning behind the DynamoDB GSI design decision."
What's interesting during development is that context switches dynamically based on conversation content. If I write "investigate this bug," for example, solutions to similar past errors automatically surface. Behind the scenes, Claude Code hooks detect the user input's intent (debugging, design, research, etc.) by keywords and inject relevant memories. Without any conscious effort, related knowledge from the past enters the conversation.
Another mechanism is being able to ask another AI for a review. When I'm unsure about a design direction, Claude Code calls OpenAI's Codex CLI via MCP for a brainstorming session. Since the session persists, it's not just a one-off question — I can have multiple exchanges like "the design intent here is like this, what do you think?" "I see, so what about this pattern then?" Claude Code decomposes the task and delegates to the external AI, so I just talk to Claude Code as usual. It feels like having a teammate even while developing solo — and that's always a good feeling.
Once morning development on Project A reaches a stopping point, I save the state with /context-save project-a and switch to another project. For Project B preparation it's /context-load project-b, for blog writing it's /context-load blog, and so on.
This "context load/save" feels like save points in an RPG — the cost of switching from one dungeon (project) to another has dropped considerably. By the way, even if you forget to run /context-save, it's fine. When you end a session with /exit or /clear, a hook fires and a background worker automatically records a summary of the session content. It's a two-layer system of manual saves and auto-saves.
Uses Beyond Development
I've been talking mostly about coding so far, but Claude Code's role actually goes beyond that.
For instance, planning a family trip. I typed "Seoul in October, 3 nights 4 days, including a rainy day plan" into the terminal and brainstormed candidates from there. I could have opened ChatGPT, but being able to just ask in the terminal I already have open is so convenient that I end up using it anyway.
I also frequently use it for brainstorming design decisions. Something like "for this use case, which is better — DynamoDB single-table design or multi-table design?" I get the pros and cons laid out and then make the decision myself. This use as "a partner to organize my thinking" rather than "to get me an answer" feels less like a development tool and more like a thinking partner.
Organizing sudden ideas, summarizing English documentation, refining text for team sharing. The subtle comfort of handling things that are "not quite worth opening a browser for, but I'd like to ask someone" — all without leaving the terminal — is genuinely pleasant.
Afternoon: Organizing Inputs
I often dedicate the afternoon to input.
With /clip-news, I use the Perplexity AI MCP server to search for and summarize AI-related news, organizing it into a digest. Topics I find interesting get deep-dived with /research. Research results are saved in knowledge/research/, and anything that looks like it could become blog material is automatically added to the backlog.
For example, recently my research on local LLMs developed directly into a technical blog post. It's a seamless flow from "things I investigated" to "things I write."
On days with meetings, I organize meeting notes with /meeting-note. My regular meetings are on Google Meet, and Meet's transcription feature automatically saves to Google Docs. I just pass that transcription data to Claude Code via Google Drive, and it handles the extraction and structuring of key points — so the effort for writing meeting notes is nearly zero. The key point here is a deliberate choice: keep only a link and summary locally, with master data in Google Docs. Trying to hold everything locally leads to breakdown, so I've adopted a policy of "keep only the index at hand."
For offline meetings and study sessions, I pass transcription data from PLAUD.ai to /meeting-note. Even without transcription data, passing handwritten notes directly gets them structured, so the input barrier is low.
Evening: Converting to Output
This is the time to turn inputs into outputs.
Loading /context-load blog brings up a list of in-progress articles, the backlog, and writing guidelines. From there I either work on new draft ideas with /blog-draft or refine the continuation of an existing draft.
For topics that need deeper exploration, I use a dedicated research agent. It investigates across multiple sources like Perplexity AI and AWS documentation and compiles results with citations, which is useful for fact-checking articles as well.
With this flow, I published 3 articles in January. Since research, writing, and review all happen within the workspace, the barrier to getting started when I think "let me write" is low — I think that's a big part of it.
End of Day: Reflection and "Saving"
At the end of the day, I reflect with /daily-log.
What's interesting about this command is that it leads the reflection based on the plan I set in the morning's /morning. It asks "this task was in today's plan — did you complete it?" and I just answer with a number. Incomplete tasks can be moved to "carry over to tomorrow," "no longer needed," or "on hold."
Once the plan check is done, it asks about Good (what went well) and Could be better (what could be improved). Daily logs have a reputation for being "tedious to write," but the conversational format makes them feel considerably less burdensome. Especially in solo development, reflection itself tends to get forgotten, so having a forced trigger is helpful. The final result is saved as a Markdown daily log file in knowledge/daily-logs/ and also synced to Craft's Daily Notes.
The "things to do tomorrow" written here carry over to the next morning's /morning, creating a cycle that starts with /morning and closes with /daily-log.
Separately from the daily log, session records are automatically saved as well. When a session ends, a summary of the conversation log is automatically generated in the background and registered to the knowledge graph. The reason "continuing from yesterday" mostly works in the next day's session is thanks to this mechanism. Technically, the SessionEnd hook sends an async job to a Docker worker, which follows the flow: generate Markdown → create summary with Ollama → register to Graphiti. Since hooks execute synchronously and have timeouts, the design queues heavy processing.
Also, Markdown files edited in external editors (VSCode, Obsidian) are automatically registered to Graphiti via a post-commit hook at git commit time (a standard git feature that can execute arbitrary scripts right after a commit). By treating "commit = declaration that this state is worth keeping," notes written outside of Claude Code sessions are also incorporated into memory.
In other words, a dual structure of intentional reflection (/daily-log) and unconscious recording (SessionEnd hook + post-commit hook) carries the day's knowledge forward to the next day.
Even From the Bath or in Bed?
I also use Claude Code from the bath, or lying in bed before sleep.
The mechanism is: I have a tmux session running on an always-on Mac mini, connected via Happy CLI — a mobile client for Claude Code — through the Happy app on my iPhone. Happy CLI is a tool that connects to a remote terminal with E2E encryption; once you scan the QR code once, it auto-connects afterward.
Why go that far? Because the freshness of a sudden idea doesn't last until the next morning. When I think "that implementation, wouldn't it be better this way?" — I brainstorm quickly from the iPhone on my nightstand and leave a note with /quick-note. When I type /morning the next morning, that note is reflected in how planning starts.
Notes scrawled from the bath or bed naturally blend into the next morning's context. This "idea → record → next morning's action" cycle never breaks, and that's quietly wonderful. The sight of me typing git status on an iPhone's small screen with flick input isn't something I'd want others to see — but once you know this convenience, there's no going back.
Behind the Memory Infrastructure
"So how exactly do you save those memories?" — some of you may be wondering. The "second-brain-server" I built myself is what supports everything described so far.
The thing I cared most about in the design is a locally self-contained setup with no dependency on external APIs. Graphiti is designed by default to use the OpenAI API, but I implemented a custom LLM client and Embedder so it runs on Ollama alone. Cost is a factor, but even more than that — there's something fun about "having my own personal memory space on hand." Entrusting my memories to an external API gives me a vague unease, like my thoughts are leaking outside. Though since Claude Code's conversations are sent to Anthropic, I can't really claim it's fully offline.
The memory infrastructure is all configured with Docker Compose. The docker-compose.yml defines four services — FalkorDB, PostgreSQL, the session worker, and the memory search MCP server — with data persisted to the ./data/ directory. When migrating to a new machine, just bring the data/ directory and .env and run docker-compose up -d, and the environment is restored memories and all. As I mentioned in the "Mothership" section, this portability provides more peace of mind than I expected.
Another thing I'm particular about is the dual-wielding approach to search. The knowledge graph (Graphiti) excels at tracing relationships — like "the reason for decision B in project A was C" — but struggles with fuzzy memory searches like "I feel like I saw a similar error somewhere before." So I run PostgreSQL + pgvector vector search in parallel, with automatic routing based on query content. Ask about a decision's background and graph search runs; semantic similarity search uses vector search. There's also a hybrid mode that merges and returns results from both.
I also paid attention to isolating memories per project. Using Graphiti's group_id feature, I keep Project A's decision logs and blog writing history from mixing together, while still allowing cross-project searches.
Project-specific memories are separated under names like project-a, while daily logs and meeting notes go into area-knowledge, and technical decisions into area-tech. Specifying multiple group_ids during a search enables cross-project searching, so queries like "I think I made a similar judgment in another project" are also supported.
I've been running this system for about half a year, continuously adding features and improvements through daily development. It started as a simple note-saving system and gradually grew through the introduction of the knowledge graph, local LLM integration, and dynamic context injection via hooks. By the way, it wasn't always this dual-wielding design. At first I was running on Graphiti alone, but when "I feel like I saw a similar error before" type searches kept returning completely unrelated results, I realized "relationship" and "similarity" need to be handled separately — and added pgvector afterward.
If you're building something similar from scratch, I think the realistic path is to first get the standard setup running by following Graphiti's official documentation, then gradually localize it from there. Replacing the OpenAI API with Ollama will be your first customization point.
How I "Relate To" Claude Code
Reflecting on everything I've written, I realize this is less about how to use a tool and more about how to "relate to" it.
Claude Code is excellent, but out of the box it's "a one-time consultant." Define rules in CLAUDE.md, set up memory persistence via hooks, shape daily workflows into patterns with custom commands. Only then does it start to feel like "a development partner with shared context."
Of course, there are still challenges. The summary accuracy of local LLMs doesn't match cloud APIs, and Graphiti's search accuracy is far from perfect. Sometimes when I ask "do you remember what we talked about yesterday?" it brings up something from a completely unrelated project.
However, I feel there's a large gap between "zero memory" and "imperfect memory." Even imperfect context undeniably reduces the "explanation time" at the start of a session.
Conclusion
In this article, I introduced a day in the life centered around Claude Code.
Looking back, what I'm doing boils down to "giving an AI tool memory and habits." Context is everything, really. Rules via CLAUDE.md, memory via hooks, habits via custom commands. With these three in place, you can create an environment where development context doesn't break across sessions.
And as I continued using it, its applications went beyond coding alone. Brainstorming design decisions, planning trips, jotting down ideas before bed. It has become a "thinking companion" that lives in the terminal — something that slightly overflows the boundaries of a development tool.
It might seem like an elaborate system, but there's no need to build everything at once. My own first step was just writing rules into CLAUDE.md.
If you're thinking "I'd like to try this myself," here's a recommended order: first write a CLAUDE.md and define project-specific rules. Next, create one simple custom command (something like /today to display today's tasks is more than enough). Then venture into automation with hooks, and build the memory infrastructure last. Including the joy of growing it step by step, it's quite a rewarding experience.