Patterns / Prompting basics

Few-shot examples

Show two to five worked input/output examples instead of describing the format in prose.

The problem

Describing an output format or a judgement call in words is hard, and the model's interpretation of your description may not match yours. Tone, level of detail and edge-case handling are especially hard to specify in prose.

The pattern

Include a small set of examples that show exactly what you want. Make them:

• Representative: typical cases, in the real format.
• Varied: different enough that the model learns the rule, not the surface details of one example.
• Inclusive of an edge case: show how to handle the awkward input (empty, ambiguous, out of scope).

Put examples in their own tagged block so they are not confused with the real input. If outputs copy an example too literally, add variety or say the examples illustrate the format, not the content.

Template

Convert each changelog line into a user-facing release note.

<examples>
<example>
<input>fix(auth): handle expired refresh token without 500</input>
<output>Fixed: you're no longer logged out with an error when your session expires; we now ask you to sign in again.</output>
</example>
<example>
<input>feat(export): add CSV export to reports page</input>
<output>New: export any report as a CSV file from the Reports page.</output>
</example>
<example>
<input>chore(deps): bump lint config</input>
<output>SKIP</output>
</example>
</examples>

The examples show format and tone; do not reuse their wording.
Internal-only changes (chore, ci, refactor with no visible effect) → SKIP.

<input>{{CHANGELOG_LINE}}</input>

When not to use it

• When a clear instruction or a schema already gets reliable output. Examples cost tokens on every call.
• When you cannot produce good examples yet. Bad or inconsistent examples teach the wrong thing more effectively than no examples.