Why does "you are a professional XX" barely help — shouldn't Claude already understand what that role means?
Claude does understand the general meaning of terms like "marketing consultant" or "copy editor" — and that's exactly the problem. Because Claude already knows this, restating the job title adds no new information. The real value of a System Prompt is filling in what Claude has no way of guessing on its own: what your judgment standard is in this specific situation, which details you actually care about, what the Output Format should look like. A job title is a very broad category, and countless different actual practices can exist under the same title.
Think of the job title as "the name of the folder" and the specific judgment criteria as "the actual files inside that folder." Writing only the folder name leaves Claude guessing what should be inside based on its general sense of that category; writing the actual rules is what genuinely supplies content.
Besides reviewing copy, where else can this "write out specific judgment criteria" approach apply to common daily tasks?
This approach applies to any task where Claude needs to judge or filter according to some standard. For organizing meeting notes, instead of writing "summarize the key points for me," you could write "organize into three categories: decisions made, action items (with owner and deadline), and open issues needing further discussion — flag any action item that has no clear owner." For replying to customer service emails, instead of "reply in a friendly tone," you could write "first restate the customer's issue to confirm you understood correctly, then give a specific solution; if the solution requires more information from the customer, clearly list what's needed from them in the final paragraph."
The common pattern is breaking a vague adjective or job title down into several specific, checkable rules. That breakdown process itself is what fills in the piece of information Claude had no way of guessing.
How specific should judgment criteria get? Could writing too much detail box Claude in and lose flexibility?
This is a real tradeoff, and the deciding factor is the nature of the task itself. If a task has a clear, error-intolerant standard process (fixed-format data validation, steps that must run in a specific order), it's worth making the criteria extremely specific — down to which word to use or what order to follow. But if a task genuinely needs flexible judgment depending on context (whether copy's tone should be playful depends on which audience it's for this time), nailing down every detail can actually prevent Claude from making a better judgment based on context.
In practice, think of judgment criteria as sitting on a spectrum. One end is an "open field" — a task with high tolerance for variation where multiple approaches count as success; here, give general direction and let Claude judge the details itself. The other end is a "narrow bridge over a cliff" — a task with low tolerance for error and only one correct way to do it; here, spell out every step, leaving no ambiguity. Figuring out where your task sits on that spectrum, then deciding how specific the criteria should be, is more efficient than always aiming for "as detailed as possible."
If I already have a vague System Prompt, how do I improve it step by step into a specific version instead of rewriting the whole thing?
You don't need a full rewrite. A more efficient approach is to first identify what, in the current output, feels "not quite what I wanted," and work backward from that gap to figure out what judgment basis Claude was missing that led it to make that choice. For example, if you notice Claude's copy review missed flagging an exaggerated claim, that means the original prompt never mentioned checking for exaggerated language at all — so add that one rule specifically, rather than rewriting everything.
In practice, this is a gradual, cumulative process: every time an output doesn't match what you expected, go back and ask "what specific judgment criterion was Claude missing that caused this," and add that answer into the prompt. After a few rounds of this, the originally vague role description will naturally get replaced by a set of specific rules. This approach is more realistic than trying to write the perfect version from the start, because many of the details worth adding only surface after you've actually used it a few times and seen a concrete gap.
Most people writing their first System Prompt end up with something like "You are a professional marketing consultant, please help answer my marketing questions." That sentence isn't wrong, but it barely provides any information Claude didn't already have — Claude already has a general sense of what a marketing consultant does, and the sentence doesn't make its answers any more accurate or closer to what you actually need.
A genuinely useful role setup relies less on a job title and more on the judgment that role would actually apply in a specific situation. Here's a real example showing how to turn a vague role description into a system prompt that actually shapes output quality.
Say you need Claude to review product copy. A vague version might read: "You are a senior copy editor, please review the following copy." This offers limited practical help, because what "senior copy editor" means in terms of review standards can vary completely depending on the company, product, and audience.
A more effective approach spells out exactly how this role would judge things:
Example system prompt:
"You review e-commerce product copy. Check three things in order: first, whether every feature claim is backed by a specific number (for instance, 'improved battery life' should become something verifiable like 'battery life improved by 40%'); second, whether absolute terms like 'best' or 'number one' are used without additional justification — flag these if found; third, whether the copy's ending clearly communicates a next action (purchase, add to cart, learn more). For each point, first identify where the original text falls short, then provide a specifically revised version — don't just give abstract advice."
This version doesn't use any impressive adjectives to describe the role itself, but it clearly defines three specific things to check, the type of problem to look for in each, and a format requirement for the output (identify the problem first, then give a revised version — not just abstract advice). This is exactly the kind of information Claude didn't already have and needed you to supply.
After writing a role setup, test it with this question: "If I removed this sentence, would Claude's answer actually change?" If the answer is "not much," the sentence is probably just describing a job title without providing an actual basis for judgment. If the answer is "yes, because without it Claude wouldn't know what standard to review against," the sentence is genuinely doing its job.
Next time you write a system prompt, resist the urge to think about "how impressive this role should sound," and instead ask yourself: "If I had to explain this task to someone with strong logical ability but zero knowledge of this domain, what specific judgment rules would I need to give them?" Writing those rules into the system prompt usually gets you what you want faster than stacking up adjectives. This principle isn't limited to copy review — any task that requires "judging by a specific standard" (code review, data analysis, customer service replies) follows the same logic: specific judgment criteria are always more useful than a vague job-title description.