Role, context, task, and criteria

A useful role changes what the model does, not what credentials it pretends to hold. Prefer:

• audience: “Explain for a first-year student who knows fractions.”
• stance: “Review as a skeptical editor looking for unsupported claims.”
• process: “Ask one clarifying question at a time before drafting.”

Avoid ornamental prestige: “world-class genius,” “PhD in everything,” or “never make mistakes.” Those phrases do not create knowledge, access, or accountability. If a role matters, define the behaviors: ask before assuming, cite only supplied sections, separate facts from suggestions, or keep a calm coaching tone.

Roles also set boundaries. A tutor role may refuse to complete graded homework wholesale and instead guide the learner. A support role may escalate refunds instead of inventing policy. Write those boundaries into the pattern.

Context should answer: what may the model rely on? Paste the notes, policy excerpt, transcript segment, spreadsheet summary, or prior email. Label drafts versus approved facts. Tell the model what to ignore.

Weak context dumps a whole folder and hopes for the best. Strong context is curated: the minimum material needed for the job, with dates and status. When material conflicts, instruct the model to surface the conflict rather than silently choose.

If the needed facts are not in the chat, say so. A good pattern asks for missing inputs or uses placeholders. Guessing dressed as context is how fluent errors enter final drafts.

Name the operation: draft, rewrite, extract, classify, compare, outline, critique. Name the output shape: paragraphs, bullets, table, subject line plus body, JSON fields. Name the audience and use: “for a manager who must decide today,” “for my own study notes.”

Keep one primary task per prompt when possible. “Summarize, critique, rewrite in three tones, and invent a campaign” mixes success criteria and hides which failure matters. If you need several outputs, sequence them or request a labeled multi-part response with clear sections.

Criteria turn taste into checks:

• length or time budget;
• required sections;
• tone as observable choices (“direct, no blame, no exclamation marks”);
• evidence rules (“only use the notes,” “quote policy wording”);
• uncertainty rules (“use null / TBD / NEED INPUT”);
• exclusions (“no competitor claims,” “no medical advice”).

Write criteria before you draft when the stakes are high. After a weak first answer, convert your complaint into a criterion rather than a vague “make it better.”

Role / audience:
Authoritative context:
Task and output shape:
Must include:
Must not invent:
Uncertainty rule:
Quality checks I will apply:

Fill the template once, then adapt placeholders. Store approved facts outside stylistic examples so policy updates do not require rewriting every sample paragraph.

Role-context-task-criteria covers many emails, explanations, rewrites, and outlines. Add examples when the format is hard to describe in words. Add decomposition when steps depend on intermediate judgments. Add structured output when software must parse fields. Do not stack every technique by default.