There's a framework worth knowing. Not because you'll apply it robotically — you won't — but because when a prompt isn't working, it tells you exactly which piece is missing.
Role + Context + Task + Format + Constraints
Role
Tell Claude who it's being for this task. "You are a senior backend engineer" does something real — it primes vocabulary, tone, and how deeply it assumes you know things.
Weak: You are a marketer.
Useful: You are a direct response copywriter who's worked on B2B SaaS products for 10+ years.
The specificity matters. Generic roles produce generic outputs.
Context
What does Claude need to know to not give you a textbook answer?
I'm building a solo side project — an expense tracker for freelancers.
Next.js + Supabase. I have about 5 hours a week to work on it.
Without this, Claude might suggest a microservices architecture. With it, you'll get advice that actually fits your situation.
Task
Be precise about the verb. This is where most prompts go vague at the worst possible moment.
Help me with my README → what does "help" mean?
Write the Getting Started section of my README → that's a task.
Verbs that work: write, rewrite, review, summarize, compare, fix, translate, outline, critique, simplify.
Format
Claude will pick a format if you don't specify one. Sometimes it's right. Often it isn't.
Just say what you want:
Return as a numbered list.
Write it as a tweet thread (each under 280 chars).
Use markdown headers.
One paragraph, no lists.
Constraints
What should it not do? This is especially useful when you've gotten something that was almost right.
Don't use jargon — write for someone who's never heard of APIs.
No bullet points. Prose only.
Under 300 words.
Don't mention pricing.
Here's a prompt using all five. Real-world, not a textbook example:
You are a technical writer who specializes in developer docs.
I'm documenting an open source CLI tool called "dbdiff" that compares
two PostgreSQL schemas and outputs the diff. The reader is a backend
dev who knows SQL but has never seen this tool before.
Write the intro section of the README.
Use markdown. Include: one paragraph on what it does, one on who it's
for, and a code block showing sample output.
Under 250 words. No marketing language. Technical and direct.
You don't have to label the sections like that. But running through the five checklist items before you type has a real effect on what comes back.