skip to main content
Mari Hirano
back

Solo Design Sprint Week 4 - System for Claude to observe how I work

Over the course of my career, I learned that I absolutely love designing and problem solving. On the other hand, I don't enjoy parts of the work around reflecting and talking about my past projects.

While I recognize the great value in reflecting, it is often a very time-consuming process and the first draft tends to give me the blank canvas syndrome. To distribute this effort throughout the course of my project in hopes that it'll reduce the dreaded feelings, I started writing reflections daily.

Prior to this week, I had experimented with a few things using those daily notes: I had Claude summarize my reflections on my projects, and I even had it try writing the first draft for me. But I didn't like anything that it produced for some reason, so I decided to take a different approach.

Flow diagram of my reflection process. Top row: write daily reflections in Obsidian and FigJam, have Claude summarize it, ignore what Claude wrote, and write everything into a doc again, with the last two steps highlighted red under "I hate these parts". Bottom row, highlighted green under "I don't mind these parts": read what I wrote, edit (looping back to reading), and publish.

What I did I made the assumption that my initial approaches with Claude failed because Claude didn't know how I crafted my story and what my process looked like. It was like a new hire on day one being handed my big presentation.

So instead of handing it the work, I created a system to let it watch me do the work first. Over the next several weeks, Claude will simply observe and report its findings, while I continue to write my first drafts and do the rest myself. Claude will take notes, and I will decide later whether those notes become a skill.

Claude's Scheduled tasks page for "Weekly reflection watcher": active, running daily at 7:51 PM with auto permissions. Its instructions tell Claude to watch how I turn a week of project work into a published blog post, so that over several weeks it can learn to draft my raw brain dump for me.

Using my daily reflections, FigJam, and published posts as context, I created this "shadowing" system. It will produce two outputs: 1) an observation summary on how my week went, which gets sent to me via email and push notification, and 2) a note that Claude keeps to itself for its own knowledge.

Diagram of the shadowing system, split into local and cloud. Locally, my Reflections vault holds daily reflections, weekly reflections (the raw first draft) and a Claude folder for its observation memory and report, all auto-synced every 15 minutes to a GitHub repo. My blog vault's Published folder goes to my portfolio repo on command. A Claude scheduled job reads both repos plus FigJam, writes an observation memory and an observation report back into the Claude folder, and sends the report to me by email and push notification.

What I learned As someone with no engineering background, I'm always low-key paranoid that AI might be writing things on my computer that could potentially cause harm. What I'm learning through these workflow automation projects is that they can easily get quite complex, and this doesn't help with my paranoia.

On the other hand, it is also an opportunity to learn how things work because, now, instead of reading about it, I can actually learn by doing. To lean into this, something I found works well for me is to visualize my own interpretation on how everything works together behind the scenes and confirm that understanding with AI. This has helped me quite a bit so far with learning and also keeping the sense of control.

My first diagram of how the system fits together, from local Obsidian vaults to GitHub repos to a Claude scheduled job that sends an email and a push notification. Below it I ask Claude, "I visualized the flow. Does this seem accurate?" and Claude replies that it's mostly right, with corrections: the repo's real name, the dev branch, a missing return path back into my vault, and FigJam as a missing input. My revised diagram, now with FigJam as an input, the dev branch, and the observation memory and report flowing back into a Claude folder in my vault. Claude replies, "This one's accurate", noting that both files go back into the Claude folder and only the report goes out to email and push.

This week was a lot more experimental than other weeks, and unlike previous projects, I didn't have a clear problem and solution. Nonetheless, I'm excited to see how it turns out, and there's more to come on that.

If you've had a similar problem and did any experiments like I did—with or without AI—I'd love to hear about it.