Topic: Learning notes

Core Prompting Techniques: When Should I Add Examples?

When one instruction isn't enough, should you add rules or examples? Compare standard, zero-shot, one-shot, and few-shot prompts using GitHub issues.

“Organize these GitHub issues for me.”

Quick to type. But does “organize” mean summarize them, add labels, or write a fix plan for each one? Before the actual work begins, we’ve already given the model a guessing assignment.

I’ll use issue triage to work through the Core Prompting Techniques chapter of Sabrina Goldfarb’s Practical Prompt Engineering. What I want to sort out is practical: when one sentence doesn’t cover it, should I spell out the rules or show it an example?

The issues and prompts below are original examples. Expected labels follow the rules in this article; they haven’t been tested with a model. Course and research sources are linked where relevant.

Put the names aside for a moment

A standard prompt describes a direct request; the shot count describes how many task demonstrations it includes. Background material is not automatically a demonstration. Supplying code for debugging can still be zero-shot if you do not show another input paired with its desired output. This distinction follows the course definitions of Standard Prompt and Zero Shot.

Standard prompts: say what you want back

Back to “organize these issues.” If all I need is classification, I can say that directly and specify the response format:

Triage GitHub issues.
Return one label per issue so maintainers can decide what to handle next.
Use only bug, feature, or question.
If there is insufficient information to classify, return needs-info.
Do not write fixes or add requirements.

That’s a clearer assignment: add a label, with a fallback for missing information. But what if one issue reports a bug and asks for a feature? We still need the team’s classification rule for that.

The separate Standard Prompt note covers context and targeted clarification through a subscription-form example. Here, we will continue with demonstrations.

Zero-shot: give it rules without examples

Zero-shot supplies no task demonstrations, but can still include detailed rules. This classification prompt is self-contained:

Classify the issue below. Return exactly one label.
bug: explicitly reports existing behavior that differs from expectations.
feature: requests a capability that is not currently available.
question: asks how to use existing functionality.
needs-info: insufficient information to apply these definitions.
If multiple categories apply, use the priority bug > feature > question.

Issue to classify:
Deleting a card removes it, but it reappears after refreshing the page.

Following these rules, the expected label is bug: deleted data returning after a refresh describes broken existing behavior.

I’d start with this version. If it gets something wrong, I can check for a missing rule, a misunderstood instruction, or an issue that barely explains the problem. If it already works reliably, there’s no rush to add more ingredients to the prompt.

One-shot: here’s one, follow this format

One-shot supplies one demonstration. The course recommends a representative, complete example to establish the pattern.

Keep the classification rules above and append:

Example input: How can I rename a saved prompt?
Example output: question

Issue to classify:
Please add JSON export. Currently I can only view the data on the page.

This time, the expected label is feature. The example shows a user description going in and a single label coming out. Bugs and mixed requests haven’t appeared in the examples yet.

Read your own example first, too. If the instructions say “label only” but the example includes a paragraph of analysis, which one should it follow? Fix that conflict before testing.

Few-shot: bring out the easy-to-miss cases

In this course, few-shot means two or more demonstrations. I’d prioritize cases that are easy to mix up. Five similar bug examples still leave us with zero demonstrations of a mixed request.

Keep the same rules and replace the previous demonstration with:

Input: Saving reports success, but my data disappears after a refresh.
Output: bug

Input: Please add tag filtering, which is not currently available.
Output: feature

Input: How can I delete a saved prompt?
Output: question

Input: Doesn't work.
Output: needs-info

Input: Deleted data reappears. I would also like bulk deletion.
Output: bug

Issue to classify:
Please add dark mode. Also, how can I rename a prompt today?

The new issue combines a feature request and a usage question, so feature > question makes the expected output feature. The demonstrations now cover vague reports like “doesn’t work” and issues asking for two things at once. If the team later allows multiple labels, change the rules and examples together.

The course cites Language Models are Few-Shot Learners, which studied GPT-3 using demonstrations in context without task-specific weight updates. This differs from fine-tuning, and those results do not guarantee that adding examples will improve every modern model.

A quick aside: the course connects its exercises through a prompt-library app. Standard and zero-shot prompts build saving and deletion, one-shot produces a star-rating plan, and few-shot produces an implementation prompt for notes. That distinction is easy to miss: a finished plan still leaves the feature to build. Asking for a plan, a prompt, or an implementation gives us different things to check afterward.

For information placement and long conversations, see the separate Context Placement note. Here, we will keep the focus on rules and demonstrations.

Try a few cases it hasn’t seen yet

After editing a prompt, don’t stop at its lovely answers to the demonstration cases. Hold a few cases back and check them against the same rules. Here are some for a future experiment, with expected labels set manually:

Test zero-shot first, then add one and multiple demonstrations separately. Keep the model version, settings, and test inputs consistent, retain the complete context, and repeat runs. Check policy compliance, whether the response contains exactly one allowed label, and recurring failures. More examples also consume input tokens, so record cost and latency alongside quality.

When comparing shot counts, keep the classification policy fixed and change the demonstrations. Change the rules and test cases at the same time, and even a correct answer won’t tell you which change helped.

References and scope

• Sabrina Goldfarb, Practical Prompt Engineering for Developers. This note covers standard prompts and the three shot settings; context placement has its own article. The site lists its content under CC BY-NC 4.0 and code samples and exercises under Apache 2.0.
• Brown et al., Language Models are Few-Shot Learners: research background on in-context demonstrations and GPT-3.

Sources checked on 2026-10-16. This is a concept summary with original examples, not a verbatim translation. Advanced Prompting Techniques are outside its scope. No issue-classification model tests were run; the expected labels are not evidence of improved quality.