Introduction
This guide treats a prompt as a small creation brief. It shows six decisions that connect a user need to a format-ready result, then uses the same decisions to review the generated content.
A good prompt describes a job
A topic is not a job. "Write about onboarding" names an area, but it does not say who needs the content, what they should take away, or what the result should look like.
A useful prompt gives the work a boundary. It tells the creator:
- who the content is for;
- what should change for that audience;
- which material can be trusted;
- what form the result should take; and
- what must be true before the draft is ready to use.
Longer prompts do not automatically create better content. Extra adjectives can hide an unresolved decision. A compact brief with the right decisions gives the generation step something useful to follow.
How to write a good prompt with six decisions
Use these six decisions before asking for a draft:
| Decision | Question | What it gives the draft |
|---|---|---|
| Intent | What should change for the audience? | A reason for the content to exist |
| Sources | What material is reliable? | An evidence boundary |
| Context | Who is reading and what do they already know? | The right level of explanation |
| Format | Which form fits the job? | A visible structure and reading order |
| Constraints | What should the draft include or avoid? | A controlled scope |
| Done | What must be true at the finish line? | A review contract |
The decisions do not need to become six paragraphs in the final prompt. They can stay as short answers in a brief, a template, or a guided form. Their value is making the missing choices visible before generation begins.
Define the change the reader should make
Start with the outcome, not the content type. Write one sentence that names the audience, the intended change, and the task boundary.
For example:
> Help a product team decide which three onboarding interactions to test first, using the current flow notes and keeping the recommendation practical for a one-week study.
This is more useful than "Write a guide about onboarding UX." It gives the draft a reader, a decision, a source boundary, and a limit. It also gives you a way to reject interesting details that do not help the team make the decision.
If you cannot state the intended change, pause before generation. The prompt is not ready yet. A focused question such as "What should the reader do after reading this?" may be more useful than another instruction about tone.
Set the source boundary
Generated content becomes hard to trust when the source boundary is implicit. Separate what the draft may use from what it must not invent.
Name the material that is authoritative for this task:
- a product brief, research note, or meeting transcript;
- a link or document supplied by the team;
- an image, screenshot, or table that contains the relevant detail; and
- the claims that still need external support or human judgment.
Then mark the gaps. If a date, number, customer statement, or conclusion is uncertain, turn it into a question or a visible placeholder. Do not ask the model to "fill in anything missing" when the missing detail changes the meaning of the result.
A good prompt can be explicit about uncertainty: "Use only the supplied notes for factual claims. Flag any missing evidence instead of guessing." That one constraint often protects the draft better than a long request for authoritative language.
Name the audience and context
The same source material can produce very different content for a new user, an executive, a researcher, or a customer. State what the reader knows and what they need next.
Useful context includes:
- the reader’s role and starting knowledge;
- the decision, task, or question in front of them;
- the channel where the content will be read;
- the level of detail the reader can handle; and
- any terms that need a plain-language explanation.
When the content will be read on a phone, context also includes interruption. A mobile reader may return to the page later, scan headings first, or need the next action visible without a long preamble. The format and review contract should account for that reality.
Choose the output format
The format is part of the prompt because it determines what information stays visible and what can be left out. Choose the lightest form that can do the job.
| If the reader needs to… | Consider… | The format should make visible… |
|---|---|---|
| Follow a process | Step-by-step guide | Order, prerequisites, checkpoints, and failure points |
| Compare options | Comparison infographic | Criteria, contrasts, and the decision boundary |
| Remember one argument | Carousel | A clear sequence and one takeaway per frame |
| Return to a reference | Web page | Navigation, context, and durable supporting detail |
| Understand movement or change | Short video | Pacing, scenes, and the role of spoken and visual information |
"Make it engaging" is not a format. "Create a five-frame carousel for first-time managers, with one decision per frame and a final checklist" is a format boundary that a draft can follow.
FormaLM uses this format-led approach in its creation flow. A user can start with an idea or source material, choose a template and output format, answer focused questions, and receive a structured Prompt Card before the content is generated. The workflow makes the decisions that shape the prompt easier to complete.
Add constraints and a definition of done
Constraints are most useful when they protect the job. They should tell the draft what to include, what to avoid, and what the reader must be able to do afterward.
Examples include:
- keep the recommendation within the supplied evidence;
- use headings that let a reader scan the result on a phone;
- include one concrete example for each major step;
- separate confirmed behavior from an assumption or proposal; and
- end with the next action the named audience can take.
Then write the finish line. "Make it good" is an impression. "A reader can choose the next test, see the evidence behind it, and understand the remaining uncertainty" is a reviewable condition.
The definition of done should match the risk of the content. A private idea card can stay lightweight. A public claim about a product, financial decision, health topic, or security practice needs a stricter evidence and review contract.
Leave room for focused questions
Do not force a prompt to pretend that every decision is already known. Good workflows ask only the questions that change the structure, evidence, or finish line.
A focused question has a reason:
- Identify the missing choice.
- Explain why the choice affects the result.
- Ask for the smallest answer that resolves it.
For a product update, "Which launch risk should the reader act on this week?" is more useful than "Can you provide more context?" For a guide, "What is the observable finish state?" is more useful than "Make it detailed."
This is the practical difference between a blank prompt box and a guided creation flow. The user can answer what they know, attach the material already available, and let the remaining questions reveal themselves instead of rebuilding the entire prompt.
Why generated content still needs a review contract
A clear prompt improves the starting point, but it does not make the result automatically correct. The generated content still has to be checked against the original job.
Review the result for two different failures:
- generation failure: the draft misunderstood the request, dropped a source detail, or invented a claim; and
- format failure: the information may be accurate, but the chosen form makes it difficult to scan, compare, follow, or reuse.
Keeping these failures separate makes revision more precise. If the facts are right but the reading order is wrong, a longer prompt about tone will not fix the problem. The format or completion checklist needs to change.
Review generated content against the original job
Use the six decisions as a compact review contract:
| Review question | Pass signal | If it fails |
|---|---|---|
| Does it serve the named audience? | The reader can act without private context | Rewrite the intent or audience line |
| Does it stay within the sources? | Claims are supported or marked uncertain | Remove guesses and add evidence |
| Is the context sufficient? | Terms and assumptions are understandable | Add only the missing explanation |
| Does the format fit the job? | The reader can scan the intended structure | Change the format or reading order |
| Did it respect the constraints? | Required parts are present and exclusions remain absent | Edit against the checklist |
| Is it finished enough to use? | The next step, conclusion, or handoff is clear | Define the finish line more concretely |
The AI draft readiness checklist adds a deeper seven-part review for task fit, source fidelity, hierarchy, edit burden, and handoff readiness. Use it when the generated result will be shared beyond the person who created it.
A worked example: from product notes to a clear guide
Imagine a product manager has notes from three onboarding sessions. The notes mention a confusing permission step, a missing empty state, and a question about what new users should see after setup.
The vague prompt is:
> Turn these notes into content.
The six decisions make the job concrete:
| Decision | Working answer |
|---|---|
| Intent | Help the product team choose the first three onboarding interactions to test |
| Sources | Three session notes and the current onboarding screenshot; no invented user quote |
| Context | Product team; familiar with the flow but short on research time |
| Format | A step-by-step research guide with a short prioritization table |
| Constraints | Keep the study within one week; separate observed behavior from hypotheses |
| Done | The team can choose tests, see why they matter, and identify what remains unknown |
The generated content now has a job and a shape. It can still be wrong, but the review has something specific to compare against. A reviewer can point to the missing evidence, the wrong priority, or the section that does not help the team act.
When a shorter prompt is the right prompt
Not every task needs a large brief. A short prompt is enough when the audience, source, format, and finish line are already stable.
For example:
> Rewrite this approved release note for a customer email. Keep the three supplied facts, use plain language, and end with the setup link.
The prompt is short because the decisions are already settled. The mistake is not brevity; it is leaving a decision unresolved and hoping the generated content will choose correctly.
Use more structure when the task is ambiguous, the source material is mixed, the audience is unfamiliar, or the output will be reused in another format. Use less when the job is routine and the review contract is already known.
Use the prompt-to-content worksheet
The Prompt-to-Content Brief worksheet turns the six decisions into a small working document. Fill it out for one real content need, keep the answers short, and use the review column after the first draft.
The worksheet is deliberately format-neutral. It can guide a brief, FAQ, guide, infographic, carousel, web page, or video. The point is to clarify the job before the output becomes expensive to revise.
FormaLM follows the same sequence in a product workflow: start with what you know, answer focused questions, let the format define the boundary, and review the generated result before you use or share it. The system builds the prompt from the decisions instead of asking the user to become a prompt specialist first.
A good prompt makes the content job visible. Start with the change the reader needs, protect the source boundary, choose the form that fits, and define what finished means. The generated content is easier to judge because the prompt gave it a job worth finishing.