Working with Claude

Claude is a capable, literal collaborator with real breadth and no ability to read your mind. Like any large language model, it knows only what you put in front of it, holds no memory of what you didn’t say, and will attempt almost anything you ask. Working with it well is mostly managing those facts: giving it context, being specific, and checking what comes back. The rest of this guide is how.

Every tool has a shape: things it does easily and things it does badly. Knowing the shape of a language model keeps you from asking for what it can’t reliably give, and frees you to lean on what it does well.

Context is the single biggest lever you have. The model works only with what’s in front of it, so the quality of the output tracks the quality of what you put in. Before refining how you ask, make sure you’ve supplied what it needs to answer well.

Once the context is there, how you ask still matters. A good prompt is specific about the goal, the shape of the answer and the standard to hit. You don’t need secret phrasing; you need clarity a person could also follow.

The biggest cause of disappointing output is asking for too much at once. A language model does its best work on one clear job at a time. Break a large task into steps, run them in sequence, and check each before moving on.

The first answer is a starting point, not the finish. The real power of working with a model is the conversation: you react, it adjusts, and a few rounds reach somewhere neither the first prompt nor you alone would have found. Expecting perfection first try wastes the best feature it has.

Whatever comes back, you own it. A language model can be fluent, confident and wrong in the same sentence, so the last step is always yours: read it critically, check anything that matters, and don’t ship what you haven’t verified.

A language model is not the only tool, and not always the best one. Part of working well is knowing when to reach for something else, particularly for visual work, where a model built for words is the wrong instrument.

For anything bigger than a single answer, you’re not prompting; you’re running a session. The model holds the thread of a conversation, so you can build up context, establish a way of working, and tackle a large piece over many steps, much as this series was made.

Two things stay with you no matter how good the tool gets: judgement, and discretion about what you feed it. Working well means keeping both, and being clear about which parts of the work should never leave your hands.

If this is a lot, start here, in order. Most of getting good at this is a few habits, repeated until they’re automatic.

Part one is the durable method. This part is the opposite on purpose: it’s how I actually put Claude to work, opinions included, and it names specifics, tiers, tools and costs, that will date. Treat the practices as sound and the numbers as a snapshot: everything here is accurate as of 2026-08-17, and worth checking before you lean on it.

The most useful habit in longer work is to separate planning from doing. Use one pass to decide what to build and in what order, and a different pass to actually build it. Blur the two and you get confident execution of a half-formed plan, which is the expensive kind of mistake.

A PRD, a product requirements document, is just a written brief for something you’re going to build. It’s the planning artifact: it states the problem, who it’s for, what a good result does, and what’s out of scope, so that both you and Claude are building the same thing. It doesn’t need to be long; it needs to be clear.

The todo.md is the doing artifact: a single file that holds the whole task list in a structure Claude can read and work through. Sections group the work, tasks sit under them, and child tasks break the hard ones down. Because it’s one file, it’s the source of truth that keeps a long build on track across many sessions.

You don’t need to be a developer to work with Claude on technical things, but a handful of words make your requests precise and your reading of its answers faster. These are the terms that come up constantly, in plain English.

Two practical things shape how you work day to day: Projects, which decide where your context lives, and your plan tier, which decides what you can and can’t do. Both are worth setting up deliberately. The specifics below are a snapshot as of 2026-08-17 and change often, so confirm the current details before you rely on them.

Where you work changes what works. The honest position: it’s far easier to work off documents or a codebase that travel with the chat than to rely on the agent features to fetch and manage things for you. In my experience the autonomous pieces, Cowork and dispatched background work, are still quirky, and I wouldn’t trust them for travelling work you can’t supervise with a laptop open. So choose your device before you start, and set the work up to match.

If you want the best of both, one setup beats the rest: use GitHub as your folder and connect Claude Code to it, so the same project is there whether you’re moving or sitting, and you can work on it in tandem from either. From there, if you want a real interface for tracking tasks, files and memory, you can build yourself a small private site.

To put this part to work, in order. Start light, and add the heavier setup only when the work justifies it.

Part one describes a durable way of working with language models, independent of any product or version. Part two adds a practical playbook that does name specifics, tools, tiers and costs, dated on purpose. The method lasts; the numbers will move.