Prompting Fundamentals

Almost every good prompt sets five things, in whatever order reads naturally: role, context, task, format and constraints. You do not need all five every time, but naming them stops you leaving out the part that was doing all the work.

Role - who the model should act as, which pulls it toward the right vocabulary and standards: "Act as an experienced architect," "You are a lighting designer," "Review this as a quantity surveyor would." Context - the situation it needs: the project, site, client, climate, budget, constraints, and any real source material (this is where you paste the actual brief or code clause). Task - the single, specific thing you want done, with a strong verb: summarise, compare, draft, critique, list, rewrite, extract. Format - the shape of the answer: a table with these columns, a bulleted list, 150 words, a JSON object, one paragraph per option. Constraints - the guardrails: what to avoid, the tone, the length cap, the must-includes, and honesty rules like "say if you are unsure" or "only use the document I pasted."

Here is the same request built up from lazy to loaded:

Weak:
  "ideas for a small cafe interior"

Strong:
  Role:       Act as an interior designer.
  Context:    A 40 sq m cafe in a hot-humid Indian coastal town,
              young budget-conscious crowd, ceiling fans not AC,
              owner wants a calm, natural, Instagram-friendly feel.
  Task:       Propose 6 distinct concept directions.
  Format:     A table: Concept | Material palette | One hero move |
              Rough cost band (low/med/high) | One risk.
  Constraints: Locally available materials only. No generic
              'industrial chic'. Flag anything you are unsure about.

The strong version is not longer for show - every line removes a guess the model would otherwise make for you, badly.

Words describe what you want; examples nail it. When the shape or style of the output matters, give the model one or two samples of exactly what 'good' looks like - this is called few-shot prompting (zero examples is 'zero-shot', a couple is 'few-shot'). Models are pattern-matchers, so a concrete example steers them far more precisely than an adjective.

Suppose you want space-programme rows in a consistent voice. Instead of describing the tone, demonstrate it:

Write room descriptions for a house programme in THIS style:

Example -
  Room: Study
  Description: A quiet 9 sq m room off the entry, north-lit for
  glare-free work, with a full wall of shelving and a door that
  actually closes. Priority: acoustic separation from the living area.

Now write entries in the same format for: Master bedroom,
Puja room, Utility.

The model copies the length, the north-light-then-priority rhythm, the concrete tone - because you showed it, not told it. The same trick works for anything with a house style: proposal paragraphs, spec clauses, email replies, drawing-note wording. Two good examples usually beat any amount of description, and they are how you get consistency across a batch instead of the model reinventing the format on every row.

The biggest myth in prompting is the perfect one-shot prompt. In real use, the first answer is a starting point you steer, not a verdict. Fluent prompters are not the ones who write the ideal prompt first try - they are the ones who read the reply critically and fire back a precise correction.

The move is conversational refinement. The output is too generic? "These are too safe - push three of them somewhere genuinely unexpected." Too long? "Cut to 120 words, keep only the strongest point." Wrong angle? "You are optimising for cost; redo it optimising for daylight instead." Missing something? "Add a column for maintenance burden." Each turn spends the model's speed to close in on what you actually wanted - which you often only discover by seeing what you did not want.

Two force-multipliers here. First, ask the model to improve its own output: "Critique your last answer as a senior designer would, then rewrite it fixing those flaws." It is often a better editor than first-drafter. Second, ask it to ask you questions: "Before you answer, ask me the 5 questions that would most improve your response." This flips the burden - instead of you guessing the perfect prompt, the model tells you what context it is missing. For anything meaty, that single line raises quality more than any template.

And know when to stop or restart. If a chat has drifted, wandered, or filled with your corrections, do not keep patching - open a fresh conversation and write one clean prompt with everything you have learned. A poisoned context is often faster to abandon than to fix.

A prompt that asks for too much at once gets you a shallow answer to everything and a good answer to nothing. The fix is decomposition - splitting a large task into a sequence of smaller prompts, each of which the model can do well, with you steering between them. Do not ask 'design me a full space programme for this house'; ask it to list the required rooms, then to size each against the site area, then to group them into zones, then to flag adjacency conflicts. You stay in the loop at every hand-off, catching drift before it compounds - which is exactly the human-in-the-loop applied at the scale of a single task.

For anything involving reasoning - a comparison, a calculation, a judgement between options - it helps to let the model think step by step rather than jump to a verdict. A simple "work through this step by step before giving your answer" (or turning on a reasoning mode) makes the model lay out its intermediate logic, which both improves the answer and, crucially, lets you inspect the reasoning and catch a wrong turn. An answer you can see the working for is one you can actually evaluate; a bare conclusion is one you can only take on faith.

A related habit is to ask for options, not a single answer, on anything where judgement matters. "Give me three approaches with the trade-offs of each" turns the model from a decider into an option-generator - which is what you actually want, because the deciding is yours. And when a task is genuinely complex, sketch the sequence yourself first: what are the sub-steps, in what order, and where do you need to check the output before moving on? That planning is design thinking, and it is precisely the part the model cannot do for you. The prompt executes the plan; the plan is yours. Get comfortable chaining a handful of well-scoped prompts into a small workflow, and you have the seed of the tool-chaining and custom assistants that Module 8 builds into something powerful.

A few habits separate people who get consistently good output from people who get lucky sometimes. Be specific over polite - the model does not need 'please could you possibly'; it needs the number, the audience, the length, the columns. One task per prompt for anything complex - a prompt asking for a summary and a critique and a table gets you three mediocre things; split them. Give it your material - the biggest quality jump, as the last lesson showed, is pasting the real brief, clause or data rather than relying on the model's memory. Set the audience - "explain this for a client with no technical background" versus "for a structural engineer" produces genuinely different, better-aimed writing.

Then the guardrails that keep you safe, especially as stakes rise. Add honesty instructions as a matter of routine: "only use the information I gave you," "do not invent citations or figures," "mark anything you are unsure about," "if you do not know, say so." These do not make the model incapable of error - remember it has no reliable sense of its own uncertainty - but they measurably reduce confident invention and make the shaky parts easier to spot.

One more habit pays off constantly: save the prompts that work. When a prompt reliably produces good output - a spec-clause drafter, a precedent analyser, a proposal-paragraph writer in your voice - keep it in a simple notes file and reuse it, tweaking the specifics each time. Over a few months this becomes a personal prompt library that captures your hard-won phrasings, and it is the raw material for the reusable custom assistants of Module 8. You are not just getting one answer; you are building a reusable asset every time you get a prompt right.

Finally, remember what you are doing: prompting is directing, and directing is the designer's half of the human-in-the-loop. The prompt gets a good draft in front of you fast; your judgement is still what decides whether it is any good. A great prompt is not a substitute for evaluation - it is what makes evaluation worth your time.