Jeff Kuna

Last updated: 2026-07-19

This is the workflow I use daily at work as an engineer at AWS. I've led internal sessions at AWS on adopting AI for design, development and operation, but the most positive feedback I've received has been about this system so I am sharing it here. I primarily use Claude Code but I work on a team that uses a variety of agents, so you'll note that I don't use memories or per-project CLAUDE.md files.

I am a long time Obsidian user and use it both at home and at work, so my current workflow has its roots in pre-AI days. What you see here evolved as natural optimizations to an already functioning system. This structure is battle-tested and focuses on resiliency and simplicity. Polishing productivity systems can quickly become quicksand, so I attempt small experiments and make changes only when I hit friction points. The backbone is minimal and works without AI, so this system can spring back after crunch time, on-call weeks, or time off when regular grooming stops or falls short.

Obsidian

Obsidian is the backbone of my workflow. I loved it before Claude entered my life, but Claude and Obsidian take it to the next level. I don't use many plugins -- only calendar view and a custom theme I made for myself. The workflow boils down to commands and the structure of my vault, which by the way, currently looks like this:

Active/
Archive/
Career/
Daily/
DeepDives/
Runbooks/
Plans/
Projects/
Templates/
CLAUDE.md

The Daily note

The Daily note is the main interaction surface area with my Obsidian vault and is the backbone of my system. I never open this directory and instead access it from the calendar view.

My daily note looks like this

Reminders

## Todo
- [ ] ...
      
## Log

## Capture

I start the day by creating a daily note and this initiates a daily ritual I detail in the next section. The daily template (stored in Templates) carries a list of Reminders and Obsidian copies this list verbatim when I create the daily note. This section focuses me and the reminders are whatever I need in my system prompt: growth areas I am working on, key deliverables I need to focus on, or just simple encouraging words. It sounds hokey, but this has helped me build and maintain habits.

The Todo section is self-explanatory. Log and Capture are both running notes for the day. Log is intended primarily for Claude while Capture is intended for me. This split lets me maintain my own voice and focus, and keeps Claude's edits to Log.

I have a custom theme that includes different todo status: ! for high priority tasks, > for tasks I am actively working on, x done and - cancelled. I tried more statuses like scheduled or deferred but found this was a lot of overhead for little value. I do append the date for when I close out a task and often add an explanatory note. I do this on past days as well so the date provides context on when that task was last updated with some background on why.

Daily Review Process

I start each day by creating a new Daily note. The first action is curating the Todo list. I have a good idea of what needs to be done but I do scan the prior day to jog my memory. I used to automatically roll over todo items but I intentionally stopped doing this because it forces me to be intentional of where I will spend my energy and attention. Plus, it feels better to actively prioritize work rather than deprioritize work.

After I set the day into motion, I finally start up a session of Claude Code dedicated to maintaining my notes. This is tied to an iTerm2 keyboard shortcut ctrl + shift + 3 that launches a new session that runs an alias engage (Yes, I am a Star Trek fan.) engage starts Claude in the notes directory with a minimal prompt that points to a daily review runbook. I prefer to keep my commands lean and point to md files. I found this allows their content to be discovered and allows me to make manual tweaks.

The runbook provides instructions: get the current date, read the last week of daily entries and check that I created the daily note before proceeding. This last bit is important because I want to keep my brain engaging in prioritization and I do not want to be biased by past tasks. This command provides context on what I have been working on and what I want to focus on for the day.

I used to have Claude suggest ways to unblock lingering tasks but that got annoying. Low priority tasks would be suggested distracting me, and complex tasks would be presented as quick tasks to knock out. Now Claude just gets a sense of what's stuck and what I've done, and where I am pivoting. I usually have a good sense of what I need to do that day, but occasionally I will check that I have no lingering tasks that were not resolved. Sometimes these get moved to projects but often they are moved to the day's Todo list or cancelled. This leaves me in control and lets my system be leaky. Unimportant or stale tasks naturally get dropped.

One helpful addition I've found is a few short reminders of commands or experiments I want to run. I try out new approaches regularly, having used nudges on stuck tasks, using Obsidian tags for highlighting items for review, different template formats, etc. These little nudges either help build habits and muscle memory or reveal that an experiment is not working out. Either way, it's a great way to maintain visibility of new directions in the system.

Plans

I use this main notes session to remain organized and do my actual work in other sessions. Plans are the mechanism I use to communicate between different sessions and the notes session. I create new plans using a command /newplan that I can run from any Claude Code session. I most often call this command only after a plan has been sketched out via discussion with Claude and this can occur in the main notes session after reviewing research notes or after completing another plan in a work session. This mechanism works because it rolls that context forward after a long session and allows me to /clear instead of /compact. However, I find it useful to also create a "stub" plan on a topic to provide a place to dump some details so I can continue the research and design in another session.

Each plan covers a chunk of work that can be completed in 1-2 days and is orthogonal as possible from other plans. For instance, one plan might be to build a POC of a design, another plan may cover running and analyzing experimental data, and a third plan could cover deep diving an operational issue and adding additional metrics to the service. This prevents agents from stepping on each other's toes and helps me avoid juggling branches locally. Each plan gets a unique name and follows a minimal template that identifies the date it was created and current status. The end of a plan is always a ##Log section. This allows updates to be appended to the end without re-reading the file. Each log entry is a single line bullet point starting with the date and time and whatever afterwards. This can be a brief update or a paragraph or more of notes.

The Plans directory organizes plans by sub-directories per status: active, paused, planned. I use a command /brief in my notes session to provide a view of all plans. This command skims each plan to see the current state and produces a table per status. The table contains the date the plan was created, date of last activity per the plan log, and a mini summary of where we left off. I usually juggle 3-4 work streams so active is helpful to monitor what I have in flight. If my bandwidth is saturated or I need to pivot from a semi-completed plan, I will move it to paused.

It takes some discipline but I try to limit my active and paused plans. I often create more plans that never get moved to active. I don't archive these directly since they can go stale but creating plans like this is sometimes useful to reason through an approach. I end up deleting this but do record insights from this research in my daily note.

The Plan cycle

In another terminal, I start Claude in my main workspace directory. I no longer run Claude in the directory of a project or specific package. This means I don't have per-project memories but does allow me to pick up any plan. I also often have the same packages checked out with one being a POC implementation and the other being the actual production code. This allows me and Claude to cross reference these packages.

After selecting a plan to work on from my notes session, I start the plan with /pickup <plan name>. This command instructs Claude to read the plan and referenced files. The same command works for fresh plans, paused plans or active plans being continued from another session. This command moves the plan to the active directory and updates the front matter.

Often some additional planning is needed and it is during this step I have Claude research (using agents or workflows) and enrich the plan with more details. What I do next depends on how much of the context window was used. Usually I am well under 100k tokens at this point so I proceed. If I am over 250k tokens I usually /clear and rerun /pickup.

As Claude works, we may create additional md files, experimental data, or other files that are semi-ephemeral and not a good fit for the repository or my general notes. These get organized under a directory that shares the plans name. This keeps my git repos clean but the data at hand.

Claude does well enough to update the plan file as work is completed, but I have an additional command /report that I can run to force capturing status. I can include additional guidance with this command to ensure important details are not lost.

Learning from experience

Once a plan is completed, I return to the notes session and run /archiveplan <slug name>. This command will confirm the plan is complete and flag any incomplete items. Claude will also scan the log for notes or learnings that should be extracted. This allows me to capture notes that eventually flow back into my general notes. This process is a discussion-- points will be surfaced and I direct how to process them, either to create or edit a Runbook or just update my Daily note.

All completed plans and their associated folders are moved to the Archive folder under the plan name. Archive contains directories organized by year and month (YYYY-MM) and once archived I don't edit or move the contents. However, I retain all notes and details for posterity and this has been helpful when I hit issues I remembered encountering previously.

The /archiveplan command ends by adding an entry to my daily note's Log section that links to the archived directory. This serves as a reminder of what I did and also helps Claude understand references to recent work. I was concerned that archiving all artifacts with monthly resolution would make searching more expensive but the entries in the daily notes' Log sections help find the relevant plan.

Runbooks

This directory started as runbooks for handling autocut tickets but has since broadened significantly. The directory is structured by area or topic: on-call work, notes about the various build systems, outlines for experimental procedures, and testing and validation. I do not read or author these files directly. New entries nucleate from the /archiveplan review process or from me finally solving a tricky issue with Claude. I prefer to capture as much as I can from that session while we have examples and details in context.

This section does not need to be terribly well-organized I've discovered. File names and grep <topic> work quite well for Claude. However, from time to time, I will have Claude reassess the organization and tidy up as needed.

At this point you may wonder if I share this information with my team and if so, how? My team uses an internal wiki but is increasingly moving toward documentation repositories. Once my notes reach a certain quality bar, I will migrate them to these common repositories. However, I keep my notes after moving them since I find that these document repositories need to be edited to be streamlined for my use. What works for me is using my notes as the primary reference falling back to the common documentation repositories. Anything not in my own notes gets folded in. This way I can tailor the notes to my liking while remaining somewhat in sync with my team's notes. It's not perfect and I expect more iteration here as software development practices adapt.

Active and DeepDives

Both of these directories serve similar purposes as short term working spaces for documents. Active is primarily for me to work in. I can create document drafts or sketch out designs then invite Claude to review and edit. Usually these files will be copied to a document that is shared with the team, at which point I will update the md file with a link to the document then archive it. Other files here are fodder for /newplan or simply get cleaned up when I get around to reviewing this folder.

DeepDives is a folder that is used for local reference material. I will send Claude off to research code packages, public documentation or to read and summarize research papers in a directory on my Desktop. I seldom read the content here directly and instead use Claude to interrogate it. This allows me to shift the focus of what it covers and factor in notes and feedback from me. Again, more subject specific context that may or may not be tied to an active plan. I usually end up absorbing these files into my Runbooks or plans so they get deleted instead of being archived.

Projects

This pattern is far more useful in my home workflow but I retain it at work for certain aspects. I track long running work streams here that will take 3+ weeks to drive to completion and may be restarted and paused multiple times. Each of these acts more as a reminder and north star than a complete work breakdown. They do not track history but contain notes and pointers to the next steps for a project. This allows me to remain fluid and adapt to changes while converging to key outcomes. My work is quite open-ended these days, so this may become more concrete, but for now, it works to clarify my research and design directions and land actual delivered projects.

Career

This directory is updated on an ad hoc basis. It contains one note per month (also YYYY-MM.md) that is based on a monthly review template (also stored in Templates). This template is used by Claude and not by Obsidian. I found a rough template is useful to guide the review process but my work varies month by month so there is no standard that fits all months.

Roughly, this template identifies:

I originally tried to have Claude author the monthly review autonomously but that did not work out so well. Much of my notes focused on work done and concrete deliverables and did not always capture outcomes or the "soft" side of work. This gap left Claude in the dark and invited speculation that misconstrued or overemphasized my contributions.

Currently, I update the monthly review as I go. After landing any features or gaining consensus in a meeting or via a document, I direct the notes session to track this item and provide a bit of background. This leaves gaps so I do try to do a general review of past weeks to fill in gaps. However, by setting the bar for contributions and style, I've found this makes preparing for career related discussions far less painful.

Summary

Attention is an increasingly scarce resource. Plans are a nice way to dispatch work and track progress across multiple work streams. Think of your workflow as a set of feedback loops and try mechanisms to capture learnings and improvements.