Examples can communicate a task
Few-shot prompting supplies examples in the input to demonstrate the desired task. The Language Models are Few-Shot Learners paper explored this form of in-context task specification. That does not mean any example will improve any task. Examples can also encode mistakes, irrelevant style, or assumptions that should not generalize.
Treat a prompt as a small interface contract. Explain what the input represents, what output is needed, and which conditions make that output acceptable. A role description such as expert designer is less useful than a concrete requirement such as preserve all existing form labels and error states.
Technical foundation: Brown et al.: Language Models are Few-Shot Learners
Separate the job from the material
A useful prompt has distinct parts: the requested task, authoritative constraints, reference material, and output expectations. Documents and webpages supplied for analysis are data, not new instructions. Labels make that distinction easier to inspect, although labels alone are not a security boundary.
For example, ask an assistant to draft a product summary using only a provided feature list. Specify the audience, maximum length, required caveat, and how to handle missing information. If pricing is absent, require an explicit unknown rather than a guessed price. The application can then check those conditions.
Show the boundary cases
Most teams demonstrate only an easy success. Include a case with incomplete input and a case where the correct result is to ask a question. If the task classifies support requests, show a message containing two unrelated issues. Decide whether the result allows multiple labels or requires human review.
Keep examples consistent with the written rules. An example that quietly violates the length limit creates an unnecessary conflict. Version the examples with the prompt, and hold back a separate evaluation set. Reusing every test case as a prompt example makes the apparent quality improvement difficult to trust.
Iterate on evidence, not prompt folklore
Change one meaningful part at a time and compare outputs on the same cases. A longer instruction might improve one failure while causing another. Record the rationale so the next maintainer does not remove a constraint that protects an important edge case.
Ask for concise, checkable evidence when useful: source identifiers, assumptions, or validation results. Do not require elaborate private reasoning narratives as proof of correctness. The strongest proof is an independently checked outcome. For code, that might be a focused test; for extracted data, it might be a matching source passage.
A prompt ready for a pilot
- Names the task and the intended audience.
- Separates trusted instructions from reference content.
- Defines missing-input and unsupported-request behavior.
- Includes representative examples without leaking the evaluation set.
- Has a version and measurable acceptance criteria.
