#Four building blocks: role, task, constraints, output format

Splitting a prompt into four blocks beats piling on adjectives. OpenAI recommends tone and identity in the system message, the concrete task and materials in the user message. Anthropic recommends saying the job directly instead of hoping the model infers it.

#1. Role

Role answers which professional stance, which reader, and what “good” looks like. An empty role (“helpful assistant”) adds almost nothing. A useful role names the audience and a quality bar:

You are a backend code reviewer. The reader is the author of this repo.
Prefer correctness, safety, and reversibility over style nits.
If unsure, mark “needs author confirmation”. Do not pretend you read files that were not provided.

This is not character play. A long “you have 20 years of experience…” usually wastes tokens. Function + reader + bar is enough.

#2. Task

A task is verb + object + done-when. Turn “take a look” into a checkable deliverable:

Put the actual ask near the front. If “return JSON only” is the last sentence of a long essay, the model will often start in prose anyway.

One main task per call. If you need “extract then rewrite”, number the steps or split into two calls (see Few-shot and Structured output).

#3. Constraints

Constraints are negative space: scope, forbidden moves, resources, tone. Without them, the model completes the most common answer from training.

Typical kinds:

• Scope: only src/auth/; do not touch migrations/
• Evidence: use only text inside <doc>; if it is missing, say you do not know
• Safety / compliance: do not invent legal conclusions; do not emit secrets
• Voice: second person; no marketing filler
• Budget: at most eight bullets; code samples ≤ 40 lines

Constraints must be checkable. “Write it better” cannot be graded. “Do not use the word ‘synergy’” can.

#4. Output format

Format is for the next consumer: a human, another model, or a parser. Humans can take Markdown headings. Programs need JSON / a schema (next: Structured output).

Role: technical editor. Reader: someone cloning this repo for the first time.
Task: write a “five-minute run” subsection from the README draft.
Constraints: do not invent env vars that are not in the draft; Windows commands in PowerShell.
Output: Markdown with only the h2 “Five-minute run” and an ordered list. No preamble.

Put the format at the end of the instructions or in its own section, and pin it with examples (Few-shot). If format fights the task (“detailed analysis” + “reply with one word”), the model randomly drops one side—a classic pitfall.

#One rewrite

Before:

Make this email more professional.

After:

Role: outbound support. Calm, no blame.
Task: rewrite the draft into a sendable email: delay reason and the new arrival window.
Constraints: no compensation promises; do not blame the customer; ≤ 120 words.
Output: body only. No subject line. Do not explain your edits.

Draft:
{{DRAFT}}

You do not need tags every time, but you should be able to point at a missing block. Chat can stay short. Rules, Dify nodes, and system_prompt should include all four.

#Checklist

After you write:

1. Who is the reader? Should the model admit ignorance or keep guessing?
2. Can you accept the deliverable in one sentence?
3. Is there an explicit “do not”?
4. Can the next consumer (human or code) parse without guessing?

#Next steps

• Structure and delimiters
• Few-shot examples