Claude for Writing and Analysis: Drafts, Documents, and Decisions

Writing and analysis look like different skills, but the failure mode underneath both is the same one: accepting a plausible-sounding first pass instead of pushing for the version that's actually correct or actually sounds like you. This lesson covers both, because the fix is identical in both cases — name the specific problem before you try to solve it.

Writing: A Loop, Not a Single Draft

Good writing with Claude isn't one prompt that nails it — it's a short loop that separates diagnosis from treatment, run against a Style you've already locked in from the previous lesson.

The stage most people skip is Critique, jumping straight from a draft they're unhappy with to "make this better." That instruction is too vague to act on precisely — better how? Asking Claude to read the draft back critically first, naming specifically where it drags or where a claim goes vague, produces a diagnosis you can act on. Only then does Revise target something concrete, instead of a blanket rewrite that might fix the one thing you noticed while breaking something you didn't.

The Voice Check stage is the one that's easy to treat as optional, and it shouldn't be. Reading a draft aloud is still the fastest way to catch the specific failure mode of AI-assisted writing that reads as competent but generic — technically correct, structurally sound, and unmistakably not something you would have said. When that check fails, the loop routes back to Revise, not back to Draft — you're tuning an existing piece of writing toward your actual voice, not discarding real progress and starting over.

Analysis: From Raw Material to a Recommendation

Analysis has a different failure mode: producing a competent summary of the input material that never actually answers the question you needed answered. The fix starts before you send the request, in how you frame the ask.

The gap between a weak ask and a structured one isn't politeness or length — it's specificity about what the output has to do. "What do you think of these numbers?" is an invitation to react, and Claude will react reasonably, but there's no clear standard for what a good answer looks like, so you can't easily tell whether it actually helped. "Rank the three options by risk-adjusted upside and state what would change the ranking" specifies the exact shape of a useful answer — a ranking, a rationale, and the assumption underneath it — which makes the output immediately checkable against what you asked for.

That last piece — stating what would change the ranking — is doing the same job the adversarial follow-up did in the research lesson. It forces the analysis to name its own load-bearing assumption instead of presenting a conclusion as if it were unconditional.

The Recommendation Is the Whole Point

The clearest signal that an analysis has stalled at "summary" instead of reaching "decision support" is a simple test: could you retitle the output "Summary" without losing anything? If yes, it never actually took a position — it restated the input material in organized form and stopped short of the one line that makes it useful: a stated recommendation.

Both Workflows, One Underlying Skill

Look back at what actually fixed each problem in this lesson. Writing improved when Critique got separated from Revise — diagnosis before treatment. Analysis improved when the ask specified exactly what comparison it needed — a target before the reasoning. Both are the same move applied to different material: get specific about what "better" or "useful" actually means before asking for it, instead of hoping a vague instruction converges on the right answer through iteration alone.

That discipline — specificity before the ask, verification before you trust the output — is the thread running through every workflow lesson in this track so far. The next lesson turns it toward a different question: not what you're asking Claude to produce, but where the material it's working from actually comes from in the first place.