Prompting basics

The minimum that doesn’t work

Here is a typical first prompt:

Write me a payment reminder.

What does the model produce? Something generic in English: “Dear Sir/Madam, This is a friendly reminder that your invoice…” — passable, but neither in the right language, nor the right tone, nor matched to the situation. The model had to guess at all of that.

You wouldn’t accept this from a human assistant. You wouldn’t say “write me a reminder” without telling them the language, the tone, who the client is, how overdue the payment is, or whether you’ve reminded them before. The model deserves the same context.

Rule 1 — Give it a role

A small, almost-free improvement: tell the model who it is before you tell it what to do. This sets the register.

You are a polite professional accountant at a small Kathmandu accounting firm. Draft a payment reminder…

The output gets immediately more appropriate. Tone shifts. Vocabulary shifts. You’re not lying to the model; you’re focusing it.

Rule 2 — State the task precisely

The verb matters. “Write” is too vague. Pick the precise verb you want: draft, summarise, rewrite, translate, extract, classify, compare. Each invokes a different mode.

Draft a polite payment-reminder email…

“Draft” tells the model: I want a first version, professional tone, ready to edit. “Compose” might give you a longer, more formal piece. “Write me something” might give you a poem.

Rule 3 — Specify the constraints

This is the rule that produces the largest single improvement. Tell the model the constraints — everything you would tell a human writer about format, length, language, tone, and audience.

Draft a polite payment-reminder email in Nepali. About 150 words. Polite but firm tone — the client is two weeks late but is otherwise a long-standing customer. Address them as Sir/Madam (श्रीमान्/श्रीमती). End with a clear ask: please clear the dues by next Friday, or contact us if there’s a problem.

Almost everything you put in the constraint list improves the output. Length. Language. Tone. Audience. Format (email, table, list, JSON). Whatever shape the answer should take.

Rule 4 — Give it the relevant context

If you have material the model needs to know — the client’s name, the original invoice details, prior correspondence — paste it in. The model has no way to know things you don’t tell it. (And no, it cannot look up your invoices unless you’ve explicitly connected a tool.)

Context:

• Client: Aastha Trading Pvt. Ltd.
• Invoice #2024-187, dated 12 Mangsir 2081, NPR 86,500.
• Due 27 Mangsir. Today is 11 Poush. Two weeks overdue.
• Previous reminder sent 4 Poush by phone, no reply.

Draft the email referencing the invoice number and the prior reminder.

The output now is genuinely usable. The model has a specific situation, specific facts, and specific people. It doesn’t have to guess.

Rule 5 — Ask for the format you want

Last rule. Be explicit about output structure.

• “Output the email in plain text, no markdown.”
• “Give me three subject-line options at the top, then the email body.”
• “Return your answer as a bulleted list.”
• “Respond in JSON with these keys: …”

You will get exactly what you ask for. If you don’t ask, you’ll get the model’s default — which is usually markdown-formatted, English, with extra preamble like “Sure! Here’s a draft email for you:”.

Putting it all together

Here is the full, well-constructed prompt — about 20× longer than the original but producing a finished, usable draft:

You are a polite professional accountant at a small Kathmandu accounting firm. Draft a polite payment-reminder email in Nepali to a client whose payment is two weeks overdue.

Context:

• Client: Aastha Trading Pvt. Ltd.
• Invoice #2024-187, dated 12 Mangsir 2081, NPR 86,500.
• Due 27 Mangsir. Today is 11 Poush.
• Prior reminder by phone on 4 Poush, no reply.

Constraints:

• Polite but firm tone — long-standing customer.
• Address as श्रीमान्/श्रीमती.
• About 150 words.
• Clear ask: clear dues by next Friday, or contact us.

Output the email body in plain Nepali (Devanagari), no markdown. Provide three subject-line options at the top.

The output, on any of the major models, will be a finished draft. Five minutes of editing and it ships.

The rule of thumb: time spent writing the prompt is time saved on the output. A 30-second prompt produces a draft that takes 10 minutes to fix. A 3-minute prompt produces a draft that takes 30 seconds to polish.

Common bad-prompt patterns to avoid

Three failure modes that consistently produce bad output:

1. The wish. “Make it good.” The model has no idea what “good” means here.
2. The dump. Pasting an entire 30-page document with no instruction. The model picks a task at random.
3. The over-polite. Long apologetic preambles (“If you could please be so kind as to…”) add no information and cost tokens.

The best prompts are direct, specific, and as long as they need to be — no longer.

Check your understanding

Quick check

—

A prompt is most likely to produce a useful, targeted output when it includes which of the following?

1. AA polite long preamble apologising for taking the model's time
2. BA clear role, a precise task verb, specific constraints, relevant context, and the desired output format
3. COnly the bare task — "write me an email"
4. DThe model's underlying source code

Check answer→

Quick check

—

You ask ChatGPT to write a Nepali email. The output is in English with overly formal phrasing. The most likely fix is:

1. ASwitch to a different model entirely
2. BAdd the constraint "Respond in Nepali (Devanagari)" and specify the tone ("warm and conversational")
3. CRestart your computer
4. DWait for the model to update

Check answer→

What comes next

We’ve covered the structure of a single prompt. The next section shows a different technique — showing the model what you want with examples, rather than describing it. This is sometimes called few-shot prompting, and it is sometimes more powerful than any amount of instruction.