Writing Prompts

By the Syncfusion DevTutorials team · Last updated

Prompts for emails, summaries, blog posts and reports: the reader, purpose, facts, tone and length, checking facts and length in code, outline-first writing, and avoiding filler.

Writing is the most common thing people ask AI models to do: emails, blog posts, reports, summaries, product descriptions. It is also where vague prompts do the most harm. "Write an email to my team about the delay" gives you a polite, generic email that says nothing your team needs to know.

This lesson puts the whole course to work on writing tasks. You will build prompts that say who is reading, why, what must be in the text, and how long it should be, and then check the result in code.

The main idea: a writing prompt needs a reader, a purpose, the facts, a tone, and a length. Give all five, and check the result.

A Real-World Example

Think about asking a colleague to write a note for you.

  • "Write something about the delay" gives you a guess.
  • "Write a 3-sentence note to the client. Say the release moves from 10 March to 24 March because of a security fix. Apologise once, and offer a call this week" gives you exactly the note you need.

The second request contains facts only you know. A model cannot invent those correctly, so it has to be told.

What You Will Learn

In this lesson, you will learn:

  1. The five things every writing prompt needs.
  2. How to prompt for emails and check them.
  3. How to prompt for summaries and check their length and key points.
  4. How to write long pieces, like blog posts, in steps.
  5. How to control tone and avoid filler words.
  6. How to write reports with a fixed structure.

The "Try it" cards run in the Prompt sandbox at the bottom of the page. Use the Compare tab to see a vague writing prompt next to a complete one, and the Test tab to check summaries on several inputs.

The Five Things a Writing Prompt Needs

A writing prompt needs five things: the reader, the purpose, the facts, the tone and the length. Missing facts are the most common cause of generic text.

PartQuestion it answersExample
ReaderWho will read it?The client's project manager
PurposeWhat should the reader do or know after reading?Know the new date and book a call
FactsWhat must be in the text?New date 24 March, reason: security fix
ToneHow should it sound?Polite, direct, no drama
LengthHow long?3 sentences, under 80 words

The facts matter most. A model writes fluent text easily. What it cannot do is know your dates, names, numbers, and decisions.

Emails

The next box builds an email prompt from the five parts. The facts go in a list, so none are missed.

Build an email prompt from five parts

function emailPrompt(e) {
  return [
    "Write an email to " + e.reader + ".",
    "Purpose: " + e.purpose,
    "Include these facts:",
    ...e.facts.map((f) => "- " + f),
    "Tone: " + e.tone + ". Length: " + e.length + ".",
    "Start with a line 'Subject: ...', then the email body.",
  ].join("\n");
}

console.log(emailPrompt({
  reader: "a client's project manager",
  purpose: "tell them the release date has moved and offer a call",
  facts: ["Old date: 10 March", "New date: 24 March", "Reason: a security fix", "Offer a 20-minute call this week"],
  tone: "polite and direct",
  length: "under 90 words",
}));

Expected output:

Write an email to a client's project manager.
Purpose: tell them the release date has moved and offer a call
Include these facts:
- Old date: 10 March
- New date: 24 March
- Reason: a security fix
- Offer a 20-minute call this week
Tone: polite and direct. Length: under 90 words.
Start with a line 'Subject: ...', then the email body.

Compare a vague request with the full prompt below.

Prompt A has to invent the dates and the reason. Prompt B cannot get them wrong unless it ignores them, and that is something code can check.

Check an Email

Turn the prompt's rules into checks: is there a subject line, is it under the word limit, and does it contain every fact?

Check an email against its rules

function checkEmail(text, mustInclude, maxWords) {
  const problems = [];
  if (!/^Subject:\s*\S/m.test(text)) problems.push("no subject line");
  const body = text.replace(/^Subject:.*$/m, "");
  const words = body.trim().split(/\s+/).length;
  if (words > maxWords) problems.push(words + " words, more than " + maxWords);
  for (const fact of mustInclude) {
    if (!text.toLowerCase().includes(fact.toLowerCase())) problems.push("missing: " + fact);
  }
  return problems.length ? problems : ["ok"];
}

const email = "Subject: New release date: 24 March\n\nHi Sam,\nOur release moves from 10 March to 24 March because of a security fix. Sorry for the change. Could we have a 20-minute call this week to go over the plan?\n\nBest, Priya";
console.log(JSON.stringify(checkEmail(email, ["24 March", "10 March", "security fix", "call"], 90)));
console.log(JSON.stringify(checkEmail("Hi, the release is delayed. Sorry!", ["24 March", "security fix"], 90)));

Expected output:

["ok"]
["no subject line","missing: 24 March","missing: security fix"]

The emails here are samples written for this box. The second one is the kind of reply a vague prompt gets: short, polite, and missing everything the client needs.

Summaries

A summary prompt must say how short, for whom, and what to keep. "Summarise this" leaves all three to chance.

Two checks catch most bad summaries:

  • Length. Is it really short? Compare it with the original.
  • Key points. Are the facts that matter still there?

Check a summary's length and key points

const original = "The team met on Monday to review the Q3 results. Revenue grew 12 percent, mainly from the new grid product. Support tickets fell by 20 percent after the docs update. The team agreed to hire two more engineers and to launch the mobile beta in November. Travel costs were over budget and will be cut next quarter.";
const summary = "Q3 revenue grew 12 percent and support tickets fell 20 percent. The team will hire two engineers and launch the mobile beta in November.";

const words = (t) => t.split(/\s+/).length;
const keyPoints = ["12 percent", "20 percent", "two", "November", "travel"];

console.log("Length:", words(summary), "of", words(original), "words (" + Math.round((words(summary) / words(original)) * 100) + "%)");
keyPoints.forEach((k) => console.log(summary.includes(k) ? "kept   " : "MISSING", k));

Expected output:

Length: 24 of 57 words (42%)
kept    12 percent
kept    20 percent
kept    two
kept    November
MISSING travel

The summary is short and keeps most points, but drops the travel budget. Whether that is fine depends on the reader. For a finance manager, it is the most important point. That is why the prompt must name the reader.

Run a summary test on the real model. Each case checks one key fact and a word limit.

Easy Way to Remember: for any writing task, ask "who reads it, what must they get, how long?" Then put the facts in a list, so the model cannot skip them.

Long Pieces: Outline First

Long text, like a blog post, goes better in steps (you met this in Step-by-Step Prompting):

  1. Ask for an outline: a title and section headings.
  2. Review and fix the outline.
  3. Write one section at a time, giving the outline each time so the sections fit together.

Write a blog post section by section

const outline = {
  title: "5 Ways to Make Your Data Grid Faster",
  sections: ["Load data in pages", "Turn on virtual scrolling", "Avoid heavy cell templates", "Cache sorted results", "Measure before you optimise"],
};

function sectionPrompt(outline, index) {
  return [
    "You are writing the blog post: " + outline.title,
    "Outline: " + outline.sections.map((s, i) => i + 1 + ". " + s).join("; "),
    "Write only section " + (index + 1) + ": " + outline.sections[index] + ".",
    "120 to 160 words, for front-end developers, with one short code tip.",
  ].join("\n");
}

console.log(sectionPrompt(outline, 1));

Expected output:

You are writing the blog post: 5 Ways to Make Your Data Grid Faster
Outline: 1. Load data in pages; 2. Turn on virtual scrolling; 3. Avoid heavy cell templates; 4. Cache sorted results; 5. Measure before you optimise
Write only section 2: Turn on virtual scrolling.
120 to 160 words, for front-end developers, with one short code tip.

Giving the whole outline each time stops sections from repeating each other. Asking for one section at a time keeps each reply within what a small model writes well.

Tone and Filler Words

Models love certain filler words and phrases: "delve", "in today's fast-paced world", "it is important to note". They make text longer and sound machine-written. You can do two things:

  • Say what tone you want, with an example sentence.
  • Check the reply for words you don't want.

Find filler phrases in a draft

const filler = ["delve", "in today's fast-paced world", "it is important to note", "game-changer", "unlock", "seamless"];

function findFiller(text) {
  const t = text.toLowerCase();
  return filler.filter((f) => t.includes(f));
}

const draft = "In today's fast-paced world, it is important to note that our seamless grid will unlock new speed.";
const better = "Our grid now loads 10,000 rows in under a second.";

console.log(JSON.stringify(findFiller(draft)));
console.log(JSON.stringify(findFiller(better)));

Expected output:

["in today's fast-paced world","it is important to note","unlock","seamless"]
[]

The second sentence is shorter and says something real: a number a reader can use. Ask for concrete facts and numbers in the prompt, and the filler mostly disappears.

Reports With a Fixed Structure

Reports are read again and again, and often compared. Give the model the exact headings, and check that every one is there, in order.

Check a report has every heading in order

const required = ["Summary", "What went well", "Problems", "Next steps"];

function checkHeadings(report) {
  const found = [...report.matchAll(/^##\s+(.+)$/gm)].map((m) => m[1].trim());
  const missing = required.filter((h) => !found.includes(h));
  const inOrder = required.filter((h) => found.includes(h)).every((h, i, arr) => i === 0 || found.indexOf(h) > found.indexOf(arr[i - 1]));
  return { found: found.length, missing, inOrder };
}

const report = "## Summary\nGood sprint.\n## Problems\nTwo bugs.\n## What went well\nFast reviews.\n## Next steps\nFix bugs.";
console.log(JSON.stringify(checkHeadings(report)));

Expected output:

{"found":4,"missing":[],"inOrder":false}

All four headings are there, but "Problems" came before "What went well". If reports are compared week by week, the order matters. Put "Use these headings in this order" in the prompt, and keep this check in your tests.

Never send AI-written text with facts you have not checked: names, dates, prices, promises, or legal wording. A fluent email with a wrong date is worse than no email. Read every message before it goes out.

Planning Prompts

Models are also good at turning messy notes into a plan. For planning, add three things to the usual reader, facts, and format: the time frame, the constraints, and the decision you need.

Check the plan the same way you check any output: does every task appear, are the deadlines met, and is the dependency on Sam flagged?

Common mistakes

MistakeWrong ideaCorrect ideaWhat goes wrong
No facts in the prompt"It knows what a delay email says."List every fact the text must contain.A polite email with made-up or missing details.
No reader"Everyone reads the same summary."Name the reader so the right points are kept.The summary drops the point that matters most to them.
No length"It will be a sensible length."Give a word or sentence limit.Long, padded text nobody reads.
One prompt for a long post"Write a 2,000-word blog post."Outline first, then write section by section.Repetition and a weak second half.
Vague tone words"Make it professional."Describe the tone and show one example line.Stiff text full of filler phrases.
Sending unchecked text"It reads well, so it's fine."Check facts and promises before sending.Wrong dates or promises reach a customer.

Exercises

Each exercise ends with a value on the last line. Press Check to compare it with the expected answer.

What to Remember

  • Every writing prompt needs a reader, a purpose, the facts, a tone, and a length.
  • Put facts in a list, and check they all appear in the reply.
  • For summaries, check the length and the key points, for the named reader.
  • Write long pieces from an outline, one section at a time.
  • Avoid filler words. Ask for concrete facts and numbers.
  • Give reports exact headings in order, and check them.
  • Read and check every generated text before you send it.

Next: Research Prompts, gathering information, checking sources, and learning new topics with a model.