Describing what you want is good. Showing what you want is better. One to three examples inside the prompt – called "few-shot" – often work better than any additional rule, because models copy patterns from examples more precisely than from descriptions.
Few-shot in practice
Turn bullet notes into commit messages (Conventional Commits). Example 1: Input: login button does not react to enter Output: fix(auth): trigger login on Enter key Example 2: Input: documented new endpoints for tags Output: docs(api): document tag endpoints Input: [your notes] Output:
The examples implicitly define all sorts of things: output language, prefix conventions, length, tone. Choose them deliberately – the model also imitates what you did not mean to say. A sloppy example produces sloppy output.
Show the edge cases
The most valuable examples are not the typical ones but the difficult ones: what should happen when the input is empty? When information is missing? One example with "Input: (unreadable) → Output: ERROR: input unreadable" saves you three paragraphs of special-case rules.
Enforcing formats
For machine-readable output (JSON, CSV): show the structure once as an example and state it as a rule ("Answer exclusively with valid JSON, no Markdown fences"). Both signals together are far more reliable than either alone. You'll find good reference examples under Extraction & Parsing.