> ## Documentation Index
> Fetch the complete documentation index at: https://help.pantaos.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Prompting Basics
> The five fundamentals every prompt should satisfy: clarity, context, specificity, format, and constraints.
## The Five Fundamentals
Almost every prompting failure traces back to one of five missing elements. A prompt that satisfies all five is rarely brilliant, but it is almost never a disaster. Treat this list as a checklist before you ship any prompt to production, including the system prompts behind your PANTA OS assistants.
The model should know exactly what it is being asked to do, in one reading, without inference.
The model should have the background it needs to perform the task: who the audience is, what came before, what to assume.
The output should be defined by attributes, not adjectives. Length, structure, level of detail, voice.
The shape of the response should be specified upfront: prose, JSON, table, bullet list, XML envelope.
The boundaries should be explicit: what to include, what to exclude, when to refuse, when to ask.
Two or three examples make the contract concrete and resolve most edge cases without further instructions.
## Clarity
The single most reliable improvement to any prompt is to read it aloud and ask whether a competent stranger could execute the task from the words alone. If the answer is no, the model will not do better.
Clarity has three components: the task is named, the inputs are labeled, and the success criterion is explicit. If a colleague with no context reads the prompt and is confused, the model will be too.
```text theme={"theme":"github-dark"}
Bad
Summarize this.
Better
Summarize the article below in three sentences for a non technical reader. The summary
should answer: what is the main claim, what evidence supports it, and what is the
strongest counterargument?
Article:
{article}
```
The improved version names the task (summarize), labels the input (the article), and gives the success criterion (three sentences, three specific questions answered).
## Context
Models do not know who is asking, what the broader project is, or what the deliverable will be used for. Anything that affects how the task should be performed has to be in the prompt or in a system message. The relevant categories of context:
* **Audience.** A summary for a board reads differently from a summary for an engineer. Name the reader.
* **Purpose.** Will the output be published, used in a meeting, fed into another prompt, archived? The destination shapes the voice and length.
* **Prior decisions.** If you have already decided that the output should be in German, or should avoid a certain term, or should follow a house style guide, say so.
* **Domain.** If the task is in a specialized domain, say so plainly. "You are reviewing a medical device regulatory filing" is better than letting the model guess from the input.
Context is what separates generic output from output that fits your specific situation. It is also where most prompts are weakest, because the writer holds the context implicitly and forgets to state it. In PANTA OS, the system prompt of an assistant is the right place for stable context, while user messages should carry the situational context for that specific request.
## Specificity
Adjectives are dangerous in prompts. "Make it engaging" and "make it professional" mean different things to different people, and the model will pick the most generic interpretation. Replace adjectives with attributes wherever possible.
```text theme={"theme":"github-dark"}
Vague
Write an engaging product description.
Specific
Write a 90 to 120 word product description in second person, addressing the reader as
"you". Open with a concrete benefit, not a feature. Use one short sentence and two
medium sentences. Avoid the words innovative, revolutionary, and seamless.
```
The specific version replaces "engaging" with seven measurable attributes. The output will be much more consistent across runs, which matters when you are generating descriptions at scale.
## Format
Telling the model what shape the response should take is one of the cheapest improvements available. It costs almost no tokens and removes a category of post processing failures.
The most useful format directives are:
* **Length.** Word count, sentence count, or paragraph count. Models are imprecise at exact counts but reliable at orders of magnitude.
* **Structure.** Headings, bullet points, numbered lists, or flowing prose. Specify which.
* **Output container.** Raw text, JSON, XML, Markdown, code in a fenced block. If the output will be parsed, specify the schema.
* **What to omit.** "Do not include a preamble or explanation, only the JSON object" is a common and effective directive.
For machine readable output, define the schema in the prompt and ask the model to validate against it. The structured output features in modern model APIs make this even more reliable, but a schema in the prompt remains a good practice.
## Constraints
Constraints are the rules the output must obey beyond the task itself. They are easiest to think about as four buckets:
1. **Inclusion.** What must be in the output. "Always include the source URL." "Always include a confidence score from 1 to 5."
2. **Exclusion.** What must not be in the output. "Do not invent statistics." "Do not name specific people."
3. **Refusal.** When the model should decline. "If the input does not contain a valid invoice number, return an empty object."
4. **Escalation.** When the model should ask for clarification or hand off. "If the user request is ambiguous, ask one clarifying question before proceeding."
Phrase constraints positively where possible. "Respond only in formal English" produces more reliable output than "Do not be informal." The model can act on a positive instruction; a negative one requires it to first imagine the forbidden behavior, which sometimes produces exactly that behavior.
## A Minimal Complete Prompt
Putting the five fundamentals together produces a prompt that looks like this:
```text theme={"theme":"github-dark"}
You are a regulatory affairs analyst reviewing FDA submissions.
Task
Review the document below and identify any claims that lack a cited study.
Output format
Return a JSON object with a single key "unsupported_claims" containing an array of
objects. Each object has the keys "claim" (verbatim quote), "page" (integer), and
"reason" (one sentence).
Constraints
- Quote claims word for word; do not paraphrase.
- If the document contains no unsupported claims, return an empty array.
- Do not include claims that are merely opinions or forward looking statements.
Document:
{document}
```
This prompt is unambiguous, contains the necessary context, specifies the format precisely, and sets clear constraints. It does not need to be longer to be effective; in many cases, longer is worse.
## What Comes Next
The fundamentals get you to a reliable baseline. The next page, Prompting Techniques, introduces the named methods that build on these fundamentals: zero shot, few shot, chain of thought, role prompting, prefilling, and chaining.
Iteration is part of the workflow. Write a first draft, test it on five to ten realistic inputs, and refine based on the failures. Most production prompts go through three or four revisions before they are stable, and the same is true for the system prompts that drive PANTA OS assistants.