There's a good chance you've written a brief in your career already. It could've been a ticket, a design brief, maybe a discovery document for a new client. When the brief is clear, the work comes back close to what you imagined. When it's vague, you get a flood of clarifying questions, or worse, work that misses the mark entirely.
I've been a stickler for ticket creation my whole career. I've spent more time than anyone should have explaining why a well structured ticket matters. But that habit is a big reason I picked up better habits with LLMs quickly.
A prompt is a brief. The difference between a prompt that works and one that disappoints follows the same rules as the difference between a brief that lands and a brief that flops. You're not learning a new skill when you learn how to prompt Claude well, you're recognizing a skill you already have.
What A Brief Actually Contains
Most of the work you delegate professionally moves through a brief, written or implicit. The brief contains, in some form: the task, the background needed to do it well, the constraints that bound it, and the format the deliverable should take. If that sounds like both a ticket and the prompt structure from Brick 1, it's because they're the same thing.
When you brief a colleague, you do this without thinking. You wouldn't ask someone on your project to "write an email to Susan about her message." You'd say something more like, "write an email to Susan, push back on the new timeline she proposed without sounding like we're committed. Keep it short, and send it off by 4:00pm today." Task, context, constraint, format. When people communicate well on a project, almost everything naturally takes that shape.
Claude Is A Contractor
Claude needs the same thing, for the same reasons, and even more so than a colleague does. Claude can't read the room or pick up on unspoken context the way a coworker can. Unless you've taken the time to set up the guardrails, skills, instructions, and resources, the output's going to suffer by comparison. Anything you'd tell a colleague to get the job done right, at a minimum, you have to share with Claude. Anything you leave out gets filled in with a best guess, and Claude's best guess is not your judgement.
This is why most surface level prompting frustrates people. Asking Claude to "write a follow-up to the client" and getting a generic response back isn't a Claude problem. It's a brief problem. Imagine your company hired a brand new contractor and gave them those same instructions with zero context. You'd get the same flat output. Claude is a contractor, almost by definition. You're paying for it to perform tasks in your business, and the quality of those tasks tracks directly with the quality of the brief you give it.
Compare Two Versions Of The Same Prompt
Run two versions of the same prompt and feel the difference yourself. As always, use this as an example to guide you with a real example from your own work.
Version 1
"Write a follow-up email to my client about the timeline."
Version 2
"Draft a follow-up email to Maria, the COO at [Client]. We had a check-in yesterday where she raised concern that the implementation is taking longer than expected, and she mentioned the issue to her CFO. The actual cause is two mid-project scope additions her team requested in March. I want to acknowledge the concern without being defensive, briefly explain what's actually happened, and propose a recovery plan. Tone: professional and warm; we have a strong relationship and I don't want it reading like a CYA email. Length: under 200 words. Format: three short paragraphs with a clear next step at the end."
Version 1 is a request. Version 2 is a brief. The gap in output between them is going to be enormous, and none of it has to do with the capabilities of Claude.
The Questions To Ask Yourself
The shift this requires is small but specific. Use the contractor comparison as your starting point. If you've already injected some of the relevant information into Claude through Projects, knowledge files, or standing instructions, you're reducing the lift required for any single prompt.
But before you hit send, ask yourself:
- Have I named the task clearly?
- Have I given Claude the context it would need, or pointed to where that context lives?
- Have I set the constraints, like length, tone, format, audience, and deadline?
- Have I shown what good looks like, or named what bad looks like?
Anything you answer with a "No" is a gap that'll show up in the response. Claude will still produce something, maybe correct, maybe a hallucination, but it'll reflect every piece of the brief you skipped.
The skill your career has been training you on for years is the skill Claude is waiting for.