How to write a good prompt: give the model a role, state the task in one sentence, add context and input data, and specify the output format and constraints; add an example if format matters. A good prompt answers the questions of a brief for a colleague: what to do, with which data, for whom and in what shape.
This guide covers the parts of a prompt, a step-by-step process, common mistakes and reusable templates. The examples come from the daily work of a site owner or sysadmin rather than from marketing: reviewing HTTP headers, finding the cause of a 502 in an nginx log, writing a robots.txt rule, and explaining dig and openssl output. Technical tasks make the difference between asking a question and assigning a task very easy to see.
What makes a good prompt?
A prompt is everything a language model receives before it starts answering: your question, any pasted data, instructions and, in a chat interface, the earlier messages of the conversation. The model continues that text in the way it judges most fitting. The practical consequence is simple: the model only knows what is in the prompt, what it learned in training, and what its connected tools (web search, file reading, where the product supports them) can fetch.
It does not see your server, your nginx config or your current DNS records. Ask "why am I getting a 502?" and you get the textbook list of causes. Paste the last lines of error.log and you get an analysis of your case. Most of the quality gap between prompts comes from how much relevant information reached the model, not from clever wording.
The model can also be confidently wrong: it may invent a command flag or a config directive that does not exist. A good technical prompt therefore asks the model to separate what the data shows from what it assumes, and every answer gets verified on the real system.
The parts of a good prompt
| Part | What goes in it | Sysadmin example |
|---|---|---|
| Role | The point of view and level of detail | "You are an experienced Linux and nginx administrator" |
| Task | One action, starting with a verb | "Find the most likely cause of the 502 errors" |
| Context | Environment, versions, what you already tried, why you need it | "Ubuntu 22.04, nginx proxies to PHP-FPM over a unix socket, started after a PHP upgrade" |
| Input data | The real material, kept apart from the instructions | The last 30 lines of error.log inside delimiters |
| Output format | Structure, length, language, what comes at the end | "Answer as a list: cause, log line as evidence, command to confirm, fix" |
| Constraints | What not to do and how to behave when data is missing | "Do not suggest rebooting. If the data is insufficient, tell me what output to send" |
A seventh part, an example of the desired output, often does more than a paragraph describing the format: the model copies its structure, tone and length. Not every prompt needs all of this. "What does status 301 mean?" is fine as a single sentence. The harder the task and the higher the cost of a wrong answer, the more parts you fill in.
How to write a prompt, step by step
- Decide what the output is before you write. A command, a config file, a ranked list of causes, an email? If you cannot describe the result in one sentence, split the task.
- Lead with the task, not the backstory. Start with a verb: "Write", "Find", "Explain", "Compare". Context comes next.
- Give data, not a summary of it. "Some upstream errors in the log" loses exactly the details a diagnosis depends on. Paste the lines.
- Separate data from instructions. Wrap logs and command output in triple quotes, a code block or tags such as
<log>...</log>, so a line of log text is never read as an instruction. - Specify the format. A table, a numbered list, a complete file, no more than N items. Models follow explicit limits far more reliably than they guess them.
- Say what to do under uncertainty. "If the information is not enough, ask me questions instead of guessing" is the most useful single line in a technical prompt.
- Ask for evidence where you need to verify. "For each conclusion, quote the line of input it is based on" separates findings from filler.
- Reread it as an outsider. Would a colleague who has never seen your server understand the request? If not, the model will not either.
What is an example of a good prompt?
Four common site-owner tasks show the pattern. The weak version still gets an answer, but it is a generic one.
| Task | Weak prompt | Strong prompt | What changed |
|---|---|---|---|
| HTTP headers | "What headers should my site have?" | Pasted curl -sI output, task: find missing security headers and caching problems, answer as a table | Real data and a format |
| 502 error | "Why does nginx return 502?" | Environment, when it started, 30 lines of error.log, no guesses without log evidence | Context and constraints |
| robots.txt | "Write a robots.txt for my site" | Which URLs to block and keep, the current file, a line-by-line explanation | A verifiable, narrow task |
| dig and openssl | "What does this output mean?" | The output, the actual question behind it, the level of explanation | The model knows what to look for |
Reviewing HTTP headers
Get the real headers first. On Linux and macOS, and on Windows 10 or later, where the binary is curl.exe:
curl -sI https://example.com
curl.exe -sI https://example.comWeak: "Check the headers of example.com." Without web access the model cannot fetch them and will either refuse or describe a typical set. Strong:
You are a web application security specialist.
Task: review the HTTP response headers of an online store's home page.
Context: nginx, customer accounts and a checkout form.
Headers are between the triple quotes.
"""
(paste curl -sI output)
"""
Answer as a table: header | present? | risk if missing | nginx config line.
Then add notes on Cache-Control for an HTML page.
Where a header has no single correct value, say so instead of choosing for me.The last line matters: headers such as Content-Security-Policy have no universally correct value, and a "standard" one picked by the model can break the site's scripts.
Finding the cause of a 502 in an nginx log
A 502 means nginx did not get a valid response from the upstream. The error log almost always names the reason, so the data matters more than the wording:
sudo tail -n 50 /var/log/nginx/error.log
sudo awk '$9 == 502' /var/log/nginx/access.log | tail -n 20The second command assumes the default combined log format, where the status code is the ninth field; a custom log_format moves it.
You are a Linux administrator experienced with nginx and PHP-FPM.
Task: identify the most likely cause of the 502 errors.
Environment: Ubuntu 22.04, nginx proxies to PHP-FPM over a unix socket.
It started today after a PHP upgrade.
Client IPs are masked as x.x.x.x.
<log>
(paste error.log lines)
</log>
Format: 1) cause; 2) the log line that points to it;
3) a command to confirm; 4) the fix.
Do not suggest rebooting the server as a fix.
If the log is not enough, list the output you need from me.With real lines the model can work from messages such as connect() to unix:/run/php/php8.1-fpm.sock failed (2: No such file or directory), which typically means the socket name changed with the PHP version while nginx still points at the old path, or upstream prematurely closed connection while reading response header from upstream. The full troubleshooting order is in 502 Bad Gateway: what it means and how to fix it.
Writing a robots.txt rule
A model mistake here is expensive: one stray Disallow: / blocks the whole site. Make the prompt specific and ask for a line-by-line explanation:
Task: extend an online store's robots.txt.
Block crawling of: internal search /search/, URLs with the ?sort= parameter, the cart /cart/.
Keep crawlable: the whole /catalog/, including ?page= pagination.
Current file:
"""
User-agent: *
Disallow: /admin/
Sitemap: https://example.com/sitemap.xml
"""
Return the complete file, then explain every new line and list any URLs
from my description that your rules will NOT affect.A reasonable answer looks like this. Check it against the syntax rules before publishing:
User-agent: *
Disallow: /admin/
Disallow: /search/
Disallow: /cart/
Disallow: /*?sort=
Disallow: /*&sort=
Sitemap: https://example.com/sitemap.xmlThen test the file in the robots.txt report in Google Search Console. The syntax and common traps are covered in robots.txt: syntax, examples and how to test it.
Explaining dig and openssl output
dig example.com MX +short
dig example.com TXT +short
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -datesOn Windows, use nslookup -type=mx example.com or, in PowerShell, Resolve-DnsName example.com -Type MX.
I run a website and I am not a network engineer. Email from our domain lands in spam.
Below is dig output for MX and TXT and openssl output for the site certificate.
"""
(command output)
"""
Task: explain in plain language what this data shows and whether the TXT
records include SPF and DMARC. If something is missing for a conclusion
about spam, tell me which command to run next.
Assess the certificate separately: who issued it and when it expires.The prompt sets the level of explanation, the real goal, and gives explicit permission to say "not enough data". Without that permission a model tends to produce a conclusion even when there is nothing to base it on.
How to improve a prompt that is not working
- Too generic: add data and context, not adjectives like "detailed" or "expert".
- Wrong format: show a sample and say "format it like this".
- Invented facts: require a quoted source line for each claim and allow "I don't know".
- Too long: set a hard limit, such as "max 5 items" or "command only, no explanation".
- Too big: split it across messages: diagnosis first, then the fix, then verification.
You can also ask the model to critique the prompt: "Here is my prompt. What information is missing for you to answer precisely? Ask me." Once a prompt works, save it as a template and swap only the data next time.
Common prompt mistakes
- A question instead of a task: "What can I do with my site?" has no good answer.
- Several tasks in one sentence: "Check the config, optimize it and document it" gets three shallow answers.
- Contradictory constraints: "short but with every detail" forces the model to choose for you.
- Expecting live knowledge: without tools, the model cannot see your site, current DNS or certificate dates.
- Applying output blindly: a config from a chat is a draft. For nginx, run
sudo nginx -tbeforesudo systemctl reload nginx.
What never to paste into a prompt
Anything you send to a cloud chat leaves your environment and is stored by a third party. Before pasting logs or configs, remove passwords, API keys, tokens and database connection strings (.env contents); never paste TLS or SSH private keys; strip personal data such as emails, phone numbers and visitor IP addresses. IPs can be masked in one pass:
sed -E 's/([0-9]{1,3}\.){3}[0-9]{1,3}/x.x.x.x/g' error.log > error-masked.logAlso check the service's data settings: many chat products have a setting that controls whether your conversations may be used to improve their models. If you call a model through an API, the key is a secret too; see the guide to AI API keys.
Prompt templates
Role: you are a [Linux administrator / SEO specialist / PHP developer].
Task: [one action, starting with a verb].
Context: [environment, versions, what you tried, when it started].
Data:
"""
[log, command output, config - no secrets]
"""
Output: [table / list / complete file / max N items].
Constraints: [what not to do]. If data is missing, ask; do not guess.
For each conclusion, cite the line of data it is based on.For image generators the parts differ: describe the subject, setting, style or type of shot, lighting, angle and composition, plus aspect ratio if the tool supports it. Parameter syntax varies between generators, so check the tool's own documentation.
How to check what the model told you
Treat every technical answer as a hypothesis until the real system confirms it: collect fresh data, give it to the model, apply the change, collect the data again and compare.
- Response headers and page availability: the HTTP header check, whose output you can paste into a prompt instead of
curl -sI. - DNS records before and after a change: the DNS lookup.
- The certificate, its chain and expiry: the SSL check.
If you want an assistant to run such checks itself instead of waiting for pasted output, see how to give Claude and Cursor site diagnostic tools. The model vendors' own guides are the best primary sources on prompting: Anthropic and OpenAI.
Frequently asked questions
What are the 5 P's of effective prompting?
It is a mnemonic, not a standard, and different authors fill the five letters with different words. What they share maps onto the parts above: a clear purpose, relevant context, a defined output, and constraints. If a checklist helps you, use it; the table in this guide covers the same ground.
How long should a prompt be?
Long enough to hold what the task needs and nothing else. One sentence for a simple question; task, context and a few dozen log lines for a diagnosis. The data sets the length, not polite preambles.
Does "you are an expert" actually help?
A role helps when it sets a level or angle, such as "explain it as an admin would to a beginner". The label alone adds no knowledge; data and format have a bigger effect.
Can the model read my website if I give it a link?
It depends on the product: some fetch pages, others work only with the text you send. How AI bots fetch and process pages is covered in how AI crawlers read your site. For a precise answer, paste the relevant part yourself.
How do I start a writing prompt, and what is an example?
In creative writing, a "writing prompt" means something else: a short starter for a story or essay, for example "Write about a day when the internet stopped working in your town". Start it with a situation and a constraint (length, point of view). For AI prompts, start with the task verb, as described above.
Why does the same prompt give different answers?
Generation is probabilistic: the model picks the continuation anew each time. That is one more reason to ask for a fixed format and quoted evidence, which make different answers easy to compare.
