The role-constraint framework: the two-part structure behind every effective prompt

You've probably noticed something: some prompts just work, while others make Claude go sideways. The difference isn't luck. It's structure.

After working with Claude extensively, I've identified a pattern that separates mediocre prompts from the ones that actually deliver. I call it the role-constraint framework, and it's deceptively simple: every effective prompt has two essential parts working in tandem.

What the framework is (and why it matters)

The role-constraint framework consists of:

1. Role: Who Claude should be or how Claude should think
2. Constraints: The specific boundaries, rules, and output format

These aren't separate concerns you handle casually. They're the load-bearing walls of your prompt architecture. When either one is missing or poorly defined, your results suffer.

Here's the critical insight: role and constraints work synergistically. The role gives Claude a cognitive framework—a lens through which to approach the problem. Constraints translate that framework into actual output discipline.

Without role, you get generic responses. Without constraints, you get unfocused sprawl. Together, they create precision.

The Role component: giving Claude a lens

The role is your answer to: "How should Claude think about this?"

This isn't about getting Claude to roleplay as a pirate or a medieval knight (though you can use those). It's about specifying a perspective, expertise level, or cognitive approach.

Strong roles include:

• Expertise-based: "You are a senior systems architect reviewing infrastructure decisions"
• Audience-aware: "You are writing for developers who know Python but not async patterns"
• Constraint-aware: "You are a technical writer who prioritizes clarity over comprehensiveness"
• Process-based: "You are a Socratic tutor who guides through questions rather than answers"

The role works because it shapes how Claude prioritizes information, selects vocabulary, and structures thinking. It's your way of saying: think like this person would.

A concrete example. Compare these two prompts:

Without clear role: "Explain cloud architecture."

With role: "You are a CTO explaining cloud architecture to a board of non-technical investors who need to understand cost implications and competitive advantages, not implementation details."

The second version constrains Claude's entire approach. It knows to skip the Docker explanation. It knows to lead with business value. The role does that work.

The Constraints component: enforcing discipline

Constraints are the rules that keep Claude's output in bounds. They answer: "What are the limits?"

Effective constraints address:

• Format: "Use a bulleted list, not prose" or "Structure as: Problem → Solution → Trade-off"
• Scope: "Focus only on frontend concerns" or "Cover Q1 and Q2 results only"
• Depth: "Explain in two sentences" or "Include one detailed example"
• Tone: "Match HubSpot's blog voice: conversational and evidence-based"
• Constraints on constraints: "If the task is impossible, say so—don't fake it"

Constraints prevent Claude from doing what it does naturally: generate comprehensive, thoroughly elaborated responses. That's a feature, not a bug. You often want to constrain completeness in favor of focus.

Here's a real example from my own work. I was generating product comparison tables. Early attempts were bloated—too many columns, rows that didn't matter. The constraint that mattered: "Include only criteria where the products differ meaningfully. Sort by relevance to the user's decision. Max 8 rows."

That constraint forced prioritization. Claude stopped listing every possible feature and started thinking like an editor.

Putting them together: real prompt examples

Let me show you how role and constraints interact in practice.

Example 1: Technical documentation

You are a technical writer who specializes in making
complex topics accessible to intermediate-level developers.

When documenting this feature:
- Assume readers know REST APIs but not message queues
- Use a three-part structure: What it is → Why it matters → How to use it
- Include one real example, not pseudocode
- Flag any gotchas with a "⚠️ Watch out" section
- Keep it under 300 words

The role tells Claude how to think about the audience and their gaps. The constraints tell Claude exactly what shape the output takes. Neither one alone would work.

Example 2: Content marketing

You are a marketing strategist writing for our blog.
Your audience: startup founders considering switching away from our competitor.

Write this piece:
- Lead with a concrete problem they face (not features we lack)
- Support claims with specific examples, not generic statements
- End with a clear next step that's low-friction (not "book a demo")
- Avoid: superlatives, technical jargon, mentions of our competitors by name
- Target length: 1,200 words

Role = strategic perspective + audience awareness. Constraints = form, scope, and prohibited content.

Example 3: Code review feedback

You are reviewing this code as a senior engineer who values
pragmatism over perfection. You want to help junior developers learn.

Provide feedback as:
1. One or two high-impact observations (not a laundry list)
2. For each: explain the why (learning goal) and the how (concrete fix)
3. Highlight one thing they did well
4. Flag anything that's a blocking issue vs. nice-to-have

The role determines your stance (pragmatic, educational, respectful). The constraints determine the structure and depth.

When the framework breaks (and how to fix it)

Most disappointing Claude outputs trace back to weak role or constraint definition.

If Claude's response is generic and surface-level, usually your role is too vague. "You are a helpful assistant" isn't a role—it's surrendering the framework. Get specific about perspective and expertise.

If Claude's response is sprawling and unfocused, usually your constraints lack teeth. "Write about climate change" is asking for chaos. "Write a 400-word explainer on carbon pricing aimed at policy students, structured as: mechanism → tradeoffs → real-world example" constrains it.

If Claude keeps misinterpreting your intent, usually role and constraints are working against each other. I once had a role ("financial analyst") that kept pushing jargon while my constraints asked for accessibility. Fixing the role solved it.

Practical next steps

For your next prompt, audit it against the framework:

1. Role: Can you describe it in one sentence? Is it specific enough that it would change Claude's answer?
2. Constraints: Do you have at least 2-3 active constraints? Are they format, scope, or depth constraints?
3. Fit: Do they work together or fight each other?

The role-constraint framework isn't a rigid formula. It's a diagnostic lens. But I've found that every prompt that reliably produces quality output has both parts firing.

Once you start thinking in terms of role and constraint, you'll notice it in good prompts everywhere. And you'll know exactly what to fix when things go sideways.