Few-Shot Examples

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

You want consistent commit summaries from known changes, but readers interpret type and scope differently. The teaching input is ‘Cache queries reject an empty key’. This project’s contract uses fix for bug fixes and cache for the cache module’s scope. Examples demonstrate a format rather than supplying facts for a new task.

Mechanism

Choose a few input-to-output pairs that expose meaningful differences and state their rules. A feature addition and a bug fix show type; different modules show scope. An incomplete counterexample shows when generation needs more information.

Then supply the actual input. Transfer the format and decision rule, not the example’s module or feature. List missing information when the input is incomplete.

Bad example

Summarize 'Cache queries reject an empty key'. Make it sound like a good authentication commit, such as adding token refresh.

Good example

Use this project's commit contract: feat for new features, fix for bug fixes, and the actual module as scope. Examples: Add token refresh → feat(auth): add token refresh; Reject empty email → fix(validation): reject empty email. The counterexample 'Improve stuff' lacks a behavior and module, so request those inputs first.
Actual input: Cache queries reject an empty key. This is a bug fix in the cache module. Output one line. Reuse the example format without copying its feature facts.

Why the change matters

The bad instruction names an example’s topic without identifying which parts should transfer. The improved version presents inputs, outputs and rules together. Readers can connect type, scope and behavior, and recognize when copying a complete example would invent facts.

Observable expectation

The illustrative output is fix(cache): reject empty key. Verify that type follows the bug-fix fact, scope is cache, behavior preserves rejection of an empty key, and neither token refresh nor email appears.

Change the input to ‘Improve stuff’: an acceptable response identifies the missing behavior and module rather than choosing an example at random. This checks how examples express a rule, not measured model success.

Limits

Examples consume context and can encourage over-imitation. Prefer examples covering real distinctions; complex formats may also need explicit constraints or a validator. The sources demonstrate input/output formats and rejected framings. This type/scope contract is a teaching-project choice, not a rule shared by every repository.