Prompt engineering that works
Most bad AI answers are bad prompts: missing context, no examples, no definition of done. A working prompt has four parts — role and context, the task in one sentence, two or three input-output examples, and hard constraints (format, length, what is forbidden).
Iterate like code: change one thing, rerun the same three test prompts, keep what scores better. Vague prompts («write about testing») lose to specific ones («write a 5-step checklist for API testing beginners, each step one sentence») every single time.
Shapes that work
Three shapes cover most needs. Instruction style («you are a senior QA
engineer, review this checklist») sets tone and strictness. Few-shot
style shows two solved examples and asks for the third in the same
shape — the most reliable way to fix output format. Decomposition
style («first list the risks, then write cases for each») forces
multi-step work instead of a one-shot guess.
Pick the shape by failure mode: wrong tone means weak instruction,
wrong format means missing examples, shallow answers mean no
decomposition.
Know the limits
Prompting cannot inject knowledge the model lacks: version numbers, internal APIs and yesterday news will be hallucinated no matter how elegant the wording. For facts, attach sources or use RAG; for repeatable team behavior, write a skill. Prompts steer reasoning, they do not create knowledge.
| Writing skills for AI assistants | |
| Creating and developing agents | |
| RAG: answers from your own documents |