· 9 minute read
Claude Code for Writers
How working with project files and written instructions changed the way I use AI for editorial work.
This essay describes how I was using Claude Code when I wrote it. Product interfaces, plans and permission settings change; the examples are a record of my workflow, not a current setup guide.
One of my team members recently asked how I use Claude Code for editorial work. The question caught me off guard. Because the answer has changed so much since I fired up Claude Code. What started as a curiosity about context management has become my primary creative tool. Not just for writing, but for presentations, mockups, and now actual software.
The most useful change was being able to give Claude access to my project files and keep decisions there between conversations. That changed how I prepared, reviewed and developed work.
Opening Terminal for the first time
I was an early OpenAI user through Jasper, back when writers used AI privately and felt guilty about it. Eventually I moved to Claude's web interface. The writing felt more human than ChatGPT. But I kept hitting context limits. Long projects would lose track of earlier decisions. I'd re-explain things constantly.
Then I heard Dan Shipper on Lenny's Podcast describe using Claude Code as an editorial leader. That didn't make sense to me. Claude Code was for engineers. Why would a content person use a terminal?
But his example stuck: Claude Code can access your entire filesystem. Read documents, reference past work, execute tasks. It piqued my curiosity enough to do something intimidating. Open Terminal on my Mac for the first time in my life.
I remembered my days working at Apple. I was never on a technical team. But I'd watch the Geniuses constantly logging into Terminal. It seemed like a secret language for talking directly to the machine.
That's exactly what Claude Code turned out to be. A way to use AI to communicate directly with your computer. It could work with files I kept on my computer and return to them in later sessions.
The first project
My first real use was preparing for a speaking event in 2025. I needed a template to share with the audience and visual mockups I could screen-record for my slides.
Claude Code built them in HTML. Not artifacts in a chat window. Actual files I could open in a browser, tweak, record. Having a real file on my computer made a difference. Suddenly I wasn't constrained by what the web interface could render. I had a tool that could create anything I could describe (within reason).
From there, my capabilities grew because my understanding of what was possible grew. I started mocking up graphics to explain concepts to my team. Using it for strategy ideation. Editing and reviewing content. Each project taught me something about context management.
Then I started asking Claude what it could actually do. Could it build real software, not just prototypes? I'd been put off by other tools due to limitations in execution and maintenance headaches. But Claude explained it differently. It could control tools on my computer. Build codebases in Xcode. Teach me to iterate.
So I experimented. And years of communicating clearly with collaborators paid off. I had patience. I knew how to give feedback that moved things forward. The process was a joy because I'd already developed the underlying skill without realizing it.
Context, not code
I started using Claude Code to manage the information a project needed, as well as to write code. What makes it powerful is its ability to read, reference, and act on information across your filesystem.
Keeping files in a project folder gave me a persistent record outside any one conversation. Claude Code could read and work with those files when access was permitted. I still had to point it to the relevant material and check the result.
This reframing helped me see why certain skills transfer so directly. Managing context is something many professionals already do. Knowing which information someone needs, when they need it, and how to organize it. That's the same skill as setting up a project folder for Claude Code.
The CLAUDE.md file
Before Claude Code, I was loading up the web interface's project description with context. It worked, sort of. But Claude would miss things. Forget guidelines. Lose track of decisions.
The CLAUDE.md file helped. I use it to record project instructions and decisions. Claude Code loads applicable instruction files as context, but that does not guarantee it follows every instruction. I still review what it does.
This was immediately familiar to me. A CLAUDE.md file is like a project brief or guidelines document. The same document that tells a team what standards to maintain, what decisions have been made, what the goals are. I'd been writing these for years. Now I was writing them for an AI.
This structure works for software projects, presentations, creative projects. Anything. The CLAUDE.md captures scope, philosophy, decisions made. The reference folders hold everything Claude might need to look at. The archive keeps old versions without cluttering the main space.
I used to download files without a plan. Now I organize them intentionally, because I know Claude navigates via file paths. Clear folders make it easier to find the right reference.
The infinite loop
This became more useful when I started updating CLAUDE.md as the project changed. Every conversation that produces something useful goes back into the file. A decision, a refinement, a lesson learned.
Later conversations can use the decisions I've recorded in CLAUDE.md. I'm not re-explaining my preferences every session. I'm not losing decisions to forgotten chat history. The record is there for the next session.
I have a high-level CLAUDE.md for my entire product studio that understands all my tools in development, archived ideas, design philosophy, even my goals. When I start brainstorming something new, it holds me accountable to what I've already decided. It knows the portfolio strategy. It can tell me when an idea doesn't fit.
Skills that transferred
I didn't expect my background to matter for a "coding tool." But the skills that make you good at communication and project management are exactly what make Claude Code useful.
Patience with iteration. Good output rarely comes on the first pass. You give feedback, it revises, you refine based on what you see. The patience I'd developed for collaboration translated directly.
Clarity in communication. Vague requests produce vague results. I'd learned to be specific. Not prescriptive, but clear about intent. That skill matters even more with AI, where ambiguity gets interpreted rather than questioned.
Choosing what to share. What context does someone need to do good work? What can be left out? Same question with Claude Code. What files should it read? What should stay in the CLAUDE.md versus a reference folder?
Discoveries along the way
Some things I learned that surprised me:
Permissions matter. I could review actions before they ran in the setup I was using. Permission modes and rules determine which actions need approval. Do not assume every edit or command will prompt you.
Ask for current sources. I found it useful to say when a task needed web research. I check the sources rather than assume the model has searched or that its stored knowledge is current.
It can grab tools on the fly. I needed to make an icon background transparent. Claude downloaded an image processing tool and did it itself. I didn't have to install anything manually. It just handled it.
Check what an export contains. When sharing a document for review, make sure the comments and their context are actually included. Do not assume a plain-text download preserves them. Keeping the review material in a project folder makes it easier to reference later.
Multiple terminals, focused work
Something I've grown to love: running multiple Claude Code sessions at once.
It started with one terminal. Then two. Now when I'm deep in a project, I might have three or four open. Each focused on a specific task with specific context. One working on visuals, another on copy, another on technical implementation.
This parallelism was a shift. Instead of one long conversation trying to do everything, I have focused conversations that do one thing well. This was practical within the usage allowance I had at the time. Voice dictation makes this even more practical. I can speak to each conversation in turn.
The tactile feel
Something unexpected: I've grown to like the interface. It isn't as pretty as the web. Copy-pasting from Terminal into other apps can be janky. But there's something robust about it.
Working with files in Finder again. Organizing folders. Editing markdown directly. Everything feels tactile and real in a way that the web interface doesn't. The files are on my machine. I can see them, move them, back them up. They're not trapped in a chat history somewhere.
Writing is thinking. The way I communicate with Claude is the way I communicate ideas generally. Recording examples and preferences in CLAUDE.md gives later sessions something to work from. I still need to check whether a draft sounds like me.
The terminal became less intimidating once I understood that I could ask the AI to work with my files. If you've spent years managing context in any professional capacity, choosing which information to share and how, you already have the core skill.
I learned to guide the development process. I'm not writing Swift syntax from memory. I'm describing what I want, reviewing what Claude produces, and iterating until it's right. That's collaborative work with a different output. I shipped my first Mac app in a couple of months, with no coding experience.
I'm significantly more creative and productive than I was before. I can now try ideas I would previously have left as notes. I highly encourage you to experiment with it, if you haven't already. When you see things come to life and learn to reinforce better context over time, it becomes a real joy to use.
This is a working document. My workflow keeps evolving as I learn what's possible.