AI Prompt Engineering: A Practical Guide
If you use ChatGPT, Claude, Cursor, or any other LLM daily, you already know the difference between a vague ask and a sharp one. One gets you a polite essay. The other gets you something you can paste into a terminal, a ticket, or a GlassPad draft and keep moving.
Prompt engineering is simply the skill of telling a model what you want with enough clarity, context, and constraints that the answer is usable on the first or second try. It is not magic wording — it is structured communication. As someone who spends a lot of time in AI/LLM training and self-learning, this is the workflow I actually use.
Why it matters
Models are powerful, but they are also eager to please. If you leave gaps, they invent. If you stay vague, they hedge. Good prompts reduce:
- Hallucinations — by narrowing the task and demanding sources or uncertainty
- Rework — by specifying format, length, and audience up front
- Cognitive load — by turning “help me with X” into a repeatable checklist
You do not need a PhD. You need a habit: treat the model like a smart junior teammate who needs a clear brief.
Core principles
Most strong prompts share five ingredients. Miss one and quality drops.
1. Clarity
Say exactly what the deliverable is. “Explain Docker” is weak. “Explain Docker networking to a junior sysadmin in 8 bullet points, with one common mistake” is clear.
2. Context
Give the background the model cannot see: OS, stack, error message, audience, goal, constraints. Paste the relevant snippet. Skip the novel.
3. Constraints
Boundaries help. Word limits, “no fluff,” “Sri Lanka travel only,” “must work on Ubuntu 22.04,” “output JSON only” — these stop the model from wandering.
4. Role
A light role (“You are a senior Linux admin reviewing a junior’s bash script”) steers tone and depth. Keep it short; do not over-roleplay.
5. Examples
One or two mini-examples of the desired style beat a paragraph of abstract instructions. This is few-shot prompting in everyday clothes.
If a human coworker would ask “what do you mean?” after your prompt, the model will guess — and guessing is expensive.
Anatomy of a strong prompt
Here is a reusable template I keep in my notes. Copy it, fill the blanks, delete what you do not need.
Role: You are a [expertise] helping a [audience]. Goal: [One sentence — what success looks like] Context: - Stack / environment: […] - What I already tried: […] - Constraints: [time, tools, tone, region, etc.] Task: 1. […] 2. […] 3. […] Output format: - [bullets / numbered steps / table / JSON / markdown] - Length: [e.g. under 200 words] - If unsure, say so explicitly — do not invent facts.
Techniques that actually help
Few-shot prompting
Show one or two examples of input → output. Great for tone, classification, rewriting, or any pattern you want repeated. Keep examples short and representative.
Chain-of-thought (carefully)
For multi-step reasoning (debugging, planning, trade-offs), ask the model to think in steps before the final answer — or ask for a short “reasoning then answer” structure. For simple lookups, skip it; extra reasoning can add noise.
Iterative refinement
First pass: get the structure. Second pass: “Tighten this. Cut fluff. Keep the bash commands. Expand the security note.” Treat prompting like editing a draft with a collaborator, not like casting a single spell.
System vs user prompts
In APIs and many tools, a system message sets lasting rules (persona, safety, format). The user message is the task. Put stable rules in system (“Always reply in markdown. Never invent package names.”) and the variable task in user. In chat UIs without a system field, put the rules at the top of your first message.
Especially for commands, medical/legal topics, and current events — run the commands in a safe environment and double-check facts. Prompt quality reduces errors; it does not eliminate them.
Common mistakes
- One giant vague ask — “Build me a CRM” without audience, features, or stack.
- Hiding the error — describing a bug instead of pasting the traceback.
- No output contract — then complaining the answer is “too long” or “not structured.”
- Overloading the role — ten personas at once confuse more than they help.
- Accepting the first draft — skipping the refinement pass that would have fixed 80% of issues.
- Asking for secrets or credentials — never paste real passwords, API keys, or private customer data into public models.
Worked examples
Three prompts I might actually send — notice how each one packs role, context, constraints, and format.
Nginx reverse proxy returns 502
Weak: “My nginx is broken, fix it.”
Stronger:
Role: You are a senior Linux admin. Goal: Diagnose why my reverse proxy returns 502 Bad Gateway. Context: - Ubuntu 22.04, nginx 1.18, Node app on 127.0.0.1:3000 - proxy_pass http://127.0.0.1:3000; - curl localhost:3000 works; curl through nginx returns 502 - error.log: "connect() failed (111: Connection refused)" Task: 1. List the top 5 likely causes, ranked. 2. Give exact commands to verify each (safe, read-only first). 3. Propose the most likely fix with a minimal config diff. Constraints: Do not invent log lines. If something needs more info, ask one focused question.
Three days in Kuala Lumpur (realistic pace)
As a travel consultant, I care about pace, transit, and food — not a laundry list of every attraction.
Role: You are a practical travel planner for Southeast Asia. Goal: A 3-day Kuala Lumpur itinerary for a couple who likes food, skyline views, and light walking — not shopping malls all day. Constraints: - Mid-range budget (not luxury, not backpacker-only) - Avoid packing more than 2 major stops per half-day - Prefer MRT / Grab over taxis when sensible - Flag any ticket that should be booked ahead - Include one rainy-day backup per day Output: - Day-by-day morning / afternoon / evening - Approximate time + how to get there - One signature meal suggestion per day (dish + area) - End with a short packing note for tropical weather
GlassPad-style feature outline
When I sketch docs or landing copy for something like GlassPad, I want structure first — not marketing fluff.
Role: You are a technical writer for indie SaaS products. Goal: Draft a clear outline for a help article: "Exporting from GlassPad to PDF and Word". Context: - GlassPad is a free browser word processor with a glass UI - Privacy-first: documents stay on-device; no signup required - Users need: how to export, what formats, limitations, troubleshooting Task: 1. Propose an H2/H3 outline (max 8 sections). 2. Under each H2, add 1–2 bullet points of what the section should cover. 3. Suggest a short intro paragraph (under 60 words) that leads with the user benefit. Constraints: - Friendly, precise tone — no hype words like "revolutionary" - Assume the reader is non-technical but comfortable with browsers - Call out privacy as a feature, not a footnote
A simple practice loop
- Write the prompt using the template.
- Run it once without editing mid-stream.
- Score the answer: usable / needs tweak / rewrite.
- Change one thing (format, context, or constraint) and retry.
- Save the winning prompt next to the task type (debug, itinerary, docs).
Over a few weeks you will build a personal prompt library — worth more than any “100 best prompts” list, because it matches your work.
Wrap-up
Prompt engineering is not about secret phrases. It is about briefing well: clear goal, enough context, tight constraints, a light role, and examples when style matters. Start with the template, steal the structure from the examples above, and iterate like you would with a good teammate.
If this was useful, check back on Guides for more practical write-ups — AI, IT, and the self-learning habits that keep both moving.