Prompt engineering starts with a task you can check

“Give me the best answer” does not tell an assistant what success means. “Extract the event title, day, and location from this note; use null for missing values” does. The second request gives you something to inspect.

Consider a note saying, “The reading club meets Saturday; the venue is undecided.” A useful extraction contains the title, Saturday, and a missing location. A JSON object naming a library may look neatly structured while adding an unsupported fact.

This illustrates two separate checks. First, can software parse the response and find the expected fields? Second, do the values match the source? Passing one does not establish the other. A response can be syntactically perfect and factually wrong.

Examples can help explain the desired behavior. Include a complete case and a missing-information case so the format does not accidentally imply that every field must be filled. If the task has ambiguous boundaries, show how ambiguity should be handled. Avoid teaching a shortcut such as classifying every message containing “book” as a materials question: “How do I book a session?” means something different.

Then evaluate the prompt on cases you did not use to construct it. Save the actual outputs, including failures. A revised prompt should earn its place by improving the intended behavior, not simply by sounding more elaborate.

You can learn this process before paying for any model. Our fixed-output lab makes the evaluation logic visible without pretending to run an LLM. An optional local-model adapter can generate real outputs later, when a compatible model is available on your machine.

LLMs: From Prompts to Practice ends with a prompt portfolio containing three tasks, test cases, scoring rules, and a revision log. The result is a record of what you tested and learned, not a collection of supposedly universal magic phrases.