Module 11 · Lesson 02

Role, Context, Task, Constraints — The Four Pillars

Reading time: 16 minutes Track: Claude Fluency for Teams · Required for all learners

The four-pillar framework

Every well-constructed prompt contains some combination of four elements. Not every prompt needs all four, but knowing them helps you diagnose why a prompt is underperforming.

Role — Who is Claude in this interaction?

Assigning Claude a role — expert, reviewer, editor, skeptic, customer — activates different response patterns. An expert will go deeper. A reviewer will be critical. An editor will focus on prose, not content.

You are a senior security engineer reviewing code for vulnerabilities.

Act as a skeptical enterprise buyer evaluating this sales pitch.

Role is optional but powerful for outputs where perspective and expertise level matter.

Context — What does Claude need to know?

Background that changes how the task should be done. Your situation, the audience, relevant history, constraints of the environment.

Context: This document is for a non-technical executive audience.
They have 5 minutes to read it and need to make a go/no-go decision.

Task — What exactly should Claude do?

Specific, verb-led instruction. Not "help me with" but "write", "review", "extract", "convert", "summarize into three bullets", "find every instance of X".

Constraints — What should Claude avoid?

What not to include, what tone to avoid, what assumptions not to make, length limits, format restrictions.

Do not suggest solutions that require database schema changes.
Keep the response under 200 words.
Avoid jargon — the reader is a first-year analyst.

Pattern library: common professional use cases

Code review

Role: You are a senior [language] engineer focused on production readiness.
Context: This code will handle [volume/criticality]. Team is mid-level.
Task: Review this code for bugs, security issues, and performance problems.
Constraints: Focus on serious issues only. Flag nitpicks separately.
Be direct — skip praise.

Document editing

Context: This document goes to [audience]. Tone should be [tone].
Task: Edit for clarity and conciseness. Cut 20% of the length.
Constraints: Keep all the data points. Don't change the conclusion.

Decision analysis

Context: We're deciding [decision]. Key constraints: [constraints].
Task: Analyze the tradeoffs between [options A, B, C].
Format: For each option: pros, cons, key risks, recommended for whom.
Constraints: Don't make the final recommendation — give me the analysis.

Research synthesis

Context: I need to understand [topic] well enough to [purpose].
Task: Explain [topic] covering [specific aspects].
Format: Use headers. Include a "what to do with this" section.
Constraints: Assume technical background but no domain expertise in this area.

The role of constraints

Constraints are underused. They're the difference between "pretty good" and "exactly what I need."

The most useful constraint types:

• Audience constraints: "Assume no technical background"
• Scope constraints: "Only address X, not Y"
• Tone constraints: "Be direct, skip hedging"
• Format constraints: "Under 100 words", "table format", "numbered list"
• Quality constraints: "Flag when you're uncertain", "cite your reasoning"

One powerful constraint that applies almost universally: "Be direct. Skip preamble."

Claude has a tendency to open responses with context-setting ("Great question! This is indeed an important consideration..."). This is often unhelpful. The constraint "be direct, skip preamble" eliminates it.