In two months there is a large divide between those who get tremendous benefit from using Claude (Cowork) and those who do not. While the primary area of concern is certainly in relation to creating appropriate prompts and developing an efficient workflow process, I believe that providing Claude the means to recall information that it would have otherwise forgotten if it were able to remember is also critical. In addition to the above mentioned tools, I have created the following additional tools to assist with this task: a working folder that it will always reference, a CLAUDE.md file that it will reference at the beginning of each session, skills that reflect repeated actions I take during the course of my daily work, and a voice DNA file so that the writing produced by Claude reflects my own voice. The toolbox I developed for this purpose and the unanticipated tool I developed while doing this are outlined below: building this tool helped me better understand myself rather than build a tool for helping Claude provide better support for my work.
I am currently working with Claude as a colleague who does not retain any memory of our interactions from one day to the next. It is brilliant, fast, and capable of a wide range of skills. However, Claude cannot remember your input. Therefore, it can review your work and produce an initial draft. Additionally, Claude is capable of producing a report based upon your input, reviewing filings, explaining concepts, and running code-based scripts. After completing this work, Claude shuts off its computer and tomorrow morning has no memory of meeting you.
During the first month I used Claude (Cowork), I often found myself extremely dissatisfied, angry, and even enraged. At the same time, many of the outputs Claude generated caused me to be amazed at what it produced. The output of Claude's intelligence was both jagged and uneven. Early in a project, Claude's output was often very strong. As the project continued however, this strength began to wane. Each subsequent interaction with Claude required me to reintroduce Claude to the same issue we were addressing. Many of the corrections I requested in one session were undone in the subsequent session without my ever requesting they be reversed.
At that point, I realized the issue was not Claude itself. Rather, I had not provided a mechanism for retaining knowledge on Claude's behalf. Like any other human colleague would retain knowledge through their notes, calendar, and physical workspace (as well as their ability to retain previously discussed topics in their memory), Claude retained no such knowledge. Further, I was failing to fill this void for Claude.
The second month consisted of establishing this retention mechanism. This included a folder for storing items I wanted to retain; a document titled CLAUDE.md which contained a history of our conversations; a series of skills which would repeat certain processes; a voice DNA file so that Claude would produce written content which sounded similar to my own voice; and finally, a failure log so that I would not repeat errors which occurred during previous sessions. Each item individually may seem minor. Collectively, they greatly increased the amount of time spent interacting with Claude and reduced significantly the number of times I needed to ask Claude questions regarding specific details related to prior conversations.
Additionally, I did not anticipate the secondary outcome.
Creating this repository of documentation which Claude could reference at any given moment compelled me to create clear definitions of various aspects of my professional life. These definitions include: what constitutes a high quality research report? How should a high quality email begin? Who are the individuals whose ideas I draw upon when writing? What are common errors I tend to make? The end result of creating this repository was a greater understanding of how I approach my work.
The toolbox I established consists of three layers: Setup, memory, discipline.
Layer 1: Setup: Where Claude Works
1. Establishing a working folder
The single most valuable step I took in week 1 involved pointing Claude toward a single folder on my machine and stating: “this is where you perform your work.” All data that I generate or modify either manually or via scraping resides within C:\Users\tgrka\CLAUDE GLOBAL FOLDER\. I organize this folder into subdirectories representing different types of work I engage in (skills, scrapers, reports, drafts). None of this data leaves this location.
While the reasons behind why this is important may appear trivial or even unnecessary at first glance, it provides significant benefits. By allowing Claude to consistently read and write within a single folder, data persists between sessions; scripts continue to locate their inputs; and paths that I designated last week remain accessible today. Conversely, when Claude searches for files in a random manner throughout my file system each session, data goes missing or is placed in directories that I rarely access. A research report becomes lost in Downloads. A draft skill is saved in Documents. A scraper produces its output in temp and is unable to locate it in subsequent sessions.
Designate the folder; do not relocate it.
2. Choosing the correct model for use
Claude represents multiple models; it is not one. For most purposes, Sonnet is sufficient. Opus is used whenever the task requires deeper reasoning or nuance (investment analysis, voice writing, etc.). Any type of decision-making activity falls under Haiku due to speed, cost and specificity. Identifying which model I need to utilize prior to initiating a task is a relatively small practice which impacts the quality of the output far more than most realize. When utilizing Sonnet for Opus-type activities, the output appears reasonable although lacks substance; utilizing Opus for Sonnet-type activities simply results in slower performance at higher costs.
I now make decisions about which models will be used in each application in less than 2 seconds. Hours of differences follow downstream.
Layer 2: Memory: What Claude Knows About You
Claude's “persistent” memory is actually very close to being mine, a record of what I have found useful while learning to work with an AI. This file remains regardless of any given conversation and is edited by no other user but myself.
3. Persistent Memory: CLAUDE.md
Perhaps the most crucial file associated with my Claude configuration is named CLAUDE.md. This resides at C:\Users\tgrka\.claude\CLAUDE.md, and Claude Code reads it at the beginning of every new session. Within it reside: details regarding who you are (and what you do); your hard rules (never create fabricated financial information; never use sub-agents to analyze; etc.), the directories where I work; project(s) I’m actively engaged within; and a record of each major behavioral decision I’ve made relative to how I want Claude to function for me.
As of today, there are approximately 140 lines in the document. When it was first created, it had only 12. Every time something didn’t go as planned, or something did go well, and I desired to retain functionality for future sessions, a new line would be added. For example, after the financial information incident with Snowflake, I designated Hard Rule #9, “Do Not Create Sub-Agents.” In addition, upon discovering that I had been misinterpreting my request for auto-mode as a permission prompt (Hard Rule #10), I added another rule, distinguishing tool-internal errors from legitimate permission prompts. Lastly, the Pinegrow CSS Variables were included as well because they represented yet another area where I desired to preserve the lessons learned during development.
4. Skills
Next is skills. Skills represent the second tier of memory. While CLAUDE.md represents everything Claude knows about me generally; skills represent everything Claude knows about different types of work I perform.
Here is the most basic definition from Anthropic’s engineering team:
“A skill is a directory containing a SKILL.md file.”
- Anthropic Engineering, “Agent Skills: Equipping Agents for Real World Applications”Each directory includes directions, optional scripts and documentation references. The SKILL.md file defines exactly what the skill performs and under what conditions Claude should execute it. According to Anthropic, they provide a structure through which Claude may discover these folders and load them dynamically for specific tasks. Skills operate identically across both Claude.ai, Claude Code and the API.1
In terms of practical application: I may convert an activity that I repeat regularly (i.e., reading a 10-K, creating an investment memo, writing a blog post in my voice) into a folder that Claude reads. The next time I engage in this task, the folder will automatically load and Claude will execute according to its defined parameters without requiring me to explain again.
Over the last two months I have developed roughly half a dozen skills. They break down into three categories.
Skills related to Investment Process. The process I complete as a Portfolio Manager, documented.
Voice and identity skills. Skills that capture me, not the work.
Engineering / dev tooling skills. The narrowest category, useful when I’m building.
The skills compound. Each new skill I write makes the next session shorter, because I’m no longer re-explaining the work.
5. Voice DNA
The voice-dna skill deserves its own line. It started as a way to get Claude to write blog posts that sounded less like a press release and more like me. It became something more useful than that.
The skill is built on close reading of sixteen of my actual writing samples spanning seven years: Substack essays, Medium pieces, IFC investment memos, board papers, technical posts. Three registers, four formats, a dial for how professional the output should be. It’s the most opinionated file in my whole setup, and the one with the strongest deterministic enforcement.
The enforcement matters. A skill is a prompt, and prompts are suggestions. Earlier this month I wrote about how LLMs are bad at the mechanical parts of work; the same logic applies to writing. Some rules are non-negotiable: certain rhetorical patterns I always strip out, certain layouts I won’t use (no pull-quote boxes containing one-line maxims), certain closings I won’t accept (the kind that announces the takeaway): and the only honest way to enforce non-negotiable rules is with code that fails the build. So I built voice_gate.py: regex over the output, two tiers, hard violations block delivery. The skill is the spec; the gate is the gate.
Layer 3: Discipline: How Claude Does Its Work
6. Session recap
At the end of just about every non-trivial session, I ask Claude one question: “what do we need to document so the next session can build upon our last?” That answer usually contains something I would forget by the next day.
The documentation then typically goes into either CLAUDE.md if it was a behavioral rule, into a project specific notes file if it pertains to the work at hand, or into the skill itself if it relates to how I wish to perform some type of task. Recalling what was accomplished during the previous session allows the subsequent sessions to begin at a higher baseline than having to start completely from scratch.
7. Logs of failure
In addition to all of the major skills I am developing, there exists a file called FAILURE_LOG.md adjacent to the corresponding SKILL.md file. Whenever an error occurs (a fabricated number, improperly formatted tables, etc.) the details are documented along with the date, root cause, and solution implemented to avoid similar errors in the future. This single document alone represents the difference between a skill improving over time vs. continually breaking in the same manner on a bi-weekly basis.
Without this type of log system, each problem is addressed individually; i.e., the fix may apply only to the current report being produced for company X, but did not address the underlying issue that will occur again on the next Wednesday for company Y. However, once you implement a log system and track each instance where your skill failed to produce accurate results, each fix becomes more systemic: adding a new rule to your skill or verifying that certain information has been properly populated within your verification gate prior to producing a report.
8. Verify prior to delivery
A fundamental aspect of my workflow that has evolved more than anything else over the past two months is that Claude should not provide any material result to me without first executing an automatic verification routine against it. An example of verification is a script that returns a value greater than 0 if there is a problem and/or something is incorrect with regards to the output.
As such, verification routines are used in conjunction with all forms of reporting regardless of whether they relate to financial statements, written content (voice writing), or even documents that have been compiled from multiple sources. final_gate.py is used in conjunction with financial reports: cross-verifies all referenced figures, flags any references to placeholders, verifies the reconciliation between the balance sheet. voice_gate.py is used in conjunction with voice writing: utilizes regex against the generated prose and performs a hard fail on any of the worst responses provided by the LLM. The merge scripts' assertion checks verify that headings follow proper structure and ensure broken bold counts equal zero. All gates are generally short in length (fewer than 100 lines) and execute extremely quickly (approximately 2 seconds per execution); however, they catch many errors that would go unnoticed even if reviewed thoroughly by an experienced human reader.
The toolkit isn’t finished. New skills get added, existing ones get rewritten when something breaks, the failure logs keep growing. What I’ll know a year from now is different from what I know now. But the shape is set: a working folder, a memory file, skills for the work I repeat, voice DNA for the writing, recaps and failure logs for the things that broke, verification before anything goes out the door, and one conversation per task.