Start From Your Week, Not From a List of What Claude Can Do

Most people decide what to hand to Claude by reading about what Claude can do. You come across a list of thirty use cases, three of them look impressive, you try one on a Tuesday afternoon, and by the following Tuesday you’ve stopped. The task you picked was fine. It just got chosen against a list someone else wrote, about a tool, with no knowledge of your week.

That’s the ceiling of the capability-first approach. It answers “what is possible” when the question you need answered is “what, in my specific job, repeats often enough and cheaply enough to be worth building something around.” Those two questions have almost nothing to do with each other. The first one has the same answer for everyone. The second one has an answer only you can produce, and producing it takes about twenty minutes.

So we start from the week. Not the tool.

What an audit is for

An audit of your work isn’t an inventory. You’re not trying to catalog every part of your job, which produces a long list and no decisions. You’re trying to separate two kinds of time: the hours where your judgment is the whole product, and the hours that drain into shaped, repetitive output that a well-built process would handle at least as well as you handle it from a blank page at 4pm on a Thursday.

Once you have that separation, five signals decide the rest. They’re five things to look at before you commit to building anything, not a scoring system.

Two of those get skipped almost every time, and they’re the two that decide whether the thing survives past week one.

Context is the quiet one. A task can look highly suitable and still be a poor first candidate because everything that makes the output correct lives in your head — the history with that client, the reason the format changed in March, the thing your director doesn’t want to see in a summary. You can supply all of that, and later in a system you will. But at the audit stage, “how much of this is externalizable?” tells you what it will cost you to build, and a task that requires transplanting six months of tacit knowledge is not where you start.

Consequence is the one people get backwards. They reach for the highest-stakes work first, because that’s where the pain is. High stakes means you have to catch every error, which means you review everything at full attention, which means you’ve replaced writing with proofreading and saved nothing. Low consequence isn’t a consolation prize. It’s what makes the time saving real, because it’s what lets you accept an output at a glance.

The question that does the sorting

Once a task is in front of you, one question places it, and it isn’t a technical question. Don’t ask whether Claude can do this. Claude will attempt nearly anything you put in front of it, so that question always returns yes and tells you nothing.

Ask instead: could I take what comes back and use it, after a quick read — or would I be rewriting it from the ground up?

If the answer is “use it with a light pass,” the task can be handed over now. If the answer is “I’d rewrite most of it, but the draft would still save me the blank page,” it’s a shared task: Claude does the first version, you do the part that carries your name. If the answer is “I’d throw it away,” you’ve found work that belongs to you, and that’s worth knowing precisely. There’s no failure in a task that stays yours. Feedback to someone who’s struggling, a call where the relationship is the point, a decision you’d have to defend — those are where your time is doing something nothing else can do. An audit that finds none of them was done dishonestly.

One thing to expect: tasks split. Someone running client onboarding at a small agency starts with “client email” as a single line and finds it’s really three — the scheduling and document-chasing messages, which come back usable; the check-in notes, which need a draft plus a rewrite; and the two or three conversations a month where something has gone wrong and the wording is the entire job. That split is a sign the audit is working. A line item that stays whole is usually a line item you haven’t looked at closely.

And none of these placements are permanent. A task that needs a rewrite today can become one you accept at a glance once the context behind it is documented and the process is tuned. Where a task sits describes your current setup, and setups change.

Twenty minutes, this week

Take a blank page. Write down everything you do at least once a week, and don’t filter: the small stuff, the obvious stuff, the parts you’d be embarrassed to admit take forty minutes. Eight to twelve lines is normal. Next to each, put the real weekly time — the time it takes on a week where the meeting runs long, not the time it should take.

Then go down the list once with the rewrite question, and mark each line: use it, draft it, keep it. Split anything that resists a single mark.

Do not pick the most important task on the page. The most important task is almost always the one with the most context locked in your head and the highest cost if it comes out wrong, which is to say it’s the worst possible first build. Pick the task that clears all five signals at once: it comes back every week, it’s costing you real hours, the raw material already exists in a form you could hand over, you can tell at a glance whether the output is right, and nobody gets hurt if the first version is mediocre. It will feel unambitious. That’s the point. You’re not trying to prove anything on the first one. You’re trying to get one piece of your week running on a process instead of on effort, so that the next one is a smaller step than the first.

That page is the thing you build on. Everything after it — what standing context you give Claude, which workflows are worth writing down, what you check before you trust an output — is decided by what’s on it. Skip the audit and you’ll build a system for a week you don’t have.

Redo it every few months, or whenever your responsibilities move. The map goes stale faster than you’d think.

(This is the reasoning behind Chapter 3 of Stop Using Claude AI Like a Magic 8-Ball*, where the audit runs as a fill-in exercise with a worked example.)*