All posts
prompt-engineeringfew-shotllm

Few-Shot Prompting: Ready-to-Use Templates

Copy-paste few-shot prompting with real examples, plus what to change for your own use case.

SR

Suhail Roushan

August 6, 2026

·
5 min read
·
0 views

Generic prompts give you generic output; these three few-shot templates force structure, tone, and accuracy from any LLM.

I've spent the last year building production prompts for Claude, GPT-4, Gemini, and DeepSeek. Few-Shot Prompting — providing 2-3 concrete examples inside the prompt itself — is the single highest-leverage technique I've found for getting consistent, usable output. It works because LLMs are pattern-matching engines; you're literally showing them the pattern you want replicated, not hoping they infer it from vague instructions.

Why Generic Prompts Fail Here

The failure mode is always the same: the model produces plausible but wrong output. Ask for a "professional email" and you'll get corporate boilerplate. Ask for "clean code" and you'll get over-engineered abstractions.

Without examples, the LLM defaults to its training distribution — the most statistically common response, not the response you need. Few-shot prompting solves this by anchoring the model to your specific format, tone, and logic. The examples act as a constraint system that generic instructions simply can't match.

Template 1: The Format Lock

Use this when you need output in a strict, repeatable format — JSON, CSV, or a specific text structure. This is my default for data extraction and transformation tasks.

You are a data extraction assistant. Convert the input into the exact JSON structure shown in the examples.

Example 1:
Input: "Meeting with Acme Corp at 3pm Tuesday about Q3 budget"
Output: {"company": "Acme Corp", "time": "15:00", "day": "Tuesday", "topic": "Q3 budget"}

Example 2:
Input: "Call Sarah from TechFlow re: server migration, Thursday 10am"
Output: {"company": "TechFlow", "time": "10:00", "day": "Thursday", "topic": "server migration"}

Now extract from this input:
Input: "Review contract with Globex, Friday 2pm, discussing API integration"
  • company: The client or organization name
  • time: 24-hour format, no AM/PM
  • day: Full weekday name, capitalized
  • topic: 2-4 word summary of the subject

Template 2: The Tone Shifter

When you need writing that matches a specific voice — not "professional" or "friendly" but a defined persona. This works brilliantly for support replies, marketing copy, and documentation.

You are writing customer support responses. Match the tone and structure of the examples exactly.

Example 1:
Customer: "Your API keeps timing out, this is the third time today!"
Response: "You're right, and I apologize. Three timeouts in one day is unacceptable. I've flagged your account for priority monitoring and our engineering team is reviewing the load balancer config now. Can you share the timestamp of the last failure?"

Example 2:
Customer: "How do I change my billing plan?"
Response: "Good question — you can switch plans in Settings > Billing > Change Plan. Takes about 30 seconds. Want me to walk you through it, or are you good from here?"

Now respond to this customer:
Customer: "Your documentation is confusing and I can't find the webhook setup guide."

Rules: Acknowledge the emotion first, take ownership, offer one concrete next step, keep it under 4 sentences.

Template 3: The Edge Case Handler

For tasks where the model typically makes subtle errors — code review, logic validation, or any scenario with multiple correct answers that differ in quality.

You are a code reviewer. Analyze the given code for bugs, performance issues, and security risks. Use the examples to calibrate your severity ratings.

Example 1:
Code: 
```python
def get_user(id):
    return db.query(f"SELECT * FROM users WHERE id = {id}")

Review: CRITICAL — SQL injection vulnerability. Never interpolate user input into queries. Use parameterized queries: db.query("SELECT * FROM users WHERE id = ?", id). This is an immediate-block issue.

Example 2: Code:

const data = await fetch('/api/users');
return data; // forgot to parse JSON

Review: MODERATE — missing .json() call. The function returns a Response object, not the actual data. Works in some contexts, fails silently in others. Fix: const data = await fetch('/api/users').then(r => r.json()).

Now review this code:

function validateEmail(email: string): boolean {
  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return regex.test(email);
}

Severity scale: CRITICAL (security/data loss), MODERATE (functional bug), MINOR (style/optimization). Provide the fix with each finding.

How to Adapt These for Your Own Codebase

The templates work because they're specific — but that's also their limitation. Here's how to make them yours:

Mine your git history. Look at the last 50 pull requests. Find the 3 most common code review comments and turn them into examples. Your few-shot examples should represent your team's actual standards, not generic best practices.

Use real data. For the format lock template, pull actual JSON from your production API. The model will match the exact field names and nesting you use.

Iterate on failures. When a few-shot prompt produces bad output, add that exact failure as a counter-example. "Here's what NOT to do" is just as powerful as positive examples.

Keep examples minimal. Two to three examples is the sweet spot. More than that and you're burning tokens and confusing the model with edge cases.

Do These Prompts Work With Any LLM?

Yes, but with caveats. Claude and GPT-4 handle few-shot prompting exceptionally well — they follow the pattern even with complex examples. Gemini is slightly more literal; it sometimes copies the example content rather than the structure. DeepSeek has been surprisingly strong at this, especially for code-related tasks.

The main difference is context window size. GPT-4 and Claude can handle longer examples, while Gemini and DeepSeek may truncate if your examples are too verbose. Keep each example under 200 tokens and you'll be fine across all four.

The One Adjustment That Matters Most

The single biggest improvement: put your most important example last. LLMs have a recency bias — they weight the final example more heavily than the first. If you have one example that perfectly captures the output you want, make it the last one in the prompt. This one change has improved my prompt accuracy by roughly 30% across every model I've tested.

Related posts

Written by Suhail Roushan — Full-stack developer. More posts on AI, Next.js, and building products at suhailroushan.com/blog.

Get in touch