Intermediate Prompting

• Role framing
• Few-shot examples
• Output schemas
• Iteration loops
• Asking the model to ask questions
• Combining the techniques

This guide assumes you already structure prompts with task, context, format, and constraints (see Prompting Basics). The techniques here build on that foundation.

Role framing

Assigning a role tells the model which perspective, vocabulary, and priorities to use. It works because the same question has different good answers depending on who is answering: a security engineer and a UX designer will flag different problems in the same signup flow.

You are an experienced technical editor at a publisher of programming
books. Review the chapter draft below. Focus on what an editor cares
about: unclear explanations, missing prerequisites, inconsistent
terminology, and places where a code sample would help. Do not fix
prose style line by line.

Two cautions. First, the role should be doing real work — "you are a helpful assistant" adds nothing. Pick a role that changes what the answer should contain. Second, a role does not add knowledge the model lacks; framing it as a tax attorney does not make its tax claims reliable. Roles shape emphasis and voice, not accuracy.

Few-shot examples

A few-shot prompt shows the model input–output pairs before giving it the real input. It is the most direct way to teach a transformation that is easier to demonstrate than to describe.

Convert customer feedback into structured tags.

Feedback: "Took 3 weeks to arrive and the box was crushed."
Tags: shipping-delay, packaging-damage

Feedback: "Love the color but the strap broke after two days."
Tags: quality-defect, positive-aesthetics

Feedback: "Support answered in five minutes and fixed everything."
Tags: support-positive

Feedback: "The app logs me out every time I switch wifi networks."
Tags:

Guidelines that matter in practice: use two to five examples; cover the variety you expect in real inputs, including at least one tricky case; keep formatting identical across examples, because the model imitates format as faithfully as content. If your examples all have two tags, the model will lean toward producing two tags even when one or three would be right — vary what you want varied.

Output schemas

When output feeds into code, a spreadsheet, or another prompt, define its structure exactly. Show the schema, state the types, and say what to do with missing values.

Extract event details from the email below. Respond with only a JSON
object in exactly this shape, and no other text:

{
  "event_name": string,
  "date": string or null,        // ISO 8601 if present, else null
  "location": string or null,
  "rsvp_required": boolean,
  "contact_email": string or null
}

If a field is not stated in the email, use null. Do not guess.

The two failure modes to design against are extra prose around the JSON (hence "only... and no other text") and invented values for missing fields (hence explicit null handling and "do not guess"). If your tooling supports a structured-output or JSON mode, use it in addition to the instructions, not instead of them.

Iteration loops

Treat the first response as a draft, not a verdict. The model retains the conversation, so follow-ups can be short and surgical:

Good start. Now:
1. Cut the second paragraph entirely.
2. Make the opening line a question.
3. The tone drifted formal in the closing — match the casual tone
   of the opening throughout.

Numbered change requests work better than a paragraph of mixed feedback, because each item gets addressed rather than averaged. When a conversation has accumulated several rounds of corrections, consider a consolidation step: ask the model to restate the current requirements in one list, check that list, then have it produce a clean final version from the list. This prevents earlier, superseded instructions from leaking back in.

If a thread has gone badly off course, starting a fresh conversation with an improved prompt is often faster than repairing the old one.

Asking the model to ask questions

By default, models answer immediately, filling gaps with assumptions. For underspecified tasks, invert this: make gathering requirements the first step.

I want to build a personal website. Before proposing anything, ask
me up to five questions whose answers would most change your
recommendation. Ask them one at a time and wait for my reply to
each. Only after that, propose a plan.

A lighter-weight variant keeps the answer but surfaces the assumptions:

Draft the proposal now, but first list the assumptions you are
making about budget, timeline, and audience, so I can correct any
before reading the draft.

Use the question-first pattern when you are not sure what you want yet; use the assumption-listing pattern when you want a draft immediately but want its guesses visible.

Combining the techniques

These techniques compose. A realistic working prompt might frame a role, define a schema, and invite questions all at once:

You are a hiring manager reviewing resumes for a junior data analyst
role. For the resume below, respond with only this JSON:

{
  "strengths": [string],
  "gaps": [string],
  "interview_questions": [string]   // exactly 3
}

If the resume is missing information you need (for example, no
dates on roles), note that inside "gaps" rather than guessing.

You rarely need every technique in one prompt. Reach for a role when perspective matters, few-shot when the transformation is easier shown than told, a schema when software consumes the output, iteration when quality matters more than speed, and model-asks-questions when you have not fully specified the task — which is more often than most of us admit.